Slashdot Log In
A Case Study In GPLv2 / GPLv3 Compatibility
Posted by
kdawson
on Sun Sep 30, 2007 03:25 PM
from the growing-pains dept.
from the growing-pains dept.
An anonymous reader writes "A project called OpenChange is working to develop an open source client library for Microsoft Exchange. They are heavily dependent on Samba code for the underlying protocol support and have been forced to move to GPLv3 once Samba moved. This has gotten in the way of legally adding support to other software such as KDE, which is unwilling or unable to go GPLv3." It sounds like all the developers involved expect the GPLv2/GPLv3 issues to be resolved in time.
Update: 10/01 12:26 GMT by KD : Dan Shearer, of OpenChange and the Samba Team, wrote in to correct the anonymous submitter's mistaken implication that OpenChange moved reluctantly to GPLv3. Read on for his actual position.
Update: 10/01 12:26 GMT by KD : Dan Shearer, of OpenChange and the Samba Team, wrote in to correct the anonymous submitter's mistaken implication that OpenChange moved reluctantly to GPLv3. Read on for his actual position.
I'm Dan Shearer of both the OpenChange project and the Samba Team, and I wrote the message on bacula-devel linked by anonymous' original post. I would like to correct the unfortunate impression given by anonymous that OpenChange has been reluctantly forced to change licenses because Samba has moved to the GPLv3. In fact, OpenChange see that the GPLv3 is entirely appropriate for Samba, and OpenChange plans to use the GPLv3 even when not necessarily required to do so by upstream licenses. The move to GPLv3 was one of two license changes we plan to announce on openchange.org in the next few days.
The specific issue highlighted in the post is not a general GPLv3/v2 incompatibility. Code which is licensed under the GPLv2 but no later version is incompatible with the GPLv3. There are a few significant examples of GPLv2-only code, including KDE as mentioned and also the Linux kernel, which cannot be linked to GPLv3 code. That is a matter of policy for those few projects. We would of course be delighted to be able to use their code as appropriate if they change their policy at some point, but we have no complaint if they do not choose to do so. The GPL offers many choices and this is one of them.
Most GPLv2 code includes the words "or any later version", which is a statement of trust by the licensor in the people who create those later versions. The GPLv3 was created as a community effort, a very large and representative community effort, and in that sense many people think that this trust has been maintained. Including the Samba Team and the OpenChange project. If you are unsure about this, go to archive.org and search for "Eben Moglen 2007", which will give you a choice of media and plain text for the summary talk in Edinburgh a day or two before the GPLv3 was released. We respect that there are different opinions on licensing including some who do not like the GPLv3, however it is indisputable that the GPLv3 is very much a community production rather than a statement from the FSF. That fact of community evolution supports the idea that the trust implied by "or any later version" has been maintained.
It might also be helpful to reflect on the history of OpenChange. OpenChange is an independent work from a team led by Julien Kerihuel built on the research and tools produced by the Samba Team. OpenChange has been the direct beneficiary of a lot of effort contributed by the Samba Team over the last four years. We strongly support Samba's use of the GPLv3 as being an appropriate response to the current legal environment.
The thread the anonymous poster linked to was in response to Kern Sibbald of the excellent Bacula project. Kern has his particular views, and we respect those views, but they are by no means general. (Readers may also like to read the entire thread on bacula-devel.) When we look at the numbers at Palamida we find many thousands of projects that OpenChange can link against, besides all the others with compatible licenses such as the Apache license. We don't feel very lonely :-)
Related Stories
[+]
Samba Adopts GPLv3 For Future Releases 219 comments
Jeremy Allison - Sam writes with news that the Samba Team has decided to adopt the GPLv3 and LGPLv3 licenses for all future releases of Samba. Follow the link for a FAQ addressed to Samba developers and contributors. "To allow people to distinguish which Samba version is released with the new GPLv3 license, we are updating our next version release number. The next planned version release was to be 3.0.26, this will now be renumbered so the GPLv3 version release will be 3.2.0. To be clear, all versions of Samba numbered 3.2 and later will be under the GPLv3, all versions of Samba numbered 3.0.x and before remain under the GPLv2."
Submission: GPLv3 Scuppers Open-Source Exchange Compatibility by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Non-issue (Score:5, Interesting)
Re: (Score:2)
Re:Non-issue (Score:5, Insightful)
Samba --OpenChange -- KDE
KDE operates on top of OpenChange, which operates on top of KDE. From the write up, OpenChange is "heavily dependent on Samba code for the underlying protocol support". So they mix in outside (Samba) code which changed license, and thus are forced to change the license. Fair enough - they want the free lunch, they have to use the license specified by the guy who wrote the code.
What doesn't make any sense is that OpenChange cannot support KDE now. Of course they can. As long as they don't share any code, they can be licensed independently.
Parent
Re:Why are developers wasting their time with this (Score:5, Interesting)
Where did you get that datum? I think if you read any decent analysis, you'll find that the vast majority of code in active FOSS projects is written by programmers paid to do so. This means that project leaders, i.e. the ones who invest the most in the project have every incentive to think long and carefully about the future of their project, because it affects their professional future, too.
You only see that one solution because you haven't done your analysis properly.
There are very good reasons why more FOSS developers choose the GPL than all the other licenses combined [dwheeler.com]. Perhaps you should investigate those reasons before discarding it as a nuisance.
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Every individual on our core team except one does paid work on the project. We also do unpaid work as well. Most of our contributions also come from people create the work in the course of either employment or consulting contracts. I know that two of our core members (out of six) are employed in positions where development of LedgerSMB is not a duty.
So at least in my experience with one project, I would say that between 80 and 90 perce
Check out a recent bit from my journal (Score:3, Interesting)
However, there are two basic premises:
1) In today's market, one cannot compete with Free. Hence closed source versions are only viable if they are competing with your competitors' closed source products primarily. Note that every proprietary PostgreSQL spinoff has died if its primary goal was to compete with the Free version. The only 2 that have survived are primarily targetting specific markets held by Oracle and DB2. (Arguably, even SunOS wasn;t really aimed at co
Re: (Score:3, Interesting)
Thats not always legally possible though. For a hypothetical example, lets say you wrote some special music managing software that did plenty of neat and innovative tricks, and released it bsd.
Now Apple comes along and re
Re: (Score:3, Informative)
Re:Non-issue (Score:5, Interesting)
It is precisely for this reason that a GUI platform should not be GPLed; it should be LGPLed (which GTK/GNOME is, in the relevant portions). And also precisely for this reason that the Linux kernel, while GPL, is effectively LGPL for code in userspace according to their interpretation. Otherwise, the kernel would have this exact same problem - you wouldn't be able to run Samba on it.
Parent
Re:Non-issue (Score:5, Insightful)
That said, I have no clue if KDE includes that line or not.
Parent
Re:Non-issue (Score:4, Informative)
Parent
Re:Non-issue (Score:5, Informative)
You can use the GPL terms (possibly modified) in another license provided that you call your license by another name and do not include the GPL preamble, and provided you modify the instructions-for-use at the end enough to make it clearly different in wording and not mention GNU (though the actual procedure you describe may be similar).
Parent
Re: (Score:3, Insightful)
The "or any future version" is optional for the developers. I have removed it from all of my software, as I do not want to license my code under rules which have not yet been written.
from the GPL:
(emphasis mine)
In other words, if RMS decides to make the GPL7 with a copy of the Microsoft Vista EULA (or even the BSDL) -- Not only could you renounce it as 'not GPL' as envisioned in the license, but you could conceivably sue him for breach of
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
"The GPLv3, for the first time, departs from the "share and share alike" nature of the source code and attempts to dictate what hardware it should be allowed to run on and what hardware makers are allowed to do with the code they don't own"
Fixed it for you, but I uess that GPLv2 did the same.
Re: (Score:3, Insightful)
The effect of this is that if a project is GPLv3 licensed (like Samba), you can't use it to do X just because GPLv2 says you can. What this means for the project is that
Re: (Score:2)
Re: (Score:2)
KDE seems to have the (or a later version) in 3 header files I looked up. They still have the option to use a gplv2 version of samba.
And even then if you think your software is that important you can still contact the author of the gplv2 file you want to link/include in your gplv3 code and ask for special permission to include it in your project.
Re:Non-issue (Score:5, Informative)
393 4848 40829
grep "version 2"
217 2878 22629
994 10962 104446
grep "version 2"
0 0 0
** License version 2.0 as published by the Free Software Foundation
** and appearing in the file LICENSE.GPL included in the packaging of
** this file. Please review the following information to ensure GNU
** General Public Licensing requirements will be met:
** http://trolltech.com/products/qt/licenses/licensing/opensource/ [trolltech.com]
Parent
Re: (Score:3, Interesting)
Almost right. In legal English, "or" means exclusive or. So, when it says "or any future version" it means you get to pick a single version. Thus, if GPLv2 allows X an
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2, Informative)
"Or any future version" clause means the code can be forked and "the later version" license assigned. Existing code is never automatically license-upgraded ( I know it is not a word)
I do not think anybody will be interested in forking big projects unless they have the backing of a large group/any company.
That said, I think it is a non issue in this case as long as they do not intend to change Samba or KDE code in anyway.
Re: (Score:3, Informative)
This is why I use FreeBSD. (Score:2, Insightful)
When it comes to the open source software that I develop and release, I always use the MIT license. That's just the safest thing for me to do, and the safest thing for those who want to use, modify and redistribute the softw
What does that have to do with USE? (Score:4, Insightful)
Did you totally miss the part of the GPL that says it doesn't cover use? You can't run afoul of the GPL merely by using software.
As the GPL [gnu.org] puts it:
> When it comes to the open source software that I develop and release, I always use the MIT license.
And I thank you for that. I don't care what your motives, I appreciate those who share code.
But please don't spread FUD about the GPL. Is that too much to ask?
Parent
Re: (Score:3, Insightful)
Re:This is why I use FreeBSD. (Score:5, Informative)
GPL is designed to give Freedom to the 3rd person in the chain of development. BSD only gives freedom to the second person in the chain, but he can restrict the 3rd person's freedom if they so choose. The 1st person is of course the original developer and he can do whatever he pleases regardless of license.
Hence, with BSD your code is only free to the first two persons and even though the 2nd person can be generous and release his changes in BSD to the 3rd... The 3rd is still free to restrict the freedoms of the fourth and so on.
GPLv3 makes sure you can't take away freedom at any point in the chain of development of anyone else that comes after you.
Parent
Re: (Score:3, Insightful)
I really don't want to tell the 2nd and 3rd person what to do.
The problem is by not telling the 2nd person what to do you are not even giving the 3rd person a chance.
Re: (Score:3, Insightful)
Surely a freedom loving "3rd person" would get the code from either the "1st person" or a freedom loving "2nd person" instead?
This is why I find the FSF a bit patronising - trying to enforce freedoms on those that don't want them just seems a little too much to me.
I would prefer that the ongoing freedom aspects were handled by education
Re:This is why I use FreeBSD. (Score:5, Insightful)
I have always considered the BSD a libertarian license, in that it depends on individual goodness and doesn't try to impose any restrictions. The GPL on the other hand is more of a socialistic license in that it tries to impose the "greater good of the society" condition on downstream contributors. Which license you prefer very much depends on which philosophy you prefer.
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
With the huge difference that socialism as a political system is compulsory, as a license it's voluntary. If you ask what's wrong with socialism, the usual answer is that you're paying for everyone else. You don't
Re: (Score:3, Informative)
Without a condition that says not to remove the warranty, you would be setting yourself up for legal disaster. I wish it weren't the case, but that's the reality we live in.
One could also have a licence saying you can do what you like (e.g., WTFPL as the other commenter pointed out).
That is essentially what the BSD, MIT and similar licenses do. On
GPL X Confusion (Score:3, Insightful)
Unwilling to move to GPLv3? (Score:3, Insightful)
Dlugar
Re: (Score:2)
As I understand it, the GPLv3 is actually much more compatible with other Open Source licenses than the GPLv2 was. I honestly don't know of anything I would consider a downside to the GPLv3. I think it's all around a better license than the GPLv2.
Re: (Score:2)
Are there any it's compatible with that the GPLv2 isn't, that v3 doesn't have a special exception for? That would be news to me.
I think the biggest downside to the GPLv3 is for those who simply want to protect the four freedoms [gnu.org], and don't feel like a general-purpose
Re:Unwilling to move to GPLv3? (Score:5, Interesting)
My requirements for a software license center around Stallman's original Four Freedoms [gnu.org]. Any software I write I want to have those four freedoms protected, both for what I distribute as well as derivative works, but have no other restrictions, either for developers or users.
The GPLv3, I feel, unnecessarily limits Freedom 0, as well as containing additional clauses that do more than protect the four freedoms. The BSD license doesn't preserve these freedoms for derivative works, so it's not my ideal license either. The patent clauses of GPLv2 simply say, "any patent must be licensed for everyone's free use or not licensed at all", which adequately protects the four freedoms, but doesn't make any further restrictions. It's not what I would call an "anti-patent" provision in the same sense as the GPLv3.
Regarding DRM: it is impossible, in my opinion, for DRM to infringe upon the Four Freedoms in a software sense. Software-based DRM cannot prevent users from exercising any of their Four Freedoms, because since they have access to the source code, they can simply remove the DRM portions of the software. For DRM to work at all with open-source software, the DRM must be entirely hardware-based, and, in every case, that exact software will run on modified or alternate hardware. Thus, I believe anti-DRM provisions are out of scope for a software license, because it attempts to dictate what sort of hardware you are allowed to distribute with your software.
What it really comes down to for me is the four freedoms: anything the license does that is above and beyond those four freedoms is something I don't want. Any of the four freedoms it fails to protect is a deficiency. And that's why I've chosen the GPLv2 for my software.
Dlugar
Parent
Re:Unwilling to move to GPLv3? (Score:5, Interesting)
I could construct a piece of hardware that will only run an unmodified RHEL3 image, but never actually distribute that image myself. By building and selling that piece of hardware, have I somehow removed any freedoms of all the people running RHEL3? Not at all. They still have access to the source code, they can modify it and distribute their modifications, they can run the code for whatever purposes they want, etc. The only restriction is to the hardware, not the software. Furthermore, there may be very legitimate reasons why somebody might want to ship a piece of crippled hardware that can only run a single image. Even the FSF has recognized that in their DRM exceptions in the GPLv3.
I could agree that some people might interpret Tivoization as an infringement of the first freedom, but a statement so strong as "clearly infringes" I have to disagree with.
Dlugar
Parent
Re:Unwilling to move to GPLv3? (Score:4, Insightful)
If someone were to take my code, and extend it with GPLv3-only code, then the derivative works would have more restrictions than Stallman's four freedoms, which is something I don't want to have happen. I would be unable to take their changes back, for example, and use them at a company who was worried about the patent retaliation [gnu.org] clauses, or other restrictions that aren't present in v2.
Dlugar
Parent
No, it is not (Score:3, Interesting)
The GPL v3 requires that the corresponding source is distributed as a single work, under the GPL v3, which means that all dependencies part of that work (defined in section 1) must be GPL v3 compatible.
Now, the real killer is Section 7, Paragraph 2, which states t
OpenChange is more than a client (Score:5, Informative)
OpenChange is basically the Samba of Exchange. It aims to provide both a library to be used in clients (as mentioned), and also provide a drop in replacement for Microsoft Exchange server.
Personally, I'm a bit weary of the project. Although it would be nice to have an open source server thats natively compatible with Outlook, and provides an easy transition off of Microsoft products, I'd much rather see a real Open standard take hold rather than turning MAPI into a pseudo standard like Samba has done to CIFS and is doing with Active Directory. Perhaps this is the best that can be done considering how entrenched Microsoft Exchange/Outlook has become in many companies.
Re: (Score:2)
That way people can wean themselves off the proprietary protocols gradually, while moving to a standard one.
Response from OpenChange and Samba (Score:5, Informative)
The specific issue highlighted in the post is not a general GPLv3/v2 incompatibility. Code which is licensed under the GPLv2 but no later version is incompatible with the GPLv3. There are a few significant examples of GPLv2-only code, including KDE as mentioned and also the Linux kernel, which cannot be linked to GPLv3 code. That is a matter of policy for those few projects. We would of course be delighted to be able to use their code as appropriate if they change their policy at some point, but we have no complaint if they do not choose to do so. The GPL offers many choices and this is one of them.
Most GPLv2 code includes the words "or any later version", which is a statement of trust by the licensor in the people who create those later versions. The GPLv3 was created as a community effort, a very large and representative community effort, and in that sense many people think that this trust has been maintained. Including the Samba Team and the OpenChange project. If you are unsure about this, go to archive.org and search for "Eben Moglen 2007", which will give you a choice of media and plain text for the summary talk in Edinburgh a day or two before the GPLv3 was released. We understand there are different opinions on licensing including some who do not like the GPLv3, however it is indisputable that the GPLv3 is very much a community production rather than a statement from the FSF. That fact of community evolution supports the idea that the trust implied by "or any later version" has been maintained.
It might also be helpful to reflect on the history of OpenChange. OpenChange is an independent work from a team led by Julien Kerihuel built on the research and tools produced by the Samba Team. OpenChange has been the direct beneficiary of a lot of effort contributed by the Samba Team over the last four years. We strongly support Samba's use of the GPLv3 as being an appropriate response to the current legal environment.
The thread the anonymous poster linked to was in response to Kern Sibbald of the excellent Bacula project. Kern has his particular views, and we respect those views, but they are by no means general. (Readers may also like to read the entire thread on bacula-devel.) When we look at the numbers at Palamida (http://gpl3.palamida.com:8080/index.jsp) we find many thousands of projects that OpenChange can link against, besides all the others with compatible licenses such as the Apache license. We don't feel very lonely
Re:Linus is right (Score:5, Insightful)
Linus himself does not think GPLv3 is a good thing. So why do people keep adopting it.
People are adopting gpl3 for some of the same reasons they adopted gpl2, which is to ensure that users are free to modify their software to suit their needs.
Parent
Re: (Score:3, Informative)
Heck, I don;t think anyone understands the license. The large, nasty surprise is that Paragraph 2 of section 7 pretty much makes the license incompatible with every other license which doesn't have a clause authorizing sublicensing under the exact terms of the GPL v3. It *might* even be the case that GPL v3 + linking exceptions might be incompatible with generic GPL v3...
Re:Linus is right (Score:4, Insightful)
I'm amazed there are people out there thinking this kind of behaviour is fair game. Just because somebody makes their source available, doesn't mean they want you to pass off their work as your own.
It really is very simple:
BSD says "Do what you want. I don't care."
GPLv2 says "You got the source, so should your customers."
GPLv3 says "Stop jumping through loopholes! You got the source, so should your customers."
Commercial licenses say "You want the source?!?! Go f*%$ yourself."
Personally I would never BSD license any of my code. There are too many people in the world that will happily rip it off.
Parent
Re: (Score:3, Interesting)