Navigation path

Additional tools

European Union Public Licence

(
 
)
4.57/5 | 7 votes

Public Consultation on the draft EUPL v1.2

25 message(s)
Patrice-Emmanuel Schmitz
Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on November 21, 2012 at 20:16.
(Joinup - legal expert, Belgium) - 15/02/2009
.
(
 
)
5/5 | 1 votes | 4715 reads
"

Introduction

The EUPL is the European Union Public Licence, published by the European Commission. It has been studied and drafted in 2005 and launched in January 2007. The current version is the multilingual and OSI certified EUPL v1.1 (January 2009).

 

The EC strategy is to reinforce its legal tools for facilitating sharing, reuse and interoperability.

The EUPL includes an appendix of “compatible licences” providing interoperability with a list of other "share alike" licences. As this list (based on a 2006 study) is outdated, a principal objective of the EUPL v1.2 is to update it (i.e. adding GNU GPLv3, AGPLv3 and some others - to discuss).

Joinup publishes the draft EUPL v1.2

Joinup published also a Working Paper to explain the planned modifications.

Modifications introduced by the EUPL v1.2 should stay “as limited as possible”.
The publication of v1.2 will have no automatic impact when software was expressly covered “by the EUPL v1.1 only” (current licensors may opt for updating, or not), but v1.2 will be compatible with v1.1.

Public Consultation

Joinup has registered your comments, thoughts and suggestions on the new draft EUPL v1.2 and the accompanying working paper. You will read some of these comments below. Other comments (i.e. on Linux forums, from OSI reviewers) where considered also. 

Comments were submitted using the box below. Please note that, to submit comments, a user needs to be logged as a registered user on Joinup. If a Joinup visitor has no account already, he can create one here http://joinup.ec.europa.eu/user/register.

Comments are public. A first series of comments was closed on 15 March 2013, but as the approval process of the EUPL v1.2 takes more time (and is still subject to revision by the Legal Service until to March 2014, additional comments are still welcome.

 

What next?

It was originally expected to publish the EUPL v1.2 in June or July 2013.
The Commission has met some delays in translations or agenda and the text is now under examination by the Legal Service.  An additional modification is the alignment, in article 5, of the compatibility clause with the copyleft clause that includes the"opt-out" condition "licensed under the EUPL v1.2 ONLY". 
Except this point in discussion, the final draft is unmodified since the end of March 2013. It has been published (pages 24-28) in the compilation of briefing notes of the European Parliament workshop "Legal aspects of free and open source software" on 9th July 2013. http://www.europarl.europa.eu/document/activities/cont/201307/20130708AT.... It was also analysed in December 2013 in the International free and open source software law revue (IFOSSLR)

 

Comments

Gervase Markham
Re: Public Consultation on the draft EUPL v1.2
Posted by Gervase Markham on December 20, 2012 at 17:19
(Mozilla, United Kingdom)
"

Hi,

I work for Mozilla, although these comments are not official Mozilla comments. I am the first point of contact for licensing issues, and worked on the MPL 2.

 

A) Line 18: You have removed the version number from the suggested notice. Why was this done? Was it to try and make forward compatibility the default?

 

The GPL has a provision in section 14: "If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation." If you are going to encourage people to put versionless headers on files, you should have a similar provision in the EUPL.

 

However, the provision in the GPL is to deal with this situation if it arises, not to encourage it. It is not a great thing that people can use the GPLv1 if they wish, or other older versions of the license which may be buggy. Are you sure you want to encourage people to be vague about the terms under which they are licensing software?

 

B) Line 243 and lines 303/304: you wish for it to be possible to update the Appendix without issuing a new version of the EUPL. I think this is not a good idea, because that means that someone licensing software under the EUPL, even if they say "version 1.2 only", does not know the exact set of terms they are permitting. It also means that someone trying to analyse the license of some software does not know exactly what it is, if it says "EUPL 1.2". This creates uncertainty. It is far better to bump the version number when you revise the Appendix. If you are concerned about forward compatibility, then make that the default.
 

C) Line 287: Addition of the AGPL v.3. You should list this license separately, as it's a different license. As of version 3, the LGPL is the "GPL plus extra bits", and so is the AGPL. If one is listed separately, the other should be.
 

D) Line 291: removal of the CPL. It is true that the EPL has superseded the CPL, but there is no automatic upgrade between the two. Therefore, software still exists under the CPL. Removing the CPL from this list will remove the ability of people to combine that legacy software with EUPL software. As there is no disadvantage to leaving it in that I can see, you should just leave it in.
 

E) Line 297: Addition of the MPL 2. The MPL has a weaker copyleft than any of the other licenses in this list. Your rationale document states that 'The EUPL is also a "share alike" (or copyleft) licence resulting from the aim to avoid exclusive appropriation of the covered software.' The MPL, by contrast, is designed to permit use of MPLed code in partly-proprietary software. You should consider this issue carefully before adding it to the list, because combining EUPL'ed code with MPLed code would result in an MPLed codebase, which could then be used in proprietary software.
 

The distinction in the working paper between "source and object copyleft" vs. "source only copyleft" is not the right way to understand the difference between the MPL and e.g. the GPL's copyleft provisions. It is true that under the MPL, binaries can be licensed any way at all, but it's also true that the scope of the copyleft is weaker. The MPL does not use the copyright concept of "derivative work" to determine what additional software needs to be MPLed. It has a narrower definition, based on individual files (not "modules" as the Working Paper suggests).
 

F) Line 299: Addition of the LGPL. The comments about the MPL's copyleft scope apply, to a more limited extent, to the LGPL. In addition, you specify "LGPL v.2 and v.3". v2.1 is extremely common (the number was changed when the name was changed from Library to Lesser), and you should list that also.
 

For both of these licenses, it would be wise to spell out the name in full, as is done with the other licenses. There is nothing to prevent someone else making a license whose abbreviation is "MPL" and which has a version 2. And then there might be confusion.
 

G) Line 301: Addition of "Previous v1.1 and later versions of this EUPL licence". This sentence is not good English. I would say "EU Public License, any version".
 

H) Typos you may wish to correct:
 

- Line 20: "any other mean" -> "any other means"
- Line 271: "governed by the Belgian law" -> "governed by Belgian law"
 

I hope this feedback is helpful to you :-)
 

Gerv
 

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on December 22, 2012 at 17:45
(Joinup - legal expert, Belgium) - 15/02/2009
"

@Gervase MARKHAM

Thanks a lot for your observations. Very useful. I react below to clarify some points, knowing that my opinion is one amongst others (decision belongs to EC). The draft will be updated at the end of January.  

A.    Line 18: You have removed the version number from the suggested notice. Why was this done?
- The aim is that “licensing under the EUPL” means always “the last version” (and not “any” version, at the contrary to what is stated in the GPL). People may add a specific version number, but the objective is not to encourage this.

B.    Line 243 and lines 303/304: you wish for it to be possible to update the Appendix without issuing a new version of the EUPL. This creates uncertainty, especially when licensing under “EUPL v1.2 only”.
- the few licences that have some compatibility list (or “secondary licences” like the MPL) declare compatibility with “any later versions of those licenses”, which is also quite uncertain.
The appendix can be "simply" updated in case of later versions of licences that are already listed in it (adding a new licence in the list would indeed bump the version number of the EUPL).

The EC has few other choices for practical reasons: because of the number of compatible licences (10) and because adopting a new version is a heavy process. Without coming back to the years taken (i.e. for the GPLv3), you know how long it takes to get OSI approval (i.e. for the MPLv2). Add to this the approval by the EC legal service and the EC commissioners, each round takes more than 6 months! 
 

C.    Line 287: Addition of the AGPL v.3. You should list this license separately, as it's a different license. As of version 3, the LGPL is the "GPL plus extra bits", and so is the AGPL. If one is listed separately, the other should be.
- IMHO, this seems right and reasonable.
 

D.    Line 291: removal of the CPL. It is true that the EPL has superseded the CPL, but there is no automatic upgrade between the two. Therefore, software still exists under the CPL. Removing the CPL from this list will remove the ability of people to combine that legacy software with EUPL software. As there is no disadvantage to leaving it in that I can see, you should just leave it in.
- We had already received in the past other comments asking to remove CPL, but probably you are right here.

 

E.    Line 297: Addition of the MPL 2. The MPL has a weaker copyleft than any of the other licenses in this list. Your rationale document states that 'The EUPL is also a "share alike" (or copyleft) licence resulting from the aim to avoid exclusive appropriation of the covered software.' The MPL, by contrast, is designed to permit use of MPLed code in partly-proprietary software. You should consider this issue carefully before adding it to the list, because combining EUPL'ed code with MPLed code would result in an MPLed codebase, which could then be used in proprietary software.
- This point is important indeed. In “avoiding exclusive appropriation” an important word is “exclusive”. It is possible that if licensor1 licenses A under EUPL, a licensor2 may licence some larger work B (=A+MPL licensed code) under MPL and that a licensor3 could license some even larger work C (=B+X code) under a proprietary licence X. But, as explained in the working paper, this is not a re-licensing of the original code A under EUPL: it applies only to the third generation of a specific larger work C. The EC is not the FSF (both organisations merit respect, but restricting to the maximum any re-use of public sector  works by the proprietary software industry is, as far as I know, not a declared objective of the EC.

The distinction in the working paper between "source and object copyleft" vs. "source only copyleft" is not the right way to understand the difference between the MPL and e.g. the GPL's copyleft provisions. It is true that under the MPL, binaries can be licensed any way at all, but it's also true that the scope of the copyleft is weaker. The MPL does not use the copyright concept of "derivative work" to determine what additional software needs to be MPLed. It has a narrower definition, based on individual files (not "modules" as the Working Paper suggests).

- It seems indeed appropriate to correct the working paper (“file” and not “module”).
Regarding the interpretation of the MPL, you are the expert.

F.    Line 299: Addition of the LGPL. The comments about the MPL's copyleft scope apply, to a more limited extent, to the LGPL. In addition, you specify "LGPL v.2 and v.3". v2.1 is extremely common (the number was changed when the name was changed from Library to Lesser), and you should list that also.

- Another point for you, indeed. LGPL 2.1 is to be included.

For both of these licenses, it would be wise to spell out the name in full, as is done with the other licenses. There is nothing to prevent someone else making a license whose abbreviation is "MPL" and which has a version 2. And then there might be confusion.

- Also a remarks that looks very useful.
 

G.      Line 301: Addition of "Previous v1.1 and later versions of this EUPL licence". This sentence is not good English. I would say "EU Public License, any version".
- Also a remarks that looks very useful: "any version as from 1.1." (because v1.0 was automatically superseeded). 
 

H.     Typos you may wish to correct:
- Line 20: "any other mean" -> "any other means"
- Line 271: "governed by the Belgian law" -> "governed by Belgian law"
Thanks, will be corrected (end of January)

I hope this feedback is helpful to you :-)

Yes it is :-)!

 

Roland Alton-Scheidl
Re: Public Consultation on the draft EUPL v1.2
Posted by Roland Alton-Scheidl on January 19, 2013 at 13:05
(ALLMENDA Social Business eG, Europe, Austria) - 07/12/2011
"

Applicability to any Work

I am glad to see that the EUPL 1.2 draft is now referring to "Works" and not software only (as previously discussed here: https://joinup.ec.europa.eu/community/eupl/topic/producing-derivative-li... ). This perfectly matches our need in a number of application areas, most prominently:
1. licensing both software, related documentation and art ware like logos with the same license scheme
2. licensing content, when Creative Commons-by-sa or the Free Document License are not the first choice.
The latter may happen when legal departments are allergic to U.S.-copyright derived licenses. (Disclaimer - I am not allergic as the spokesman of Creative Commons in Austria, but we had this issue in Open Government Data talks, when three cities decided to go for CC licensing). You may consider to add CC-by-sa (unported 3.0) to the list of compatible licenses.

Inheritation of additional agreement to compatible licenses

We find the clause of allowing "Additional agreements" extremely useful. We have now a case of a software partner, who used to publish under GPL, but wants to restrict the usage (no military use, use by hedgefunds etc). They are now looking for some kind of "fair trade" license and we will propose to them an additional clause listing moral rights. But what about the "Compatibility clause" in that case? How can an additional obligation be applied to a derivative work under a compatible license? The fork's license would prevail and the additional agreement would cease. The GPL explicitly states that a distributor may not impose "further restrictions on the rights granted by the GPL". This was intended to forbid distributing the software under a non-disclosure agreement, but would also restrict inheritation of any other (e.g. moral) additional agreement. Shouldn't we add a sentence to the compatibility clause, that the chosen sister license may not conflict with additional agreements issued together with the EUPL? 

 

 

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on January 21, 2013 at 11:43
(Joinup - legal expert, Belgium) - 15/02/2009
"

The idea to add CC-by-sa (unported 3.0) to the list of compatible licences looks interesting. A suggestion would be to add it “for works other than software”. The draft will be updated at the end of January.

The exclusion of specific uses (i.e. military, hedge funds, unfair trade), although it looks morally well-founded, cannot find place in the licence because in contradiction with the Open Source Definition principle #6 stating: “No Discrimination Against Fields of Endeavor. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.“ Including such restrictions in an additional agreement is possible, but would it be valid and for whom? If the agreement is accepted by a first generation of recipients, it looks difficult to enforce it in the case of re-distribution. The problem exists not only in case of distribution of a larger derivative work (possibly under a compatible – “sister” licence), but also in the normal case or re-distribution under the same primary licence (the EUPL only). In fact, the case is the same with all open source or free software licences, and it looks difficult to regulate the issue at licence level. Could alternative ways exist (i.e. communities refusing to provide support for specific uses they dislike)?

Gervase Markham
Re: Public Consultation on the draft EUPL v1.2
Posted by Gervase Markham on January 21, 2013 at 23:02
(Mozilla, United Kingdom)
"

Hi Patrice-Emmanuel,

I'm afraid I couldn't work out how to add this as a comment to your reply :-( Maybe my account does not have sufficient permissions. Anyway, you said:

 

"The aim is that “licensing under the EUPL” means always “the last version” (and not “any” version, at the contrary to what is stated in the GPL). People may add a specific version number, but the objective is not to encourage this."

 

Combined with the ability for the license authors to change the license list without need for consultation, this effectively means that if you license your software under the new EUPL, you are effectively giving full control over its licensing terms to the EUPL maintainers. Say you used the EUPL to get compatibility across a variety of copyleft licenses - because currently, all the compatible licenses are copyleft ones. Then, the EUPL team added a weak copyleft (such as MPL!) or no copyleft option to the list of compatible licenses, for some reason. Your desire for copyleft would be thwarted.

 

Your comments about this later are interesting - "restricting to the maximum any re-use of public sector works by the proprietary software industry is, as far as I know, not a declared objective of the EC". Someone who read the EUPL version 1.0 might have thought that what linked all the licenses in the compatibility list was copyleft, and therefore there was an implied commitment that this would continue to be the case. But your words suggest that this is not, in fact, true.

 

Is there any statement which restricts the EU to having only open source (OSD compliant) licenses on the list? Or perhaps someday could a non-OSD-compliant license be added?

 

The MPL also technically has this issue, in that we could possibly add more licenses to the compatibility list; however, the license steward in that case is a non-profit, committed to the good of the community, with a track record of license intent stability. It could be argued that the EU's license list might be less driven by a particular view of how open source licensing should work, and more driven by politics or pragmatism.

 

(As it happens, OSI approval for the MPL 2 was granted pretty much simultaneously with its final release. Getting approval for new versions is not necessarily an onerous process.)

 

Gerv

Roland Alton-Scheidl
Re: Public Consultation on the draft EUPL v1.2
Posted by Roland Alton-Scheidl on January 22, 2013 at 10:32
(ALLMENDA Social Business eG, Europe, Austria) - 07/12/2011
"

We seem to have a dilemma with "additional agreements": if they conflict with a compatible license, they may get worthless, in case the work is being forked.

Thus I suggest to extend line 135: "... the obligations of the Compatible Licence shall prevail, unless a right or an obligation is explicitly exempted within an additional agreement, as defined in Article 9." 

So we keep the default case that licenses are compatible.  In the rare case of an additional agreement a licensee can explicitly restrict the compatibility. This would give us a maximum of flexibility.
 

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on January 22, 2013 at 11:27
(Joinup - legal expert, Belgium) - 15/02/2009
"

@Roland Alton-Scheidl
It seems that there are several issues in the proposed scenario:
1. How will a 2nd generation of recipients be informed about your "additional agreement" without being directly binded by it, as a negotiating party? The EUPL conditions are transparent and published by the EC, but how to proceed with (a lot of) agreements?
2. T
he EUPL (v1.1 so far) was screened and approved by the OSI (checking the conformity to the Open Source Definition). How will you ensure that additional agreements are compliant with the OSD?
3. A conflict may occur not only with a "compatible licence" (in the exceptional case of a larger derivative work) but also with the EUPL itself (in all other normal cases of re-distribution): how to ensure that the agreement will be compliant to article 5 of the EUPL (copyleft clause) stating that in case of re-distribution "
The Licensee (becoming Licensor) cannot offer or impose any additional terms or conditions on the Work or Derivative Work that alter or restrict the terms of the Licence"? 

 

  

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on January 22, 2013 at 11:39
(Joinup - legal expert, Belgium) - 15/02/2009
"

 

@Gervase Markham
Hi Gervase, To your question: Is there any statement which restricts the EU to having only open source (OSD compliant) licenses on the list? Or perhaps someday could a non-OSD-compliant license be added?

It is clear that adding a new licence in the compatibility list will produce a new version of the EUPL. What would be considered as a simple update of the compatibility list is the case where a licence steward updates one of these compatible licences (i.e. if the French INRIA, CEA and CNRS update their CeCILL from 2.0 to 2.1).

The conditions for adding a new compatible licence in the list are stated in the working paper (page 5):

1.    the compatible licence should be recognized as a FOSS licence (by the acceptance as such by either the FSF or the OSI);

2.    the licence must be copyleft (at least as regards the source code); and

3.    the licence must be of practical use, that is

a.    a large number of software rely on it, or

b.    it governs either

 i.    at least one major software having a large number of user in the field where it applies, either

ii.     a project developed inside a public administration of a Member State of the European Community, or

iii.    a project partially or totally funded by the European Community or one of its Member States.

So, regarding compatible licences, there is a clear reference to OSI (meaning to the OSD) and to FSF. These conditions are resulting from a study from Philippe Laurent (the founder of the yearly EOLE event) published in 2006.

In addition, there is a formal statement in the EUPL itself (Article 13) that the European Commission may publish new versions of the EUPL “without reducing the scope of the rights granted by the Licence” meaning that, (according Article 2, which defines the rights) the licence must stay royalty free (RF) and compliant with the OSD (because Article 2 lists the rights established by the OSD). Article 2 stays unmodified in EUPL v 1.0, v 1.1, draft v 1.2.
 

The question of adding the MPL in the compatibility list or not is indeed open to discussion (is MPL copyleft as regards the source code?).

The European Commission, through the IDA, IDAbc, ISA programmes and trough the Digital Agenda and several declarations has demonstrated as from the early 2000 a long term commitment for open source and standards, even if –as we all know – European institutions and Member States governments make still intensive use of proprietary products. This is indeed a question of commercial politic (what is available, looks easier, secure, best value for money) and pragmatism.

It is perfectly comprehensible that many open source developers are inclined to give more trust to a non-profit foundation committed to the good of the community (as Mozilla or FSF) than to a governmental body. However, enterprises and many public administrations may think differently and appreciate examples or guidelines given by European Institutions...

Gervase Markham
Re: Public Consultation on the draft EUPL v1.2
Posted by Gervase Markham on January 22, 2013 at 17:46
(Mozilla, United Kingdom)
"

Hi Patrice-Emmanuel,

 

You wrote: "In addition, there is a formal statement in the EUPL itself (Article 13) that the European Commission may publish new versions of the EUPL “without reducing the scope of the rights granted by the Licence” meaning that, (according Article 2, which defines the rights) the licence must stay royalty free (RF) and compliant with the OSD (because Article 2 lists the rights established by the OSD). Article 2 stays unmodified in EUPL v 1.0, v 1.1, draft v 1.2."

 

That by itself does not affect whether a non-OSD-compliant license could be added to the list. Doing so would not "reduce the scope of rights granted" by the EUPL, it would instead permit the relicensing under a different license (which had reduced rights). Article 13 places a restriction on future terms of the EUPL, not on the features of licenses on the compatibility list.

 

I note your references to the working paper; however, I suspect that if push came to shove, the EU would not feel itself bound by those. That paper is one person or group's opinion of how the license should change, not a restrictive covenant to only change it in those ways.

 

I guess the point I am making is this: if the EUPL is to contain a mechanism whereby the list of licenses can be updated, it would be good if the text of the EUPL itself set some parameters as to what those updates might involve, in order to give more certainty and guidance to people considering using the EUPL for their work. For example, it might say "In the future, this list may only be augmented by other OSD-compliant licenses, and licenses will never be removed". Then people would know, for example, that they could potentially expect any OSD-compliant license to show up there (and so not to rely on the EUPL to preserve copyleft) but they would also know that there was no chance of their code becoming relicensable under a proprietary license.

 

Gerv

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on January 22, 2013 at 18:25
(Joinup - legal expert, Belgium) - 15/02/2009
"

Hi Gervase,
The study of Philippe Laurent (and François Bastin, for CRID) is in fact more than an opinion: it was ordered and approved by the Commission. However, your point is valid: history has proven that human beings or institutions could change their mind or even turn mad... So we will try to improve in line with your proposition.   

To avoid complex and external references to OSD and to copyleft (how strong?), the addition could be something like: "The European Commission may extend this Appendix to new licences providing the rights granted in Article 2 of this Licence and protecting the covered Source Code from exclusive appropriation". The purpose is to stay simple enough and to define the minimum level of copyleft that is expected from compatible licences.  

 

 

Roland Alton-Scheidl
Re: Public Consultation on the draft EUPL v1.2
Posted by Roland Alton-Scheidl on January 22, 2013 at 23:06
(ALLMENDA Social Business eG, Europe, Austria) - 07/12/2011
"

Dear Patrice-Emmanuel,

with your list of issues based on additional agreements, I understand now that those are not intended for inheritation. But if  a licensor can easily escape from any additional obligation (defined in an Article 9 agreement) by moving to another license (or simply re-license under the EUPL): how can we reach legal certainty for those additional obligations?

Maybe we need different EUPL flavours:

EUPL: as proposed, may not contain conflicting additional agreements and is fully compatible with other OS licenses

EUPL plus: with an additional agreement, which must be inherited and prevails any compatibility

EUPL fair: restricting use for military purposes, genetic research, fossil energy and hedge funds business

One could think of more flavors, like non-profit, governmental and educational use only. Ideally we have a robust core license and allow a few marked-up variants (which are less open, indeed). That way Creative Commons is successfully entering its 10th year with more than 400 million licenses issued (whereas only a quarter of CC licensed works choose the OS compliant CC-by or CC-by-sa variants).

--Roland

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on January 23, 2013 at 12:46
(Joinup - legal expert, Belgium) - 15/02/2009
"

Hi Roland,

Making different flavours is possible (after all, everyone can propose its own specific copyleft licence, and licence proliferation is a definitive fact) but these new licences - especially the "fair" flavours excluding some field of endeavour - may not be compliant with the OSD (and will not be approved by OSI). CC versions (even CC0) are not OSI-approved. In most cases, open data licensing (i.e. via CC) and FOSS licensing supported by active contributors communities will stay two distinct approaches. In the EUPL v1.2 draft, it was opportune, according to your suggestion, to refer to the "Work" in more general terms. A recent screening of 500 projects distributed under the EUPL confirmed indeed that some of them were about data only (i.e. ministerial declarations published under the EUPL). The suggestion to add CC-by-sa in the compatibility list (for non-software part of the work) is considered too. However, the objective of the current EUPL v1.2 update is not to propose a general alternative to CC.    

Alfonso de Cala
Re: Public Consultation on the draft EUPL v1.2
Posted by Alfonso De Cala on February 22, 2013 at 13:25
(SADESI - Junta de AndalucĂ­a, Romania)
"

URL to full license is now obsolete in software licensed before the joinup subdomain came up.

IMHO planning a durable new URL -in order to be included in program headers- will be a good idea.

Please, forget subdomains, and any part of the URL conditioned by the platform (cms, language...) and publish a canonical stable one.

 

 

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on February 22, 2013 at 13:46
(Joinup - legal expert, Belgium) - 15/02/2009
"

@Alfonso De Cala
Alfonso is entirely right. After other comments reporting the same issue, a formal request has been introduced to route all "old" OSOR links to the current URL (or any other durable solution).

 

Mike Milinkovich
Re: Public Consultation on the draft EUPL v1.2
Posted by Mike Milinkovich on March 04, 2013 at 14:40
(Eclipse Foundation, North America)
"

Greetings, and apologies for joining the discussions so late.

I would like to point out that Gervase Markham's comment regarding CPL to EPL conversion is incorrect.

"D) Line 291: removal of the CPL. It is true that the EPL has superseded the CPL, but there is no automatic upgrade between the two. Therefore, software still exists under the CPL. Removing the CPL from this list will remove the ability of people to combine that legacy software with EUPL software. As there is no disadvantage to leaving it in that I can see, you should just leave it in."

In fact, the EPL 1.0 is the successor to the CPL 1.0, and projects can and should move automatically from the CPL to the EPL. I have no idea why Gervase made this assertion, without checking with the relevant parties first.

As the Executive Director of the Eclipse Foundation (which is the steward of both the CPL and the EPL), our recommendation would be to remove the CPL from the list of Compatible Licenses.

References:

http://mmilinkov.wordpress.com/2009/04/16/one-small-step-towards-reducing-license-proliferation/ 

http://mmilinkov.wordpress.com/2013/02/13/jruby-moves-to-the-epl/

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on March 04, 2013 at 15:43
(Joinup - legal expert, Belgium) - 15/02/2009
"

@ mike: Is it certain that all CPL licenses have been "automatically" changed in EPL, even if the CPL licensor did nothing?
We had a case of automatic change, for example, when switching from EUPL v1.0 to v1.1. However, (as the community was reluctant for automatic changes) the provision was removed from v1.1 and change will not be automatic anymore when the EUPL v1.2 will be published (especially when software was "licensed under EUPL v1.1 only").  It is understood that your aim is that projects "should" move, but is it automatic? Is there any negative consequence if the CPL is maintained for historical reasons in the EUPL compatibility list?
It seems that the CPL is not listed anymore ine the OSI alphabetical license list, but it is still listed at FSF...

 

 

 

Gervase Markham
Re: Public Consultation on the draft EUPL v1.2
Posted by Gervase Markham on March 04, 2013 at 15:54
(Mozilla, United Kingdom)
"

Hi Mike,

 

I hesitate to contradict the guy in charge of the Eclipse Foundation, but documentation on your website suggests that what I wrote is entirely correct.

 

Exhibit 1 is the FAQ on Eclipse's conversion from the CPL to the EPL: http://www.eclipse.org/legal/cpl2epl/cpl2eplfaq.php . It says:

 

"I am a committer and I received an email asking me to identify contributors whose code I committed.  Why am I getting this?
Contributors to an Eclipse project provided their contribution under the CPL.  We are seeking their agreement to dual license their contribution under both the CPL and EPL. ..."

 

If the ability exists to automatically upgrade from one licence to the other, why would permission need to be sought from the CPL contributors?

 

Exhibits 2 and 3 are the texts of the CPL and EPL themselves; neither suggests that there is an auto-upgrade from the CPL to the EPL. In particular, there is nothing to suggest that EPL 1.0 is a "later version of this license" as defined in CPL 1.0. IBM (or perhaps Eclipse, if it inherited the right from IBM) could perhaps issue a CPL 1.1 to say that "CPL 1.1 is actually EPL 1.0", just as Affero did with the AGPL 2.0 to point to the GNU AGPL 3.0, but as far as I know it has not done so.

 

It may well be that Eclipse has successfully transitioned entirely from the CPL to the EPL. However, the CPL is a generic open source licence, and it may well not only be the Eclipse Foundation who is using it. If other projects are using it (such as Microsoft's projects WTL and Wix) then they will no longer be able to incorporate EUPLed code.

 

So my suggestion stands that the CPL be retained in the list.

 

Gerv

Mike Milinkovich
Re: Public Consultation on the draft EUPL v1.2
Posted by Mike Milinkovich on March 04, 2013 at 16:12
(Eclipse Foundation, North America)
"

Gerv,

Re: Exhibit 1: That was written in 2004 and was superseded by the events of 2009. It is an historical document, and no longer applies.

Re: Exhibit 2 & 3: Did you read my blog post? All of the parties involved decided that creating a CPL 1.1 simply to supersede it was silly. So that was not done, and the fact that it was not done was publicly communicated at the time. However, it is a statement of fact that the EPL 1.0 is the successor of the CPL 1.0, and that projects can move automatically to the EPL.

The argurment that the CPL is a generic open source license is true. But that is *not* the argument you started with. However, the CPL is a generic open source license that has been deprecated and superseded. Anything we can do to help the community move on to the EPL would be goodness.

Gervase Markham
Re: Public Consultation on the draft EUPL v1.2
Posted by Gervase Markham on March 04, 2013 at 16:29
(Mozilla, United Kingdom)
"

Hi Mike,

 

My apologies - I missed the URLs to the blog posts where you explain this. I would only say that if you visit http://www.eclipse.org/org/documents/epl-v10.php and click on the sidebar link "CPL to EPL conversion", you end up directly at that superseded document. So you may want to change or remove that link, or mark the document more clearly as superseded, in case anyone else is confused in the same way that I was.

 

Similarly, I did a search for "CPL 1.1" to see if it had existed, and got no hits, so assumed it was not created - which it wasn't. These two things together led me to erroneously assume that an upgrade path had not been defined.

 

You are right that I did not initially state the argument in terms of software which could be migrated from CPL to EPL but chose not to move. This was due to my misunderstandings as noted above. However, I do think that's a valid argument. Your blog post says the only substantive difference between the two is the breadth of the patent license termination. Given that, I can see how people might not want to move from a license called "Common" to one called "Eclipse", if they were not part of the Eclipse Project. We at Mozilla often get confused enquiries from people who think we have something to do with all software licensed under the Mozilla Public License.

 

Anyway, given that CPL-ed software (the examples I gave, and others) continues to exist, it seems right to keep it on the list, rather than attempt to use the EUPL as an "encouragement" to get people to change licence. After all, perhaps the FSF would like the EU to remove the GPL v2 from the list, to get people to move to the GPL v3 :-)

 

Gerv

Mike Milinkovich
Re: Public Consultation on the draft EUPL v1.2
Posted by Mike Milinkovich on March 04, 2013 at 16:51
(Eclipse Foundation, North America)
"

Gerv,

 

With apologies, you are certainly correct that we need to spend some time cleaning up those old pages on our website. I don't think you're the only one who has been led astray by our lack of housekeeping. We need to fix that.

 

To both Gerv and Patrice-Emmanuel,

 

I assume Gerv's original comment was motivated by an earlier draft which did remove the CPL. I can understand both sides of this argument, so whatever decision you make is fine with us. That said, I am not completely sure that I buy the argument that keeping the CPL in the EUPL 1.2 will be a hardship for any projects that continue to exist under the CPL. First, other than JUnit I am actually not aware of any projects under the CPL which are still active. Second, I am not aware of any projects that combine the CPL and the EUPL. Third, any such projects could, for example, continue to use previous versions of the EUPL.

 

If anyone is aware of a project for which this would cause harm, I would certainly change my tune. But in my mind at least, the concerns are abstract, rather than tangible.

 

Simon Grant
Re: Public Consultation on the draft EUPL v1.2
Posted by Simon Grant on June 25, 2013 at 6:44
(JISC CETIS, United Kingdom)
"

Patrice-Emmanuel

You say at the top that the final EUPL 1.2 will be released in June -- is that still true (only a few days left)? I was looking out for it. If there are any delays it would be good to know.

 

Thanks

Simon

Domenico Di Nolfo
Re: Public Consultation on the draft EUPL v1.2
Posted by Domenico Di Nolfo on June 26, 2013 at 12:33
(, France, Italy)
"

Bonjour à tous,

Yes it is also eagerly that I expect to see the result of this version 1.2 of the EUPL.

 

Librement

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on July 01, 2013 at 11:23
(Joinup - legal expert, Belgium) - 15/02/2009
"

@ Simon and Domenico

We are many, waiting for the "official" publication of the version 1.2 by the European Commission. The Project Officer in charge of it (Mr. Szekacs) has reported some delays due to translation. He is currently in a mission and I hope to obtain more precise committments when he will be back.

What looks good is that the text has not been changed after public consultation. It will be published (English version, draft "as is") inside the compilation of briefing notes of the European Parliament 9 July 2013 workshop "Legal aspects of free and open source software".

It is expected that this compilation will be published by the Parliament during or after the workshop. 

 

BREAKING NEWS: EUPL v1.2 is now revised by the EU Legal Service (19 Feb 2014)

 

Patrice-Emmanuel Schmitz
Re: Public Consultation on the draft EUPL v1.2
Posted by Patrice-Emmanuel Schmitz on February 19, 2014 at 19:52
(Joinup - legal expert, Belgium) - 15/02/2009
"

Questions related to modifying compatibility clause in Article 5 of the EUPL

Summary of users’ remarks the possibility to opt-out the “default compatibility” implemented by the EUPL article 5 compatibility clause and the attached Appendix of compatible licences.

 

1.      On its web site, the Free Software Foundation (provider of the GPL v2 and GPLv3) have focused on the “too large compatibility” (in their vision) when providing comments on the EUPL: “This is a free software license. By itself, it has a copyleft comparable to the GPL's. However, it gives recipients ways to relicense the work under the terms of other selected licenses, and some of those—the Eclipse Public License and the Common Public License in particular—only provide a weaker copyleft. Thus, developers can't rely on this license to provide a strong copyleft.” http://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses .

 

2.      During the EUPL v1.2 public consultation (on the JOINUP forum), Gervase Markham (a regular observer and contributor to OSI licence discussions) warned about the possibility to update the Appendix of compatible licences without issuing a new version of the EUPL, because  “that means that someone licensing software under the EUPL, even if they say "version 1.2 only", does not know the exact set of terms they are permitting.” https://joinup.ec.europa.eu/community/eupl/topic/public-consultation-draft-eupl-v12  In fact this issue is now fixed: in the draft version 1.2 of the Appendix, it is now stated that ADDING a new licence in the Appendix must indeed generate the issue of a new version. However, due to the extension of compatibility to MPL, the remark concerning the impact of licensing “under the EUPL version 1.2 only” is pertinent. Markham added: “You should consider this issue (of including the MPL) carefully before adding it to the list, because combining EUPL'ed code with MPLed code would result in an MPLed codebase, which could then be used in proprietary software.”

 

3.      In his communication at the European Parliament workshop (9 July 2013) on legal aspects of free and open source software, Carlo Piana (the FSFE lawyer) said that the EUPL, given its compatibility clause, implements a novel concept commonly referred to as “legal interoperability” - upon which the author (Mr. Piana) remains very sceptical, he said. http://www.europarl.europa.eu/document/activities/cont/201307/20130702ATT68998/20130702ATT68998EN.pdf

 

4.      In a discussion on Open Source groups in Linked’in in December 2013, following the publication of the documented analysis of the EUPL compatibility in the IFOSSLR (http://www.ifosslr.org/ifosslr/article/view/91/164), Nuno Brito (project manager in Darmstadt – licensing the TripleCheck project under the EUPL said that effective control of the use of EUPL code could procure some headache (as the list of compatible licences was extended).

 

5.      New relevant requests were formulated in February 2014 through the “Joinup legal questions” facility: In the “JUS-1137” question (14 February 2014) Mr J.E. Langevoort wrote; “In the EUPL, Software as a Service (SaaS) is covered explicitly, yet in the EUPL "downstream" compatibility list there are licences which do not have this protection against SaaS. The explicit mention of `communicating, transmitting or otherwise making available, on-line or off-line' in the section `Distribution and/or Communication' in the EUPL v1.1 can be circumvented by using a different licence (e.g. GPL v.2) and is therefore completely irrelevent providing only a false sense of security.
In the draft of the EUPL v1.2 there is no chance regarding this loop-hole that enables you to circumvent the SaaS-clause. As an developer interested in the EUPL I am curious as to why this situation is as I think it is and how this problem will be addressed.”

 

6.      In the “JUS-1138” question (18 February 2014), Mr K. Sibbald, author/owner of the Bacula software (www.bacula.org) wrote: “I am interested in using the EUPL v1.1 or v1.2, but am a bit surprised by the "Compatibility clause" that seems to permit licensees to change the license in a derivative version to be one of the compatible licenses listed in the appendix of the EUPL.
(…) The EUPL license seems to resolve my concerns (…). However, if someone can relicense the Bacula software under a compatible license, then the very nice Attribution rights section you have could possibly be canceled in a derivative work. Would it be possible to allow a licensor restrict the list of compatible licenses hould he/she so desire?”

 

In response to the above questions, it has been explained that the EUPL compatibility does not allow re-licensing of the project, but simple reuse of some code in another project (at the condition that this EUPL covered code is merged, to produce a derivative, with code covered by the compatible licence (All these arguments are presented in the IFOSSLR analysis http://www.ifosslr.org/ifosslr/article/view/91/164). It is also acknowledged by a lot of reasonable persons that forming “too strict compatibility barriers” between open source licences was not a good thing (see the opinion of Mr. Richard Fontana “Taking license compatibility semi-seriously” at FOSDEM event 2014 https://fosdem.org/2014/schedule/event/licensecompat/ ). Therefore the EUPL legal interoperability, which is innovative, should stay the “default option” in EUPL v1.2.

However the possibility to have a clear “opt-out” mechanism (which exists in other licences like the MPL v2) by licensing “under the EUPL v1.2 ONLY” seems reasonable too and addresses all the above user’s questions. This is the reason why the last draft in discussion at the Legal Service aligns the two clauses: copyleft and compatibility: the opt-out option will clearly impact both of them, and not only the first of them, as it was the case before. This looks more consistent and provides more possibilities to the licensor.

david jsa
Re: Public Consultation on the draft EUPL v1.2
Posted by David Jsa on March 06, 2014 at 2:31
(, )
"

Hi all,

 

The license “Creative Commons Attribution-ShareAlike v. 3.0 Unported (CC BY-SA 3.0)” is in the “Compatible licences” list, for “works other than software.”

 

There’s the newer  “Attribution-ShareAlike 4.0 International (CC BY-SA 4.0),” which was published in November 2013. Maybe you could consider adding it to the list also, if it’s not too late.

 

Thanks.