Request for Changes-84: Change license to Apache v2.0
[Request for Changes - 84] Change license to Apache v2.0
- Author: Manuel Grizonnet
- Additional Contributors : Sebastien Dinot
- Submitted on dd.mm.yyyy
- Proposed target release 5.12 / 6.0
- Migration scripts : Migration scripts
The purpose of this RFC is to abandon the strong copyleft license (CeCILL v2.0) under which OTB have been released up to now in favour of a permissive license (Apache v2.0).
The goal is to change of license for OTB to adopt the Apache v2.0 license. The rational for this change is as follows :
For some time now, the OTB community is considering a licensing change for OTB to move from CeCILL v2 to the Apache v2 license.
Copyleft is a very good protection for open-source software in general, as it ensures that it will remain open. But in the current context where OTB can be useful, copyleft may also restrict the use of the library. With hindsight, we observed that OTB was considered by many institutions and companies as part of their project, and the choice of its integration in their solutions could sometimes not succeed because they (or their clients or partners) wanted to distribute their solutions, integrating OTB under different terms.
This has sometimes caused individual and expensive schemes to include OTB in projects and still respect the license requirements. We've tried to convince our partners that copyleft is not "dangerous", but we note with regret that these arguments do not work and that the OTB thus not meet the public that it deserves. So we, from a practical standpoint, think that a more permissive license could only increase interest in the OTB and help its development and also the development of the community of contributors.
This licensing change also means better management of contributors with the implementation of specific documents to respect the rights of the latter.
With a growing number of contributions, it has been now mandatory to improve the management of contributor. For example in the case of a change made necessary by a license update, we would need to seek permission from each contributor (thing still possible at this stage but would quickly become impossible if one of them simply disappears).
Two options were open to us regarding the improvement of contributions management:
- Request an assignment of copyright, in which case the project owner will own the economic rights of authors and will be able to take further action on the distribution of the contribution, or
- Ask a wide license on the contribution while leaving the copyright to the contributor.
We prefer the second option because there is no reason that contributors resign their copyrights.
A better contribution management for OTB will be of course better for contributors but also for potential users as it will reassures that the software contains no infringing code.
This licensing change is also part of the initiative to make the project governance more open to any potential contributors following the establishment of the OTB steering committee in March 2015.
Note that moving to the Apache license has no impact on users which contributes code as remote modules : they will not have to relicense or follow the new OTB license. Indeed the modular architecture of OTB allows to integrate external modules with different (open-source) licenses as OTB core (GPL for instance). Also note that it is already the case for the OTB standalone binary package distributed on www.orfeo-toolbox.org, since it includes the GPL FFTW module in ITK : as a consequence the full OTB standalone binary package license is GPL and not CeCILL V2.
The Requests for Comments-12: Changing licence to Apache v2.0 gives more details about the reason to propose changing OTB license to Apache v2.
License migration will be apply to all the source code and will be automated.
Helper scripts which will allow to perform the migration are available in otb-devutils repository
Classes and files
List impacted modules, classes and files, and explain the changes that were made.
Consider grouping changes by module names if several modules are impacted.
Give insight on important implementation details, and on all API changes (add link to specific changesets if possible).
List documentation modification that were made (doxygen, example, software guide, application documentation, cookbook).
List remaining open issues if any, and additional notes.