With the "or later" version it's a concern that in the future someone nefarious could gain control of the FSF, and publish a GPL removing most of the copyleft provisions.
On the other hand, if Linux had used the "or later" version it could have helped prevent TiVoization.
Linus was a little liberal about the restrictions of software freedom (boy is that an awkward phrase) even early on - e.g. his general acceptance of "binary blobs" in the kernel and such for things like NVidia kernel drivers, to the chagrin of much harder-core free software people.
Anti-Tivoization is a pretty radical idea that restricts the rights of hardware developers for the benefit of software developers. Linus doesn't really care about strong-arming hardware developers the way RMS does. He just cares about the software.
> Anti-Tivoization is a pretty radical idea that restricts the rights of hardware developers for the benefit of software developers.
How does anti-tivoization restrict the rights of hardware developers, considering that hardware developers can choose not to pre-install anti-tivoization-licensed/contracted software? Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes, using encryption to communicate only with certain other pieces of hardware, or for that matter, any restrictions at all. All in the name of enabling hardware developers to tinker with their hardware without those pesky software developers getting in the way with their pesky encryption.
> Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
In the way that all copyleft enforcement requires copyright, then yes… but what does that have to do with anything?
I think Linus was spot on about the FSFs scope creep when he said:
“The kernel license covers the kernel. It does not cover boot loaders and hardware, and as far as I'm concerned, people who make their own hardware can design them any which way they want.”
If TiVo hypothetically were to ship a device running an operating system built on an anti-tivoization copyleft-licensed kernel, and if I were buy the device at TiVo's asking price, the very terms of the software license would dictate that the device hardware let me install a FOSS operating system. I as the buyer would not be restricting TiVo's hardware developer rights, and I don't see how the anti-tivoization copyleft license on the operating system TiVo would have chosen to install would meaningfully restrict TiVo's hardware developer rights.
(TiVo's hardware did not actually prevent people from installing a modified operating system [1]. My previous paragraph applies just as well to both Richard Stallman's definition of anti-tivoization and my long-lived misunderstanding of "anti-tivoization" corrected by Bradley Kuhn.)
>> Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
> In the way that all copyleft enforcement requires copyright, then yes… but what does that have to do with anything?
What rights of hardware developers does anti-tivoization restrict? For example, do you believe in a moral right (or a strong moral privilege) for hardware developers to install any software of their choosing on their own hardware? Most hardware-agnostic software copyright licenses and the lack of a copyright license restrict such a right/privilege. Porting most proprietary software to your own custom hardware would violate copyright (unless your port is a clean-room rewrite) because copying most proprietary software to anywhere including an instance of market-standard hardware would violate copyright. A FOSS license with an anti-tivoization clause does not prevent a hardware developer from installing or modifying covered software: the license conditions do not trigger until the software is distributed (as with the GPLv3) or a modified version of the software is run over a network (as with the AGPLv3).
> Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes, using encryption to communicate only with certain other pieces of hardware, or for that matter, any restrictions at all.
The concept that software "runs on" hardware and not the other way around makes a massive difference in how I believe hardware should be able to restrict software vs. how software should be able to restrict hardware. Letting a human validate the appropriateness (however that may be defined, including and not limited to criteria unrelated to structural integrity) of a bridge will have more moral use cases (both as a percentage of use cases and as absolute "numbers" of use cases) than letting a bridge validate the appropriateness of a human trying to cross it.
> Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes
(I would generally disapprove of both a hardware license that prohibits software from validating the hardware and a software license that prohibits hardware from validating the software.) Morally speaking, I might oppose a particular program that shuts down if the hardware has been repaired by a third-party while simultaneously supporting a particular program that shuts down if the hardware randomness module has been altered. I might oppose a particular computer that refuses to run DeCSS while simultaneously supporting a particular computer that refuses to run cryptocurrency miners.
Does anti-tivoization prohibit hardware from validating software, or does anti-tivoization merely prohibit hardware from acting on a detection of invalid software?
> All in the name of enabling hardware developers to tinker with their hardware without those pesky software developers getting in the way with their pesky encryption.
How does anti-tivoization get in the way of tinkering by hardware developers, considering that (1) the hardware developer chooses which kernel and which operating system the hardware ships with and (2) a FOSS license with an anti-tivoization clause does not restrict personal use any more than an otherwise equivalent FOSS license without such a clause does? Are the hardware developer's rights restricted whenever the hardware developer can't control what a buyer does with the hardware and the software that came with it? Does anti-tivoization copyleft software restrict proprietary hardware any more than proprietary hardware restricts free software?
> if Linux had used the "or later" version it could have helped prevent TiVoization
Only if the hardware manufacturer used a combined work of Linux and some GPLv3-only code, no? Otherwise, if Linux was GPLv2-or-later, they could just use it under GPLv2 terms and tivoize.
On the other hand, if Linux had used the "or later" version it could have helped prevent TiVoization.