Why GPL will kill GPL, and maybe open source...

Over the last few weeks, I have reviewed many of the main resources regarding open source license compliance, which are quite complex. To help ease the elaborate nature of the material I created a license approval table that outlines the compliance of specific licenses.

The process of generating the table included the use of a "standardized" name and acronym for each license, while adopting the SPDX acronym. Afterward, I analyzed the various references to determine whether the licenses are compliant for distribution within software that utilizes the following license types: Apache, GNU GPL (2 or 3), Eclipse, or Proprietary.

Basic Comments

• Some licenses in the references where not listed in SPDX 1.16, lot of work stil have to be done.
• SPDX is a great initiative, and more people should look at it, and get invovled.
• Even if resources provided by the FSF and Fedora project are useful, compliance with or even within the GNU licenses is a nightmare compared to other alternatives.
• Software development is integrating more and more components, and it will be increasingly harder to provide clean software bill-of-materials including components distirbuted under one of the GNU licenses.

Topics for Discussion

• Can we make the assumption that GNU license prominence will continue to decline?
• Shall GNU licenses be limited to specific situations (end-user applications competing for properitary software; software based on a key technological asset, like Linux; dual licensing model)?
• GNU GPL's non-compliance with mainstream licenses (i.e. Apache and Eclipse), along with its difficulties addressing license compliance within the GNU licenses themself, may lead to separate ecosystems, and thereby minimizing the situation so that GPL is the correct license choice.
• Communities that use licenses, which comply with other licenses, can grow faster if they are leveraging merge/reuse/interoperability with other communities.
• Can we imagine that the open source ecosystem will no longer need copyleft licensing in the near future to be sustainable?

Note: The follow-up to this blog is "GPL is dead. Long Live the GPLs"

Table Legend

• Yes/Authorized : Source code and components can be merged/linked with software distributed under license defined at the top of the column
• Sometime : Refers to the situation where compliance is possible but requires special conditions.
• No/Excluded : Source Code and components cannot be merged/linked.
• Unknown : This compliance is not addressed by one of the references, it's unclear regarding which license is involved, or it needs further investigation.
• (Family) : Refers to more than one license. "Sometimes" or "Unknown" means that situation is not clear unless checking for specific situation.

Please, feel free to provide your feedback, or identify any incorrect information.

Note: The follow up to this blog is "GPL is dead. Long Live the GPLs"

Ressources:

(1) Software Package Data Exchange (SPDX) specification

(2) List of approved licenses via the Open Source Initiative (OSI) Review Process

(3) List of the various approved software licenses according to the Free Software Foundation

(4) Apache Software Foundation, 3rd party licensing policy

(5) "Are the Eclipse Public License (EPL) and the General Public License (GPL) compatible?" according to the Eclipse Foundation F.A.Q

(6) Eclipse Foundation Legal Process Poster

(7) Fedora licensing page

(8)  http://www.apache.org/licenses/GPL-compatibility.html   http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

(9) It depends on which BSD License you are considering. BSD-4-Clause and BSD-4-Clause-UC do not comply

Disclaimer : The materials and information provided are not intended or offered as legal advice. They are provided for general information purposes only.