The meaning of “Copyleft” in…

The meaning of “Copyleft” in EUPL

(a legal expert opinion)

In an open source licence, the impact of a copyleft clause is quite clear: the same licence must be reused when re-distributing the covered work and its direct modifications or the derivatives where significant parts of the work is copied/integrated/adapted etc. Therefore, the EUPL is copyleft for avoiding any re-licensing of the work under another licence that could even be proprietary (meaning exclusive appropriation). In addition, and when it is necessary for legal interoperability reasons, the EUPL authorises the licensing of combined derivatives under one of the compatible copyleft licences that are listed in the EUPL Appendix.

Things become less clear since an important fraction of free software supporters have put forward a distinction between strong copyleft (that would be produced by the GPL and AGPL licences) and weak copyleft (that would be produced by the LGPL or MPL licences, for example). In their mind, strong copyleft would grant a better protection, because linking the covered files with other works would extent the coverage of the strong copyleft licence to the whole application: all linked or combined files would become covered. Opponents once qualified this as a “viral effect”.

Although often highlighted by some free software lawyers, this notion of “strong copyleft” has never been recognized by case law. On 2 May 2012, the Court of Justice of the European Union ruled that a software licence cannot prohibit the legitimate licensee from reproducing the portions of covered code (for example, the APIs or data structures) that are necessary for interoperability and for linking the covered work with others that could be licensed differently. This was ruled in application of the Directive 91/250 EEC on the legal protection of computer programs. In fact, the case (c 406/10 SAS vs WPL) involved proprietary software vendors and no open source licensors. The portion of code that was necessary for linking the two programs was “reproduced” (by some human/intellectual deductive process), while the Directive authorises much more: to decompile the licensed program (obtaining the original code automatically from its object through a de-compiler program). However, there are no serious reasons to believe that the Court would have ruled differently in case the requested portion of code would be legitimately available to the licensee without the need to decompile the binaries, as open source published code. In such case, copying the needed APIs or data area seems compatible with fair practice.

Because of this, and in so far linking (even statically) is done for interoperability, does not prejudices the legitimate interests of the rightholder and does not conflict with a normal exploitation of the covered program, it seems that the differentiation between strong and weak copyleft has few legal reality. In applying all relevant licences, the copyleft effect should target the copies and real derivative works, where a significant portion of the functional covered code has been copied, modified, extended etc. At the contrary and in all cases, it seems that in European law the fact of linking two programs and the technology used for it (i.e. dynamic or static) does not by itself produce a derivative work. This is the reason why it was considered that adding copyleft licences like the LGPL or the MPL to the EUPL compatibility list was not more problematic than adding the GPLv3 or the AGPL.

When updating the list of compatible licences in its draft EUPL v1.2, the European Commission added: “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 (= the open source rights) and protect the covered Source Code from exclusive appropriation. This is indeed the objective of the copyleft in the EUPL: banning exclusive appropriation of the covered work by any third party. Outside this objective, there is no idea of “invading” linked works.

P-E Schmitz, legal support,

The content of this field is kept private and will not be shown publicly.