Skip to main content

EUPL v1.2 – a Free Software Licence (FSF said)

Better late than never…

Published on: 10/08/2018 Last update: 02/10/2018 News Archived

It took some times for the Free Software foundation (FSF) to include the EUPL v1.2 in its “official” list of free software licences. It was done at the beginning of July (2018), while 1.2 was published one year ago in the Official Journal.

To be recognised as “Free Software”, a licence must grant at least four freedoms to the program  users:

  • The freedom to run the program for any purpose;
  • The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this;
  • The freedom to redistribute copies;
  • The freedom to distribute copies of your modified versions, giving everybody chance to benefit from your improvements.

The FSF provides an additional distinction between licences that are compatible with its own GNU GPL (green section) and licences that are not or not fully compatible (yellow section). The EUPL v1.2 is still classified as “GPL-Incompatible”, which look astonishing since the EUPL Appendix lists all the existing GNU licences as compatible: the GPLv2, GPLv3, AGPL and LGPL.

The FSF and its president and founder Richard Stallman reason for maintaining this classification is as follows: the EUPL Appendix permits a reuse of the code in programs covered by the GPLv2 and the GPLv3, but it does not extend this compatibility to the “GPL v3 or any later version of it” known as the GPLv3+. Therefore if in some very hypothetic day a GPL v4 would be discussed and adopted, there is no formal guarantee that the compatibility would be extended.

The EUPL Appendix states that “the European Commission may update this Appendix to later versions of the above licences without producing a new version of the EUPL, as long as they provide the rights granted in Article 2 of this Licence and protect the covered Source Code from exclusive appropriation." Therefore, it looks clear that if someday a GPLv4 would be adopted, the appendix will be updated within short delays, without the burden of adopting a new version of the EUPL. The simple condition is that this GPLv4 must still be checked as a real free license. 

Yes… Mr Stallman said, but the text states “the European Commission may” and not “must”! In other words, FSF requires trust from the Commission, but refuses that trust to the Commission. What's fun is that such very hypothetic issue would not exist if the GPL itself was compatible with its own later versions. But that is not the case: GPLv2 is not compatible with v3 and nothing in the v3 states that the covered software could be distributed under its own later versions (and vice-versa).

There is more to be said about the complex and quite ambiguous message the FSF communicates about the EUPL. On the FSF site, this message is developed in three points as follows:

  °(The EUPL v1.2) is a free software license. By itself, it has a copyleft comparable
    to the GPL's, and incompatible with it. However, it gives recipients
    ways to relicense the work under the terms of other selected licenses,
    and some of those -- the Eclipse Public License in particular -- only provide
    a weaker copyleft. Thus, developers can't rely on this license to
    provide a strong copyleft.

    The EUPL allows relicensing to GPLv2 only and GPLv3 only, because those
    licenses are listed as two of the alternative licenses that users may
    convert to. It also, indirectly, allows relicensing to GPL version 3 or
    any later version, because there is a way to relicense to the CeCILL v2,
    and the CeCILL v2 gives a way to relicense to any version of the GNU GPL.

    To do this two-step relicensing, you need to first write a piece of code
    which you can license under the CeCILL v2, or find a suitable module
    already available that way, and add it to the program. Adding that code
    to the EUPL-covered program provides grounds to relicense it to the
    CeCILL v2. Then you need to write a piece of code which you can license
    under the GPLv3+, or find a suitable module already available that way,
    and add it to the program. Adding that code to the CeCILL-covered
    program provides grounds to relicense it to GPLv3+.

The first point (developers can't rely on this license to provide a strong copyleft) would require a long development, because most of the “strong copyleft” concept is related to the extension of the licence coverage in case of linking. According to the European law (Directive on the legal protection of computer programs, recitals 10 and 15), linking two programs that a recipient has purchased or legitimately received under any license can be done without any permission of the copyright holder and therefore cannot be restricted by any license.

Stallman agreed regarding private linking (for own use): “The GPL does not place any conditions on private modification or combination” he wrote. “when we talk about linking or otherwise combining programs, we always mean for distribution of the combination.”

However, the European Law does not fix any restriction regarding distribution. It seems that as soon the parts of the source code that are strictly necessary to make two programs interoperable may be reproduced freely by their legitimate recipients, without the copyright holders permission or restrictions, the recipient of program A (under license X authorising distribution) and program B (under GPL authorising distribution) may distribute a combination of A-B (even statically linked, i.e. by reproducing data area needed for interoperability). In such case, the two components could keep their original licenses (GPL for component B and license X for component A). The original purpose of the EU law was to provide more freedom to the legitimate licensees of proprietary programs (i.e. when the source code for making the various components interoperable was hidden and not accessible, except by de-compilation). This was illustrated by the Court of Justice in the case SAS/WPL where WPL distributed its own software specifically designed to be interoperable with the proprietary SAS software and to exploit SAS data, but distributed under its own proprietary WPL licence. 

Concerning the second and third points, the term "Relicense" that is used by FSF could be misleading. "Reuse" or "Merge with software under GPL" in another project is more appropriate and authorized by the EUPL, but "Re-licensing" a project licensed under EUPL is copyright infringement.

So, but what is the difference? "Re-licensing" is changing the licence of a program: something the copyright holder can do, and no other. If a program "Thunder" is licensed to you under the EUPL, you (recipient) cannot distribute copies of "Thunder" under the GPL. Reusing or merging code is something different: you may access the source code of “Thunder” according to the license given freedoms and copy/ the parts you need to enlarge the functionalities of your own program "Storm", licensed under the GPL. And due to the EUPL compatibility list, you may continue to distribute "Storm" under the GPL, even when it is partly a derivative of "Thunder", as the attribution marks present in the source code (and to preserve according to the EUPL) will demonstrate. In the meantime, "Thunder" will stay distributed under the EUPL.  This is the letter and the spirit of the EUPL.

But, Stallman said, “Modification include deletion.  Thus, someone can download Storm and
delete all but those parts of Thunder, and continue distributing under
the GNU GPL.”

True. Stallman is legally correct, but provides here a good example of thinking right legally and wrong reasonably! This is illustrated as well with the comic suggestion of a two-step relicensing via the CeCILL license. What would happen if a Mister Nobody distributes such program, copied from some European Commission licensed work, without adding anything new except changing the name (and logo, web site etc.), without planning any development, without any supporting organisation or a community of developers? The answer is obvious: nothing. Legally, you may imagine many distortions or ways to "get around" (i.e. by renaming a project as it was a new one, after adding some trivial GPL code to it or after the proposed two-steps “relicensing” via CeCILL). This is not the letter, neither the spirit of the EUPL and it would just be wasting time and reputation. The situation would be different if the recipient has a real project, mobilises a community, develops the program and gives it new life and functionalities, because this is the way free software builds and improves, requesting leadership and efforts.

Source: https://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses

 

Comments

Andrew Berezovskyi Thu, 06/07/2023 - 21:00

The EUPL v1.2 is still classified as “GPL-Incompatible”, which look astonishing since the EUPL Appendix lists all the existing GNU licences as compatible: the GPLv2, GPLv3, AGPL and LGPL.

I think it was clear that "EUPL [...] By itself" in FSF's analysis meant EUPL sans the Compatibility clause. But the Compatibility clause is an essential part of EUPL and therefore I agree with your astonishment.

Login or create an account to comment.

Referenced solution