As a community organization supporting open source software development, the Apereo Foundation is deeply committed to the core principles of open source, as defined and managed by the Open Source Initiative (OSI) and reflected in their website at opensource.org. To this end, the Foundation uses a set of licenses, agreements, and policies to manage its software projects and the intellectual property surrounding them, which this Foundation Intellectual Property Policy embodies. These help Apereo to provide proper governance and sustainability to these projects.
1. Outbound Licensing
Apereo has adopted many of the licensing practices of the Apache Software Foundation, and also follows the ASF in many of its intellectual property management policies and in its community project structures as a whole.
The default outbound software license for Apereo projects is the Apache License, Version 2.0. In the absence of an explicit licensing declaration, software released by Apereo is implicitly licensed under the Apache License, Version 2.0. More specific information about the Apache License is available in the Apache License and Distribution FAQ.
Several Apereo projects use the Educational Community License, Version 2.0, which is a slight variant of the Apache License with one small change that narrows the conditions of any implicit patent grant, and which is preferred by some institutions contributing to projects.
New projects are free to select either license, and should use the one that best fits the core community of contributors and adopters to the project. Use of any other outbound license needs to be reviewed and approved by the Licensing & Intellectual Property Committee and by the Apereo Foundation Board of Directors, and would only be considered if the license complies with the Open Source Definition and has been approved by the OSI.
2. Inbound Licensing (Contributor License Agreements)
Apereo requires that all project contributors complete a Contributor License Agreement (CLA). The CLA clearly defines the terms under which intellectual property is being contributed, and affords Apereo greater latitude to provide comprehensive governance over the project.
The Contributor License Agreement enables Apereo to update the licensing of its projects, when necessary or desirable, while maintaining the provenance of the code, and the rights of Apereo, as well as those of the contributors and adopters of this code.
The CLA also makes it possible for the Apereo Foundation, at its corporate discretion, to defend the project, and/or its contributors and adopters, should the project become the subject of any claim or dispute, legal or otherwise.
In all cases, contributors retain full rights to use their original contributions for any other purpose, while providing Apereo and its projects the right to distribute and extend their contributed work.
Individuals must have an Individual Contributor License Agreement (ICLA) on file with Apereo before any significant contributions will be accepted and before commit privileges will be granted on Apereo projects.
Organizations that have tasked employees to work on an Apereo project should also complete a Corporate Contributor License Agreement (CCLA) so intellectual property that may have been assigned as part of an employment agreement can still be properly contributed. Individuals still need to submit an ICLA, even when their organizations has completed a CCLA. Individuals are responsible for making sure their organization has completed a CCLA if their contributions are owned by their employer.
When an individual or corporation donates existing software or documentation to an Apereo project, they need to execute a formal Software Grant License Agreement (SGLA) with Apereo. Incubating projects with pre-existing codebases are required to execute the Apereo SGLA prior to formal acceptance as sponsored Apereo project.
Contributor License Agreements may be submitted to the Apereo Foundation by emailing scanned signed copies, by fax, or by postal mail.
Historical Note: Some Apereo projects were originally managed under the New BSD License. Contributions to these projects were then accepted under the terms of that license. For historical purposes, the New BSD License is broadly interpreted as the Contributor License Agreement for those contributions, and those projects still honor all the terms of that License. New contributions to any Apereo project are now only accepted with an ICLA, CCLA, or SGLA in place first.
3. Frequently Asked Questions (FAQ)
These are frequently asked questions (and answers) about Apereo's Licensing & Intellectual Property Policy.
Q1. Why does Apereo prefer the Apache License?
First, Apereo strongly support the use of mainstream software licenses that have been approved by both the Free Software Foundation and the Open Source Initiative. Apereo also feels that License Proliferation is a problem and that all Free / Open Source Software (FOSS) projects should endeavor to use the widely-adopted, well-understood license that best meets their needs.
Second, since Apereo projects are frequently combined with other open source projects, Apereo prefers a license that is widely compatible with those projects and that is generally as permissive as possible. At the same time Apereo desires a comprehensive license that provides appropriate protections for both contributors and adopters of open source.
Apereo feels that of all the current mainstream open source licenses, the Apache License best fits these needs.
Q2. Why not prefer a copyleft license like the GNU General Public License (GPL) or Affero General Public License (AGPL)?
Apereo supports the general ideas behind "copyleft" and believes that free software should stay free. However, Apereo is more interested in promoting widespread adoption and collaboration around its projects, and copyleft licenses can be a barrier to this. Specifically, the required reciprocity of copyleft licenses (like the GPL and AGPL) is viewed negatively by many potential adopters and contributors. Apereo also has a number of symbiotic relationships with other open source communities and projects with Apache-style licensing that would be hurt by copyleft licensing.
Apereo strongly encourages anyone who improves upon an Apereo project to contribute those changes back to the community. Contributing is mutually beneficial since the community gets a better project and the contributor does not have to maintain a diverging codebase. Apereo project governance bodies that feel licensing under the GPL or AGPL is necessary in their context can request permission from the Licensing & Intellectual Property Committee and the Apereo Foundation Board of Directors to select this copyleft approach to outbound licensing.
Apereo believes that the reciprocity in a copyleft open source software project should be symmetrical for everyone, specifically that all individuals and organizations involved should share any derivative works as defined in the selected outbound license. Apereo sponsored projects that adopt a copyleft approach to outbound licensing will be required to maintain fully symmetric reciprocity for all parties, including Apereo itself.
Q3. Why not generally prefer the Educational Community License (ECL)?
Many Apereo projects, while supporting the academic mission, are not exclusive to the domain of higher education. Apereo prefers to use the Apache License because the relative obscurity of the ECL license can be a barrier to broader adoption of Apereo projects in broader circles. This is not unusual, and there are many other open source project in higher education that choose the Apache License for this reason.
That said, the ECL is a completely fine alternative that is preferred by some Apereo project communities and their contributing institutions, specifically because the patent licensing language is more attractive to some institutional technology transfer offices.
Q4. Why not use the New BSD License (or similar)?
The New BSD License is a very simple and straightforward open source license. Its simplicity is both its greatest strength and its greatest weakness. This license simply does not provide enough protection for either contributors or adopters to really understand the terms under which the software is being shared.
Apereo prefers a more comprehensive license that fully defined the nature of the agreement and provided clearer protection to all the parties involved.
Q5. Why does Apereo require Contributor License Agreements (CLAs)?
There are two main reasons that Apereo requires Contributor License Agreements before accepting contributions to its projects.
The first reason for requiring CLAs is to provide proper legal protection to the contributors and the adopters of the projects. CLAs protect contributors by explicitly making it clear what the terms and conditions are for properly contributing to a project, thereby avoiding any confusion or misunderstandings between the contributor, the project, and the community. CLAs protect adopters of the project by ensuring that the contributions that make up the project are legitimately and appropriate licensed all the way from the contributor to the adopter. Furthermore, CLAs give Apereo better legal standing to defend against violations of the project license, providing protection for both contributors and adopters.
The second reason for requiring CLAs is to allow Apereo to better ensure the sustainability of the project. In the future, there may be unforeseen needs to adjust the licensing of Apereo projects. Without appropriate CLAs in place for all contributions, Apereo would have to seek individual permission from all past contributors in order to make changes to the licensing of the overall project - this could prove impossible in a long-running project with hundreds of contributors. The Mozilla Relicensing effort serves as a cautionary tale as to what can happen to projects that do not have central governance with the ability to adjust project licensing.
Q6. How do CLAs benefit developers?
As mentioned in some of the earlier questions this policy benefits developers in two ways:
The Apache License is a comprehensive license that fully defines the nature of the agreement between the developers of the software and the users of the software and thereby provides clearer protection to all the parties involved, including developers.
The Apereo CLAs provide explicit assertions about the standing of the contributor to make the contribution, the provenance of the contribution, and the terms and conditions under which the contribution is being made to Apereo. This clarity provides better protection to the developers and their contributions.
Q7. How do CLAs benefit users?
As mentioned in some of the earlier questions this policy benefits users in two ways:
The Apache License is a comprehensive license that fully defines the nature of the agreement between the developers of the software and the users of the software and thereby provides clearer protection to all the parties involved, including users.
The Apereo CLAs provide explicit assertions about the standing of the contributor to make the contribution, the provenance of the contribution, and the terms and conditions under which the contribution is being made to Apereo. This clarity provides better protection to the users because there is an explicit licensing chain fully connecting the copyright holders and the end users.
Q8. Is it okay if our counsel wants to make some minor changes to the CLAs before we sign them?
It is important that we maintain consistency in the Apereo CLAs for three reasons:
Consistency cuts costs. We are a deliberately lightly staffed and financed organization serving higher education. A consistent contributor license agreement -- which has been reviewed and signed by many hundreds of institutions world-wide -- means we do not have to revisit agreements legally each time a new organization contributes. This means we can effectively manage the intellectual property rights with which we are entrusted, keep our membership dues down, and better serve our members and higher education in general.
Consistency keeps clarity. Despite the widespread, and growing, adoption of open source software in higher education, the nuances of inbound and outbound licensing are not widely understood. To help build adoption, we try to make inbound and outbound licensing as straightforward as possible. A raft of different contributor agreements creates confusion, rather than clarity. This confusion can act to slow adoption, and, critically, slow or prevent contributions from others. Ultimately, contributors to open source projects make their code available out of a strong element of self interest; so that others will adopt, contribute, and lower the costs of further development and maintenance. Any action that slows or prevents this should be avoided.
Consistency simplifies partnerships. Collaboration around an open source project is best enabled by all partners agreeing to vest the rights to manage intellectual property into a common entity under a common agreement. When the partners use same agreement, equity is maintained, trust is developed, and partnerships can be built on a level playing field that is understood across the community. If one partner requires a special or adapted contributor agreement, not only is the ability to manage intellectual property eroded, but trust itself -- the basis of the partnership -- may be similarly eroded.
If your counsel would like to talk to peers at other organizations that have signed the standard CLAs, please contact us and we can help connect you.
Q9. How do projects implement the Apereo Licensing Policy properly?
Apereo maintains a set of Licensing & Intellectual Property Practices for projects to follow. These must be implemented during the Incubation process for projects that are joining the Foundation, and it is the responsibility of the governance group of the project to maintain these practices over time.
Q10. Whom should I contact with questions about Apereo licensing or intellectual property?
Simply send an email to licensing[at]apereo[dot]org and someone from the Apereo Licensing & Intellectual Property Committee will respond to your question as soon as possible.