...

It is also good to keep binary distributions as clean as we can from a licensing standpoint. But a bit more latitude around common things that are LGPL is reasonable and we should still be able to distribute the entire binary distribution under the Apache license in those circumstances. Including GPL is another story – inclusion of any GPL code, even unmodified binaries, would mean the entire binary distribution would have to be done under the GPL. This would still technically be okayfine, but it would have to be clear that this binary distribution is under more restrictive licensing than normal for Jasig.

There has historically been some confusion/disagreement as to how LGPLv2 works in Java applications. Specifically as to whether Java libraries packaged as jar JAR files that are licensed under the LGPL and are then included with larger application will create a "derivative work" and cause the copyleft aspects of LGPL to kick in. Since Java isn't technically "linking" in quite the way the LGPL discusses, some camps have believed that the LGPL and GPL are actually identical when it comes to Java. In fact, the Apache Foundation specifically stays away from LGPL code because of this concern, as you can see in some old mailing list discussions here and here, and that position is still present in their licensing policies and is why it is on their Category X list and also on ours. LGPLv3 is considered somewhat clearer on this matter, although the issues are still largely the same.

The Free Software Foundation (the author and maintainer of the GPL and LGPL) has generally been quite clear that they believe the LGPL works as intended with Java and that we should not be so concerned about this. See their article The LGPL and Java for details.

All this being said, we think it's okay (but not desirable) it is acceptable to include LGPL libraries in binary distributions of Jasig projects, as long as we avoid pulling them into the original source code distributions. It does need to be clear in the NOTICE file that there are LGPL components in the distribution.

Another interesting side note about GPL and LGPL projects is that even though they are distributed with a specific version of the license, many of them allow consumption under any later version of the license. So some GPLv2 and LGPLv2 licensed projects can actually be consumed under GPLv3 and LGPLv3. You have to check the source code headers to see what they say about the version of GPL/LGPL that applies to the code.

Java API Specification Interface Classes

In some cases, projects will need to include the binary version of some Java API Specification Interface Classes as part of their binary distribution. Examples might include things like JSTL or JTA. The Specification and the APIs are generally licensed under some terms that are intended to control the way an implementation of the standard is developed, tested, and distributed. Unless we are building an implementation of one of the Java standards, these licensing terms do not apply to our projects.

The API Specification Interface Classes themselves are generally licensed separately under Sun's "Binary Code License (BCL) Agreement with Supplemental Terms". This license allows the unmodified binary JARs to be redistributed with projects that are using them. This is what applies to our projects, and so it is fine to redistribute these JARs with a binary distribution of our projects as long as we comply with this license, which essentially just means we cannot modify the binary JAR files in any way.

It is important to realize that this all applies only to the API itself, not to an implementation of the API. An implementation can be built by anyone (as long as they comply with the licensing of the standard) and can then be distributed under any license they choose. So, if we are redistributing an implementation of the API (which will usually be the case) we have to look at the specific implementation we are redistributing and make sure we are okay with that license as well. For example, if a project is using and redistributing the Apache Standard Taglib, which is an implementation of JSTL, then we are fine because that project is licensed under the Apache License 2.0.