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
My requirements for a software license center around Stallman's original Four Freedoms. 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
Computer Go: Writing Software to Play the Ancient Game of Go
GPLv3 makes sure you can't take away freedom at any point in the chain of development of anyone else that comes after you.
What about the freedom to take away the freedom of others?
Freedom is a funny thing like that. True freedom does involve allowing one the freedom to restrict the freedom of others. And the moment you take away the ability of a person to restrict the freedom of others, you in turn have directly restricted their freedom, thus eliminating freedom for everyone.
The same goes for tolerance. To be truly tolerant, you have to tolerate intolerance. But that's usually not what we see. Instead, we get hypocrites preaching how great tolerance is, but then they in turn have a zero-tolerance policy when it comes to others who are intolerant.
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.
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
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
Computer Go: Writing Software to Play the Ancient Game of Go
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
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.