Guest post: 2010 – Threats to copyleft

This post is by Patrice-Emmanuel Schmitz, Director for European institution studies at Unisys Belgium (Brussels). His team is in charge of the www.OSOR.eu (Open Source Observatory and Repository), the Free/Libre/Open Source information platform and forge launched by the European Commission for public sector projects.

Combining freedoms and copyleft in the Gnu GPL licence (invented by Richard Stallman) was the cornerstone of free software. This is now questioned due to the proliferation of incompatible copyleft licences.

After counting 1,800 free software licences used in hundreds of thousands of projects, the Black Duck company patented (Patent US 7,552,093 B2) the technology for controlling the use of open source licensing in a multi-source development process (meaning combined works, elaborated from multiple free components under different licences).

No need to say that patenting proprietary technology to solve copyleft licences incompatibility may not be seen by everyone as a major achievement!

Lamenting on licence proliferation or blaming new licence authors – who all call upon the best reasons of the world, looks useless. It would certainly be reasonable, as recommended by Bruce Perens, to deal with only four permissive and copyleft licences, but this is wishful thinking. New licences are presented every week by FLOSS authors and communities, and no benevolent dictator will limit human innovation regarding licensing.

The heart of the problem does not lie in the number of licences, but in their incompatibility. I do not think that licence proliferation is a failure of the FLOSS movement, it is rather the entire contrary: a testimony of the attractiveness of FLOSS models. In reality, licence proliferation illustrates the failure of a certain model of strong copyleft, as it was initiated by the GPL in the ’80s and – unfortunately – reproduced by nearly all subsequent copyleft licences. Once necessary and successful, this model looks not adapted anymore because it was copied and – seeing the Black Duck patent – one may question (like Ernest Park has done) if the way copyleft is applied does not generate today more jails than freedom.

According to my first study for the European Commission, the Gnu GPL v2 was used in 85% of the FLOSS projects in 2001. With a copyleft that was – maliciously – said “viral” by some, meaning that compatibility is always “upstream” (to itself) and never “downstream” (to other licences), the adoption rate of the GPL should have been universal in 2010, confirming analysts’ assumption that “it is good for the community if people use a single copyleft license [1]”. However, the exact reverse happened: the GPLv2 (reducing) is still used in 50% of projects, the new GPLv3 reaches little more than 5% and other licences are proliferating.

The fact a dozen of licences are used by 90% of the FLOSS projects does not help very much, as the implementation of free solutions (which are often combined works) is done through integrating many components. It is enough to find only one incompatible licence to compromise the distribution of these solutions.

The current situation is damaging for other reasons: it creates endless discussions on what could be considered as integration in combined works (dynamic or static linking) and it feeds disputes. To preserve their communities from schisms, gurus and acolytes urge followers not to use any other copyleft licences, whatever their specific merits or advantages could be. It is time to admit that the strategy of keeping a “captive asset” of licence 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 FLOSS world.

In Europe, the recent – OSI approved and copyleft – European Union Public Licence (EUPL) meets some initial successes due to its compliance with Member States’ law and because it has equal value in the 22 languages of the Union. It has been selected by the German Federal Agency for Information Technologies, it is the licence of choice in schemes published by the Dutch NOiV (see on the www.OSOR.eu site an English version of this scheme, translated by a member of the Swiss administration), a dedicated EUPL site was created in Italy, etc. In Spain, the Ministry of Industry, Tourism and Commerce (where the public agency Red.es is located, in charge of information technology) provides the following in call for tenders (software specifications):

“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 licences and rights necessary to transfer the ownership of the development to , which will submit it, including the elements that are performed under the contract (such as fonts, dll, scripts, etc..) to the public licence EUPL. In any case the total and final result of the development and the overall project will be subject to a licence EUPL.”

Applying such provisions excludes strong copyleft components from the delivered combined work: all original developments are allowed; all “permissive” components are allowed (BSD, MIT, etc.); all “weak copyleft” components are allowed (i.e. LGPL), but no Gnu GPLv2 (or V3) components (except if the copyright owner is entitled to dual license the component under LGPL-like terms, for the purpose of addressing the contractual specifications).

The EUPL itself has an innovative approach to solve copyleft licence conflicts: it publishes a downstream compatibility list (to other licenses). It is allowed to integrate EUPL components in a combined work that will be distributed under a compatible 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 combined or derivative works: if the library is propagated on its own, it must be under the provision of its original licence (LGPL), but if the library components are part of a derivative work, this work can be licensed under another licence, while the original library remains LGPL. The EUPL compatibility is exactly the same, but its copyleft effect is stronger than in the LGPL (because compatibility is restricted to a limited and published list of other copyleft F/OSS licences). Therefore it is not a weak but – say, a “tolerant copyleft”.

Such flexibility removes incompatibility barriers and restores developers’ freedom, while keeping it in the limits of the desired copyleft effect.

While the EUPL solution may be considered as a conceptual progress, its tangible impact will stay very limited as long other copyleft licences will not give some reciprocity: the quantity of available EUPL-ed material is quite small today, compared to the mass of components that are already available under the GPL terms. Extending the list of EUPL compatible licences (i.e. by adding the still missing GPLv3) will not change the issue resulting from the Spanish specifications, where the government requires the facility to distribute the received combined work under the single licence of its choice (the EUPL in this case).

Solving problems related to the proliferation of copyleft licences requires setting up interoperability provisions between these main licences. It will create, and focus attention, on a kind of “circle of trust” where the original copyleft licensing condition of a software will never be changed, but where – just to take an example – a GPL component could be part of a combined work that the recipient (let’s say the French or the Spanish government) could distribute as a whole under the provision of the copyleft licence of its choice (i.e. CeCILL or the EUPL) provide these licences are allowed in the compatibility list.

The Gnu GPLv3 includes (in its section 13) the exact provision corresponding to the above need, but it is directed to the AGPLv3 only. The intellectual effort to extend this provision in direction of a small list of interoperable licences seems easy to deliver. The reciprocal condition must be added: in the example above, the combined work could be also (as the need may be) distributed under the provisions of the GPLv3.

This could be a way out to the deadlock where we are, due to the proliferation of incompatible licences.

Looking for alternative? Pay a Black Duck patent licence!

Patrice-Emmanuel Schmitz – www.OSOR.eu

[1] R.T. Nimmer, Legal issues in Open Source and Free Software distribution, The Law of Computer technology, Ch. 11 (1997, 2005 Supp.) (“Two different copyleft licenses are usually “incompatible”, which means it is illegal to merge the code using one license with the code using the other license; therefore it is good for the community if people use a single copyleft license (GPL)”).

7 thoughts on “Guest post: 2010 – Threats to copyleft

  1. It’s another example of software method patents, the threat is to everyone, developers and users. I believe they went for the patent(s) because the whole patent battle is a game won by those that get it first with the USPTO, as it is.

  2. The compatibility issue is indeed a significant problem. Our audits have shown that roughly one half of open source projects we audit suffer from some sort of licensing incompatibility issues, with about one fifth suffering from serious problems.

    For a few examples, see the OSS IPR Database at http://oss-ipr-database.com/ (we started posting summaries of our audits there to help spread knowledge of the problem).

  3. It seems indeed a pity that – due to licence incompatibility, strong copyleft software modules licensed under GPLv2 or v3 would be pushed out of combined works delivered to governments! Producing such collateral damage was certainly not the original purpose of copyleft (aimed to protect the free software community from their copyright appropriation). In such cases, – I mean the production of combined works, It would indeed be appropriate to extend interoperability between copyleft licenses. I fear that bringing even a small modification to licences like the GPLv3 would be a huge job. However, does the FSF care about what is happening in Europe?

  4. GPLv3 and AGPLv3 material can be combined, but the combination is effectively under the AGPLv3 and is subject to the special requirement that source be available to users interacting with the program over a network. Allowing the combined work to be relicensed as GPLv3, as suggested, would defeat the purpose of the AGPLv3.

  5. Well, Matt, I do not think so: If the primary license of a component in a combined work is AGPLv3, the purpose of interoperability provision (with the EUPL in my example) would be to enable licensing the whole combined work under EUPL (which is an “Affero” license) and under AGPLv3 (and not GPLv3 in this case). In general, interoperability should not modify the primary licence of a component.

  6. Pingback: EUPL.it segnalato su OSS Watch Team Blog

  7. OK, the reference to the GPLv3 misled me about the point you were making.

    Note that two nominally different licenses with identical terms are compatible; incompatibilities are a result of substantive differences between license terms. To the extent that the differences reflect a community’s intent not to allow its work to be used under the other terms, it would be wrong to just add a relicensing provision. The differences should be discussed and their implications understood first.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>