A look inside the EC Open Source Software Strategy 2020-2023

On October 21st (2020), the European Commission approved and published its Open Source Software Strategy 2020-2023 that focuses on sharing and interoperability.

Under the theme ‘’Think Open’’, the strategy sets out a vision for encouraging and leveraging the transformative, innovative and collaborative power of open source, its principles and development practices. It promotes the sharing and reuse of software solutions, knowledge and expertise, to deliver better European services that benefit society and lower costs to that society. The Commission commits to increasing its use of open source not only in practical areas such as IT, but also in areas where it can be strategic.

Concerning sharing, the strategy (section 5.3) states that software produced by the Commission services, in particular software produced with the objective of being used outside the Commission, will be open sourced and published on the Joinup platform and will use the European Union Public License (EUPL), which is a reciprocal licence: in case the software is modified or improved and redistributed by a third party, its source code must be published and provided back under the same licence, or under a compatible licence when the code is integrated in another project.

This bring us to interoperability (section 5.6), as the Strategy states that the produced software should aim to be interoperable. The key to interoperability is the use of well-established standards and open specifications. To ensure our digital sovereignty and guarantee a level playing-field, for all future IT developments the Commission will promote standards and specifications that are implemented and distributed through open source software, and include this in its corporate governance approach.

Although a central point in the EU strategy, it is amazing that interoperability is still not understood by many people, including some lawyers: In a recent case of copyright infringement, the recipient of software covered by the AGPL licence (it was an Italian governmental body) had copied most, if not all, of the received software in its own solution and redistributed this solution (under its own new name) under the EUPL licence. But of course, this was not permitted by the AGPL, which is incompatible with all other outbound licences. It is the EUPL that is compatible with the AGPL, but – unfortunately, the reciprocal case is not true.

The case was clear-cut, and this (involuntary, hopefully) copyright infringement was solved by amiable settlement, but one of my honourable colleagues, an Italian lawyer, questioned the concept of interoperability. It is an imprecise language (he said) that “led the Italian governmental body to believe that indeed, because EUPL and AGPL were reportedly "compatible" or "interoperable" without further specification, they could get away with relicensing a project that was licensed originally as AGPL, despite in more in-depth documentation about EUPL this distinction is made graphically clear.” My colleague added that the wording “interoperable", was not a legal concept he could discuss, because unknown to him.

But, although admitting it had no real role in the disputed case, my colleague lost sight of an important point: interoperability IS a clear legal concept. It was forged 30 years ago by Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs, which has defined interoperability as "the ability to exchange information and mutually to use the information which has been exchanged" (Recital 10) and that for implementing this interoperability, the reproduction of "interfaces" (also defined in recital 10 as "the parts of the program which provide for interconnection and interaction between elements of software") is authorised as a copyright exception to the author's exclusive rights (possibly formalised in a copyright licence), provide this exception is not used in a way which prejudices the legitimate interests of the rightholder or which conflicts with a normal exploitation of the program. (Recital 15). This exception targets components that are otherwise independent in their normal exploitation and where made interoperable by their legitimate licensee for combining them in a broader multi-functional system.

The concept of interoperability and this exception, as defined above, are used later in the Directive (article 6) for authorising the extraction (via a de-compilation process) of the needed source code. Drafted at the end of the 80’ and published in May 91, the target of the directive was proprietary software, where the provider keeps the source code hidden from the legitimate licensee who receives the object code only. Therefore the exception implemented by article 6, allowing this licensee to retrieve this source code (by the technical mean of de-compilation) and to reproduce it freely for ensuring interoperability. The Directive did not mention “Open Source”, which is a later concept (emerging in 1998 as a schism of the free software movement created earlier by Richard M. Stallman, who published the GPL-2.0 licence in 1991), however, it looks obvious that the exception implemented for the benefit of the licensee (the freedom to retrieve and reuse the source code of interfaces) should not be more restricted if the software is received under an open source licence, and not a proprietary licence. The sole difference is that, in the case of open code, no de-compilation is needed because the source code is provided to the licensee: a simple copy will do the job.

According to the above, lawyers like Niklas Plutte and others categorised the EUPL, which is governed by EU law, as “interoperable”, which is indeed a well-defined legal concept (https://www.ra-plutte.de/open-source-software-recht-grosse-faq-tipps/).

The real legal concept to question now is rather the famous “strong copyleft” theory, still promoted by the Free Software Foundation, who states that “Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination” (https://www.gnu.org/licenses/gpl-faq.en.html ). Such statements are the core of the “linking produces derivative” theory that many, like Lawrence Rosen in a recent “License Discuss” forum, involving also Bruce Perens and other pioneer contributors, consider as causing more damages than benefits to free software, because at the origin of “viral” fears and because security experts and risk-rating organisations classify all GPLs (and behind them all reciprocal licences, including the EUPL) as “high risk” licences, which is really damaging and false.

Why not politely suggest to the relevant organisations (Free Software Foundation and Open Source Initiative) that it is time to move the lines?

More information: the EC open source strategy (in EN, FR, DE) 

https://ec.europa.eu/info/departments/informatics/open-source-software-…