FSF should separate GPLv3 changes (Linux.com)
Posted Oct 17, 2006 21:46 UTC (Tue) by man_ls
Parent article: FSF should separate GPLv3 changes (Linux.com)
I would say it is not worth it. The most vocal opponents against the anti-tivoization clause are the kernel developers. As Ciaran has suggested above it can be added as an exception. They are not candidates for using the new license anyway, since the kernel is "GPLv2 only".
Besides, their arguments seem to be more of a, let's say, tactical nature than otherwise. It is only natural that they would want the Linux kernel to be used as widely as possible. Short term this is good for the community and good for them personally: there will be a healthy demand for their skills for many years to come. Long term we may imagine a less promising picture: a situation where most devices are locked down, and people cannot lawfully replace the software anywhere. Even if there are some general purpose computers still open, people would see no difference between, say, Windows 2015 and any Linux-based system. Even worse, they would see no value at all in learning how to program those growingly complex systems, not more than in designing your own microwave ovens. Not for fun anyway.
The message of "share and share alike" is completely lost on these future people. The free software community was so slow and painfully put together, and it has done something with no equivalence in History -- a collaborative effort spanning many thousands of people from all continents who do barely know each other and communicate almost solely using the written word. Something as close to Plato's "government of the wise" in its governance as the world has seen; and it has produced a complete and free multipurpose operating system available to all; it also underlies the most powerful means of communication that we have so far invented, the internet. It all falls apart quietly and slowly as people fail to see the point in cooperating with your neighbor, since only professionals would be allowed to play with such things as "source code" on real-world equipment. "See but not touch" code would be the norm.
Here is where the interests of kernel developers and of the general community diverge. Their skills would still be in high demand in this scenario, but we all lose in the process.
to post comments)