I was with you until you said something about restrictions. No court of law anywhere has said that you running standard X86 code in a standard X86 environment is illegal.
Taken literally, your stance would mean that software licenses have no legal standing and binaries can be copied to anyone to be run anywhere -- it's just "running standard x86 code in a standard x86 environment" after all.
I'm not saying that EULAs are good. But they're not obviously invalid just because common sense suggests you should be able to run some software on some hardware.
If Apple's EULA is unenforceable, how about Oracle's licensing agreements? Or the GPL? These are complicated questions.
Effectively this is testimony to how well the GPL has been put together from a legal point of view, it is bad contracts, agreements and licenses that are tested in court.
Uncertainty over what adaption means serves their purposes. Uncertainty about the legality of taking somebody else's code and just relicensing it as GPL also serves their purpose. As does uncertainly over what results in a combined or derivative work with GPL binaries. The more solidly those lines are drawn then the less risk people face when calling GPL code from GPL incompatible code. That means people are more likely to do all the kinds of things that RMS fears (e.g. proprietary IDEs that call out to gcc and all that kind of thing, which RMS was talking about recently in relation to emacs interfacing with gcc).
The problem they face is that ultimately they can't create a license that prevents interoperation with proprietary code without also violating freedom zero. The only real way they have to discourage people from doing that is legal uncertainty. That is why it's very difficult to get a straight answer from the FSF or SFLC about what constitutes a combined work (other than them just claiming everything in the world is a combined work, which is the usual nonsense reply you will get). If they answer the question then it's them flagging up the best way to get around the GPL.
For example the FSF claim that distributing FooApp that links to a user chosen library at runtime and calls frobulate() requires FooApp to be GPL licensed, even if the developer of FooApp doesn't distribute the library with the app (or at all), so long as there exists a library implementing frobulate() that is GPL licensed. If you really press them on this point then they will argue that it depends if other non-GPL libraries also implement frobulate(). Of course that creates a large loophole - just create a very basic crappy implementation of the API and make it available, with the expectation that users will actually use the superior GPL library. So it's worth noting that the FSF doesn't actually accept that argument when it comes the readline and editline. Distributing a binary containing the symbols for the readline API [2] is a GPL violation as far as they are concerned. Yet they have not taken anybody to court over this yet even though the FSF owns the copyright for readline.
You can easily find people with quite different views on what the linking clauses in the GPL mean[3], so it's clear that there is a great deal of confusion out there. Nobody really knows what it means till it gets tested in court and the FSF have no interest in getting this cleared up because there is a non-zero chance that the courts don't agree with the FSF's interpretation of title 17. Once the red line is drawn over what is and isn't a combined work then people will be free to work around the GPL with minimal legal risk.
That much legal uncertainty is not the sign of a well written license, if you think the aim of a license is to clearly enumerate what rights people have. If you think a software license is a political weapon then you probably don't care that some people are being scared away from doing things they have a legal right to do with your code (but that you don't like).
[1] http://marc.info/?l=openbsd-misc&m=118963284332223
[2] e.g http://tuomov.bitcheese.net/b/archives/2005/12/23/T22_53_01
