GPLv3 incompatible
|
| Author | Content |
|---|---|
| Sander_Marechal Mar 13, 2009 11:18 AM EDT |
The EUPL is incompatible with GPLv3. The EUPL explicitly provisions to be compatible with GPLv2 but only version 2. That makes it incompatible with vast amounts of software because "GPLv2 or later" is incompatible as well, thanks to the "or later" clause. I wish the EU collaborated with FSF on this one. It's a missed opportunity... |
| theboomboomcars Mar 13, 2009 12:38 PM EDT |
With the GPLv2 or later, can't you choose whether you want the redistribute it under GPLv2 or v3? Since that is what the or means, you can use it this way, or that way. If there were an and in there then you would have to fulfill all the stipulations from v2 and the later licenses. |
| caitlyn Mar 13, 2009 3:31 PM EDT |
@Sander: OSI considers a number of licenses Open Source which FSF doesn't consider Free. This is nothing new. |
| Sander_Marechal Mar 13, 2009 9:15 PM EDT |
@theboomboomcars: Yes, as a third party you could take a "GPLv2 or later" package, combine it with EUPL code and release it under GPLv2 only, but the upstream projects can't profit from the changes unless they relicense their codebase to GPLv2 only as well. caitlyn: I know, but GPL compatibility matters. See this for good reasons why: http://www.dwheeler.com/essays/gpl-compatible.html |
| caitlyn Mar 14, 2009 12:36 AM EDT |
Sander: I didn't say it didn't matter. The Wheeler article also argues strongly against license proliferation and what do we have here: a new license. There are a number of prominent projects still under GPLv2 because of concerns about GPLv3. The Linux kernel is one of them. I have to wonder if the EUPL is deliberately structured the way it is for that reason. |
| krisum Mar 14, 2009 2:12 AM EDT |
Quoting: OSI considers a number of licenses Open Source which FSF doesn't consider Free. This is nothing new.As far as I know all of OSI approved licenses are considered free by FSF (any glaring counter examples?). Actually there are a number of licenses which are considered free by FSF but which are incompatible with GPL including apache's, BSD etc. See this: http://www.fsf.org/licensing/licenses/index_html#GPLIncompat... |
| caitlyn Mar 14, 2009 12:25 PM EDT |
krisum: The NASA Open Source Agreement is an example of an OSI approved license that FSF considers non-free. There are others but they are generally pretty obscure. |
| hkwint Mar 14, 2009 7:02 PM EDT |
Quoting:I wish the EU collaborated with FSF on this one. I wish the FSF collaborated with the EU on this one, because if I understand correctly the EUPL was made because the GPL had it shortcomings, mainly when it comes to different national laws and the same validity for different languages. The GPL is mainy aimed at US-law and _only_ the English version is valid, was one of the comments of the EU. FSF could have prevent this proliferation have they sought more advice. Both initiatives started about the same time as far as I can tell. Quoting:"The GPLv3 is complex, hard to read and nearly three times longer than the EUPL", Schmitz said. http://www.osor.eu/news/european-public-licence-preferable-t... Note to oneself: Point FSFE to http://www.osor.eu/communities/eupl/forum/eupl-and-gplv3/937... |
| azerthoth Mar 14, 2009 7:32 PM EDT |
One has to wonder if the FSF will continue down the current path and evangelize themselves out of any real world relevance. |
| hkwint Mar 30, 2009 3:55 PM EDT |
Sorry for digging up a dead threat, but I have some 'news': Shortest answer: Sander is right (duh!) Short, however longer answer is: "GPLv2" and "GPLv2 and later" are compatible with EUPL, "GPLv3" is not according to FSF. Full answer and 'conversation'; the response on this issue I received from FSF, followed by my original questions. ____ Hello, Thank you for your interest. We maintain a non-exhaustive list if licenses and their compatibility at . According to our list, "The EUPL is compatible with GPLv2, because that is listed as one of the alternative licenses that recipients may use. However, it is incompatible with GPLv3, because recipients are not given permission to use GPLv3's terms, and the EUPL's copyleft conflicts with GPLv3's. Because of this incompatibility, we urge you not to use the EUPL for any software you write." As for GPLv2 and "any later version," the "any later version" provision allows the user to choose which version of the license they utilize the software under. Since the GPLv3 is incompatible with the EUPL, they would have to choose GPLv2 if they want to add EUPL code to the program. So yes, the EUPL is compatible with GPLv2 and "any later version" code, because users have the option of just using the code under GPLv2, which is compatible. But you still shouldn't use EUPL for your code because users won't be able to distribute their modified versions under the GPLv3. Thanks again for you interest, and I hope this helps. >Sat Mar 14 19:25:00 2009 > > Dear Sir, Madam, > > Recently at our website LXer.com we were discussing about GPLv3 and > EUPL being > incompatible and this being a shame (license proliferation). > Also, one of the notes was EUPL is also incompatible with GPLv2 if the > latter > says 'GPLv2 or higher'. > > Also recently, Mr. Schmitz of the EU asked for comments on whether or > not to > expand EUPL compatibility or not. The specific question was whether or > not it > should be (made) compatible with GPLv3 or not. > > ____ > > One of the uniqueness of the EUPL is that the licence has a > compatibility > list. This means that if software licensed under the EUPL is merged > with > software licensed under a compatible licence, the derivated work can > be > distributed under the compatible licence, which will prevail. > > Due to the non-revokable character of F/OSS licences, the > compatibility list > could grow, but not be reduced. > > The compatibility list of the EUPL v.1.1 includes (in February 2009): > > - General Public License (GPL) v. 2 > > - Open Software License (OSL) v. 2.1, v. 3.0 > > - Common Public License v. 1.0 > > - Eclipse Public License v. 1.0 > > - CeCILL v. 2.0 > > Would it be opportune to add other licences? > > _____ > > > http://www.osor.eu/communities/eupl/forum/eupl-and-gplv3/937... > > Could you please answer the following questions: > -If a GPL license says 'v2 or above', is it compatible with EUPL? > -How about GPLv3 compatability with EUPL? > > Also, I think it would be a good idea to reply to Mr. Schmitz. > > Please keep me up to date about any proceedings. > > Thank you in advance for your time and efforts, and I really > appreciate FSF > provides an easy way to ask questions about the licenses. > > Best regards, > > Hans Kwint > Breda, The Netherlands > LXer.com editor > > > -- Sincerely, Donald R. Robertson, III, J.D. Assignment Administrator Free Software Foundation 51 Franklin Street, Fifth Floor Boston, MA 02110 ____ I sent this to Mr. Schmitz (OSOR@EU) and ask for his comments. Will let you know once I receive a response, if any. |
| caitlyn Mar 30, 2009 6:40 PM EDT |
Dear Hans, Thanks for getting this clarified. I still see the EUPL as problematic but perhaps slightly less so. |
| hkwint Mar 31, 2009 5:16 PM EDT |
Update: Mr. Schmitz from OSOR replied really quick; here it is: Dear Hans, There is a legal study on the compatibility mechanism of the EUPL, see the summary and reference to this study in Philippe Laurent remarks on: http://www.osor.eu/communities/eupl/forum/eupl-and-gplv3/937... In my own opinion (I have no decision power, decisions are taken by the Commission), there are no objections against adding GPLv3 to the EUPL compatibility list, because the proposed criteria for acceptance of a licence in the original list are: 1) The licence must be recognized as a FOSS licence, a point that we formally characterised by the acceptance as such by either the FSF or the OSI (This is the case with GPLv3); 2) the licence must be strongly copyleft, at least as regards the source code (This is the case with GPLv3); 3) The licence must be of practical use, that is: a large number of software rely on it, or it governs either - at least one major software having a large number of user in the field where it applies, either - a project developed inside a public administration of a Member State of the European Community, or - a project partially or totally funded by the European Community or one of its Member States. Therefore the criteria suggested (in the study quoted above) in order to add a licence in the compatibility list were: - the licence meets the three criteria proposed above; and - either a public administration of a Member State of the European Community or developers partially or totally funded by the European Community or one of its Member States make use of this licence (as licensee or as licensor) for existing code and express the willingness either to include this code, or part of it, with or without modification, inside EUPLed code, or to include EUPLed, with or without modification, code inside the code under this licence. And there is the small problem, to say it frankly: GPLv3 advocates proclaim that the licence is very popular, but at the same time it is a fact that no public administration of a Member State of the European Community or developers funded by the European Community ever asked - so far - for extending the list to the GPLv3! It would therefore seem interesting to receive (i.e. on the EUPL forum or blog) some feedback from administrations, from their developers or from the EUPL community about their use of software under GPLv3... In addition, it may be that the FSF was not very amused by the initiative of the European Commission: probably they would have preferred a massive support for their V3, but at the same time they were (and they are still, as far as I know) unwilling to support linguistic diversity, not to speak of all other differences between these two - very heterogeneous - organizations. That's the story so far... And by the way: if the EUPL would add GPLv3 in its compatibility list, do you believe GPLv3 would add EUPL in its own list (do they have one, or do they consider compatibility as a one-way in the direction of AGPLv3)? All this is to discuss honestly (and honesty is very rare). Best regards, Patrice-E. Schmitz OSOR team ---Message Ends--- ____ This is what I asked: (First quoted the response from FSF legal department; then continued:) To me, this looks like GPLv3 can't be added to the compability list as FSF deems the copyleft of GPLv3 conflicts with the EUPL. I'd like to know if you share this opinion? Thanks in advance for your time and efforts. Best, Hans Kwint, Breda, The Netherlands ---My mail to Mr Schmitz ends --- ____ If I see all of this correctly; Mr. Schmitz says if EUPL is merged with GPLv3 code the result may be released as "GPLv3 only" when it comes to EUPL, but he is not in a position to decide. Mr. Donaldson from FSF says code released under GPLv3 merged with EUPL cannot be released as "EUPL only", even if GPLv3 was in the compability list, because of conflicting copyleft. So its one way only: EUPL to GPLv3 and not the other way around; however until now that's no problem because people writing software under GPLv3 don't want to release it under EUPL (that's only my guess; if they didn't agree with FSF they wouldn't have used GPLv3 in first case), and governments don't plan to use or release software under GPLv3 as far as OSOR knows - yet. Time to ask NoiV http://www.ososs.nl/about_ososs/ I guess. |
| Sander_Marechal Mar 31, 2009 6:53 PM EDT |
Hans, don't forget that "GPLV2 or later" currently means "GPLv2 and GPLv3". Many, many software is "GPLv2 or later". I bet that many projects are used by the EU that use this license. They may not use any projects yet that are "GPLv3 only", but they use a lot that are dual-licensed under GPLv2 and 3 through the "or later" clause. The fact that GPLv3 is one-way from EUPL to GPLv3 should be no problem. It's the same for EUPL and GPLv2 code. That's a one-way street as well. The real core of the problem is that the vast amount of "GPLv2 or later" projects in the world cannot incorporate EUPL code. If they wanted to do that they'd have to change the license from "GPLv2 or later" to "GPLv2 only". |
| hkwint Apr 01, 2009 7:10 AM EDT |
Quoting:Hans, don't forget that "GPLV2 or later" currently means "GPLv2 and GPLv3 As I understand it doesn't, it means v2 _OR_ v3, if v3 is no option than the only choice is v2. Quoting:The real core of the problem is that the vast amount of "GPLv2 or later" projects in the world cannot incorporate EUPL code. If they wanted to do that they'd have to change the license from "GPLv2 or later" to "GPLv2 only". That's a contradiction, first you say they cannot and then you say they can because they can choose "GPLv2 only"; isn't it? |
| Sander_Marechal Apr 01, 2009 7:52 AM EDT |
Quoting:As I understand it doesn't, it means v2 _OR_ v3, if v3 is no option than the only choice is v2. No, it's _AND_ here. You have to look at it from the developer's point of view. The people providing the software use multiple licenses at the same time. _AND_. The user who is downloading and using it can choose any or all of them. _OR_. A project "Foo" that wanted to incorporate EUPL code would need to change from "GPLv2 or later" to "GPLv2 only". That's a relicensing and could be problematic. Suppose there is another FOSS project called "Bar" that builds on Foo and is GPLv3 only. At the moment Bar can build on Foo because Foo compatible with GPLv3. When Foo incorporates EUPL code it must change to GPLv2 only, so project Bar can't build on Foo anymore. GPLv2 only is not compatible with GPLv3. Project Foo would need to choose between incorporating EUPL code and supporting project Bar. |
| hkwint Apr 02, 2009 5:20 AM EDT |
OK, so if there's something "GPLv2 or later" it can be merged with EUPL or GPLv3 but not both.
I think I see the problem. What I referred to was the possibility to relicense "GPLv2 or later" to "v2 only OR v3". But I didn't understand the problem arose _after_ relicensing. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!