8 ms·

If you believe that "software will eat the world", then hardware doesn't matter. Sure, the customers who purchase a locked-down device might not be able to up

by tytso 6y ago

If you believe that "software will eat the world", then hardware doesn't matter. Sure, the customers who purchase a locked-down device might not be able to update their device. But the technology will still be out there, so that it can be built upon to improve the next generation of hardware --- perhaps hardware created by a competitor, or using open hardware. This is especially true for consumer-grade devices, which generally become obsolete and replaced within 2-3 years anyway. 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.

selfhoster11 6y ago
Right to Read comes to mind. 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.
na85 6y ago
>hardware doesn't matter >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.
AnthonyMouse 6y ago
The way free software is supposed to work is that you buy a device, you want to improve it, so you do. And then you share your improvements with everybody else. 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.
ohazi 6y ago
This argument doesn't work when PCs are essentially the only widely available hardware platform that ended up with an open standard for modifying the software running on the device. Even here, the fact that we ended up with this model was an accident. 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.
- tytso 6y ago
  That simply is not true. Chromebooks, many Android phones (all of the ones sold by Google) have a way of turning off the requirement for signed boot. The device is less secure if you disable signed boot; an evil maid who gains access to your device, or the FBI after they seize your device, will have a much easier time getting access to your data --- but if you want to build your own version of Chromium, or put your own Linux distro on a chromebook, or if you want to build your own version of Android from source, and put it on a Nexus or Pixel phone, you can do this easily. (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 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!
TaylorAlexander 6y ago
Intellectual property is a state enforced monopoly that interferes with market forces. In a purely market driven world “locked down” phones would be harder to create/enforce.
- zerocrates 6y ago
  If you're eliminating intellectual property you're eliminating the GPL anyway. 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.
  - TaylorAlexander 6y ago
    My point is that this is not a "free market". It has substantial restrictions.
kmeisthax 6y ago
You have the market forces backwards. People don't avoid the lockouts, the lockouts shape people into a particular behavior. For example, look at Apple's ridiculous levels of anti-repair nonsense - it is designed specifically to make it harder for non-Apple technicians to properly repair a device. These lockouts have legal force thanks to... rather prevalent misreadings of DMCA 1201 that make large companies unwilling to design circumvention tools for these sorts of things. 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.)

by tytso 6y ago

selfhoster11 6y ago

Right to Read comes to mind. 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.

na85 6y ago

>hardware doesn't matter >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.

AnthonyMouse 6y ago

The way free software is supposed to work is that you buy a device, you want to improve it, so you do. And then you share your improvements with everybody else. 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.

ohazi 6y ago

This argument doesn't work when PCs are essentially the only widely available hardware platform that ended up with an open standard for modifying the software running on the device. Even here, the fact that we ended up with this model was an accident. 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.

tytso 6y ago
That simply is not true. Chromebooks, many Android phones (all of the ones sold by Google) have a way of turning off the requirement for signed boot. The device is less secure if you disable signed boot; an evil maid who gains access to your device, or the FBI after they seize your device, will have a much easier time getting access to your data --- but if you want to build your own version of Chromium, or put your own Linux distro on a chromebook, or if you want to build your own version of Android from source, and put it on a Nexus or Pixel phone, you can do this easily. (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 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!

TaylorAlexander 6y ago

Intellectual property is a state enforced monopoly that interferes with market forces. In a purely market driven world “locked down” phones would be harder to create/enforce.

zerocrates 6y ago
If you're eliminating intellectual property you're eliminating the GPL anyway. 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.
- TaylorAlexander 6y ago
  My point is that this is not a "free market". It has substantial restrictions.

kmeisthax 6y ago

You have the market forces backwards. People don't avoid the lockouts, the lockouts shape people into a particular behavior. For example, look at Apple's ridiculous levels of anti-repair nonsense - it is designed specifically to make it harder for non-Apple technicians to properly repair a device. These lockouts have legal force thanks to... rather prevalent misreadings of DMCA 1201 that make large companies unwilling to design circumvention tools for these sorts of things. 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.)