Peter Åstrand wrote: > http://en.wikipedia.org/wiki/Tivoization seems to explain it quite good. I guess that after reading this, I come down on the side of Linus. Software licenses are not contracts, and they aren't intended to guarantee that you can hack any hardware that the software is used upon. There is nothing that would prevent a hacker from taking the Tivo code and building their own Tivo box.
Ultimately, the GPL is supposed to protect us, the developers, from companies modifying our code and selling those modifications without making them available to others. So let's look at the worst case scenario-- what happens if TigerVNC ends up in a Tivo-like box which doesn't allow modified versions of the code to run. So what? How does that really damage our project? The box vendor is required to contribute back any changes to the source code, so we can merge them back into the repository if they're applicable (in most cases, they probably wouldn't be applicable.) In fact, it's in the box vendor's best interests to work with us, unless they want to fork the project and become experts on the code. Otherwise, they have to come to us to obtain new features, bug fixes, and support. Ultimately, if there's enough demand for a hackable version of the box, then the users will drive the box vendor to create one. If the pre-installed software on the box is inadequate, then it is up to the users to demand new software or the ability to install their own, or they are always free to buy someone else's hardware. You also have to look at this from the point of view of the embedded systems developer. They are simply trying to prevent casual hackers from finding some poorly-written blog on how to hack the box which causes them to brick it and send it back for replacement. I guess my point is that the software is still free, and I don't think that requiring that the hardware be free as well is within the scope of a software license. > Regardless of whether one think this new wording is good or bad, > please note that this already applies to TigerVNC and TurboVNC, since > they are "v2+". Users can choice v3 if they want. Sure, but they don't have to use v3. That's the key. > To summarize: I understand that you both sees a need for v2 > compatibility as well as have some doubts over the v3 wording. Since > the current source is v2+, we cannot "get rid of" v3 entirely; I guess > you have to accept it. > > When it comes to keeping v2 compatibility, I understand that this is > important to you, but you haven't yet convinced me. The main argument > as I understand it is to allow code copying to v2 projects, but I > don't see a real need for this. Well, I'm not convinced of your point of view either, so our choices are basically either to keep v2+ or to put it to a vote. If you're OK with keeping it v2+, then that makes me happy. If I'm outvoted on moving to GPL v3, then I'm outvoted and I'll deal with that, but I definitely think we should delay this decision until we have a better sense of what the community is doing. Who knows? Maybe FSF will come out with a GPL v3.1 that addresses some of the concerns. ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
