X
Tech

Torvalds should create a better GPL

The anti-GPLv3 position of Torvalds, and now a large cross-section of Linux kernel developers, appears to be hardening. In response to a rebuttal by Eben Moglen, chief counsel for the Free Software Foundation, re-invited the Linux kernel team to engage in the GPLv3 discussion process, Torvalds had this to say: I wonder why everybody but the FSF seems to know my email address, but the FSF can't find it.
Written by John Carroll, Contributor

The anti-GPLv3 position of Torvalds, and now a large cross-section of Linux kernel developers, appears to be hardening. In response to a rebuttal by Eben Moglen, chief counsel for the Free Software Foundation, re-invited the Linux kernel team to engage in the GPLv3 discussion process, Torvalds had this to say:

I wonder why everybody but the FSF seems to know my email address, but the FSF can't find it.
If it has an anti-Tivo clause, I think it's bad. I've tried to explain it to some people (the freedom of the _project_ is much too important to let any license clause limit how you can use it), but when other people did that, the FSF just explained how they had mis-used the word "use".
But I'm so fed up with the FSF right now that I'm not in the least interested. There's no way in _hell_ they can claim that they don't know my standpoint, so what are they even asking for?

Other quotes from Torvalds in the aforementioned article on NewsForge provided what I thought to be a clear and distilled explanation of the problem with the anti-DRM provisions in GPLv3:

It's their hardware. I do _not_ want to ask for control of the "environment" back in a license. I want the improvement to the _software_, not the keys to the kingdom. The "environment" a program runs in (or the medium it is distributed on) doesn't have to be open. Just the program itself.

Exactly. The fact that TiVo opts to make it impossible to alter the hardware / software combination on a TiVo system does not in the least affect someone's ability to take Linux and make a hardware / software combination that is NOT restrictive, nor alleviate TiVo's need to distribute the source code for any changes made to the GPLv2-licensed base.

The problem with finding a resolution to this conflict, however, is that the Free Software Foundation (FSF) is philosophically opposed to making it easy to use open source software for proprietary purposes. Asking Stallman (the founder of the Free Software Foundation as well as its titular head) to compromise is like asking the Pope to be less Catholic.

As I've discussed before, I believe that a middle ground between proprietary and open source software is not just feasible, but very desirable. Further, I think it would attract large numbers of open source programmers who believe in the community development process, but aren't interested in the more extreme views of the Free Software Foundation (FSF). Unless I'm a complete oddity in the proprietary software community, I think it would attract large numbers of proprietary developers as well.

Frankly, a world where open source and proprietary software can work together with minimal risk to either side doesn't just harness the productive power of both groups to move the technology ball forward, but creates a larger market for both products by granting them access to parts of the software ecosystem to which they are currently denied. Use of Linux in a TiVo system is clearly GOOD for Linux popularity, however much the ideologically constrained might oppose the nature of that popularity. I'd also argue that proprietary drivers are good for Linux, something with which the FSF would disagree strongly.

Stallman and his Free Software Foundation represents a group that wants to divide the fabric of innovation. Most programmers don't agree with that. Why, then, give the FSF control over the next version of a license that is so important to the open source movement?

Make a license that is BETTER than the GPL, one that continues the benefits of a shared development model that requires changes to be returned to the community while making it easier for that code to be used anywhere - including in proprietary systems. Licensing competition is not a bad thing, particularly if one of the licenses enables more seamless mixing of the code domains currently kept separate due to licensing restrictions.

Editorial standards