European Public Licence
On Friday 25 January I attended an expert meeting discussing the European Union Public Licence (EUPL). This is the latest member of the growing open source licence ecology, and if I must say so, it is quite a nicely drafted document (biased opinion warning, as I helped in checking the Spanish translation). The licence is initially intended to be used as the official release method for projects funded under the IDABC framework, but it is also intended to be the first open source licence with an officially sanctioned translation in 23 official languages of the EU, which in my opinion makes it particularly useful for public sector administrations across the continent. This I think is a great example of the importance given to open source by the European Commission.
There are three main features in the licence that I think make it useful. The first is its clear language and largely unambiguous wording, which makes it easier to understand than other licences out there (*cough* GPL v3 *cough*). Secondly, the licence contains a small yet functional patent clause, which is valuable for obvious reasons. Thirdly, it has a clever compatibility clause which allows wider freedom to developers in order to release modifications under one of the compatible licences, namely GPL (v2), OSL, CPL, EPL and Cecill. Here are some of the highlights from each of the presentations:
Francisco García Morán from the Directorate General in IT gave a background presentation giving the reasoning behind the Commission's interest in OSS. He mentioned that there have been other programmes in the past. Why does the Commission promote open source? Because it avoids lock-in, and because it is a paradigm which uses the power of communities. The key elements present in OSS is that it promotes interoperability and the support of open standards, also that they are community-friendly, and that it enhances competition. He stressed that the EUPL is not a goal, it is a means to facilitate OSS activities from the Commission.
Karel de Vriendt from IDABC gave some more specific introduction about the licence. There is the fact that there is software developed and owned by the Commission, via contractors, or as work-for-hire. He then stressed that the GPL may have enforceability issues in Europe, so research was commissioned in order to study available licences. EU legal services were unhappy with existing OSS solutions, and the study confirmed this concern. The Commission hired UNISYS and legal experts in order to draft the licence, which was approved in 2006 and launched officially in January 2007 in French, English and German. The licence then was translated into the remaining 20 languages and launched in January 2008. The Commission intends to licence software within the IDABC funding framework with the EUPL, but it is hoped as well that local administrations in member states will adopt it.
Sevérine Dusollier from CRIS gave an excellent presentation on the legal background. She first explained the steps in the research leading to the final draft:
- Assessing the existing licences
- Adapting an existing licence? No
- Drafting new licence
- Making sure it is compatible with GPL
She stressed that the intended audience for the licence are public administrations. The fact that most of the existing licences are drafted with American law in mind created , the need to draft a licence that fits the European legal tradition. Some legal elements found in the research:
- Applicable law: most licences have US Law, Cecill uses French Law, OSL is the law of the residence of the licensor. EU Principle of choice if law is lex loci contractus, or consumer's residence.
- Jurisdiction: determined jurisdiction (US, California, Paris). OSL: country of residence of the licensor. EU principle: court of the defendant's residence, place where contract is performed, consumer's residence. Art. 238 Treaty of Europe gives jurisdiction to the ECJ in private matters.
- Terminology: US terminology and licensing style. GPL is valid in Europe according to courts, but making the language fit may require some work.
- Copyleft issues: moral rights are a problem for the copyleft clause, which creates compatibility issues (except in the UK, where software does not have moral rights).
- Liability and warranty: applicable law changes from one country to another, as this is a matter for commercial law and unfair terms. Limitation of liability clauses could threaten the validity of the licence, but it is all a matter of balance.
- Licence - Contract dichotomy: As it was mentioned before, other licences rely heavily on American law, where there is a practical distinction between a licence and a contract. The EUPL was drafted as a contract, but also to comply with the E-commerce directive.
- Compatibility: GPL monoculture creates some problems, particularly for lack of adaptation or lack of official translations into other languages.
Philippe Laurent also from CRIS gave a thorough analysis of the compatibility issues, too detailed to make it justice in a blog post. One of the things that I got from his presentation is that he explained compatibility really well by thinking about the direction in which the compatibility should work. In other words, if the EUPL wants to be compatible with the GPL, it can do so downstream. Code licensed under the EUPL could be modified and distributed under the GPL because the clause says that it is a compatible licence. However, at the moment, the compatibility is not reciprocal. Some other legal points:
- Defensive patent clause: simplified language that makes it different (and probably better) than the GPL v3.
- Compatibility clause: the EUPL is unique in having a compatibility clause. Shouldn't we be using the term interoperable? No, interoperability means interchangeability, compatibility can be one way or the other.
- Copyleft has problems for compatibility, as it creates obligations down a stream of distribution. The way to make EUPL downstream compatible with the GPL or others is through the compatibility clause, it creates a clause which specifically lists licences to be considered compatible. Those licences will be deemed compatible, therefore software under the GPL can be modified and distributed under the GPL. In case of conflict, the conditions of the compatible licence will prevail. I thought that this was a short and elegant way of dealing with licence proliferation.
- Distribution chains: bundle of licences is the main way in which this is done in GPL. EUPL adds sub-licensing.
- ASP issues: Application Service Providers. Does it trigger copyleft clause? Not clear at the moment. This is not a copyright matter, it is completely a contractual issue.
- DRM: not dealt with by EUPL.
- GPL v3 elements: Internationalisation, contractors and outsourcing, DRMs, anti-lock down (anti-Tivoisation), patents, additional terms. Anti-lock down is all sort of code embedded in hardware is subject to the provisions, but this seems a bit extreme as t covers products like ABS in cars. Intended devices are mobile phones and TiVO.
This is a rather sketchy look at what was a very rich meeting. There was an extended discussion session where many things were dealt with in detail. For example, at the moment the licence relies on copyright concepts such as "making available to the public". These are not harmonised and may be difficult to interpret, particularly when dealing with ASPs. The consensus seems to be that there will be some sort of political decision that will eventually deal with the questions of ASPs from a contractual basis, just like the GPL v3. There were also problems highlighted by some experts with regards to derivative works (potentially relevant to dynamic linking). The EUPL contains a copyright notice (the work is copyright of the European Commission), some people want to remove the copyright notice to the Commission because it is confusing. This may be relevant to the assertion of moral rights in the UK, but the consensus was that it is a superfluous element. A lot of discussion went into the limitation of liability as some jurisdictions may have issues with the validity of the clause because of legal requirements (e.g. double signature requirement in Italy). There was also discussion about future versioning: Should EUPL make GPL v3-like changes? The consensus was that not yet. There is compatibility already via GPL v2 and Cecill. Most importantly, there are some elements in v3 which may prove problematic, particularly DRMs.
4 comments:
There is compatibility already via GPL v2 and Cecill.
How is there compatibility via GPLv2? The EUPL appendix doesn't say "or later version" with respect to GPLv2.
Given that GPLv2 or later may be achieved via Cecill it seems silly to not list GPLv2 or later as compatible.
Hello Mike.
You could get downstream compatibility into the GPL v3 via GPL v2, just not interoperability.
Consider this hypothetical. Edinburgh City Council develops software and releases it under the EUPL, then developers from the University of Edinburgh modify the code and release their version under the GPL v2 (as it is currently possible to do because of the compatibility clause).
Assume that you get this GPL v2 code and you want to modify it ad release it under v3. As I understand, it would be perfectly possible for you to do so. See the compatibility chart under the heading "New Compatible Licenses" here:
http://www.gnu.org/licenses/quick-guide-gplv3.html
Note the dotted line between GPLv2 and GPLv3 in the graph and the text "GPLv2 is compatible with GPLv3 if the program allows you to choose "any later version" of the GPL,"
The question is whether the University of Edinburgh developers in your hypothetical could release the EUPL code as GPLv2 with the any later version choice. In other words, does the EUPL compatibility clause that permits GPLv2 allow GPLv2 release with permission to distribute under a later version?
Interesting question. Most of the experts at the Brussels meeting seemed to think so, and I would agree.
Even if the wording does not fit completely, I would argue that judges faced with a compatibility case would be willing to give the parties certain leeway with regards to stated interoperability clauses. I am a pragmatist, and I believe that the advantages of interoperability strip by far a strict reading of the licences.
Post a Comment