Closed spring-projects-issues closed 14 years ago
Juergen Hoeller commented
Ben, could you sort this out ASAP please - in time for the 3.0.4 release in mid July?
Juergen
nebhale commented
Damien,
I'm a bit unsure about what exactly needs to happen here. Any place that spring-build
is distributed it is accompanied by and governed by the license of the project that is distributing it. In this case, it simply shows as a directory and is the build system for Spring and as such is governed by Spring's license. The fact that that directory is linked in with an svn:externals
is an implementation detail that allows for reuse; it doesn't make it a separate project with a separate license file.
In addition, looking over the Spring source code, none of XML and properties files there contain license headers. As the build system for Spring is nothing but XML and properties files, I'm unsure why they need headers when others do not.
Can you clarify the needs and justifications for the changes you've requested? Thanks.
Damien Raude-Morvan commented
Hi Ben,
JFTR, I'm reviewing source code at this URL : https://src.springframework.org/svn/spring-build/trunk/ One first point : I've made a mistake in saying "All files are missing a licence header". In fact, all XML files are missing their copyright header but many Java files have one.
To my point of view Spring Build is an autonomous project : at least, it provide some JAR artifacts (like org.springframework.build.ant or org.springframework.build.osgi) which are reused by others projects (Spring Framework or Spring Security). As Spring Build is also a (pretty big) collection of Ant code snippets, we should consider those XML files as source code of the project.
My expectation are :
Chris Beams commented
To Ben's question about which files should be marked with license headers, here's an interesting snippet from the licensing FAQ for Apache projects
What files in an Apache release do not require a license header?
A file without any degree of creativity in either its literal elements or its structure is not protected by copyright law; therefore, such a file does not require a license header. If in doubt about the extent of the file's creativity, add the license header to the file.
They later mention in this same document the following:
Does this policy apply to projects outside the ASF that use the Apache License?
No. This is strictly an ASF policy. Other projects using the Apache License should still refer to the license's appendix for guidance on applying a header to their source files.
That appendix reads as follows:
APPENDIX: How to apply the Apache License to your work
To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives.
Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
So it appears it's rather ambiguous as to exactly which files should have a header, and that to play it safe, we could follow the ASF's own internal requirements and apply the header to any file "with any degree of creativity in either its literal elements or its structure".
Juergen Hoeller commented
Any status update here? Note that the 3.0.4 release is just around the corner...
Juergen
Damien Raude-Morvan commented
Hi,
Still, no changes in SVN regarding license : https://src.springframework.org/svn/spring-build/trunk/ This is a blocker issue for inclusion of Spring Framework 3.x in Debian (and therefore for depending packages).
Regards,
nebhale commented
The first issue I think is that you're looking at the incorrect location for the bit of spring-build
that Spring uses. The appropriate link for this discussion is: https://src.springframework.org/svn/spring-build/trunk/project-build/
That we've chosen to package the XML that constitutes the build system of the Spring Framework in a different repository does not mean that it is an autonomous project. It means that the best way for us to reuse the content between projects is to put it into a separate repository and link it in using svn-externals
. This is an implementation detail allowing for reuse, not an indication of the autonomy of the of spring-build
.
In addition spring-build is reused across many projects in the SpringSource portfolio and is licensed in different ways depending on the project. Putting any license header on those files would render it unusable in projects licensed differently than the Spring Framework.
Chris Beams commented
Hi Damien,
In addition to responding to Ben's comments above, could you also please explain why this package is being put into Debian?
Of course, we would like to give Debian users the most convenient apt-based access possible, but is this strictly about convenience? Or is it, for example, that another Debian package, perhaps a server runtime or other application depends on Spring, and that therefore Spring must be available via dpkg/apt like everything else?
Also, please note that there are many similar resources within Spring itself that do not contain license headers. For example, there are hundreds of Spring XML files within our test cases - they do not have license headers, nor I think obviously, should they; there are properties files, log4j configuration files, etc. I do not see other open source projects applying a strict 'license every artifact' interpretation of the ASL, and Spring Build's artifacts fall into this bucket of ancillary, supporting artifacts that probably need not be licensed. They are, at the end of the day, just a bunch of Ant and Ivy XML files.
The key question is this: If these build files were included in Spring's SVN repository directly - no svn:externals, no seemingly-separate project called Spring Build, would this issue be being raised at all?
Damien Raude-Morvan commented
Hi,
First, Ben and Chris please don't take all my comments in the wrong way. I use many Spring projects on a daily basis and really love them. I'm just here trying to understand how we can integrate Spring Framework properly into Debian, following Debian Free Software Guidelines.
Why Spring Framework in Debian ?
short : because we can :)
long : a buch of packages need it at runtime (to name of few : Osmosis, Red5, JasperReports, Grails...). As you might know, Debian provide software as packages : each end-user application depends on commons, system wide, libraries. Example : all KDE sotware use a common QT library and the same goes for Java software : Commons DBCP, ASM, Hibernate are provided as system wide libraries and used by Tomcat, Jetty and so on.
Source code of all components of Spring Framework
Debian is about providing package but also providing a way for everyone (users, debian derivatives..) to modify our packages. So we have some guidelines :
So I tried to rebuild Spring Framework from source, without depending on .jar from your zip but using system wide ones. From spring-framework-3.0.3.RELEASE-with-docs.zip, I have to handle the following dependencies (ie. taking appart all others described in */ivy.xml files) : projects/spring-build/lib/ivy/commons-logging.jar, OK provided by libcommons-logging-java projects/spring-build/lib/ivy/jets3t.jar, OK provided by libjets3t-java projects/spring-build/lib/ivy/commons-codec.jar, OK provided by libcommons-codec-java projects/spring-build/lib/ivy/ivy.jar, OK provided by ivy-java projects/spring-build/lib/ivy/commons-httpclient.jar, OK provided by libcommons-httpclient-java ??? projects/spring-build/lib/ivy/org.springframework.build.aws.ivy.jar ??? projects/spring-build/lib/ivy/org.springframework.build.ant.jar
So my starting issue was :
Then I also started looking at others Spring projects and detected also that : ??? projects/spring-build/ XML (ant files) are embedded in each project.
So my questions was :
Spring Build "standalone" ?
From my understanding (but it seems I might be wrong), org.springframework.build.ant.jar is provided by a "spring build" project.
So I've build a source tarball which use contains an extract of everything under https://src.springframework.org/svn/spring-build/trunk/ It produce two Debian packages :
libspring-build-java:
org.springframework.build.aws.ivy.jar
org.springframework.build.ant.jar
and friends
spring-build-scripts:
all ant XML files
Then, for example, Spring Framework depends on this two packages for providing both "artifacts". It might also, in near future, be used for others Debian packages (Security, Roo...)
Side note: As you've said, https://src.springframework.org/svn/spring-build/trunk/project-build/ (XML files) are used in many Spring protfolio projects. But it's not a requirement to have those files under the same licence as each project where it's used : Apache 2.0 licence is permissive enought to be used with whatever Spring project you want.
Summary
Here is a summary of my current issues :
I have to find a source tarball / SVN for all org.springframework.build.*.jar Q: Is it ok for you to create thoses artifacts from an export for you SVN ?
Licence of all source code which produce all org.springframework.build.*.jar is unclear (Apache-2.0 + GPL-3+) from my point of view. Q: Could you please add a LICENCE file describe what's expected licence of thoses Ant tasks ?
XML files: I would prefer a shared approach where all Spring-* project use a common XML but if you want to keep those inside each project is not a blocking issue. Q: Are you ok with that or would you like to keep using embedded copy from each project ?
XML files: Licence of thoses "creative work" (3000+ lines of XML) is not specified. You seems to indicate it's inherit licence from container project. Q:
Could you please answer to those questions to make things clear ? Another approach would be to strip all existing build system and use a custom one...
Thanks for your time.
Regards,
Daien Raude-Morvan
nebhale commented
To start with, the java code that was visible in the SVN area has long been abandoned and switched over to Git. You can find the current versions of the code here: http://git.springsource.org/spring-build
In all projects I've added Apache license headers, as well as LICENSE and NOTICE files.
Finally, Spring has been updated to use a version of spring-build that has the headers in it.
Chris Beams commented
Hi Damien,
Could you verify that everything is in order per Ben's last comment? Just re-open the issue if you find any problems. Thanks!
Miguel Landaeta commented
I could not access http://git.springsource.org/spring-build
Chris Beams commented
@Miguel
- try git clone git://git.springsource.org/spring-build/spring-build.git
Miguel Landaeta commented
Forget it, I found the correct URLs: git://git.springsource.org/spring-build/spring-build.git https://fisheye.springsource.org/browse/spring-build/trunk
Damien Raude-Morvan commented
Hi all,
First : Chris and Ben, thanks for your work ! For XML/Ant scripts part (git://git.springsource.org/spring-build/spring-build.git), it is ok and contains everything we need to ensure we can redistribute those. So it address my point #3 and #4 (see comment made on 07/Aug/10)
But I can't find source of all org.springframework.build.*.jar ? Are they in another Git repository ? So this leave my point #1 and #2 open for now.
Cheers,
Damien Raude-Morvan
Chris Beams commented
reopening pending resolution of Damien's remaining questions
nebhale commented
Sorry Damien, I forgot that you guys don't have access to our internal pages which show the complete contents of the spring-build repositories. The following links should give you the code you seek:
git://git.springsource.org/spring-build/spring-build.git git://git.springsource.org/spring-build/misc-ant.git git://git.springsource.org/spring-build/aws-ant.git git://git.springsource.org/spring-build/aws-ivy.git git://git.springsource.org/spring-build/osgi-ant.git
Damien Raude-Morvan commented
Thanks Ben.
It's ok for me. You might close this issue.
Again, thanks for your work.
Damien
Chris Beams commented
Damien - that's great to hear, thanks for submitting the issue. If you don't mind, please post something here once the Spring package is available via apt.
Damien Raude-Morvan opened SPR-7352 and commented
I'm Debian Maintainer of SpringFramework package [1]. I'm working on integrating Spring Framework 3.0.3 into Debian and replace our libspring-2.5-java package.
Right now, I'm reviewing source code of Spring Build (aka Ivy-overlay spring build system) and I'm a bit disapointed to see that :
Could you please have a look at this issue and update this project ?
In current state, Spring Build is a non-free module and cannot be considered free software.
[1] https://src.springframework.org/svn/spring-build/trunk/
Regards, Damien Raude-Morvan
Issue Links:
12010 Please provide a LICENSE file for spring-build subproject ("is duplicated by")