More practically, history has shown us that the GPL is necessary in order to ensure that companies don't short the community, suddenly improve everything and leave us with 99% of people using the proprietary fork. To illustrate my point, the clearest example (and the only large one) is the free distributions of BSD, mainly used by companies developing proprietary forks for it and contributing back very little. On the other side is Linux, used by companies for its freedom, security and reliability. The companies using it contribute back because they have to, continually making it stronger and always remaining free (unlike BSD, which can have many proprietary and untrusted libraries which cannot be used with security or reliability in mind). Linux is therefore getting larger only thanks to the GPL and its strong enforcement.
And this example can be applied to the entire copyleft vs permissive license debate, showing how software being free benefits the people more than people being free.
The FSF is about free people. Free software is just a mean, and they will use whatever licenses they think promotes freedom the most. That's why the GNU C standard library is in LGPL: the GPL itself would have prevented GCC from becoming popular, resulting in less freedom for the people. Also, looking at the history of GCC and the Hurd kernel, you can see they don't limit themselves to licenses.
You seem to imply that the GPL forbids you to keep your code secret. It doesn't. The right for private modification is preserved by the GPL. Only public modifications must be distributed in source form.
Companies don't contribute back to Linux because they have to. First, it's often more cost-effective to push changes upstream than maintaining them yourself. Second, monetizing private changes with GPL software is very very hard when the main distribution channel is gratis. Third people like to be good citizen. If I do changes for my company, and my company cannot possibly monetize the secrecy of those changes, why not contribute back?
If people and companies were forced to contribute back changes, they probably wouldn't use the software in the first place.
Now yeah, Linux is indeed larger than BSD thanks to the GPL.
The only restriction is that you cannot remove any of those freedoms from any users of your derivative works. That restriction is enforced by the license.
For example, if you create a derivative work, as long as you keep using it only yourself, you're not required to give the sources to your modifications to anyone (you are the only one using it and you have all the freedoms). However, if you wish to share your derivative work with someone else (which you always have the freedom to do), you cannot limit that user's freedoms. You cannot, for example, refuse to give them the source code because it would take away the user's freedom to modify the software. You also cannot attach a proprietary license that would remove the user's freedom to distribute copies of the software to whoever they want.
That phrasing presumes that the existence of a fork is not determined by the license terms.
GPL guarantees that the would-be users of a fork that would have been made by someone not interested in (or able to, because of conflicting requirements necessary to actually produce the fork in question) providing Free software on the particular terms in the version of the GPL used by the particular upstream provider on which the putative fork would depend get nothing at all.
What ways would those be? In what way does refusing to contribute the source code to your modifications qualify as using the software in certain ways?
In the case of GPLv3, the development of software for hardware devices that are tamperproofed -- unless those devices are intended for "business" rather than "consumer" markets. [1]
The GPLv3 restricts the features of products made with software licensed under it based on how the products are intended to be used.
[1] "business" and "consumer" are rough descriptions, the actual definitions are more complicated and are contained in the GPLv3.
This is not true. All the GPLv3 requires is for you to provide the means to modify or replace the software contained in the device. In the case of a tamper-proof device, this would entail providing the user with a master key or password which would allow her to unlock a developer mode of some kind.
The issue GPL fixes is when device manufacturers exercise ownership control of the device after sale (ie, do things that the owner is not allowed/enabled to do). If the manufacturers can modify or replace the software, then the device owner must be able to do the same.
Sure, you can develop one of those, as long as you subsequently provide a means to circumvent the tamper-proof mechanism. There is a critical semantic distinction that I think a lot of people are missing: the GPL does not restrict your ability to develop any sort of product you wish, it merely imposes additional obligations designed to ensure your users have the same freedom of development that you had when you developed the device.
No, you do not need to add a way to circumvent the tamper-proof mechanism. Thats the whole point of my comment.
Section 6, Conveying Non-Source Forms: "this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM)."
If the device is completely immune to software modifications, the anti-drm requirement of GPLv3 won't come into effect.
Last, a device which the manufacturer has ability to tamper with is not a device I would call tamper-proof. The attacker just need to get the developer key, so maybe Tamper-resistant is a better description?
Right, I had forgotten that. The reasoning behind it is that a non-programmable ROM chip might just as well be considered hardware for the purposes of programmability. Of course, the user might decap the chip and modify the code stored there with a scanning-tunneling microscope so the term tamper-proof in the absolute sense is probably not applicable to any device made by humans.
So maybe tamper-proof is not the best term, but at least physical security add something more than just a digital signature. The device owner has a much better chance to see if someone took apart the device, decapped the chip and then put it together. If I as the consumer want a tamper-proof device, I would go with physical security every time.
But is redistribution a use? I would say no.
Okay, you can't. Well, this is a textbook example of the GPL discouraging people from distributing proprietary software, and seeking free alternatives instead. This is its exact purpose.
I feel somewhat sorry for you, but this looks like a net win.
Intuition. If I may, you should learn to "shut up and multiply"[1]. The various costs and benefits (in terms of freedom) are pretty much nailed down: freedom at large is simply way bigger than immediate freedoms, for a simple reason: the only freedom the GPL doesn't give you, is the freedom to further restrict your users. (Contrary to how most comments are worded here,, you don't have to contribute back changes. You have to contribute back public changes.)
The end doesn't always justify the means, but sometimes it does.
Even that isn't strictly true - you only have to contribute forward public changes. Of course, since your users have the ability to share things, and since your changes are probably "out there" you might as well contribute them back at that point and doing so usually eases development.