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.
ps. I've released all my new software under GPLv3. Novell shouldn't be able to threaten people....
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.
I have to wonder how much developer time has been wasted trying to deal with these licensing incompatibilities.
Most open source developers work a full-time job elsewhere, and have a very limited amount of time to contribute to their open source projects of choice. So any time that is wasted on these licensing shenanigans is a significant amount of time that isn't being used to actually improve the software itself. And it's more beneficial to more people to have the software working and/or improved, rather than some absurd licensing conditions being met.
The one solution I see is to just avoid the GPL family of licenses. Unfortunately, that means avoiding a lot of good software that also uses those licenses. But if avoid that software allows an OSS developer to focus on developing software, rather than getting immersed in rather useless legal discussion, it may just be worth it.
Sure, they could. But then we ask, why should they have to? And the answer is: solely because of legal shenanigans.
It'd be one thing if there was a technological issue at play here. But it's not. The main problem here is completely a human-created problem. Here we have massive incompatibility between one version of a license and the next. And this is supposedly a license whose creators and advocates say is meant to encourage source code to be modified, used freely, and readily shared with the rest of the community.
I sure hope that corporate CTOs and CIOs don't hear of this. This is the very thing that brings doubt into their minds, harms the adoption of OSS, and thus limits the contribution of changes back to the community. It makes me want to start licensing all of my software under the MIT license, where I know the terms are sensible.
holy fuck...i don't care what i get modded for this, but you guys are fucking ridiculous. Open software is supposed to be about innovation and all that other fun shit, but all you guys do is bicker about what licensing to use. personally i would be like "heres my code, do whatever the hell you want to do with it."
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?
Why is this modded insightful? Yes, when you use the latter version to derive your right to distribute the code (has bugger all to do with use) then the newer version supersedes the old in it's entirety. You only need one license to be allowed to distribute the code, no matter how many other licenses you can also get.
If you link GPLv2 or later code with a GPLv3 or later code the result becomes GPLv3 licensed.
This would be a great time for a new edition of this book.
*taps foot impatiently* (but not in the manner of Sen. Larry Craig)
Every single source file with the GPLv2 or later license applied can still be used under GPLv2 or later, no matter if you have to derive the right to distribute the binaries from the GPLv3 because it's linked to GPLv3 code ... I think to say it becomes GPLv3 only is a bit disingenuous.
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.
The idea is to get MS to think there is a riff in teh open source community that they can exploit.
And when they go to exploit it, the open source community will stand together and tell MS not to mess with family.
It'll make Time Magizine cover, even better than Bill Gates did when he yelled piracy as Time cover storied it as the great software flap.
So basically, your stance is to mindlessly lick Linus' taint at every opportunity, like you just did?
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.
I've RTFA'd the links and I can't see there's any fundamental problem here (or at least none that is clearly expressed anywhere)
I appears just to be a discussion about how 2!=3 and some people on the project don't want to go to 3 but would prefer to stick to 2.
If GPL3 is incompatible with GPL2 in some fundamental way, and this is a real world example, perhaps someone could outline the issue more clearly.
At the moment this just looks like some esoteric argument about licence preferences.
Wrong,
v3 does not ensure anything v2 didnt!
V3 adds chains (which may be good under certain circumstances) but i dislike.
Actually the main reason i dislike v3 is that is easily understood for a non-"OS-Freak".
V2 is easily understood, but v3 includes weird clauses which noone without "inside" knowledge would understand. Period.
Also publishing with no license means default copyright protection, which means no copy allowed at all. That's also the way GPL works : If you disagree with its terms, or that some clause of the license is ruled abusive, default copyright protection applies, which means no distribution (by anyone other that the author(s) ).
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
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.
According to the mailing list post posing as an article, openchange only links with samba. Since when did linking with a library mean that you have obligations to the developers of that library? Microsoft would love it if that were true. It would mean that you would need a license to develop software for Windows. Nintendo tried to sue Game Genie back in the 90's for doing something similar, but with hardware. It didn't go well for them. The judge beat them down. They tried again when someone made a non-licensed game boy game, and they got beat down again.
Does openchange even distribute samba libraries? If they do, they could get around this simply by distributing them separately.
On the other hand, maybe, for some reason not specified in the "article," they have other reasons for changing licenses. Maybe they feel it will be simpler in the long run. If so, that means nothing for the rest of us.
Also, according to the "article," they aren't moving to the GPLv3, but rather are thinking about moving to a GPLv2 + exception.
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
GNOME and all of their stuff (GTK+, etc) is all LGPL where it makes sense.
Qt is dual-licensed under either GPL or some proprietary license which you have to pay for. The idea is, if you want to develop a proprietary app, you pay them. Unfortunately, that also means that if you want a GPLv3 app, you have to wait for a GPLv3 version of Qt stuff. (That is, unless you're willing to distribute GPLv3 KDE yourself, assuming, of course, that they kept the "or later" clause.)
Don't thank God, thank a doctor!
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.
But what if my need is to modify the software, and not redistribute the modified source code? Whoops, there goes the GPLv3, restricting my freedoms.
The BSD and MIT licenses follow the elements released under those licenses. Yes, you can add elements under other licenses, and thus restrict freedom, but if you are only trying to compete with Free you will lose (case in point: Pervasive PostgreSQL).
There are plenty of reasons to contribute back to BSD/MIT licensed projects, both moral and economic.
Note also that the GPL doesn't guarantee anyone any sort of freedom either. If I set up an enhanced Samba service (an SAAS model), I don't have to provide my enhancements to any third parties. If you want that go with the AGPL or Larry Rosen's OSL. However in these cases, note that the requirement to make the changes available actually undercut the ability for you maintain security released in a central point since everyone who runs a public demo of the software must distribute the code of that demo.
LedgerSMB: Open source Accounting/ERP
You are going to show me your tits on a phone?
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.
My own view is that the GPL v2 is a good license which balances flexibility with the need to provide some protection to first movers. I.e. a business which releases a new GPL v2 application isn't just subsidizing the competition. I don't think the GPL v3 continues this balance.
Because I am concerned about the future of the GPL v2, I intent to start releasing more code under the X.org license which, by my reading, is incompatible with the GPL v3 but not the GPL v2. I say this because I now understand how to get proper contributions for permissively licensed projects and thus ensure their continued success and freedom without subsidizing the competition.
LedgerSMB: Open source Accounting/ERP
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.
So, tell us, where can we find the BSD-licensed equivalents of OpenChange, Samba, and Qt?
I just want [...]
Well, and I just want a flying car and a toilet seat made out of gold. It ain't gonna happen, baby. Licenses are complicated, and there are so many of them, because the real world is complicated.
And if you release the wrong software under the BSD license, you could end up screwing open source and open standards badly. Look up Microsoft, MIT, and Kerberos.
v3 does not ensure anything v2 didnt!
Sure: it ensures that people can't claim patents on the software while at the same time shipping it or profiting from it. That's very important to ensure that the software remain free and open.
I mean, we had the Microsoft/Novell deal and Microsoft's patent threats. How much more clearly do people like you need to have it spelled out for you??
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
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
1) The license is far longer and complex than the GPL v2. I have had marithon arguments about what the GPL v3 requires or does not require, particularly as relates to BSDL compatibility (I have concluded as a result of these arguments that the BSD License is *not* compatible with the GPL v3).
2) The GPL v3 may run into copyright misuse defenses, which could render the restrictions of the license unenforceable and thus allow license violations with impunity. (For a good example of a copyright misuse case, see Lexmark v. SCC, where SCC admitted to slavishly copying Lexmark's software but was not held liable for infringement because this was required for interoperability).
3) The length of the license may pose a problem in certain fields, such as embedded devices.
4) Unclear which licenses are actually compatible with GPL v3, section 7, paragraph 2 (removal of additional permissions). This point was not addressed in the recent SFLC paper on permissive license/GPL v3 issues.
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.
(IANAL)
When you dynamically link to a library, the linking process loads both the original file and the linked library into the same protected memory space, but in different portions of that space (i.e. although they share the same protected memory segment, the address spaces are still different). This would not be sufficiently different than if you included two scholarly papers in an anthology, one of which cited the other frequently. Even if certain page numbers, paragraphs, or even sentences were specified, unless one paper reproduced elements of the other, it would not be a derivative work.
Also note that what differences exist would actually make the linking application *less* derivative than the scholarly paper. For example, you could create an application with the same API, and then rerun the linker on it to resolve the symbols and now the original work is no derivative of a different library? I don't think so... Then, does creating a new library with the same API as another alter what works other existing works are derived from? Again, I don't think so.
Furthermore, if you look at cases like Lexmark v. SCC, the court clearly said that copyright does *not* give you a monopoly on controlling add-on components (so SCC prevailed in their copyright misuse defense and could continue to slavishly copyright Lexmark's software).
LedgerSMB: Open source Accounting/ERP
I think I've read enough of Linus' opinions to see his position and why he and RMS differ in opinion. The reason is that Linus doesn't care about the four freedoms that RMS is preaching. Hold on, please wait with the torches and pitchforks for a moment. The four freedoms all refer to the users of the software, while Linus only seems to care about the developers of that software. As a developer, Linus wants to have access to modified versions of his source code (assuming the binaries are distributed) so he can merge improvements back into his own project. RMS wants users to have access to their source code so they can make improvements to their own software. Do you fail to see the difference? Well, most of the the there isn't one and this is probably the #1 reason the GPLv2 is so successful - it gives something to the developers and something to the users.
The difference only becomes clear when you introduce something like a tivoized computer. Under the GPLv2 they must still release the source code, so Linus is happy since he can look at it and add any improvements to his project. Moving to the GPLv3 means he might miss out on improvements because the additional restrictions (from a corporation's point of view) would scare them away, so for him the GPLv2 is pretty much ideal - it's pretty much maximal freedom while still returning code to his project. For RMS on the other hand, the GPL is a miserable failure in this case since the end users are locked out from making any changes to their software. On the one hand, I think RMS is right to push for the GPLv3 since he believes in the four freedoms. On the other hand, in the OSS community the variation on the golden rule is "He who writes the code, decides the license" and if the developers prefer GPLv2 then that's their perogative.
Perhaps some will choose the GPLv3 because they believe in the four freedoms. Perhaps they sit at both sides of the table as users and developers and recognize that they'd like to be granted from others the rights guaranteed under the GPLv3, thus releasing it under the GPLv3 themselves. But it's quite clear that the GPLv3 doesn't have a big carrot for the developers, since they already get pretty much what they want with the GPLv2. It will be interesting to see how adoption of the GPLv3 is - version three is much more of a "users vs developers" while the GPLv2 is a win-win for both, in my opinion. Ideology is good, but self-interest is usually a very powerful driver...
Live today, because you never know what tomorrow brings
"... or that some clause of the license is ruled abusive, default copyright protection applies, which means no distribution (by anyone other that the author(s) )."
If some clause of the license is ruled abusive, that doesn't necessarily mean that the license is null and void (triggering default copyright protection). A court has the option of ruling that the remaining clauses of the license are still in force. This "all or nothing" theory of the GPL is bunk.
Why not share that little secret of your?
You're probably right about the proportions, but that's not an accurate scenario. Those aren't the people choosing the license, nor even the people to whom the license matters most. Look at it this way: If you're only coding for a couple of hours a week, your project had better not depend on you. And if it doesn't, then either you don't have standing to decide which license you release under, or you've made the choice already by deciding to commit to a particular project.
We could have a very fruitful discussion about the distinction between community contribution and code contribution. It's a topic that's often misunderstood. There's a ton of work that doesn't require 133T H4x0r skills, and that core developers just don't have time for. I would be genuinely interested to see whether there's any relationship between license decisions and overall community involvement.
But what I took issue to was the GP's use of bad analysis to draw a false conclusion. The plain fact is that the people to whom software licensing matters the most (or arguably, those who get to decide) are the very ones who consistently choose the GPL more than the sum of all other licenses. Without suggesting that 'everybody's doing it' is sufficient, I do think it's important to ask oneself why this license is consistently preferred by the people to whom it matters most.
Crumb's Corollary: Never bring a knife to a bun fight.
(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 am with Stallman on this one. For the life of me I can't understand what this sucking up to LT is about. Stallman himself thinks GPLv3 is a good thing. So why do people keep whining about it. Without Stallman FOSS never would've gotten started. Not following Stallman is dangerous for the survival of FOSS.
If your theory is different from practice, then your theory is wrong.
X.org uses the MIT license, which is permissive and compatible with both GPLv2 and GPLv3. If you mean XFree86, that is GPLv2 incompatible and GPLv3 compatible. I've not seen anything that would make the MIT license incompatible with GPLv3.
Based on your goals, I'd suggest making your code GPLv2 only. GPLv2 only is incompatible with GPLv3.
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
I got the impression that the person you're replying to isn't worried about these piecemeal coders wasting their time worrying about what license the project gets released under. He is more worried about one of these coders deciding that it would be cool to link in some kind of functionality from a different OSS project, and now this guy has to start worrying about exactly what flavors of GPL he's dealing with on both sides. Before, he just had to know that both were GPL and everything was cool.
This extra overhead only affects those developers contributing to GPL licensed projects. The headaches of dealing with other license compatibility issues remain the same.
Linus is after the monies. And he's gotten plenty.
He's just like M$ billy goatse and Apple steve-o "blow" jobs.
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.
If you remove the copyright note, HOW do you find the original author to sue?
Spelling/grammar nazis welcome (English is not my first language and I am trying to improve my spelling/grammar)
With Stallman only it would have never started either.
Nothing more stupid than following blindly someone, which is what brings together you and the OP. Much more stupid if you are talking about Freedom.
1) Linus doesn't like GPLv3 because he's smart enough to know that allowing contributors to remove the "or later" means that the kernel may well be locked into GPLv2 forever. He sure isn't gonna go "Hey, I love GPLv3... but wait a minute, I can't change the license of some files, so we're stuck to GPLv2". It's easier to say he doesn't like GPLv3 until someone figures out whether it's possible to get out of this mess.
2) It's very stupid to not make sure there's a way to change the license of a project (and that's got nothing to do with the GPLv2/GPLv3). Either you require assignment of copyright to a specific organization, or you indirectly empower an organization to change the license (via something like the "or later"). Linus has done neither. Linus does a lot of great things. But he also does stupid things. What he's done with licensing of the kernel fits in the latter category.
3) What's the use of code if you cannot run it on the intended hardware?
1) or perhaps Linus has a legitimate beef with the GPLv3 and doesn't see it as an improvement to the GPLv2, but rather a regression. If he really, really wanted to, he could embark on a project to convert the kernel to GPLv3 by changing the license of the authors who agree to it and rewriting the code that hasn't been changed. The amount of attacks on Linus and the kernel devs because they won't submit to the FSF's wishes really speaks negatively about the FSF and its supporters.
2) It is very stupid to give control over your code to a third party. They can then turn around and completely sell you out and/or change restrictions on your work without your consent. See CDDB for example.
3) I guess that, since I can't run Firefox on my old Color Computer 2, the source to Firefox is utterly useless. Tivo's source is available. Feel free to take it and use it on any hardware you want. However, all hardware comes with restrictions (CPU type, amount of memory, available storage, etc). Tive's hardware comes with those restrictions as well as DRM. Don't want the DRM? Build your own box with Tivo's code.
Read the article once before you troll here again
But the revisions that were available until the last one, has a large amount of detractors that not only said they didn't like it but voiced opinions about how horrid it was. It wasn't until they were able to push the Novell deal as a monstrous injustice that people started supporting the GPLv3 drafts and it took another revision before the drafts were fixed to address it.
But that same fix will come back to bite them. MS can create a little covenant not to sue their customers and place it in their product offerings and in effect turn everyone who buys MS stuff into a little novell that cannot distribute GPLv3 covered works because of language in the GPLv3 itself. Of course MS would realize that some people wouldn't want the discriminatory patent deal so they would offer special licenses for 10 or 20 times as much completing the requirements of the clauses. It wouldn't be hard to happen. Anyone could do so, MS seems to be key to the puzzle because of their size. Projects like Samba and Openechange are particularly exposed to this because they needs to maintain compatibility with MS products which mean they would have to pay 10 or 20 times the normal costs for compatibility research and testing or they would have to take a license option from MS that causes the GPLv3 to bar them from distributing anything under it. Well, there is another option, Getting everyone's permission and going back to a GPLv2 or waiting for another horrid incarnation of the GPL to fix the problems this rushed version introduced.
The issue with the GPL v3 and both the MIT and X.org licenses (and possibly the MIT license as well) is that section 7, paragraph 2 requires that the license allow the extension of restriction to components added independant of copyright changes (because merely conveying the software doesn;t say anything about copyright ownership). This would seem to require that these licesens allow themselves to be *changed* to the GPL v3 with no additional permissions by anyone who does or does not hold copyrights to changes in those files.
The question is: If you distribute a GPL v3 application containing one X.org file included verbatem, and I redistribute this, does the X.org license allow me to change the license on that file to the GPL v3 without making modifications? I say it does not.
Interestingly this requirement was added in Discussion Draft 2 (Draft 1 required that the permissions were removed by somepne who substantively modified the softwre).
LedgerSMB: Open source Accounting/ERP
I think there are a couple of major reasons why people choose the GPL over other licenses (note only one reason may apply to any developer and these are not in any particular order):
:-)
1) They are fanatical followers of RMS. Anytime I get flamed for suggesting that I intend to do more under permissive licenses, this comes to mind.
2) They don't understand how to leverage the BSDL to encourage competition from both open and closed source partners.
3) They have a mature codebase and want to release it without having to worry about their competition using as free R&D. Note that the BSDL offers similar protections over time, but only in purportion to the community, so it is scary to release one's own code under the BSD license if you don't already have a strong community behind it.
In other words, they are either fanatical, ignorant, or have legitimate reasons for doing so
LedgerSMB: Open source Accounting/ERP
If I want to suggest that I have made the ultimate successor to the GNU GPL, and I take it, write my own different preamble, modify the license on other ways, and call it the GXI GPL is that prohibited? Or is this a reference to GNU? (XI is the Greek letter after NU).
Suppose my license is so great I skip an extra letter and call it the GOmicron GPL (or Go GPL for short)?
LedgerSMB: Open source Accounting/ERP
The third person is not stranded. They can always get the BSD version from you, and the closed source ersion can only really charge for their value adds, not for your own work if they are competing with you which is a problem for them if you can maintain a good pace of development.
I have been around the PostgreSQL project for some time. I have watched every closed source version that wanted to compete with the open version die. The two which have survived have done so by contributing everything back they can (i.e. everything that the community wants). They can then give customers what they want without being told what business model they need to have, while the project gets what they want out of it. It is a good situation for everyone.
Where the GPL really makes a difference though is in the initial source release. If you have a proprietary application you want to open source, you may have competitors which would like to initially use this to subsidize their own R&D, so you may want to choose the GPL instead. Note, however, that this doesn't prevent such a subsidizing of the competition (they can always clean room re-engineer), it just makes it a little more costly to do so.
LedgerSMB: Open source Accounting/ERP
If I am correct (IANAL), then linking is hardly sufficient to argue derivation and you would need to argue more than that. Of course, in the case of widgets like QT where the use of the artistic components of the widgets would likely make a work derivative on those cases (essentially copyrighted images enbedded in the UI of another application and thus creating screen output derivative of Trolltech's copyrights). Note that this could be the case whether the library was used in process, whether it was automated from another process, or whether it was automated from another machine.
A second important issue, however, is that the GPL v3 requires you to license nearly all your dependencies under licenses compatible with it (see definition of Corresponding Source in section 1, and requirements for binary distribution). Note that the GPL v2 does not make such a requirement and components whose source is redistributable if they are distributed as separate works.
So my view is that if I were to make a KDE application using OpenChange libraries, I could probably do this under the GPL v2 since the screen output is derivative of KDE, but the application is a collected rather than derivative work in memory including the OpenChange libraries. I could not do so under the GPL v3 due to the requirement to extend the license to KDE, and the question of derivative screen output.
LedgerSMB: Open source Accounting/ERP
It depends on who you ask. The FSF generally will tell you that linking creates derivative works. IANAL, but from my research, I don't buy that line. It is even less derivative than if I were to create an anthology of, say, physics papers where one paper references specific paragraphs from another (see article such-and-such, section 2, paragaph 3). Such specific references do not make one article derivative of the other.
However, the case with libraries is actually less likely to be derivative even than that. In the scholarly article, there is no possibility of substitution of the referenced article because it is what the author is citing or referencing. In a software library, we can create a library with an identical API, and then rerun the linker to generate the references. Hence the application and its library are even more loosely coupled than the articles are in the anthology I mentioned.
However, the fact is, your GUI application probably uses copyrighted images from the GUI framework. In this case, your screen output may be a derivative work of that framework.
While I would not try this without getting clear and impartial legal advice, I think one could probably create a GPL v2 application which would link to the OpenCHange libraries.
LedgerSMB: Open source Accounting/ERP
As long as the GPL allows mere aggregation with other components on the same media, it will be possible to Tivoize the package. All the GPL v3 does is prevent you from interfering with the actual execution of the binary. It does not tell you what the package as a whole has to be capable of doing.
Suppose I use a hypervisor and a hypothetical GPL v3 version of HURD. I want to Tivoize it, but I must treat a modified HURD as the same as an unmodified one by the hypervisor and hardware. So I provide the hypervisor as a separate download, and include all information necessary (including necessary encryption keys) to get modified HURD kernels actually running on the hardware.
However, I also release my updates in a way which cause the entire hypervisor and OS component image to be rewritten on every update. This includes other components in VM's which do things like DRM, HDTV reception, and the like. These components really are separate (in fact they are separate OS instances) and communicate with HURD via pipes.
So when you modify HURD and plop it on the device, HURD runs, but it cant do much because it doesn;t have anything to talk to.
Now you could use a similar system to create DRM where the OS wasn't trusted (even allowing a modified OS to run) and hence wasn't interfered with by the GPL v3, or the like.
These provisions in the GPL v3 have no impact. They are easy to circumvent if you want to, and they do not do what RMS promised.
LedgerSMB: Open source Accounting/ERP
LedgerSMB: Open source Accounting/ERP
but it stems from the idea that we need to legislate everything into the license.
The fact is, however, that technology can always be used to restrict what a modified system can do unless you start restricting any interference with the user rather than the program.
My reading of the GPL v3 would allow tivoization via hypervisors provided that the modified application is not interfered with or treated differently by the hypervisor or hardware. This doesn't mean that other aggregated components running in different VM's have to survive the OS update.
(Yes, the system runs and the existing components treat it just as if it were an unmodified version, but the components that do interesting things are now gone, so the box is now a paperweight.)
LedgerSMB: Open source Accounting/ERP
The FSF's position has been that if you ship GPL v2 software, you are giving an implied patent license covering any of your patents in that software. Although I disagree witht he FSF in most areas, I agree with them here (IANAL).
So now, the patent protections are not new. They are, however, different. The GPL v3 is actually quite a bit less strict about what patent protections are granted (in that they are effectively revoked for any license violation).
LedgerSMB: Open source Accounting/ERP
You mean that Linus should be allowed to be blunt and call it as he sees it, but others can do so about Linus' ideas/decisions? Come on...
:-)
Yes, if Linus really wanted to he could rewrite the code that cannot be relicensed. But maybe he doesn't want because it's no fun? I mean reimplementing code just because he didn't manage the legal aspect of the kernel isn't fun... not to mention that this is not entirely without legal hassle. You'll need the replacement code to be implemented in a "clean room", and that may exclude lots of the current Linux hackers.
Whether to give control over your code to third party is not a black and white matter. Leaving no way to change the license is stupid. You MUST have a way to change the license. The only question you should be asking is how this can be accomplished while factoring the wishes/concerns of the Linux project community. If you do not like the "or later", then you manage the project so that the ownership of contribution is assigned to a single individual or organization.
What has been done is to assume that the license will never ever have to be changed for any reason whatsoever. Either you make that lunatic assumption, or else you take a more sensible approach of allowing room for the project to change the license (by entrusting the author of the license with the "or later", or by requiring that contributions be given to Project XYZ foundation). This is not about GPLv3. If Linus wants to go to a BSD license for the kernel, it's still the same problem. He locked the project into being unable to make changes to the license. If a serious issue is encountered with GPLv2 (other than what the FSF consider issues), then Linus is still in trouble.
Linus messed up big time on managing the legal aspect of Linux. It's entirely possible that he has legit beef with GPLv3, but my take on this is that his biggest beef is that GPLv3 forces him to see he messed up. But you are welcome to disagree with me
If you do not like the "or later", then you manage the project so that the ownership of contribution is assigned to a single individual or organization. There aren't many third parties that I would trust to handle the licensing of my code. I sure as hell wouldn't trust the FSF to handle future licensing. Having a sole entity that handles your future licensing is a single point of failure just waiting to be attacked. If RMS dies, are you sure the FSF can't be bought out by MS at the cost of a cool billion dollars per board member?
If a serious issue is encountered with GPLv2 (other than what the FSF consider issues), then Linus is still in trouble. I'd rather handle a problem with the license as-needed rather than try to change a license blindly to some future threat derived from paranoia. Right now, the GPLv2 is very well understood. The GPLv3 is overly complex and perhaps self-contradictory. Better the devil you know than the devil you don't.
Linus messed up big time on managing the legal aspect of Linux. It's entirely possible that he has legit beef with GPLv3, but my take on this is that his biggest beef is that GPLv3 forces him to see he messed up. But you are welcome to disagree with me
No, I don't disagree with the position that the GPLv2 implied a patent license too. But the new GPLv3 specifically states that you cannot contribute something and then take it back with a patent. But more importantly, is says that if you release something under the GPLv3, you can to certify that any patents present have a license available to all down stream users. Who ever releases something GPLv3 now, even if it is moving a license from GPLv2 or later to GPLv3 takes on the liability of claiming we have the right to use any patent related materials.
In this way, I agree that they are different. You are now expressly permitting the use of the patent connected material. But as the OP I was replying to said, it ensures that people can't claim patents on the software while at the same time shipping it or profiting from it. That's very important to ensure that the software remain free and open., Which is incorrect. The GPLv3 separates the idea of it being perpetuated by someone's involvement with the product when it is GPLed and now it rests on who included it under that license.
And more to the point, neither GPL version protected something from being covered by a patent. I could have a patent and you could use it in your project without my permission and this would not negate any claims I would have. To date, most of the patent problems with the GPL were this way where a third party made a claim outside the scope of participating in the community. and of course with the GPLv3, someone had made a representation as to being able to license the patent related material so now I have a clear target to sue. so if anything, the GPLv3 has made the problem somewhat more troublesome for people who might include something that is later declared part of a patent.
Note that the ASL code cannot coexist int he same work with GPL v2 code because of the patent termination clause. The GPL v2 does not allow patent licensess to be terminated just because someone initiates a patent lawsuit, while the GPL v3 does this (and is by my reading incompatible with the ASL on other grounds, namely that Section 7, Paragraph 2 permission to change the license to the stock GPL v3 cannot be meaningfully extended to ASL code).
Hence if you distribute code under the GPL v2 or later, you can't later claim your patents allow you to sue people who violate the GPL v3 because the GPL v2 doesn't allow for this sort of patent license termination. IANAL though.
LedgerSMB: Open source Accounting/ERP
the GPL v3 prevents the following form of Tivoization:
An embedded device with a hypervisor running GPL'd software in one VM, with other VM's that handle access to specific hardware. The main VM hosting the GPL'd software only talks to the hardware through other software that is effectively on the other sides of pipes managed by the hypervisor.
I allow you to create your own main VM image, but when you install it, it wipes out all the other VMs, thus althoug nothing is interfering with your binary, your binary isn't able to do anything interesting because nothing is on the other side of the pipes.
LedgerSMB: Open source Accounting/ERP
Since when does dependency == derivation? (IANAL)
Is MinGW a derivative work of Microsoft Windows? Does anyone really believe that?
The dependency on KDE of a client app would be real since you are using their copyrighted images in widgets. But the merely functional libraries of OpenChange would seem to be another matter. I don;t see why you couldn't release a KDE client for OpenChange using their libraries under the GPL v2.
LedgerSMB: Open source Accounting/ERP
First, my reading of BSD-style licenses is that tehy follow the copyrights. I.e. you can't include BSDL code in your GPL v2 or V3 application and pretend that the restrictions of the GPL apply to that code. Or rather you can pretend to but it may lead to troublesome legal and/or political disputes.
Secondly, although this is not "passing your work off as my own," nothing in copyright law prevents clean-room reimplementation. For example, you could have 2 people read through my code, document the algorythms, etc. and hand their notes off to two programmers which implement similar solutions to the problems.
LedgerSMB: Open source Accounting/ERP
Linus mistake is unrelated to the discussion of GPLv2/GPLv3.
Linus should manage the kernel such that *IF* a licensing problem arise, or *IF* the linux kernel community decides to change the license, then it can be done. No one said you have to use "or later", or you have to give the code to the FSF. However, as it stands, people like you and Linus, are putting their head in the sand rather than addressing the problem. Letting the problem grow bigger is definitely not wise either. The problem SHOULD be addressed NOW, rather than later. Once it is addressed, then people in linux kernel community can decide whether to stay with GPLv2 for now, or move to GPLv3.
If the copyright laws change and you need to change the license, it can't be done for Linux. So, again, the matter of whether one likes GPLv3 has nothing to do with the fiasco that the linux licensing is.
If you cannot understand this, then...
It's a theory.
I *highly* doubt that makes such permissive licenses GPLv3 incompatible simply because any number of lawyers who were present during the draft process would have noticed such a glaring error.
I didn't find anyone else in a rudimentary google search who pointed this out, so I'm betting you're probably wrong here. I don't mean to sound like an ass, but it's very unlikely this is the correct interpretation of the license.
You're seeing a problem that none of us particularly cares about... we'll cross that bridge when we get to it, if we need to. At this time, there is no reason to. Would most kernel devs trust Linus' judgment on future licenses? Probably... but why give your rights away before there is a need to? Nothing is going to happen where the kernel needs to have its license changed overnight and it would be pretty short-sighted to hurry into a change, just because you can, before you truly think it out (it's been more than 2 months since the FSF mandated gcc be GPL3 only and, to my knowledge, the gcc steering committee still hasn't gotten approval on what to do with the files that need exceptions even though there's another release knocking right now (currently on RC2)). Fat lot of good the FSF being able to instantly change a license does.
Questions:
Does section 7, paragraph 2 provide the right to change the license to arbitrary portions of the code? Seems to me the answer is "yes." AFAICS, Moglen's writings and the rationale documents agree.
Does this require one to add copyrights on portions where the license changes? Certainly not. Everyone agrees here.
Does the BSD license permit the changing of the license without modifying the code? Nobody can agree here. However the SFLC did out out guidelines where they suggested that the workaround was not to change the license. This would suggest that there is at least a good chance that the answer is "no."
Is this an enforceable license incompatibility? I really have no idea. I.e. if you take my BSD-licensed code, distribute it as part of your GPL v3 appication, can I stop you? I don't know. If a downstream distributor changes the lciense on the file as allowed by the GPL v3, can I stop him? Probably. Can he come after you? There is the question....
LedgerSMB: Open source Accounting/ERP
I also don't see any specific argument that could be made tht the GPL doesn't force people to grant patent licenses under either version unless they are explicitly licensing for a specific work. Again, IANAL.
For example, suppose I have three patents, A, B, and C. I create code based on patent A which I contribute to a GPL v2 application that infringes on neither of my other patents.
I then contribute code based on patent B to a GPL v3 application which infringes otherwise on patent A. If I new about the infringement on patent A, this might be an implied license.
You take my patent B code and include it in an application that infringes on my patent C, but that application us under the GPL v3. This is not an implied license. And I don't use or distribute that application.
Hence in the third example, I can sue users of the application for patent infringemnet, I believe (IANAL).
LedgerSMB: Open source Accounting/ERP
I suggest you consider the art of parody through parallel form.
If your theory is different from practice, then your theory is wrong.
Would you care to explain your reasoning here? What is it about that paragraph in particular that you find objectionable?
The GPL has always been incompatible with licenses that do not allow sublicensing under the GPL -- in other words, every strong copyleft license that isn't the GPL -- in the sense that you can't combine code from two such "incompatible" sources into a single work. That's the nature of the beast. Version 3 does make it "easier" for BSD-like licenses to permit sublicensing under the GPL, by permitting a handful of additional restrictions (warranty statements, attribution, publicity, trademarks...)
As for GPL-with-linking-exceptions: GPLv2 exceptions generally state, and GPLv3 makes explicit, that you can remove those additional permissions if you want to; so that you definitely can combine any two GPL works into a single work and distribute it under the GPL-with-no-exceptions, or possibly with certain exceptions depending on the circumstances.
Keep reading it. More specifically, section 10 where it says
This means that unless you add something, the original licensor is granting all rights to you You have to pass those rigths on when conveying the covered works. But when you move the license, you are now the licensor. To clear this up a little, in section 11, it says
So you are obviously a contributor under the GPLv3 once you place anything under it. You couldn't just up and change the license to something without doing something to become a copyright holder. Even if it is changing the name of the project in order to change the license. Notice how is says A copyright holder and not the copyright holder. This is because you don't need everyone else's permission to move something if it has the or later versions text. And finally section 11 goes on to say
So it is obvious that you have to place something under the GPLv3 in order to be a contributor or to grant a patent license. Unlike the GPLv2, if I know about a patent of mine and continue to distribute it, I has essentially consented to others using my patent related software. With the GPLv3, as long as I didn't put it there, I didn't give any consent or any license, I have instead passed along the rights that people have passed to me. If one of those rights are bogus, like using the software related to my patent and I didn't place it in there, I can still sue over it. I did not give up any rights.
The section you are probably think means that anyone distributing the covered works would be giving the patent license automatically would be this
But this specifically says that if you arrange for a patent license to happen, it happen for everyone. You a
> You're seeing a problem that none of us particularly cares about...
Who is this "us" you are talking about?
> we'll cross that bridge when we get to it
You are assuming that you'll be able to cross the bridge at all... if you can't get a hold of those who have removed the "or later", what then?
> but why give your rights away before there is a need to?
No need to "give your rights away". Just share them. Problem is, with people being short sighted like you, the day "there is a need to", it's going to be too late because you are going to have a bunch of code who's authors are nowhere to be found.
But anyways, no amount of rational explanation about all of this is going to do much to make obtuse people like you show some common sense.
Let's hope that Linus decides to get his head out of the sand on this.
Sometimes, I think that the only way to understand every aspect of the GPL v3 is to argue about it for weeks or months :-)
:-)
Thanks for the corrections
LedgerSMB: Open source Accounting/ERP
Tivoization only comes into play when you DISTRIBUTE your computer en masse as a "consumer product." How you intend to do THAT is beyond me. It doesn't even make sense to suppose that you'd somehow get ensnared by that.
Anyhow, as I quoted above, they most certainly DO still claim that it doesn't cover use. It covers, as it always has covered, distribution. It does NOT cover mere use.
The Tivo company, after all, is NOT the user of Tivo devices. The people who buy Tivo devices are, and Tivo is the distributor of those devices.
Please, can we dispense with the "oh noes! the big bad FSF is going to sue me for using GPL'd software if I disagree with them!" nonsense? Because you'd have to do something other than merely use the software to run afoul of the GPL.
But anyways, no amount of rational explanation about all of this is going to do much to make obtuse people like you show some common sense. Allowing someone else to relicense your code is giving your rights away. I don't trust the FSF (especially after what they've done in the last year) to license my code the way I want to. Giving your full copyright to the FSF (or any other body) is no different than an artist giving the copyright on their music to their label "to make sure future licensing and work is handled on your behalf." How many people around here bitch about the record companies demanding that? How many artists go on to bitch about it (most notably Prince).
I'm not sure that I would trust anyone with the full rights to my fully original work. Linus is probably the only other entity I would trust to do the right thing with my work. All that said, there's no reason why I couldn't leave instructions in my will (or living trust or whatever) with what I want done with the copyrights I own in case I die.
Also, you keep harping on this "too late" thing. You know what it's too late for? It's too late for the FSF to stick the GPLv3 back in the bottle now that they abused their position to fracture the free software community for their own pride. THAT is what was really obtuse. Let's hope that Linus decides to get his head out of the sand on this. Let us hope the FSF gets their head out of the sand and realizes that forcing a new, incompatible license onto a two decade old code base is short-sighted. Further, pretending that it's the fault of the people who won't suck on their teet is utterly dishonest.
PS - please keep calling anyone who disagrees with you short-sighted, stupid, incapable of understanding the Holy Writ of Stallman, etc. You'll definitely win us over that way.
>not being able to change it instantly is a good thing
Sure. No problem with that statement. The problem is to not be able to change it AT ALL. Or is that nuance too subtle for you to grasp?
As I said countless times, if the "or later" isn't cutting it for the linux kernel project, then get the copyright assigned to a foundation which has voting members with veto.
> PS - please keep calling anyone who disagrees with you short-sighted, stupid, incapable of understanding the Holy Writ of Stallman, etc. You'll definitely win us over that way.
But what I've been trying to explain to you has nothing to do with Stallman or GPLV2/3. The problem you want to dust under the rug (by saying that we'll rewrite the code if it comes to that) is a problem for any project that is legally mismanaged like linux. But it could happen to a project using a licence different than GPLv2.
I doubt I'll ever win you - the individual - over. Obviously, you think it is smart for the linux kernel community to have painted itself in a corner. It's your right to think that way.
No, It ensure that no one can release something and then patent it later
No, that's wrong. It means what I said it means: people can't use it and patent it.
It does nothing to ensure that no patents can ever exist.
Of course not. I didn't claim it did. The FSF doesn't claim it does. Where do you get these insane ideas from?
That MS novell deal and the patent threat was manufactured by the FSF in order to push the GPLv3 along.
Good grief! Take off your tin foil hat.
But that same fix will come back to bite them. MS can create a little covenant not to sue their customers and place it in their product offerings and in effect turn everyone who buys MS stuff into a little novell that cannot distribute GPLv3 covered works because of language in the GPLv3 itself.
No, Microsoft can't do that because if they did, they could be hauled into court for a declaratory judgment on their patent claims.
> Not being able to change the license at all = 100% impossible to change the license.
:-) There ARE difficulties in changing the license. You've admitted that much. Those difficulties ARE a problem. Not addressing the problem now means that it can only get bigger, not smaller. You can sit on the problem and let it get bigger, or you can address the problem now, by managing the code contributions, from a legal standpoint, in an orderly fashion so that when/if the shit hits the fan, you can do something about it in a timely manner, rather than spend 2-3years to replace code before you can modify the license.
Man you are obtuse
But from what I read from you, you are perfectly happy in letting the difficulties grow until the shit hits the fan.
>If it weren't for RMS/FSF dividing the existing GPL community over an incompatible license, you wouldn't even be complaining about the Linux licensing situation to begin with.
AGAIN AGAIN AGAIN AGAIN AGAIN... what I'm explaining to you has NOTHING NOTHING NOTHING NOTHING to do with the GPL. Linus Torvald and the linux community have mismanaged the legal side of the kernel. A change to a different license, say BSD, is not reasonably feasible.
Now, if you want to have a discussion about the GPLv3, and whether it is consistant with what RMS/FSF have been preaching forever-1, then we can do this also.