Apereo Practices on Third-Party Licenses

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

In order to keep Apereo projects available under the terms of the Apache License and Educational Community License, Apereo generally follows the guidelines of the Apache Software Foundationregarding 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 Apereo projects.

Apereo 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 Apereo projects in its unmodified binary form. This is because these are "Weak Copyleft" licenses that do not cause Apereo 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 Apereo projects. If it is needed, users should obtain it themselves and combine it with the Apereo project, but Apereo itself should not redistribute content obtained under these licenses.

Apereo Additions:

If a project is compelled to redistribute third-party content obtained under one of the licenses, the inclusion will have to be recommended by the project governance body, reviewed by the Licensing & Intellectual Property Committee, and approved by the Apereo Foundation Board of Directors. This will limit the conditions under which the Apereo project can be redistributed since it will be considered a derivative work of the content in question, and restrictions will follow from that. It is likely not in the best interests of the project to limit possible adoption on this way.

If a special exception is provided for open source projects that are distributed under the license of the Apereo project (e.g. the Apache License or the Educational Community License) that allows the third-party source to be included and still distributed under the projects primary license, then the third-party source in question can be considered as coming from Category B instead of Category X. These are generally known as a “FOSS Exception” or “FLOSS Exception”. The use of the exception must be fully documented in the NOTICE file.

Other Licenses

Inclusion of third-party content obtained under a license not listed above will have to be recommended by the project governance body, reviewed by the Licensing & Intellectual Property Committee, and approved by the Apereo Foundation 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 Apereo 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 Apereo’s 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 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. Apereo’s primary concern is the licensing of the source code distribution. As long as projects are not including any Category X (including GPL or LGPL) code with the source code distributions, then Apereo is achieving its primary goal.

It is also good to keep binary distributions as clean as possible from a licensing standpoint. But a bit more latitude around common things that are LGPL is reasonable and projects should still be able to distribute the entire binary distribution under the Apache and ECL licenses 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 acceptable, but it would have to be clear that this binary distribution is under much more restrictive licensing than normal for Apereo projects.

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 trigger. 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. 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 everyone 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 Apereo projects, as long as projects 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 binary distribution.

Another important 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, and it takes some careful inspection of the project (potentially including the source code headers) to see what what the provisions are 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 projects are building an implementation of one of the Java standards, these licensing terms do not apply to projects.

The API Specification Interface Classes themselves are generally licensed separately under a Java "Binary Code License (BCL) Agreement with Supplemental Terms" or under the Common Development and Distribution License (CDDL). These licenses allows the unmodified binary JARs to be redistributed with projects that are using them, making them Category B third-party content. So, it is fine to redistribute unmodified copies of these JARs with a binary distribution of an Apereo project.

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 projects are redistributing an implementation of the API (which will usually be the case), it must ensure the licensing of the specific implementation is also compatible for redistribution as third-party content. For example, if a project is using and redistributing the Apache Standard Taglib, which is an implementation of JSTL, then everything is fine because that project is licensed under the Apache License 2.0, which is Category A third-party content.