Paper:FOSS Licensing

From Wiki

There was limited discussion of licensing at Good to Great FOSS. Licensing for FOSS projects in Africa varies, and appears to fall into the same general categories of license preferences and variations as the larger FOSS community.

To summarize those categories:

• The GNU General Public License (GPL) is the “original” FOSS license, setting forth the meaning of “Free Software” in legal terms. In lay person's terms, the GPL is defined by the “Four Software Freedoms”:1
  • The freedom to run the program, for any purpose.
  • The freedom to study how the program works, and adapt it to your needs. Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor.
  • The freedom to improve the program, and release your improvements to the public, so that the whole community benefits. Access to the source code is a precondition for this.

At the core of the GPL is a “share-alike” ethic that specifies that one must redistribute GPL-licensed code under the exact same terms as it was obtained. In this way, GPL-licensed code can never become “less free”.

• A larger class of “Open Source” licenses have been certified by the Open Source Initiative, and are referred to as “OSI-approved” licenses2. These licenses contain a range of terms that distinguish them from the meaning and intent of the GPL, but a simple generalization can be made that the primary difference often lies in the share-alike terms, or lack thereof. Licenses such as the the FreeBSD (used for the FreeBSD operating system) and the Mozilla Public License (MPL, used for Firefox and other software distributed by the Mozilla Corporation) allow code distributed under those licenses to be linked and distributed with proprietary code. The nuances of what is and is not allowed by various OSI-approved licenses drive a vast trove of online debate and discourse.

The difference between the “free” software licensing of the GPL and the “open source” licensing of the larger class of OSI-approved licenses lies at the root of much friction in the FOSS community. The Free Software Foundation and other GPL-focused stakeholders believe that licenses other than the GPL subvert the essential “freedoms” of the GPL and the larger vision for a free software future, while proponents of other OSI-approved licenses feel the strict and unyielding nature of the GPL of limits their flexibility, innovation, profit, and other opportunities.

The situation has been further complicated with the publication of GPL Version 3 (GPLv3). This thoroughly overhauled version of the GPL license was published to address coverage gaps in GPL Version 2 (GPLv2), such as defining the status of GPL code adapted and modified for “hosted” web applications which is never officially “distributed”. GPLv3 also contains a new category of restrictions relating to digital rights management (DRM), and states that GPLv3 code can not be employed in the creation of software that supports DRM. High-profile projects based on GPLv2, such as the Linux operating system kernel, have refused to adopt GPLv3. And the fact that GPLv3 is not backwards compatible with GPLv2 has only exacerbated an already complex licensing landscape.

A critical implication of balkanized FOSS licensing regimes is the issue of license interoperability. GPL code simply can not be combined or distributed with code licensed under non-GPL licenses; there is no license for the resulting aggregate which would satisfy the terms of both inherited licenses. In general, it is difficult if not impossible to combine code distributed under different FOSS licenses, though some vendors such as MySQL provide “FLOSS License Exceptions”3 which mitigate interoperability constraints. In any case, FOSS developers must choose carefully in deciding under which license they should distribute their code.

One topic of discussion at Good to Great FOSS was the advisability of “dual licensing” approaches. In such frameworks, different licenses are granted for different uses of the source code. Dual licenses can both mitigate license interoperability issues (such as GPLv2 vs. GPLv3), while also providing the foundation for FOSS business models where commercial use of the code generates revenue.

In such dual-licensing scenarios, different terms are granted based on how the resulting code will be distributed. For new code which will be distributed under GPL or open source licenses, a corresponding GPL or open source license is granted. But for commercial vendors who distribute the licensed code with their proprietary products, and do not license and distribute their own source code under the GPL, a commercial license is granted, and usually associated with licensing fees or other revenue sharing. The MySQL database platform has a good example of dual licensing on their license page at http://www.mysql.com/about/legal/licensing/.

The projects at Good to Great FOSS operate under the following licensing frameworks:

• Chisimba is distributed under GPL version 2, which is described at http://www.gnu.org/licenses/old-licenses/gpl-2.0.html.

• DrumNet has not yet decided on the licensing framework for the project.

• OpenMRS uses the OpenMRS License, which is a variant of the Mozilla Public License (MPL), and is described at http://openmrs.org/wiki/License. A primary reason for not using MPL was the need to include expanded warranty and liability disclaimers specific to healthcare-related technology.

• Mifos is distributed under the Apache License, Version 2.0, which is described at http://www.apache.org/licenses/LICENSE-2.0. The Mifos licensing page at http://www.mifos.org/developers/wiki/MifosLicensing is an example of best practices in licensing, providing template headers for all types of source code files.

• Tradenet code is not currently distributed under any license.

While best practices for FOSS licensing are hard to generalize, the following assertions are safe to make:

• The GPL still represents the highest ideals of FOSS licensing, and should be considered in any licensing decisions. However factors including dependent code licenses, partnering agreements, target markets, business models and institutional constraints may prevent GPL from being the best choice. On the other hand, GPL licensing provides a “moral high ground” in FOSS distribution, and saves projects from having to explain and defend why they opted for “less free” licensing.
• Dual or multiple license approaches should also be considered when looking to increase uptake and adoption of FOSS projects. While such licensing models have the effect of “watering down” pure GPL offerings, they provide flexibility to those who otherwise might not be able to incorporate the available code. FLOSS License Exceptions such as those mentioned above also alleviate code interoperability blockages.
• In any case, creating a new FOSS license should only be considered as a very last resort. While unique institutional and legal requirements such as those associated with the OpenMRS project can mandate a specialized license, new licenses only clutter the landscape. All efforts should be made to not only use an existing license, but to use one which is in broad distribution, so as to maximize the reusability of the licensed code.