If you buy a TiVo and then can't modify it, you don't. So there is nothing to share with everybody else. The entire system is destroyed. It's an existential threat.
> And if this is something that a sufficiently large segment of the users actually care about, then they will vote with their feet, and purchase hardware where they can update their own code.
But that's the problem. Most of the users aren't (currently) developers, but if the dominant hardware isn't open to developers then there are fewer developers, and the users then can't receive their improvements.
It's not obvious that there are always enough developers to justify a production run of open hardware separate from the hardware everybody else uses, even though everyone benefits from its existence. So we need the dominant hardware to be open.
> Maybe this will even result in a software ecosystem where the company selling an open product will be able to take those improvements from the dedicated power users to improve future releases of their product.
Except that if this becomes popular and the software is open source but can be locked down, proprietary hardware vendors will ship the improvements on locked down hardware. Then anyone who doesn't make modifications themselves, or doesn't anticipate making them even though they might have, buys the locked down hardware and the open hardware has no competitive advantage in the market among non-developers. Even though its existence is a prerequisite to continued community software improvements that everybody wants.
Every device or platform since the IBM PC, including phones, tablets, non-x86 PCs, thermostats, wristwatches, routers, appliances, cars, etc. -- all of them have switched to the device-only-accepts-firmware-signed-by-the-manufacturer model where you can't put your own software on the vast majority of devices without a significant amount of reverse engineering and hardware/firmware exploit hunting.
Software can't eat the world if nobody wants to make hardware that can run arbitrary software. Then it's only "this one particular company's software can eat your thermostat for the two years that they feel like providing device support, then it's trash."
I think that hardware (or at least boot architecture) does matter. For all of UEFI's flaws, the secure boot model is actually pretty good. A device can come with a preloaded manufacturer key, and can be configured by default to only run manufacturer signed firmware. But once a user buys the device, they have the option of adding an additional key, either from another third party (i.e. like the key that RedHat and Ubuntu use to sign their kernels), or keys that you or your organization generate and manage yourselves. You can also remove the preloaded key, because as the owner of the device, you should be able to do whatever you want with it. If the manufacturer needs their application to only work if the secure boot settings haven't been altered (i.e. in a car, with safety/liability concerns), they can do that.
I would be a lot happier if we had a model like this for literally any other non-PC platform. Right now everybody rolls their own crappy implementation of signature checking with hard-coded manufacturer keys. It's really pretty awful.
(Well, the hard part is learning how to download all of the source code and learning how to use the Android build system, and then downloading a new system image onto the Android device; there is no technical restriction which prevents you from doing this.)
I developed the ext4 encryption specifically for Chrome and Android, and I was building my own Android images and putting it on putting it on a Nexus 9 device. This didn't require any kind of special privilege or encryption keys only available to Google employees. Neither did this:
https://thunk.org/android-xfstests
It's all open source, and you can certainly rebuild your kernel, make other changes to the firmware, and install it on your phone. No reverse engineering or hardware/firmware exploits necessary!
However, Google's approach is so uncommon, that it's basically the exception that proves the rule. The vast majority of device manufacturers don't do anything like this, and if you were to pick a phone at random, you would probably expect to encounter some sort of issue flashing it. That's why we're still stuck with databases of "if you want to run a custom Android ROM on your phone / OpenWRT on your router / etc., pick from one of these known-good devices."
I say this almost preemptively, because I really don't think it should obscure your core point: open devices are increasingly the exception, not the norm.
1: https://chdk.fandom.com/wiki/CHDK 2: https://hackaday.com/2020/09/06/a-free-software-os-for-the-r...
Google takes licensing seriously (as both know you and I know :-).
No idea why we do the same for Android phones though. No GPLv3 in there :-).
Software might be eating the world, but IP industry and legislation are eating the hardware. There soon may be no user-controlled hardware, especially with the advent of the internet where "vulnerabilities" that let users run their own code can be patched, and Apple-like certificate checking can be deployed out.
GPLv3 might be seen as an effort to counter-act this situation.
>perhaps hardware created by a competitor, or using open hardware
I think as the Purism folks are demonstrating with the Librem phone, we live in a world where the barrier to entry to compete in hardware markets is enormous. The "hardware doesn't matter" argument only holds where the hardware to run software is sufficiently commoditized or where it's easy to develop open-source alternatives.
For phones and select other segments of the hardware sector this simply isn't the case: consider the yawning chasm that separates the Librem phone from the iPhone.
Granted, all of these are legal problems that need to be remedied with judicious case law and acts of Congress. However, so is the concept of software copyrightability itself. (CONTU fucked up, software should have been sui generis.) The whole point of the GPL was to legally construct something like a public domain dedication that subsequent derivative works couldn't reverse. The idea was that software would always serve the user (or be modifiable to do so). If you look at the GPL in that light, TiVoization is a clear circumvention of licensing intent.
Given that the FSF came first, I'm not entirely sure I'm OK with calling anti-TiVo a "short-term" concern. It's more like protecting the users of the software and ensuring developers are able to collaborate under equitable terms are both long-term concerns that are occasionally in conflict with one another.
(FWIW, most of those lockouts wouldn't actually qualify for 1201 protection in isolation. However, they often are tied to systems that would. Nobody builds a separate repair lockout and DRM system - they build one system that prohibits both use cases. Even when the law agrees that you're allowed to break the part of the lock that keeps you from swapping parts on a tractor, it doesn't let you distribute the tools to do so if that lockout also enforces a copyright owner's licensing intent. So, for example, it's legal to jailbreak a phone to make Touch ID work, but that jailbreaking tool you used is still illegal because someone might use it to pirate iOS games.)
You also probably create an even greater incentive for manufacturers to strictly lock down their devices, doubling down on technical solutions in the absence of legal ones.
And if this is something that a sufficiently large segment of the users actually care about, then they will vote with their feet, and purchase hardware where they can update their own code. Maybe this will even result in a software ecosystem where the company selling an open product will be able to take those improvements from the dedicated power users to improve future releases of their product. But this is something which is best enforced by market forces --- if it's really an important right that users find important, they will demand it.
This is essentially the debate when the FSF tried to convince the Linux kernel community to relicense to the Linux kernel to the GPLv3. We declined, essentially because we saw the downsides of the anti-Tivo-ization clauses had towards people choosing to use Linux versus some other OS. And we believed that growing the contributor base was in the long term, far more important than the more short-term anti-Tivoization concerns of the FSF. This is why the Linux kernel is GPLv2 and not GPLv3. We didn't give in to the siren call of the FSF position.