Skip to main content

A bug in the European license?

A bug in the European license?

Published on: 14/10/2010 Last update: 31/10/2017 News Archived

One of the important features of the EUPL 1.1 is that a recipient is forced to publish changes if the modified code is used in online services (for example Google docs and similar). Perfect, the advisor said, but… What if someone takes your EUPL v1.1 code, combine it with a small piece of GPL v2 code, publish it under the GPLv2 license (this is allowed by the compatibility list) and “voila”: this guy is not longer obliged to publish the code in case he use it for on line services (because under the GPLv2 license that's not required).

"Und jetzt haben wir den Salat" would be a striking German expression to describe the situation. And to make matters worse, he said, the EUPL states: “Should the Licensee's obligations under the Compatible Licence conflict with his/her obligations under this Licence, the obligations of the Compatible Licence shall prevail." Does such case undermines the spirit of the very strong copyleft character of the EUPL v1.1, he asked?

Well, the theoretical case reported by the advisor is well observed and could occur indeed: a pure on-line service provider may invoke a merging with a GPLv2 component to refuse the code publication that is compulsory under the EUPL (as it is also under the Gnu AGPLv3) in the case of SaaS. However, is it a "bug" or an accepted consequence of interoperability? In other words, "What is the most important aspect to prioritise: strict (strong /absolute) copyleft or interoperability?"

From the point of view of the European Commission leading IDABC or ISA programmes (where "I" focuses on "Interoperable"), we may assume that the answer is quite obvious.

First it must be understood that the EUPL interoperability does not allow developers to *change* the primary licence of any EUPLed component. It is only when *combining* a EUPLed component with another existing component under GPLv2, in a way it produces a *derivative work* that this "combined-derivative" work can be distributed under a single licence: the GPLv2 in this case. The EUPL component taken alone will keep its primary licence and anyone can make new derivative works out of it (under EUPL), combine it with other F/OSS components, merge it with other permissive components, or even with copyleft components (in this case under GPL, Eclipse/CPL, OSL, CeCILL, ...)

Ok (you will say), but what if some < malicious > developer make a wrong use of this facility and rapidly release some lines of his own written code under the GPL, and then - in a second step - merges it with the EUPLed code for distributing the whole work under GPL?

So what? If the unique purpose of this tricky manipulation is just to change the license, the new *combined-derivative work* will present no functional added value (and no interest for anyone): the outsider forking will fail or will stay limited to single use and the original EUPLed work - if it is continuously supported and improved by its community or origin – will survive and emerge in all cases.

At the contrary, if the new work presents a substantial added value (the combination implements derivatives that really complements or improve the original EUPLed component) the GPLed version may become the preferred one for a developers community supporting it. But this is the real purpose of the EUPL : it is not to “take” any “market share” in FLOSS licensing but it is to promote software reuse and sharing: "Strong" copyleft is not the most important objective of the EUPL. Many FLOSS experts, as Malcolm Bain (Cenatic - Spain), estimate that public sector should release under more permissive licences, and not under GPL or even EUPL. Like Malcolm, some analysts think that a too strong interpretation of copyleft (which has no legal basis in copyright law or case law) is contrary to freedom (at least to software writing and business freedom).

In the specific case reported, an on-line service provider may indeed bring substantial contributions to an EUPLed application, merge it with major GPLv2 components and keep the whole work secret, distributing it *only* as a service. This should not be considered as a "bug", but as an accepted consequence of a certain business freedom (choosing your business model) resulting from interoperability.

You have a quite comparable situation between the GPL family: while GPLv2 and GPLv3 are *not* compatible, many projects declares to be distributed "under the GPL" without even mentioning the version. However, GPLv2 (#9) and GPLv3 – which can be switched for AGPLv3 (#14) states "If Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation".

The choice of the EUPL is certainly to be copyleft, while putting the advantages of interoperability before claiming for a radical interpretation of copyleft principles. With more than 1.800 different FLOSS licences identified by specialists, the challenge is not maintaining too strong copyleft barriers between licences (and then lamenting about the fact of licence proliferation), it is to promote interoperability.

Login or create an account to comment.