...

As a community organization supporting open source software development, we use Jasig uses a set of licenses, agreements, and policies to manage our its software projects and the intellectual property surrounding them. These help us to provide proper governance and sustainability to these projects.

1. Licensing

Jasig has adopted the licensing practices of the Apache Software Foundation. We Jasig also follow follows the ASF in many of its intellectual property management policies and in its community project structures.

Specifically, the default software license for all Jasig projects is the Apache License, Version 2.0. All packages In the absence of an explicit licensing declaration, all software
released by Jasig are is implicitly licensed under the Apache License, Version 2.0, unless otherwise explicitly stated. More specific information about the Apache License is available in the Apache License and Distribution FAQ.

2. Contributor Agreements

Jasig requires that all project contributors complete a Contributor License Agreement (CLA). This agreement clearly defines the terms under which intellectual property is being contributed and gives Jasig broader capabilities to provide proper governance over the project. This makes it possible for Jasig to properly defend the project, its contributors, and its adopters in the case of a legal dispute of some kind. It also allows Jasig to update the licensing of its projects over time as circumstances may dictate.

...

When an individual or corporation donates existing software or documentation to a Jasig project, they need to execute a formal Software Grant License Agreement (SGLA) with Jasig. This typically occurs as part of the Jasig Incubation process for taking on new projectsIncubating projects with preexisting codebases are required to execute the Jasig SGLA prior to formal acceptance as sponsored Jasig project.

Contributor License Agreements may be submitted to Jasig in the following way:

...

Historical Note: Some Jasig projects were previously 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 Jasig project are now only accepted with an ICLA, CCLA, or SGLA in place first.

3. Frequently Asked Questions (FAQ)

Q1. Why has Jasig adopted the Apache License?

First, we Jasig strongly support the use of mainstream software licenses that have been approved by both the Free Software Foundation and the Open Source Initiative. We Jasig also feel 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.

Since Second, since Jasig projects are frequently combined with other open source projects, we Jasig wanted to select a license that is widely compatible with those projects and that is generally as permissive as possible. At the same time we Jasig wanted to move to a comprehensive license that provides appropriate protections for both contributors and adopters of open source. After reviewing all the mainstream open source licenses, it was clear that the Apache License best fits our Jasig's needs.

Q2. Why not adopt a copyleft license like the GNU General Public License (GPL)?

We Jasig support the ideas behind "copyleft" and believe that free software should stay free. However, many of the communities and projects that we Jssig regularly collaborate collaborates with currently avoid copyleft protection for their projects because they perceive it as a barrier to widespread adoption. Specifically, the "viral" nature of copyleft licenses like the GNU General Public License is viewed negatively by many. In the interests of continued symbiotic relationships with these projects and to promote adoption of Jasig projects as widely as possible, we are Jasig is not using copyleft licenses.

We do Jasig does strongly encourage anyone who improves upon a Jasig project to contribute those changes back to the community. This is mutually beneficial since the community gets a better project and the contributor does not have to maintain a diverging codebase.

Ultimately, open source projects must succeed on their own merits - the choice of copyleft protection will not be a major factor in the fate of any project.

...

Q3. Why not adopt the Educational Community License (ECL)?

The Educational Community License v2 (ECL) is identical to the Apache License v2, except for a minor change in section 3 that narrows the conditions of any implicit patent grant. This change was requested by some institutions participating in some key projects specific to higher education. To our knowledge, it is only in use by Only the Sakai project and the Kuali projects appear to use the ECL at this time.

Jasig projects have tended to be more infrastructure focused and are not exclusive to the domain of higher education. We Jasig did not want to adopt the ECL because its relative obscurity outside higher education would be a barrier to widespread adoption of Jasig projects. We Jasig also note notes that several other infrastructure projects in higher education, such as Fluid and Shibboleth, have also avoided the ECL and have adopted the Apache License.

Q4. Why not continue to use the New BSD License as previously used by Jasig projects?

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. We Jasig wanted to move to a more comprehensive license that fully defined the nature of the agreement and provided clearer protection to all the parties involved.

Q5. Why is Jasig requiring Contributor License Agreements (CLAs)?

There are two main reasons that Jasig requires Contributor License Agreements before accepting contributions to its projects.

...

The second reason for requiring CLAs is to allow Jasig to better ensure the sustainability of the project. In the future, there may be unforeseen needs to adjust the licensing of Jasig projects. Without appropriate CLAs in place for all contributions, Jasig 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:

1. 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.
2. The Contributor License Agreements make it clear that everyone asserts they are legally entitled to make the developer contributions they are makingJasig 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 they are the contribution is being made available to Jasig. 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:

1. 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.
2. The Contributor License Agreements make it clear that everyone asserts they are legally entitled to make the developer contributions they are making, and the terms and conditions under which they are being made available Jasig 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 Jasig. 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. Who should I contact with questions about Jasig licensing or intellectual property?

Simply send an email to licensing@jasig.org and someone from Jasig will respond to your question as soon as possible.

...

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. We Jasig projects can use third-party content as long as we are the project is in compliance with the license under which we acquire itthe content is acquired, and as long as use of the third-party content does not violate our Jasig's own licensing and policies. Use of any third-party content not available under one of the licenses on ASF's "Category A" list must first be reviewed by the project steering committee since it has implications for how the derivative work can be used.

...

Existing Jasig projects, like uPortal and CAS, will need to transition from their current licensing process to this new process. This must be handled carefully to make sure we don't create any future intellectual property problems are not created in the process. For each project, there will be two major steps to this process: 1) moving the committers to the new policy and then 2) moving the codebase to the new policy. The project steering committees will need to be are responsible for ensuring this process is executed properly.

Committers

First, we have the project has to make a transition with all the committers. Before we the project can change over a codebase to use the new license or issue any releases under the new license, we it must first get all the current active committers to complete at least an ICLA, and optionally a CCLA. It would also be good to get institutions who have made meaningful contributions

Getting organizations to complete the CCLA is encouraged, but optional. Individuals are encouraged to get their organization to complete the CCLA since it provides them with better protection for their contributions. But the ICLA is sufficient to provide Jasig and adopters with the protections Jasig is seeking from this process.

Institutions who have previously made meaningful contributions are highly encouraged to complete a CCLA and to specifically include a grant of all previous contributions within the CCLA.

The steering committee will need to run this process and set a deadline by which active committers must complete an ICLA. Once that deadline is reached, anyone who has not completed an ICLA will have their commit privileges suspended. These privileges will be restored as soon as the ICLA is completed.

Getting organizations to complete the CCLA is encouraged, but optional. Individuals are encouraged to get their organization to complete the CCLA since it provides them with better protection for their contributions. But the ICLA is sufficient to provide Jasig and adopters with the protections we are seeking from this process.

Codebase

completed an ICLA will have their commit privileges suspended. These privileges will be restored as soon as the ICLA is completed.

Codebase

Second, the project has to make a transition with the codebase. Once the active committers have all completed an ICLA, we the project can then make the transition of the codebase to the new license. There are still some important details for how this needs to be done that are different from how we Jasig would handle a new project.

...

Because all of the preceding contributions to Jasig projects were done under the New BSD License and there were no Contributor Agreements in place, we Jasig must continue to honor the terms of the New BSD License under which Jasig has rights to the current codebase. Fortunately, the requirements of the New BSD License and the Apache License 2.0 that we are moving to Jasig is adopting are fully mutually compatible. The Apache Software Foundation itself considers New BSD licensed projects fully compatible with the Apache License and appropriate for inclusion within Apache projects. See the ASF's Legal FAQ for more details on this, specifically the reference to the "Category A list" of licenses.

To continue to honor the terms of the New BSD License, we projects simply need to include its required statements in the NOTICE file included with each project. So, the NOTICE file for these projects should contain the following:

...