At OSCON this summer, the Open Source Initiative (OSI) publicly described its efforts to bring order and reason to the crazy panoply of open source software licenses. A week later at LinuxWorld San Francisco, the Free Software Foundation (FSF) detailed its own vision to improve license sanity. The OSI is attempting to corral its plethora of 58 licenses and the FSF is launching a widely inclusive process to update the 14 year old GPL 2.0.
Proliferation, compatibility and modernization are the big issues in all open source license debates.
Many in the industry decry the range of open source licenses while some say we could use even more!
“In the open source world, each discrete license effectively partitions the commons and reduces the collaboration possible between projects.”
Today’s 58 OSI licenses reflect the real or imagined needs of their contributors. A license solves particular problems important for an author of a software work. There are thousands of proprietary licenses for the same reason. In the open source world, each discrete license effectively partitions the commons and reduces the collaboration possible between projects.
To stop this wasteful proliferation, one approach proposed is to templatize open source licensing, much like the Creative Commons has attempted for document content licenses. Simple aspects of licensing, such as organization names, product identification and jurisdictional references can be templatized. But other complexities of software copyright licensing are not amenable to easy templating.
There are problems of granularity: how are software components with different licenses combined for copyright purposes and even what units of software (source file, object module, runtime link, or SOAP-based web services transaction) constitute the scope of the license?
Additionally, the terms for sharing source code and the degree of reciprocity to be required over distinct portions of the covered work can cause complex and perhaps unintended or even conflicting results.
In general, there are two broad models of open source copyright licenses, epitomized by The GNU General Public License (GPL) and the Berkeley Software Distribution (BSD) license respectively.
GPL style licenses require author attribution and offer the freedom to run, study, modify, and redistribute the copyrighted work. No warranty is provided. Furthermore, and most controversially, the reciprocity, or so-called copyleft provision, of the GPL requires that derivative works of software must also be covered by the GPL.
In the GPL, software is considered a GPL work for copyright purposes if any part uses or links into the GPL part. Therefore GPL code cannot be used downstream by non-GPL code. However it is important to note that, under certain compatibility guidelines, GPL code can use non-GPL software or libraries. Broader compatibility with other licenses is one of the primary objectives of GPL 3.0. For example, the FSF wishes to address the inability to combine Apache libraries, licensed under the Apache License 2.0, with software licensed under the GPL. GPL software cannot legally use Apache libraries because of subtle incompatibilities in the patent protection clauses of each license. Downstream compatibility must be a goal, where more restrictive code can benefit from less restrictive code. This is important so that, for example, X-Windows libraries can flow into GPL projects even though the reverse is not possible.
The other general open source licensing model is attribution or BSD style licenses. These licenses typically require author attribution as well as a simple non-endorsement and warranty disclaimer. Derivatives of BSD works need not be licensed under the BSD.
Unlike proprietary licenses, open source licenses are intended to be inclusive, cleverly exploiting the ownership privileges behind copyright laws to reverse their effect. Instead of restricting the rights of the recipients of copyrighted works they attempt to expand those rights for both use and redistribution. Nonetheless, as Professor Eben Moglen of FSF is keenly aware, licenses partition recipients into communities of common interest. In this role, open source licenses can become divisive, especially when used for competitive marketing position.
For example, Sun’s Common Development and Distribution License (CDDL) is regarded by many as encouraging fragmentation. CDDL is characterized as a weak copyleft open source license but it is not compatible with the GPL for a variety of reasons, many of which are inherited from the earlier Mozilla Public License (MPL). To become compatible with the GPL, CDDL could adopt, as did MPL, a dual-licensing strategy allowing both its own license and the GPL as options.
Promotion and Protection
Licenses serve variously to promote and protect, but also to partition the commons. Simple attribution licenses promote the commons but do not protect it. Non-copyleft licenses allow reuse and redistribution of software without preserving availability of software in its derivative form. With healthy collaboration, the commons is usually expanded by attribution style licenses. But because collaboration is not enforced, closed products and technologies can emerge. A notable example is Mac OS X, based on a BSD core, which has produced a niche market but not an open pool of resources from which everyone benefits.
The stronger, copyleft licenses promote the commons while also protecting it. Unfortunately, these same licenses also partition the commons because software resources under incompatible licenses cannot be incorporated for redistribution, diminishing the network effect of the commons.
“No license, not even the GPL, is sufficient to preserve a healthy software community.”
Fragmentation of OSS licenses reflects and reinforces natural project boundaries. For example, the kernel developers of Linux (GPL-based) and OpenSolaris (CDDL-based) are completely distinct. Disjoint OSS licenses reinforce disjoint engagement models surrounding distinct pools of common resources whose elements are both technological as well as social. Resource sharing is doubly inhibited, constrained both by project identity and by license. But no license, not even the GPL, is sufficient to preserve a healthy software community. Witness the strain in the Mambo community and the ill-will among the contributors to the Sveasoft project. Various GPL code may be allowed legally to work together but still may end up being disengaged, disjoint or just plain dysfunctional for practical reasons. Therefore, while fragmentation of licenses clearly inhibits resource sharing, uniformity of licenses cannot guarantee greater collaboration. Concrete project goals and good will are also important.
OSS Licensing must be brought up to date with the global evolution of copyright and other IP issues.
Modern software copyright licenses, whether proprietary or open source, depend upon the fundamentally restrictive copyright regimes enshrined in the WTO Agreement on Trade-Related Aspects of Intellectual Property Rights (TRIPs) and the newer WIPO Copyright Treaty. All software licenses are designed to establish and protect a market — or community in the case of open source — governed by the owner of the copyrighted work. In the case of proprietary licenses, copyright restrictions are intended to be exclusive and, thanks to WIPO, they now incorporate anti-circumvention laws to prevent digital piracy.
“Complex new issues like DRM, web services and patents must be addressed to preserve the benefits of OSS licensing.”
The new world envisioned by Intellectual Property proponents has become more sophisticated, forcing bodies like the OSI and FSF also to become more sophisticated. Interaction with wider issues like digital rights management (DRM), web services and patent protection must now be considered carefully in order to preserve and maximize the benefits that open source licensing can provide.
The danger of modernization is that skyrocketing complexity may lead to a combinatorial nightmare of more licenses and license changes. This would usher in a new era of potential license proliferation and incompatibility. It is, of course, unrealistic to expect that there can ever be one universal open source license. Nonetheless agreement on broad categories of licenses from the spectrum of reciprocity requirements — attribution only (BSD), weak copyleft (”middle way” or CDDL, LGPL), and strong copyleft (GPL) — is possible. However, the tricky new issues of DRM, web services, and patent peace provisions may leave no easy answers that could foster compatibility among licenses, especially as license language varies in degree of constraints and compliance.
Everyone interested in improving the open source license situation will do well to follow the global public discussion that is about to begin to upgrade the GPL over the next year. Even if you are reluctant to adopt the GPL for your own software work, the exchange of ideas and deliberation of details will benefit all open source license proponents and the open source community as a whole. The results can be used as a tool to hone other license variations toward greater compatibility and promote a more harmonious open source commons.