It’s such a shame that, if zsh gains enough critical mass, all copies of its source code will be deleted from the universe and no-one will be able to use it without paying any more.
It’s such a shame that you can’t customize the version of zsh running on your Linux-based embedded device because it’s DRM’d to prevent the modified version from being installed.
…oh wait, that’s not sarcasm because it’s actually plausible.
A plausible path is precedent and normalization, not zsh specifically.
If a widely used copyleft component (like a shell) starts being accepted as “OK to lock down” in consumer or embedded devices, manufacturers and courts get comfortable with the idea that user-modifiable software is optional rather than a right tied to distribution. Over time, that erodes enforcement of anti-tivoization principles and weakens the practical force of copyleft licenses across the stack.
Once that norm shifts, vendors can apply the same logic to kernels, drivers, bootloaders, and userland as a whole—at which point locked-down embedded devices stop being the exception and become the default, even when the software is nominally open source.
I don’t understand. It’s already ok to “lock down” devices, from the point of view of most consumers and the courts, regardless of the software license. Phones make it hard for you to flash new firmware onto them. That is still true with android and the open source components in its stack.
Using bsd licensed software in every day life cannot accelerate that because it has already happened, and I don’t see how it would be otherwise, because software licensing doesn’t protect against the kind of locking down you’re talking about.
It’s such a shame that, if zsh gains enough critical mass, all copies of its source code will be deleted from the universe and no-one will be able to use it without paying any more.
It’s such a shame that you can’t customize the version of zsh running on your Linux-based embedded device because it’s DRM’d to prevent the modified version from being installed.
…oh wait, that’s not sarcasm because it’s actually plausible.
Cool.
And what, exactly, is the path from “pushing back on zsh” to “embedded device manufacturers can no longer lock down their devices?”
A plausible path is precedent and normalization, not zsh specifically.
If a widely used copyleft component (like a shell) starts being accepted as “OK to lock down” in consumer or embedded devices, manufacturers and courts get comfortable with the idea that user-modifiable software is optional rather than a right tied to distribution. Over time, that erodes enforcement of anti-tivoization principles and weakens the practical force of copyleft licenses across the stack.
Once that norm shifts, vendors can apply the same logic to kernels, drivers, bootloaders, and userland as a whole—at which point locked-down embedded devices stop being the exception and become the default, even when the software is nominally open source.
I don’t understand. It’s already ok to “lock down” devices, from the point of view of most consumers and the courts, regardless of the software license. Phones make it hard for you to flash new firmware onto them. That is still true with android and the open source components in its stack.
Using bsd licensed software in every day life cannot accelerate that because it has already happened, and I don’t see how it would be otherwise, because software licensing doesn’t protect against the kind of locking down you’re talking about.