The EUPL community publishes here (anonymously) some questions submitted to the JOINUP Legal support.

Question:

A commercial economic operator (company) should be able to adapt sources distributed under the EUPL and use it in their environment, without being forced to publish the sources of the other linked programs under the EUPL: the licence should not be viral! What is the situation?

Comments:

The EUPL is “Share alike” on the covered code but is not “viral” for two reasons:

• First, because it was not the intention of the European Commission to produce a viral licence, and the licence provisions are not going in such direction.
• Second, because the European legal framework has implemented exceptions to copyright rules, which could invalidate many claims for viral effects (and this is true for all licensed software, not only software covered by the EUPL).

Lets’ explore the first reason:

The motivation for producing a “viral” free software licence is the promotion of the Free Software movement, with the willingness to extend it up to the maximum possible. This is the intention of the Free Software Foundation (FSF), drafter of the GPL licence, giving its view in the GPLv2-FAQs:

You have a GPL'd program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? - Yes.

It is significant that the FSF question is about linking with a proprietary program (and not with another open source program covered by another copyleft licence, which is a growing possibility with the venue of new licences as the EUPL, OSL, EPL or even the GPLv3 or AGPLv3). Anyway, the assumption (that is not confirmed by case law, but that is promoted by many lawyers except a minority) is that in case of static linking of the GPL covered source with other projects or programs, the GPL coverage is extended to these programs (because the GPL protects both source and binaries, and static linking merges binaries in a permanent object).

This is the reason why the term “viral” has been applied to the Gnu/GPL licence. The term is quite controversial because it has been coined by opponents to the GPL and may generate unreasonable fears.

Backing its assumptions, the FSF has created the more permissive LGPL “in order to permit linking covered libraries into non-free programs”: a work can be compiled or linked with the covered source without becoming a derivative work, and therefore falls outside the scope of the LGPL (Art 5 LGPL v2.1). The covered source code (and its specific modifications) will stay covered by the LGPL, but the larger work made by using and linking it (including the other linked projects) can be “distributed under any terms (of your choice), provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications” (Art 6 LGPL v2.1).

Although respectable, free software evangelisation is not the priority of the European Commission and of the European public sector in general: they mainly believe that developing, publishing and distributing their public software according to open source principles can be the most efficient, appropriate, and helpful incentive for a sustainable local ICT economy. Their current approach for open data (“an engine for innovation, growth and transparent governance” according to COM (2011) 882) is quite similar. In addition, they want to avoid the risk – even quite theoretical – to suffer from an exclusive appropriation of the distributed software, in a way they could spend public money again (twice) for some new proprietary version or improvement. This is the reason why the EUPL licence had to be both open source and share alike (or “copyleft”).

As a result the provisions of the EUPL, which protect both the source code and the binaries, avoid to determine what could be a derivative: “This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work; this extent is determined by copyright law applicable” (article 1 EUPL). This allows judges to accept “de minimis” exceptions for all cases of trivial similarities or when a work is not clearly a derivative, meaning containing (after some cut and paste action) significant portions of code or merging/linking codes for other purposes than ensuring interoperability.

In addition, article 5 of the EUPL permits distribution of larger combined derivatives under a “compatible licence” when one of the merged component was obtained under these (currently five) compatible licences listed in its appendix. This is not a re-licensing of the code covered by the EUPL, but an exception that is applicable to the larger combined derivative only. All licences listed in the appendix are also share alike (i.e. the GPL). However most of them, i.e. the Open Source License (OSL) and the Eclipse Public Licence that is share alike on the source code only, have no pretention to be viral. In fact, concerning these larger combined derivatives, the EUPL works exactly like the LGPL. The difference is that the EUPL is less permissive than the LGPL, which authorises distribution of larger works under any licence.

The second reason why the EUPL is not viral is the European Legal framework itself.

Because of its article 15, stating that “the licence shall be governed by the law of the European Union country where the Licensor resides or has his registered office”, or “by the Belgian law if the Licensor has no office inside a European Union country”, the European legal framework will always govern the EUPL. This provides the advantage that, in case legal interpretation is needed, questions could be processed by a unique jurisdiction: the European Court of Justice.

Directive 91/250 (revised and codified by Directive 2009/24/EC) has implemented exceptions to the acts that are restricted (without a specific licence or permission) by the copyright law.

In particular, article 6 of the Directive states that  the authorisation of the right holder shall not be required where a permanent or temporary reproduction of the code or its adaptation / alteration are indispensable to obtain the information necessary to achieve the interoperability of an independently created computer program with other programs.

At the time of writing the Directive 91/250 (21 years ago), the hypothesis of open source code was not considered. Therefore, article 6 authorises reproduction of the needed pieces of code after a decompilation, in case the person performing this reproduction has the right (a licence) to use the program and has not obtained from the licensor the information necessary to achieve interoperability.

An important point is the nature and content of code written, i.e. for linking purpose: In one of the first and recent case of application of directive 91/250, the European Court of Justice (2 May 2012, Case C‑406/10) considered that “neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression that is protected by copyright under Directive 91/250.”.

Concerning the method used for the “reproduction”, C-406/10 brings little clarification or extension: the litigation opposed two proprietary software vendors and no source code was disclosed. The licensee did not have a legitimate access to the source code of the licensor and did not carry out any decompilation of the object code of that program. Reproduction was done by means of observing, studying and testing the behaviour of the program, reproducing its functionalities by using the same programming language and the same format of data files. In this case, the Court made a very literal application of Directive 91/250, considering that copyright in a computer program cannot be infringed where the lawful acquirer of the licence did not have access to the source code of the computer program to which that licence relates, but merely studied, observed and tested that program in order to reproduce its functionality in a second program.

Would the interoperability exception be denied if the lawful acquirer had obtained the source code as being the recipient of a valid open source licence? It seems strongly un-logical to say “no”, even if the situation is not foreseen in Directive 91/250. In such case, the difference is that decompilation is not necessary: the needed information - the data formats, the application program interfaces (APIs) can be found and “reproduced” (what is the exact difference with “copied”?) from the source code, in order to establish the permanent (static) or temporary (dynamic) linking. It is hard to imagine why (in case of decompilation or in case of legitimate access to the source code) the solution should be so different.

Article 6 of Directive 91/250 implements additional conditions to the exception. In particular, it cannot be used for goals other than to achieve the interoperability of the independently created computer program, and the exception cannot be interpreted in such a way as to allow its application to be used in a manner which unreasonably prejudices the rightholder's legitimate interests or conflicts with a normal exploitation of the computer program.

In our opinion, the last condition, preventing to “unreasonably prejudice the rightholder’s legitimate interests” (article 6.3.of Directive 91/250) should protect the open source (or free software) licensor: assuming that you decide to distribute software under the EUPL (or the GPL, or another share alike licence) your fundamental interest is to protect your asset by placing it under a legal regime that is both open and share alike in case of modification and re-licensing. So, linking for interoperability reasons two programs covered by different copyleft licences (for example by the GPLv2 and by the GPLv3 that are *not* compatible, for distributing the linked component under GPLv3) does not prejudice the legitimate interests of the GPLv2 copyright holder (while a distribution under a proprietary licence would cause that prejudice). This interpretation of Directive 91/250 (to be confirmed by case law, as the case may be) would be beneficial for legal interoperability between programs covered by different open source licences and be a way to limit the negative impact of open source licence proliferation.