Free / Open Source Software license proliferation has gone so far that companies are patenting proprietary software to solve it in the case of multi-source development process. Could copyleft license interoperability focus the F/OSS world on a handful of compatible provisions, replacing a culture of mutual exclusion by a culture of collaboration? The original text of this article has been posted by Patrice-Emmanuel Schmitz on www.OSOR.eu
 
F/OSS license proliferation is a fact. It is growing. When In 2005 the opportunity for the European Commission to create the European Union Public Licence (EUPL) was debated, the main objection was about “too many” – more than 100 - models of free licenses. This was 2005… The Commission overruled the objection; the EUPL was created for obtaining a license in compliance with European laws and for providing it in all EU languages; it was approved by OSI.
 
Where are we now?
 
At the EOLE conference of December 2009, H. Guyomar (Black Duck software) reported in “The challenge of managing abundance” 1,800 different F/OSS licenses!
 
If creating a new license is an ill-advised activity, then it seems that the whole F/OSS world is guilty; Then the OSI should not approve licenses anymore and even the FSF has participated to proliferation for introducing the new GPLv3, LGPLv3 and AGPLv3 as their favourite licenses, which have not reached the same level of popularity than the previous GPLv2.
 
Reducing the number F/OSS licenses to an ideal set of a handful of permissive and copyleft licenses is reasonable. It is recommended by Bruce Perens (one of the most experienced F/OSS analysts). But – to be honest - it stays just wishful thinking: every week, if not every day, new licenses are presented by F/OSS authors and communities. OSI daily efforts, restricting the approval of new licenses to the strict necessary, are valuable and limit proliferation speed. However, OSI is powerless to reverse the move. No benevolent dictator will limit human innovation regarding licensing.
 
If license proliferation can be perceived as a failure, I do not think that it is the failure of the F/OSS movement. It is the entire contrary: a testimony of the vitality and attractiveness of F/OSS models.
 
In reality, license proliferation illustrates the failure of a certain model of strong copyleft, as it was initiated by the GPL in the 80’ and reproduced by nearly all subsequent copyleft licenses. Once necessary and successful, this model looks not adapted anymore because it was copied and creates today more barriers (and less freedom) than protection.
 
Why is it a problem? The main issue with license proliferation is not only to multiply the number of texts (and the obligation to analyse and to understand differences between licenses). It is the proliferation of the rigid copyleft model adopted by many licenses, which excludes other models in case of re-distribution and creates new barriers. When developers adopt a copyleft license, integrating “incompatible” code in their work makes the distribution of derivative works impossible. This is a pity when F/OSS copyleft licenses are those which should provide the best protection of user’s and developers rights and freedom.
 
The fact a dozen of licenses are used for more than 90% of projects does not solve this issue: modern free software programming is the assembly and interaction of many components, licensed by a multitude of authors and contributors. Provide only one of the key components has incompatible licensing conditions may impact on the whole solution.
With hundreds of thousands of open source projects using nearly 2,000 licenses, the problem as gone so far that Black Duck just patented (Patent US 7,552,093 B2) the technology for controlling the use of open source licensing in a multi-source development process. I guess that patenting software for managing copyleft should not be seen as a major success!
 
The classical vision of copyleft is based on “upstream compatibility”: a developer will find that a software license is “compatible” with its own licensing purpose when he/she can freely reuse or copy the licensed software into his work and redistribute the derivative work under his/her preferred copyleft conditions. This way was initiated by the GPL and worked very well until it was copied. In fact this “compatibility” is one way. It is a “funnel strategy”: all permissive licenses and LGPL are compatible with GPLv2, the previous GPL versions are compatible with GPLv3, the GPLv3 is compatible with the AGPLv3 and the AGPLv3 itself is the end of the road. No return or “downstream compatibility” in direction of other licenses.
 
As a strategy, this funnel vision of copyleft is sustainable as long the ultimate license (in the example above, the AGPLv3) will eventually become the global good practice based on the idea “all software code will finally be regulated there”.
 
The drawback is that the strategy is contradicted by the reality of license proliferation: all new copyleft licenses are incompatible by design. This feeds license conflicts and human disputes. To preserve their F/OSS movement from schisms, communities’ gurus (or grand priests) and acolytes repetitively urge followers not to use any other copyleft licenses, whatever their specific merits or advantages could be. It is time to admit that the strategy of keeping a “captive asset” of license users was not successful for avoiding proliferation, and that it is not the most appropriate way to reinforce the freedom, collaboration spirit and consistency within the fragmented F/OSS world.
 
An innovative approach to solve copyleft licenses conflicts is to publish a downstream compatibility list. To my knowledge, the EUPL is the first copyleft license to publish such a list. When it is necessary to avoid license conflicts, developers have the freedom to change for another “similar” copyleft license (in that case the GPLv2, Eclipse, OSL, CeCILL, and Common Public Licence). The concept is not new, as the FSF applied it with the LGPL a long time ago. The LGPL (now LGPLv3) is convenient for software libraries aimed to produce derivative works: if the library is propagated on its own, it must be under the provision of its original license (LGPL); however, if the library components are part of a derivative work, this work can be licensed under another license, while the original library remains LGPL.
 
In the EUPL, the copyleft effect is stronger than in the LGPL (because compatibility is restricted to a limited and published list of other copyleft F/OSS licenses), but the conditions of downstream compatibility are quite similar. These conditions are based on necessity, not on convenience:

• Compatible licenses cannot be used to re-distribute copies, but derivative works only;
• Compatible licenses can be used to solve issues in case of “single license conflict (representing most of cases: multiple license conflicts are exceptions);
• The process is currently “one way”: once a EUPL derivative work includes GPL components and is licensed under GPLv2, it cannot be licensed again under the EUPL.
• The list of compatible licenses is positive and limited (they are requests, as for example the inclusion of the GPLv3 in the EUPL compatibility list). 

In his analysis “Freedom and Choice in Open Source Licensing”, Ernest Park predicts the extension of EUPL compatibility provisions: “It’s our guess that more OSI-approved licenses will eventually evolve to include a compatibility clause like that in the EUPL v1.1, which allows developers to take their code and get away from the current license if they’re unhappy with the way things are going”, he wrote.
 
What will happen if the above prediction is verified? If downstream compatibility lists (which are currently specific to the EUPL and to the CeCILL license in direction of the GPL only) would be widely applied by many other copyleft licenses (creating a kind of reciprocity)? It would present advantages, but also some potential risks:
The advantage is much more freedom for developers (less license conflicts between copyleft licenses). For example, if their software is licensed under the EUPL, developers would have the freedom to integrate a compatible copyleft component in their work without the obligation to change the license of their own work (and reciprocal). This would speed up development of more free software and replace a culture of confrontation (between copyleft licensing communities) by a culture of collaboration.
 
The main potential risk is that compatibility lists could be adopted unilaterally and without acting in concert. In such case, the derivative work could migrate from one license to another (what would become a kind of “Licence tourism” as I said at the EOLE 2009 conference). Of course, this would not change the original licensing conditions of each component merged into the derivative work, but it may create confusion on which licensing conditions are finally applicable to the produced solution. This work could even become proprietary in case at least one of the compatibility lists, published unilaterally by one of the license owners, includes a permissive license.
 
Therefore, the convenient approach to increase developers’ freedom without compromising the F/OSS sustainability of derivative works could be called the “loan and give back interoperability” between strong copyleft licenses: a loan from a specific community could be recovered at any time by the same community (and not transferred to any other, outside a circle, without its agreement).
 
Example:
in case of interoperability agreement between the European Commission and the FSF, developers of a EUPL “My_City_Admin” solution (a set of software integrating multiple components to provide a set of functionalities) would be allowed to integrate or link components produced by another community (for example GPLv2 or v3) without being obliged to change their existing licensing policy or being blocked by license conflicts and risks of copyright infringement.
 
This is not theory: in recent European call for tenders we discover the following provision:
“In case the contractor integrates in the development that is the object of the contract with modules or elements owned by third parties, he must first obtain from the legal owners the licenses and rights necessary to transfer the ownership of the development to <the public authority>, which will submit it, including the elements that are performed under the contract (such as fonts, dll, scripts, etc..) to the public license EUPL. In any case the total and final result of the development and the overall project will be subject to a license EUPL.”  
The above text is translated from Spanish, where the specific technical software procurement conditions of the Spanish Ministry of Industry provides:
 “En el caso de que el adjudicatario incorpore al desarrollo objeto del contrato productos, módulos o elementos propiedad de terceros, deberá obtener previamente de sus legítimos titulares las licensias y los derechos necesarios para ceder la propiedad del desarrollo a Red.es, que lo sujetará, incluyendo los elementos que se realicen en cumplimiento del contrato (como fuentes, dll, scripts, etc.), a una licensia pública EUPL. En todo caso el resultado total y final del desarrollo y del proyecto en general quedará sujeto a una licensia EUPL.”
 
Interoperability will not impact the original license of the loaned component. The objective is not to change it, but to facilitate complex solution development and obtain a single licence for the solution.
To avoid any kind of abuse (and as it is not realistic to spent a lot of time defining what is exactly a “component”, its level of integration or linking – static or dynamic? - and its proportional size compared to the global derivative solution), it would be wise to set up interoperability agreements good practices, authorizing the lender community to distribute also the whole developed solution under the lent component’s original license. In our example, “My_City_Admin” could as well be distributed under the GPLv3, as the need may be.
Such exchanges will be restricted to the members of the “circle of trust” that have concluded the interoperability agreement.
 
Interoperability combines some advantages: 

• Multiple agreements can be concluded (“one to one”, or “many to many” without unilateralism);
• One agreement has no impact on others, but could be open to new participants, if agreed by previous stakeholders;
• Reducing “license conflicts” (single or multiple, depending on agreements: more freedom / less barriers for developers);
• Reducing the impact of current “F/OSS nightmares” as: “how far linking is dynamic or static between F/OSS components and may generate or not copyright infringements?”;
• Formalising complementarities between strong copyleft licenses when useful (i.e.; between the multi-lingual EUPL and other more technical licenses;
• Implementing a culture of collaboration, rather than of confrontation;
• Simplifying licensing conditions in the case of complex F/OSS solutions (one single license can be applied to the solution as a whole, even when the solution integrates a large number of components; no need for “patented” consulting).

 
Now, why is this a way out from licence proliferation?
 
Interoperability will strongly reducing the impact of license proliferation, by creating a visible interoperable circle of trust. It will focus the attention of the F/OSS world on this interoperable set and on the extension of freedom that is made possible. Entering in the circle will be depending on the real weight of licenses (and not only on the compliance with OSD principles, as for obtaining OSI approval). It will depend on the agreement of other participants. This looks the best way to realise Bruce Perens wishes to reduce the number of F/OSS licenses. A new organisation (or institution or normalisation institute) is not needed, as interoperability will be based on direct agreements between the main copyleft license producers, after establishing the compatibility of their license freedoms.
 
It would be useful that OSI (for example, or/and FSF) takes some leadership, publish the principles (good practices) of such agreements and hosts a public repository of effective agreements. A first draft could be published on OSOR.eu, but all this is to discuss, to analyse in detail, to debate and implement. Agreements must be communicated to the public, but may not be part of licenses. For the EUPL which has already compatibility provisions, it would be enough (and easy) to update the compatibility list.
 
You will say I am a dreamer… but I am not the only one (John Lennon).