RMS Explains GPLv3 Draft 3 139
H4x0r Jim Duggan writes "A transcript is now online of a talk Richard Stallman gave in Brussels earlier this week about the discussion draft 3 of GPLv3. Among other things, he explained how it will address the Novell-MS deal, from Novell's point of view and from Microsoft's, and he explained how the tivoisation clause was narrowed to make it more acceptable in the hope that it will be used by more people. After the talk he also gave an interview, and yesterday, draft 2 of LGPLv3 was released."
Compatibility with patent-nullification licenses (Score:5, Interesting)
There is a lot of software out there being developed under licenses which aren't compatible with the GPL, because the GPL doesn't allow patent nullification clauses -- this is dangerous, because the purpose of these clauses is to keep someone from slipping code into a major project that they have a patent for, and then torpedoing the whole thing later on when it's crept into wider use. I don't know if this issue just wasn't foreseen when GPL2 was written up, but I can't think of a more pressing issue at the moment.
Yeah, "Tivo-ization" and web services may keep some software out of the hands of the public, but they're not nearly as downright dangerous as submarine patents are.
[1] Examples: IBM Public License 1.0, Common Public License 1.0, Apache License v2, or any of the other licenses where the FSF cheerfully comments "We don't think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL."
Why GPL3? (Score:2, Interesting)
Tricky section (Score:4, Interesting)
This actually has a few more conditions because we were trying to avoid covering certain other things, for instance, consider a patent parasite, one of those companies that has only one business which is to go around threatening people with patent law suits and making them pay. When this happens, the businesses that are attacked often have no choice but to pay them off. We don't want to put them in a position of being GPL violators as a result. So we put in a condition: "this paragraph applies only if the patent holder makes a business of distributing software". Patent parasites don't. As a result, the victim of the patent parasites is not put in violation by this paragraph.
Really if one company is attacked for patent infringement on a piece of GPL'd software than every user is vulnerable and it's only a matter of time before the parasite makes the rounds through all the companies. I think the old form was better since it didn't allow a distributor to back down and pay them off, perhaps giving the community to gather and fight back. Of course the old version also allows an unscrupulous competitor to give their patents to a shell company with the understanding that the shell company will put the competition out of business...
Damn, patents suck.
Welcome to the World of Nuclear Regulation (Score:2, Interesting)
Even with a seemingly simple set of conditions (i.e., the license terms), someone will figure out a nuance or caveat that will challenge the conventional interpretation, and gum up the works for everyone else. Regulations (or licenses) are principally legal matters, and as such, precedents and case studies are key to understanding the bounds of their tenets.
Here's what we use in the nuclear industry to clear the air - as much as can be achieved, anyway. An industry group, like the Electric Power Research Institute or Nuclear Energy Institute, develops a guidance document that defines key terms, and most importantly, illustrates and amplifies the tenets of the regulation. These illustrations include case studies and examples that challenge the rule well beyond the obvious application. Ultimately, such a document may get accepted or endorsed by the Nuclear Regulatory Commission as a Regulatory Guide or other guidance document.
The parallels here are that:
- As technology and understanding of the license (or regulation) evolves, there will eventually be new gray areas discovered. This is true in both fields;
Where the situational similarity fails is that there is no overarching authority to endorse (or deny) the final version of the GPL. So the best that could be accomplished really would be to have a rigorous FAQ or guidance document as possible - one that anticipates the future as best as its preparers can.Re:backward persective. (Score:4, Interesting)
I hate to be the devil's advocate on this argument, because I really like free software (though I can't bring myself to whole-kool-aid on the morality argument)...
The software being open-source doesn't give me the ability to know what the device is doing any more than the law being published and accessible gives me the ability to be my own lawyer. It merely allows lawyers (or independent software developers) to exist. Hundreds of thousands of lines of code go into modern working software, and a bit of trust on the part of the average end-consumer is strictly necessary regardless of the visibility nature. The average end-consumer simply doesn't have the time to learn enough computer science to eye-verify every line of code in every piece of software they run.
I trust open-source because many eyes have seen it, and my experience has been that those eyes are not in heads that are actively engaged in the business of doing evil. I trust much closed-source from big companies because the situations where actively lying to the customer is long-term profitable are more rare than many think they are. It's true that only one of these avenues has even the potential for exploitation, but if we always kept to the safe paths we'd miss out on half the fun, eh?
It's not a morality question. It's a risk-reward question.
Re:Why GPL3? (Score:3, Interesting)
If I recall correctly, I first came across open source in 1993, when I read some fairly persuasive essays about it by RMS. I was initially sceptical of the GPLs share-alike restricitons. I recall RMS arguing that the nascent open-source movement didn't have the resources, code base, or more-or-less "head start" that proprietary software had, and they must give themselves a leg up by creating software that was only available ot themselves. This was part of the justification for the LGPL: if equivalent proprietary libraries existed, or would exist, anyway, it was better to have the open library become the standard since it wouldn't give free software any advantage anyway. The implication (which I though was even explicitly stated, though I can't find the reference) was that eventually such provisions would be unnecessary. That one day a certain critical mass would be attained, and the basic superiority of the open development model would be sufficient to sustain the movement.
Well, I think that day is here. I'd say let people take the code and do what they want with it. Those who close it will shortly wind up with suckier software, and that will be the end of it. The technical superiority of open development is sufficient, all by itself, to make open software win vs closed software. Restrictions that attempt to keep the software open are not needed, and not without cost. They require some effort to understand, and may exclude people who would otherwise have made useful contributions.
It was those essays by RMS that first convinced me of the superiority of open development, though he seemed a buit the zealot. It amuses me that I now seem to have more faith in that superiority than he.
Before I get a million angry rebuttals, let me note that I fully respect others right to disagree with me on any of this, and please use whatever license you like on your own code. But at this point in history, if you want as many people as possible to use and contribute to your project, I recommend BSD.