DEPRECATED: Third-Party Licenses

Owned by John A. Lewis
Jan 16, 2015
7 min read

Deprecated

Jasig has become part of the Apereo Foundation as of December 2012. Going forward, all policies and practices around licensing and intellectual property for Jasig projects are under the stewardship of the Apereo Foundation. The Apereo policies and practices are nearly identical to the ones used by Jasig. Please see http://www.apereo.org/licensing for more information.

 

Third-party content (source code, binary artifacts like libraries, documentation, etc.) is anything that was not submitted directly to Jasig or that is not covered under an ICLA, CCLA, or SGLA. Jasig projects can use third-party content as long as the project is in compliance with the license under which the content is acquired, and as long as use of the third-party content does not violate Jasig's own licensing and policies.

In order to keep Jasig projects available under the terms of the Apache Software License, Jasig follows the guidelines of the Apache Software Foundation regarding inclusion of third-party content in its projects. These guidelines consist of three major categories of third-party licenses that dictate whether and how the third party content can be included.

Category A List

This is the Apache Software Foundation "Category A" list. Third-party content obtained under these licenses may be included directly with Jasig projects.

Jasig Additions:

Many of these licenses have specific attribution terms that need to be adhered to, for example CC-A, often by adding them to the NOTICE file. Ensure you are doing this when including these works.

Category B List

This is the Apache Software Foundation "Category B" list. Third-party content obtained under these licenses may be only be included with Jasig projects in its unmodified binary form. This is because these are "Weak Copyleft" licenses that do not cause Jasig projects to become derivative works unless the third-party content is modified.

There should be an explicit entry in the NOTICE file for any inclusions under these licenses. That entry should name the third-party content that is included, who it is provided by, and the license under which it is provided.

Category X List

This is the Apache Software Foundation "Category X" list. Third-party content obtained under these licenses should not be included in Jasig projects. If it is needed, users should obtain it themselves and combine it with the Jasig project, but Jasig itself should not redistribute content obtained under these licenses.

Jasig Additions:

If a project is compelled to redistribute third-party content obtained under one of the licenses, the inclusion will have to be approved by the Project Steering Committee and by the Jasig Board of Directors. This will limit the conditions under which the Jasig project can be redistributed since it will be considered a derivative work of the content in question, and restrictions will follow from that. It may well not be in the best interests of the project to limit possible adoption on this way.

Other Licenses

Inclusion of third-party content obtained under a license not listed above will have to be approved by the Project Steering Committee and by the Jasig Board of Directors. The groups will need to determine which general Category (A, B, or X) the license falls into, and make its decisions accordingly.

Public Domain

Using content that is in the Public Domain does not require a license. Being in the Public Domain means the material is no longer copyrighted and all the concerns about licensing those copyrights are no longer an issue. Material that is truly in the Public Domain is completely compatible with Jasig projects and can be considered to be in the Category A list.

However, it is important to ensure that the content genuinely is in the Public Domain before consuming it as such. The primary way that content enters into the Public Domain is when the term of the copyright expires – this may take as long as 120 years, depending on the domain and the locale. For a copyright holder to put intellectual property into the Public Domain before the copyright term expires is much harder than it sounds. Many jurisdictions have strong copyright protection laws and make it quite difficult for someone to waive those rights entirely.

For our purposes, it is highly desirable for Public Domain material to be declared as such by the copyright holder through the Creative Commons CC0 process. This provides us with both a thorough declaration of Public Domain status, as well as a very liberal license in case the waiving of copyright is not effective. When seeking to use material that has been poorly dedicated to the Public Domain, please work with the original copyright holders to strengthen this dedication through tools like CC0.

See the Creative Commons Public Domain Tools area for more information about best practices for placing intellectual property into the Public Domain.

Special Considerations for LGPL

There is a difference between including things with the source code distribution of a project and with various binary distributions of a project. Our primary concern is the licensing of the source code distribution. As long as we are not including any Category X (including GPL or LGPL) code with the source code distributions, then we are achieving our primary goal.

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 under the GPL. This would technically be fine, 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 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 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, 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.