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 :-)
No.
"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.
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.
Every line in the GPL is optional for developers. You can release your code with any license you want, including one you made up yourself. I can not understand why anyone would want to release their code with a "or any future version" clause. With this clause, you give away all control of the content of the license. If RMS suddenly decides the BSD license is great and writes a GPL4 with the contents of the BSD license, your code is BSD licensed too.
Actually, the problem lies not with KDE. The core KDE Libraries are actually LGPL (parts even use some BSD license), which should be pretty compatible with the GPLv3. Just like many KDE programs are actually GPLv2+. The 'problem' is that as of yet, Qt has been licensed under GPLv2 only (and slightly more, they allow linking with a selection of other free software licenses as well, as far as I know). Which in turn makes all KDE applications linking with Qt GPLv2 at run-time. The obvious reason would be that Trolltech just does not really like giving the FSF full controll over their Qt software through their ability to modify future versions of the GPL at will.
393 4848 40829
grep "version 2"
217 2878 22629
So, it would seem that 217 files are GPL2+ and and 176 GPL2(only) as far as KDE is concerned. However, KDE is built on QT which is licensed as grep "version 2"
994 10962 104446
grep "version 2"
0 0 0
So it would seem that QT is GPL2 only. A quick scan of a couple header files notes that
** This file may be used under the terms of the GNU General Public
** 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/ So... if you can somehow mix the KDE parts that are GPL2+ without using the QT library at all and without using the KDE parts that are GPL2(only), you're safe to mix GPL3 code with KDE. Good luck with that, though.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
I'm not going to burden them with the many questions the GPLv2 and GPLv3 raise.
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.
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
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).
Nope, the problem is Qt being GPL2 only, so KDE is unable to use GPL3 OpenChange code, because any resulting binary won't be legally redistributable.
Got Pike?
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
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
That's a separate issue though. You can put a warranty disclaimer, independent of whether you put conditions on distribution, or release it into the public domain.
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. One or two clauses saying not to remove the copyright and disclaimer, then the disclaimer. There's also an advantage in using an FSF/OSI approved license.
Don't blame me, I didn't vote for either of them!
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
"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.
Rethinking email