Slashdot Mirror
A Case Study In GPLv2 / GPLv3 Compatibility
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.
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 :-)
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 :-)
How is this an issue? If KDE2 uses the GPL2, it clearly says "or any future version", which makes it forward compatible with the GPL3, which means it can be mixed with other GPL3 software. I see nothing in the linked article that contradicts this.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
This is the sort of reason why I use FreeBSD, and try my best to use BSD-, MIT-, or zlib-licensed software as much as possible. Even just as a user, I prefer the freedom and certainty that those licenses bring. Frankly, I don't need the hassle of unintentionally running afoul of the GPL.
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 software I've created. I'm not going to burden them with the many questions the GPLv2 and GPLv3 raise. I don't want them to have to read through pages and pages of legalese. I just want them to be able to use my software, modify it if they wish, and contribute back those changes (if they want to). The MIT license allows for that, and does so superbly.
It is this kind of confusion that could lead to many great ideas to be stillborn. But, maybe that is the point.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
I dislike the GPLv3, but I use GPLv2 for everything I write myself. I know there aren't many out there like me, but if there are enough, I think it might cause yet another regrettable split. Are the benefits of the GPLv3 over v2 (which seem very minimal if existant at all) worth the downsides? Only time will tell.
Dlugar
Computer Go: Writing Software to Play the Ancient Game of Go
The poster missed out on half of the introduction to OpenChange. Since most people won't visit the website, I'll fill in the blank.
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.
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 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?
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.
Time is what keeps everything from happening all at once.
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. Perhaps you should investigate those reasons before discarding it as a nuisance.
Crumb's Corollary: Never bring a knife to a bun fight.
You are arguing something different than the GP - you are saying that for any given line of code, the probability of it being written by a paid programmer is high, what he is saying is that the probability that a given FOSS programmer is paid is low. For example, if 5% of the people did 95% of the work, and those 5% were paid, then both of your claims are correct. I suspect it is probably something more like 10-25%, though not all paid, and 75-90%, but I no data to back that up. What he is concerned about is that for those who are only able to contribute a couple hours a week, spending even 15 minutes trying to figure out what license to release under, he will have lost 1/8th of his time. The ability to change the license away from original intent is quite troubling, as nice as it is to be able to maintain compatibility in licensing. This is similar to donors to foundations/universities wanting control of where their donations are used versus where the foundation/universities would like to spend their money. The catch here is that the university can replace general funds with donated and effectively remove the restrictions for most small and medium donations, whereas in the licenses, the restrictions and wishes of the creator are not removable.
The GPL v2 required that dependencies have their source available. Because there was no requirement to release the entire corresponding source as a single work, dependencies could have arbitrary licenses provided that the source was redistributed.
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 that one may, in the process of conveying the software, remove any permissions beyond those of the GPL v3. I.e. one can apply all restrictions of the GPL v3 to any portion of the covered work without asserting any copyrights in the matter. This means that if you use a BSDL file, this is only compatible if the BSD License allows changing the license of the file *without* modifying the actual code involved. My own reading of pretty much every BSD-license variant I can find suggests that the license follows the copyright and so this is not permissible.
Hence the BSD license puts further restrictions on the exercise of the rights granted in the GPL 3, section 7, paragraph 2, and is therefore not comp[atible. The BSD license is, however, compatible with the GPL v2, which specifically allows for additional permissions on elements which can be otherwise distributed separately under the terms of those additional permissions.
LedgerSMB: Open source Accounting/ERP
Personally I suspect that those who do adopt it don't understand the license.
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...
LedgerSMB: Open source Accounting/ERP
Perhaps, but exactly what relevance does that have to this discussion?
I mean, you know it's not at all the type of use I was talking about, and like you point out, even the FSF makes sure that it's not an actual problem in practice by using the LGPL for libraries.
It's only natural for people to want to protect what's important to them. But why must we begrudge each other for protecting those rights most important to them? The GPL protects the end users, the BSD license protects the people using the code itself. There's no need to attribute evil motives to either side or to avoid running code simply because it's under the "wrong" license.
Frankly, I find that just a bit silly.
FWIW, I don;t know if the LedgerSMB project is typical or not, but....
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 percent of contributors are creating contributions in the due course of other paid employement or contracts. Those same contractors may *also* be donating time and effort but that is another matter.
LedgerSMB: Open source Accounting/ERP
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.
I think one of the arguments that it comes down to is that when you create a binary you end up including code that is in the includes and that code goes into the final binaries. So any binary that uses a GPL header file gets contaminated with GPL code. Of course that arguments kind of falls apart as soon as you might have a include without macros or inline function or a language that doesn't have includes in the first place. So the GPL kind of only works fully with C-like languages and even then not always. It of course gets even more funky, since the FSF themselves argues that you can't/shouldn't have copyright on APIs, since that would make any API-cloning (wine, lesstiff, etc.) impossible, which however is really the only thing that would stop you from mixing non-GPL code with a GPL library in the first place.
So yep, I fully agree that a lawyer might interpret this quite a bit different then the FSF would do, but on the other side, doing some GPL and non-GPL mixing is just asking for trouble, if nothing else, it will make sure that such an app would never make it into any of the Linux distros around.
(I am not keeping anything secret.)
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 competing with BSD so much as competing with other proprietary UNIXs.)
2) In a BSD-licensed project, you can arbitrarily interfere with closed source versions if they are not contributing back what they should. In fact, you *will* cause them problems if you have enough development momentum. People who don't contribute back to a BSD project tend to be forced to fork and go elsewhere.
Interesting additional points include:
3) The worst punishment to any project (open source or not) which uses your code is to have an incompatible and adequate replacement for their value added features. This drastically increases the cost of maintenance and usually forces them to either contribute or forego future enhancements.
4) Community is all that matters. A strong community will be able to define and coerce wanted contributions while allowing people to sell unwanted portions. For example, nobody in the PostgreSQL community really wants the system to handle NULLs the way Oracle does, so if EnterpriseDB wants to sell that as a feature, great! EnterpriseDB, OTOH, ends up contributing pretty much every generally applicable change back so they don't get hurt though. Same with BizgressMPP and the collation node.
Again, look through my journal for an entry about encouraging contributions via the BSDL for more information.
LedgerSMB: Open source Accounting/ERP
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 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
Dan Shearer
If the printer that RMS wanted to fix had a Tivo lockdown on the code, then, despite having the code to the driver, how would RMS have fixed the printer problem? OK, he could have fixed the code but that changed code would not have worked on the printer. So how does fixing the code fix the printer? Doesn't, so it would be against the ENTIRE REASON RMS made the GPL up.
Additionally, since signing creates a derivative work (signed) of the GPL2 kernel, you need to be able to sign the code to make the derived work. Since the GPL requires that you have everything necessary to make the binary given to you under the GPL, you need the signing routine too. Irrelevant for me since I won't be getting a Tivo (since it's DRM'd so I can't undo "features" like removing ad skip).
Oh, and if GPL7 is a cut n paste of the WinVista EULA, you still get it under the (apparently acceptable) GPL6. Or 5 or 4 or 3 or 2...
Take that version and fork it.