Debian : Spring Build system has no licence / copyright [SPR-7352]

[spring-projects-issues]

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 :

• There is no copyright / global licence file [1]
• All files are missing a licence header (like other Spring project does)

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:

• Please provide a LICENSE file for spring-build subproject [SPR-7351] #12010 Please provide a LICENSE file for spring-build subproject ("is duplicated by")

[spring-projects-issues]

Juergen Hoeller commented

Ben, could you sort this out ASAP please - in time for the 3.0.4 release in mid July?

Juergen

[spring-projects-issues]

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.

[spring-projects-issues]

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 :

• provide a global licence file (at least for JAR artifacts projects)
• add licence headers in XML Ant snippets (source code of Spring Build)

[spring-projects-issues]

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".

[spring-projects-issues]

Juergen Hoeller commented

Any status update here? Note that the 3.0.4 release is just around the corner...

Juergen

[spring-projects-issues]

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,

[spring-projects-issues]

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.

[spring-projects-issues]

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?

[spring-projects-issues]

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 :

• Every package have to provide its complete source code
• Every package have to be built with other, existing, debian packages (system wide libraries)
• Every package have to be built without internet access (ie. downloads JAR from internet)

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 :

• where is source of org.springframework.build.aws.ivy.jar ?
  -> Is this https://src.springframework.org/svn/spring-build/trunk/org.springframework.build.aws.ivy/ or is there some other source tarball ?
• how this "artifact" is licenced ?
  -> It's not really cristal clear as there is only source code from SVN without
  LICENCE file (just some with Apache-2.0 headers and some with GPL-3+)

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 :

• are the files part of Spring Framework or part of something else ?
  -> I thought thoses files were part of another "global" project but you are saying
  I'm wrong here
• are those ant XML files (at least 3000+ lines) licenced under some licence ?
  -> It's not THE main issue, but as said in comment from Chris, ASF recommends licencing
  any "creative work" under some licence.

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

[spring-projects-issues]

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.

[spring-projects-issues]

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!

[spring-projects-issues]

Miguel Landaeta commented

I could not access http://git.springsource.org/spring-build

[spring-projects-issues]

Chris Beams commented

@Miguel - try git clone git://git.springsource.org/spring-build/spring-build.git

[spring-projects-issues]

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

[spring-projects-issues]

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