The European Union Public Licence (EUPL)

Patrice-Emmanuel Schmitza

(a) Legal expert – www.Joinup.eu.

DOI: 10.5033/ifosslr.v5i2.91

Abstract

This paper details the origin and main characteristics of the European Union Public Licence (EUPL), an OSI-approved free or open source software licence, copyrighted by the European Union. It focuses on the new version 1.2 of the EUPL that has been drafted in 2013, which the European Commission reports will be published before the end of the year. However, comments are relevant for the version 1.1 as well. What makes the EUPL unique is its multilingual working value, specific warranties, references to the Court of Justice of the European Union and its provisions related to licence compatibility, making its copyleft “variable” for facilitating interoperability. The operation of this copyleft component of the licence is probably its most specific aspect, sometimes wrongly understood as a possibility for “relicensing”. This is therefore especially developed in this paper.

Keywords

Law; information technology; Free and Open Source Software; licence; EUPL; European Union

Origin of the EUPL

1. grant all Free (or Open Source) software freedoms;

2. ensure protection from exclusive software appropriation (therefore be a “share alike” or “copyleft” licence);

3. have working value in all official EU languages (so there is no need for sworn translators in Court and related institutions for translations);

4. conform with European copyright law and terminology;

6. clarify the applicable law and competent court, as requested by EU institutions;

7. approach warranties and liability in conformity with “Case law” (a general exclusion of liability is not valid before most European courts); and

8. not be too long, too complex, but be comprehensive and pragmatic.

EUPL and Licence Proliferation

To compensate the issue of licence proliferation, the EUPL has chosen a system to ensure legal interoperability between potentially incompatible licenses (see below). The EUPL has also inspired other (non-EU) governments (e.g. Quebec in Canada), which have asked permission to adapt the EUPL so as to use it as a template for their own needs (changing names and jurisdiction only). In such case, maintaining the same list of compatible licences may strongly reduce the impact of such licence proliferation.

The EUPL Used as a “Reference”

Therefore, suppliers must not only assign or license to the contracting authority the IPR of the solution (including the software code), but must also guarantee that it can be legally (re)distributed to third parties by the contracting authority, without any copyright infringement issue or licence conflicts (if several components of the solution were distributed under non-compatible FOSS licences) and royalty free (e.g. to cater for the situation in which some proprietary standard or patents were implemented).

“The supplier will grant that the purchasing authority has the right to distribute the delivered application under the European Union Public Licence (EUPLv1.1 or later) or any licence(s) providing the rights stated in the article 2 of the EUPL.”

Such reference to the EUPL is especially convenient due to its multi-lingual validity: it can be part of public procurement specifications written in any language of the EU.

Rights Granted by the EUPL v1.1

The rights granted (by article 2 of the EUPL) to the recipients of the covered Work are un-modified through all versions of the license. They are those required by the Open Source Definition (OSD): to use, reproduce, modify, communicate, and re-distribute the work.

In addition, it is stated (in article 2) that the exercise of such rights and the use of necessary licensor patents (if any) must be royalty free (RF). This means that one may sell software or works covered by the EUPL (e.g. for a lump sum representing a contribution to the development costs of a standard or of a software solution, or a fixed maintenance fee for support services etc.), but once this is done, any further exploitation of the covered Work itself (but not necessary a larger work using the EUPL software) cannot be subject to the payment of royalties (e.g. a fee – even small or reasonable – per use or per user).

What Made the EUPL v1.1 Specific?

The EUPL is specific and different from other FOSS licences on a number of points:

• •Multilingualism
  This point is the most visible: like many other European Union legal instruments, the EUPL is available in 22 languages. Gaelic and Croatian version have yet to be published. 

• •Terminology
  The EUPL is drafted to work under European Law, even if it may be used outside the European Union and submitted to third country courts. Relevant provisions include the copyright terminology (the “communication to the public”), the limitation of liability clause, and the reference to European treaties.         

• •Warranty
  The covered work is licensed without warranty, except one important one: the original licensor and every subsequent contributor warrant that they are the authors (or licensees with sufficient rights) of their own contributions. This reinforces the security offered by the licence (regarding possible copyright infringements) and is in the end the type of requirement that one finds in most reasonable contributor agreements.
   

• •Reference to the European Court       
  Taking advantage of the treaties (TFEU), the EUPL will benefit from interpretation by a unique jurisdiction in case of litigation: the Court of Justice of the European Union. In addition, the 28 Member States jurisdictions may address questions and be answered by a single European Court.         

• •Variable “Copyleft”       
  The EUPL is “copyleft” on source code and binaries, but its share-alike effect is, in the interest of license interoperability, variable19 in the case of combined derivative works, as discussed below. The fundamental purpose is to avoid exclusive appropriation of the covered software. 

Changes Planned in the EUPL v1.2

The EUPL v1.2 will present the following main differences with the previous v 1.1:

• •Terminology is adapted in consideration of the Lisbon Treaty (this concerns the name of EU institutions and the references to the TFEU) in articles 14, 15; 

• •The licence now covers “the Work” – in version 1.1, it referred to both “the Work” and to “the Software”, which was confusing. The Work can be software, but also any other kind of copyrighted work: copyrighted data, specifications, documentation etc. – the modification is done in the introduction and in articles 1, 4 and 7; 

• •The scope of possible “additional agreements” is enlarged (i.e. they may cover jurisdiction and any other provisions, in so far as the granted rights are not restricted) – in article 9; 

• •The list of compatible licences is extended to licences published after the initial EUPL: GNU GPLv3, AGPLv3, MPLv2, LGPL v2.1 and v3, CeCILL v2.1. The list is extended to the EUPL itself (all versions as from v1.1) – in the Appendix of compatible licences according to article 5 EUPL.   

Software covered “by the EUPL” will be automatically covered by the new license version, but licensing of software covered by “the EUPL v1.1 only” will not. After publication of the EUPL v1.2, it will still be possible to distribute code under the EUPL v1.1 only.

How is the EUPL's Variable Copyleft Implemented?

Interoperability (at licence level) is the possibility to reuse the covered code in other projects, possibly in combination with code(s) covered by other licences, while keeping the freedom to distribute the resulting combination, even when considered as a derivative or composed work under copyright law.

Interoperability is a non-issue with permissive licences (as the BSD, the MIT) because – with the exception of respecting copyright notices - they establish no conditions for copying, merging and/or redistributing the covered code, even inside the software code of proprietary or non-free applications.

The EUPL is one of these share-alike licences, and the following question is posed: how strong is the EUPL copyleft? In other words, to what extent must any re-distribution of the work or any combination of software with the work be done under the same EUPL licence, according to its share-alike terms? And therefore, is the work protected from subsequent distribution under other licensing terms, which could lead to appropriation for the benefit of a third party software vendor?

In order to understand the way the “variable copyleft” of the EUPL operates, we can analyse three cases:

1. a)The normal case where a copy or a derivative work is distributed 

2. b)The exception for interoperability, implemented by article 5 of the EUPL 

3. c)Inside the exception, the case where a more permissive licence could be applied 

a) The Normal Copyleft Reuse Under the EUPL

With the aforementioned reservations, we can state that the EUPL “copyleft” is as strong as possible, on source code and binaries of copies and all derivative works of the covered work (derivative within the meaning applied by a court interpreting the license), with defined interoperability exceptions.

Let’s first consider the normal case with regard to the distribution of code under the EUPL:

• •

  

   

  Fig. 1

  A project "ALPHA" is more than just its software code: it is an organisation, owned by a person or a body, with an active community of developers, a web site, DNS, logo etc. Globally, this project "ALPHA” can never be "re-licensed" outside the will of its original licensor (who is free, as the 100% copyright owner, to provide exceptions or to distribute the project software under various licences, which is called dual or multiple licensing).

   

  A project "ALPHA" is more than just its software code: it is an organisation, owned by a person or a body, with an active community of developers, a web site, DNS, logo etc. Globally, this project "ALPHA” can never be "re-licensed" outside the will of its original licensor (who is free, as the 100% copyright owner, to provide exceptions or to distribute the project software under various licences, which is called dual or multiple licensing). 

• •Re-distribution of the code of project "ALPHA", covered by the EUPL, is possible inside the context of another project (e.g. "BETA"), meaning after copying and pasting ALPHA's code into BETA's software, as is or with modifications, and thus making BETA's code a derivative work according to applicable copyright law. -In all events, this redistribution must be done under the same EUPL licence. 

This is sometimes known as a "forking", when BETA takes all or most of ALPHA's code and distributes it as another owner (of the derivative work), brand name, logo, web site etc. Forking, as such, is rare, at least when the original licensor organises an active community around its ALPHA project: if this is the case, all improvements will normally be done and shared within the ALPHA project, without needing to create any new BETA project.

Forking may occur for 1) licensing / philosophical reasons or 2) for functional / technical reasons:

1. 1)A first example, is the case where ALPHA's licensor has lost its independence (e.g. is purchased by a proprietary vendor), and the community decides to re-launch the project to preserve EUPL licensing (though this is not likely to happen if the licensor is a public sector body); 

2. 2)A second example is the case where ALPHA's licensor does not want to integrate/support certain new functions. For example, an Indian government wants to localise/adapt software distributed by the European Parliament in local Indian languages, but the EP does not want to be involved in this process. However, the new Indian project code must also be distributed under the EUPL.  

The hypothesis where a portion of the covered code is merged in another project is similar: as a derivative, this project must be covered by the EUPL, in case it is distributed.

b) Exception to the “Normal Copyleft” (Reuse in Other Copyleft Works)

The third paragraph of Article 5 EUPL was written for interoperability reasons: to allow the covered code to be integrated with other projects' code covered by other stronger or weaker copyleft licences. “Integration” is here in its widest sense where a derivative work is produced, including mixing significant parts of the code as resulting from a copy/paste operation as described above. In other cases where the resulting work is not derivative, but a simple compilation or aggregate, this paragraph will not apply. This third paragraph reads as follows:

“If the Licensee Distributes and/or Communicates Derivative Works or copies thereof based upon both the Original Work and another work licensed under a Compatible Licence, this Distribution and/or Communication can be done under the terms of this Compatible Licence.”

In the EUPL v1.2, the list of compatible licences published in the Appendix contains the following licenses (v 1.2 additions to the Appendix of v.1.1 are in bold):

- GNU General Public License (GPL) v. 2, v. 3

- GNU Affero General Public License (AGPL) v. 3

- Open Software License (OSL) v. 2.1, v. 3.0

- Eclipse Public License (EPL) v. 1.0

- CeCILL v. 2.0, v. 2.1

- Mozilla Public Licence (MPL) v. 2

- GNU Lesser General Public Licence (LGPL) v. 2.1, v. 3

- Creative Commons Attribution-ShareAlike v. 3.0 Unported (CC BY-SA 3.0) - for works other than software

- European Union Public Licence (EUPL), any version as from 1.1

The presence in the list of weaker copyleft licences (the LGPL and the MPL) may look unnecessary for most cases of integration: these licenses permit larger works incorporating their code to be distributed under the EUPL. However, in case the EUPL covered code is actually mixed into the component covered by the LGPL or the MPL, the inclusion of these licenses in the Appendix is useful.

The interoperability exception of the EUPL will allow licensees running a third project “DELTA”, to reuse files or source code covered by one of the above compatible licences in the DELTA project code, and to insert or merge the EUPL covered code in DELTA's code: they can licence the resulting work as a whole under the compatible licence.

Notwithstanding the permission to authorise “this distribution and/or communication” of the new DELTA project software “as a whole” under a compatible licence, the EUPL's provisions still apply to the part of the code that was originally covered by the EUPL. In particular, it maintains the attribution obligations (article 5: the Licensee shall keep intact all copyright, patent or trademarks notices and all notices that refer to the Licence and to the disclaimer of warranties).

 

Fig. 2 Exception for compatible licences

1. 1.Software code covered by the EUPL is combined in/with another, different work. 

2. 2.The combination (larger work) forms a derivative work (i.e. the covered code was copied and pasted in another file, covered by another licence) or is otherwise covered by the other license, so that the resulting merged code must be licensed as a whole under the new license. Keeping distinct licences, like for the various parts of an aggregate work, is not an option (because the codes are mixed). 

3. 3.The other work, with which the code covered by the EUPL is merged, is licensed under a Compatible Licence (according to the list). 

4. 4.The same compatible licence (according to the list) is used to license the new larger work “as a whole”. 

Is there any risk to see someone licensing some trivial code (some kind of copyrightable wrapper, but without real functional added value) under a compatible licence for creating a formal larger work and licensing it under this compatible licence? No cases were reported in five years EUPL distribution (2007-2012). It is not the way FOSS operates. Making trivial forking is losing time and reputation. A forked work is sustainable only when a working community takes it over and improves it substantially.

The presence of the EUPL itself in the list of compatible licences is not trivial. It was important to avoid introducing more licence proliferation issues by making the two versions 1.1 and 1.2 of the EUPL incompatible (an issue that was not avoided when introducing the GNU GPL v3 which is incompatible with the GPLv2). Therefore all projects licensed under “the EUPL v1.1 only” will be authorised to integrate code that will be developed under the EUPL v1.2. The reciprocal situation is not automatic, but – due to the reversibility – it is assumed that exceptions will be easy to obtain, if and when needed.

c) Exception to the Exception

Because three of the listed compatible licences are more moderately “copyleft” (or only at file level) it may be that some code covered by the EUPL could also be reused in a third generation project that takes up the mixed code (EUPL + EPL, for example) and redistributes it – in binary executable form – under a non-FOSS licence.

 

Fig. 3 Exception to the exception

1. 1.the "daughter project" DELTA is (by decision of its own licensor and because code under these licences - EPL, LGPL or MPL - was reused) distributed under one of these more moderately copyleft licences listed as Compatible; 

2. 2.that some code from DELTA is combined or forked in a "grand-daughter" project “OMEGA”, and; 

3. 3.that the OMEGA licensor decides to distribute its executable version under proprietary terms, something that is permitted, subject to certain conditions, by the moderate copyleft licenses. 

Even in such a case (that has never occurred in real world so far) the portions of the DELTA code present in OMEGA will stay covered by their primary licence (EPL, LGPL or MPL) and – as stated before – the EUPL covered code that is present in these files will stay covered by the EUPL provisions and marked with its specific attributions. These files must stay FOSS and publicly available as source code, but the copyleft is generally limited at file level according to the provision of these licences (meaning without any copyleft impact on the rest of the OMEGA project).

This point is of course – at least theoretically – founded. But we have to see it in a context, and temper it:

• •The term “relicense the work” is somewhat ambiguous, as previously stated. 

• •Some compatible licences provide a “weaker” copyleft (LGPL, MPL, EPL): it does not mean that these licences are weak or permissive: they are copyleft, but at file level, without the aim of propagating the licence coverage by e.g. dynamic linking. 

• •The strict focus on “strong copyleft” may not be ideal in an interoperable world, where multiple FOSS licences coexist. Furthermore, the notion of “strong copyleft” is still unclear, debated and has not received confirmation from European case law. 

Conclusion

The above series of examples illustrate that the EUPL achieves several of its aims:

• •It intends to protect effectively the covered code and derivative works from exclusive appropriation by a third party; 

• •It makes some part the covered code reusable in OTHER free software projects under other licenses (without re-licensing the original project); and 

• •It does not prevent the reuse of some code of these other projects by the software industry with a variety of business models. 

The EUPL is not a goal in itself. It is just a tool for facilitating the distribution of copyrighted work by new categories of FOSS licensors, including (but not exclusively) the European public sector authorities and enterprises. The tool results from searching for the best possible compromise between copyleft (with the aim to avoid exclusive appropriation of the covered work) and legal interoperability (with the aim to see the work widely used in many other projects and to facilitate the distribution of these projects).

The tool is not perfect, it has been adapted twice (v1.0 in 2007, v1.1 in 2009) and changes that are expected in 2013 (v1.2) are reinforcing interoperability aspects.

In the future, it may be that the evolution will continue with new versions of the EUPL, or that a better legal instrument will eventually be adopted and implemented to replace software licences. Two directions look possible in the current context:

• •More copyleft licences follow the EUPL example and develop their list of compatible licence34; 

• •The relevant licence steward organisations (despite all their differences) unify their efforts and produce a multilingual working, worldwide valid, comprehensive licence with the aim to conciliate the requirements from most FOSS stakeholders. In such case, the EUPL may completely disappear or become a facet in a wider project. 

However, predicting the future is hazardous; as everyone knows that yesterday is history, today is a gift, tomorrow is a mystery...

References

• •The EUPL v1.1 and v1.2 – text of the licence, in 22 languages – Joinup.eu. https://joinup.ec.europa.eu/software/page/eupl  

• •Guidelines for using the EUPL https://joinup.ec.europa.eu/software/page/eupl/eupl-guidelines  

• •Guidelines on public procurement of Open Source Software
  https://joinup.ec.europa.eu/elibrary/document/guideline-public-procurement-open-source-software  

• •Spanish Royal decree 4/2010  (English version) see in particular article 16
  http://administracionelectronica.gob.es/recursos/pae_000002017.pdf  

• •The EUPL in Italy: www.eupl.it  

• •“Experience of introducing the EUPL in ISTAT” (Carlo Vacari 2010) presentation slides (in Italian) : http://fr.slideshare.net/vaccaricarlo/introduzione-eupl-in-istat  

• •Malta public sector software distribution policy
  https://www.mita.gov.mt/MediaCenter/PDFs/1_GMICT_P_0097_Open_Source_Software_v2.0.pdf  

• •Guide for the procurement of standard-based ICT / Elements of Good Practice – (European Economics 23 March 2012) - http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d3-guidelines-finaldraft2012-03-22.pdf
   

• •ISA standard “Sharing and reusing clauses” http://joinup.ec.europa.eu/elibrary/document/isa_share_reuse_d_2-1-standard-sharing-and-re-using-clauses-contracts  

About the author

Patrice-Emmanuel Schmitz is a legal expert at www.Joinup.eu.

Licence and Attribution

This paper was published in the International Free and Open Source Software Law Review, Volume 5, Issue 2 (December 2013). It originally appeared online at http://www.ifosslr.org.

This article should be cited as follows:

Schmitz, Patrice-Emmanuel (2013) 'The European Union Public Licence (EUPL)', International Free and Open Source Software Law Review, 5(2), pp 121 – 136
DOI: 10.5033/ifosslr.v5i2.91

Copyright © 2013 Patrice-Emmanuel Schmitz.

This article is licensed under a Creative Commons UK (England and Wales) 2.0 licence, no derivative works, attribution, CC-BY-ND available at
http://creativecommons.org/licenses/by-nd/2.0/uk/

As a special exception, the author expressly permits faithful translations of the entire document into any language, provided that the resulting translation (which may include an attribution to the translator) is shared alike. This paragraph is part of the paper, and must be included when copying or translating the paper.

 

1“Report on Open Source Licensing of software developed by The European Commission”, 16th December 2004, online at https://joinup.ec.europa.eu/elibrary/case/open-source-licensing-software-developed-european-commission-applied-circa-solution-20

2The first EUPL version (1.0) was less explicit on this specific point. It has been clarified in version 1.1.

3The Report on Open Source Licensing of software developed by the European Commission, op cit, considered the OSL as the best choice and proposed two options: adapting the OSL or writing a specific licence. The Commission opted for writing the EUPL.

4Report on outcomes of public consultation about the EUPL, 30th November 2005, online at  https://joinup.ec.europa.eu/sites/default/files/GPOSS_adv-06_V11%2019%20Jan%2006.doc

5Online at http://www.at4am.org/eupl/ .

6This “reproach” has been addressed to institutions like the NASA, after evaluation of the impact of the NOSA (Nasa Open Source Agreement): see comments from the US Department of Defence – http://opensource.com/life/11/3/nasa-concludes-first-open-source-summit-aims-make-openness-default .

7Online at http://opensource.org/licenses/OSL-3.0 .

8Online at http://opensource.org/licenses/AGPL-3.0 .

9In particular, some analysts were disappointed by the complexity of the GPLv3 that is nearly three times longer. For example, Ernest Park noted: The EUPL v1.1 is a legal instrument, simple and clear to interpret, with less baggage than the GPL v3 in “Freedom and choice in open source licensing – Comparing the EUPL v1.1 and the GPL v3”, online at http://www.linux.com/news/biz-os/legal/18749-freedom-and-choice-in-open-source-licensing-comparing-the-eupl-v11-and-the-gpl-v3 .

10http://opensource.org/licenses/alphabetical

11http://projects.opensource.org/pipermail/license-discuss/

12http://opensource.org/codeofconduct/licensing

13http://opensource.org/licenses/CECILL-2.1

14See the Guide for the procurement of standard-based ICT / Elements of Good Practice, European Economics 23, March 2012, available online at http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d3-guidelines-finaldraft2012-03-22.pdf  and the ISA standard “Sharing and reusing clauses”, available online at http://joinup.ec.europa.eu/elibrary/document/isa_share_reuse_d_2-1-standard-sharing-and-re-using-clauses-contracts .

15In 2005, the Manchester eGovernment ministerial declaration stated: “Member States will, during the period 2006-2010, share technologies, where appropriate develop common solutions and work towards interface harmonisation of existing solutions” (in the field of eProcurement), and in 2009, the Malmö ministerial declaration on eGovernment stated: “The Open Source model could be promoted for use in eGovernment projects.” (online at http://ec.europa.eu/digital-agenda/sites/digital-agenda/files/ministerial-declaration-on-egovernment-malmo.pdf )

16This example is given in Appendix 1 of the Guide accompanying the European Commission communication “Against lock-in: building open ICT systems by making better use of standards in public procurement” - COM(2013) 455 / SWD(2013) 224, 25th June 2013.

17DG Enterprise workshop, 22nd November 2012 “Implementing FRAND standards in Open Source: Business as usual or mission impossible?”, reported online at  http://ec.europa.eu/enterprise/sectors/ict/standards/extended/event_open_source_en.htm .

18See Italian Supreme Court decision (Corte Costitizionale, 22nd March 2010) http://www.cortecostituzionale.it/actionSchedaPronuncia.do?anno=2010&numero=122 , commented by Carlo Piana in IFOSSLR Vol 2, No 1 (2010), DOI: 10.5033/ifosslr.v2i1.38.

19The notion of « variable copyleft » was coined for the EUPL by Rowan Wilson (Oxford University) http://www.oss-watch.ac.uk/resources/eupl .

20Fabian Bastin and Philippe Laurent, «Study on the compatibility mechanism of the EUPL » https://joinup.ec.europa.eu/system/files/doc/Doc3ef5.pdf

21The draft EUPL v1.2, with changes highlighted, is published on the European Commissions' Joinup site :  https://joinup.ec.europa.eu/sites/default/files/EUPL%20v1.2%20-%20Draft%20EN%20v15%20Mar%202013.pdf

22The contributions to the public consultation are published: https://joinup.ec.europa.eu/community/eupl/topic/public-consultation-draft-eupl-v12

23Comments done on LWN network are illustrative  http://lwn.net/Articles/529737/#Comments

24See e.g. https://joinup.ec.europa.eu/community/eupl/topic/public-consultation-draft-eupl-v12

25Ernest Park, Freedom and Choice in Open Source Licensing: Comparing the EUPL v1.1 and the GPL v3

http://www.openlogic.com/wazi/bid/187980/Freedom-and-Choice-in-Open-Source-Licensing-Comparing-the-EUPL-v1-1-and-the-GPL-v3

26Eben Moglen, An introduction to the most used FOSS licence, the GPL license, in :European Parliament – Legal aspects of free and open source software – compilation of briefing notes / p. 12 http://www.europarl.europa.eu/document/activities/cont/201307/20130708ATT69346/20130708ATT69346EN.pdf

27FSF declares EUPL 1.1 compatible with GPLv2 and details how – via CeCILL – the EUPLv1.1 is also compatible with the GPLv3, but still categorises the EUPL as GPL-incompatible (!) http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses

28Malcolm Bain, “Software interactions and the GNU General Public Licence”  IFOSSLR 2010 p. 165 http://www.ifosslr.org/ifosslr/article/view/44/74

29Linking makes two software programs work in a single application without merging their source code. Generally speaking, static linking combines components through compilation, copying them into the target application and producing a merged object file that is a stand-alone executable., and dynamic linking combines components when the application is loaded (load time) or during execution (run time).

30Decision online at http://curia.europa.eu/juris/document/document.jsf?text=&docid=122362&pageIndex=0&doclang=en&mode=req&dir=&occ=first&part=1&cid=564907

31For a specific discussion on linking (in the context of the GPL), Malcolm Bain, op cit.   http://www.ifosslr.org/ifosslr/article/view/44/74

32For example, the too brief formulation used by the Free Software Foundation may induce recipients in error: “The EUPL allows relicensing to GPLv2, because that is listed as one of the alternative licenses that users may convert to”, at http://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses

33FSF – op. cit.

34This is the way followed by the new version 2.1 of the CeCILL licence, which is now downstream compatible with the GPL, AGPL and EUPL - http://www.cecill.info/index.en.html