[ninkendo]

Because anti-tivoization doesn’t make sense in a software license.

Imagine you make a smart toaster, and you make it entirely out of open source software. You release all the changes you made too, complying fully with the spirit of open source. People could take your software, buy some parts and make their own OSS toasters, everything’s great.

But for safety reasons, since the software controls when the toaster pops, you decide to check at boot time that the software hasn’t been modified. You could take the engineering effort to split the software into parts so that only the “pop on this heat level” part is locked down, but maybe you’re lazy, so you just check the signature of the whole thing.

This would be a gpl3 tivoization violation even though the whole thing is open source. You did everything right on the software end, it just so happens that the hardware you made doesn’t support modifying the software. Why is that a violation of a software license?

This is what makes no sense to Linus, and TBH it makes no sense to me either. Would the toaster be a better product if you could change the software? Of course. But it seems to be an extreme overreach for the FSF to use their license (and that “or any later version” backdoor clause) to start pushing their views on the hardware world.

[Brian_K_White]

It makes sense in the context of GPL specifically when you remember that the GPL itself and the entire GNU stack and movement started from frustration with a printer, not a program.

[MarkusQ]

> But it seems to be an extreme overreach for the FSF to use their license (and that “or any later version” backdoor clause) to start pushing their views on the hardware world.

Nothing is stopping the "hardware world" from developing their own operating system. But as long as they choose to come as guests to the FSF/GPL party, partake of the snacks and fill their glasses at the free-refills fountain, they're expected to abide by the rules. The doors not locked, they can leave any time.

[immibis]

No, actually anti-tivoization makes perfect sense, even in your example, and if you make this toaster then you are simply an evil anti-freedom company.

If you're afraid that modifying the software will make the toaster overheat, then include a hardware thermal fuse. You need to anyway, in case the manufacturer software fails or the processor fails.

[atq2119]

> But for safety reasons, since the software controls when the toaster pops, you decide to check at boot time that the software hasn’t been modified.

As arguments go, this is a pretty weak one considering how obvious the solution is: Make the manufacturer not be liable for what happens when you operate the device with unauthorized software.

[barnas2]

Manufacturers still may not go for it, due to the potential bad publicity. To go back to the toaster example, if some fancy open source software alternative has a critical issue and causes fires, the news will not report it with nuance. "SmartCo Toaster Fires on the Rise!" will be the headline, not "Niche Modding Community Sets Toasters On Fire, And The Manufacturer Had Nothing To Do With It".

[jcalvinowens]

Lawyers who make these decisions are so risk averse in my experience they'd still probably insist on it being nonmodifiable.

[atq2119]

Sure, which is why right to repair laws are so important.

I understand this discussion as being about how society should deal with it, not how you could try to make the argument internal to a company.

[jcalvinowens]

Right, I'm saying I don't think codifying limitations on liability in law will be effective, because it probably wouldn't be absolute enough to satisfy the lawyers. You need a law that actually says "the user must be free to modify the device".

[account42]

They don't seem to be too risk averse about misusing free software though.

[ssl-3]

I have a toaster oven in my kitchen. It's a dumb thing with a bimetallic thermostatic switch, a simple mechanical timer (with a clockspring and a bell), and a switch to select different configurations of heating elements. The power-on indicator is a simple neon lamp. (It also certainly has some thermal fuses buried inside; hopefully, in the right places.)

And, you know, it works great. It's simple to operate and (so far!) has been completely reliable.

I can hack on it in any way that I want to. There's no aspect of it that seeks to prevent that kind of activity at all.

What would I hack it to do instead? Who knows, but I can think of a couple of things. Maybe instead of having some modes where the elements are in series, I want them in parallel instead so the combination operates at higher power. Maybe I want to bypass the thermostat with an SSR and use my own control logic so I can ramp the temperature on my own accord and finally achieve the holy grail of a perfect slice of toast, and make that a repeatable task.

Whatever it is, it won't stand in my way of doing it -- regardless of how potentially safe or unsafe that hack may be.

There are countless examples of similar toaster ovens in the world that anyone else can hack on if they're motivated to do so, and very similar 3-knob Black & Decker toaster ovens are still sold in stores today.

And yet despite the profoundly-accessible hackability of these potentially-dangerous cooking devices (they didn't even bother to weld the cover on or use pentalobular screws, much less utilize one-way cryptographic coding!), they seem fine. They're accepted in the marketplace and by safety testing facilities like Underwriters Laboratories, who seem satisfied with where the bar for safety is placed.

Why would a toaster oven (or indeed, just a pop-up toaster) that instead used electronic controls need the bar for safety to be placed at a different height?

[ninkendo]

> Why would a toaster oven (or indeed, just a pop-up toaster) that instead used electronic controls need the bar for safety to be placed at a different height?

It wouldn't. It's a thought experiment. I even said:

> Would the toaster be a better product if you could change the software? Of course.

The point is, nobody should be compelling you to make your products hackable. If you don't want to, that's your prerogative.

The problem is, before GPLv3 existed, the authors that picked GPLv2 never expressed that they wanted their software to be part of some anti-locked-bootloader manifesto... they picked it because GPLv2 represents a pretty straightforward "you can have the source so long as you keep it open for any changes you make" license. That's what the GPL was. But this whole "Or any future version" clause gave FSF carte blanche to just alter the deal and suddenly make it so anyone can fork a project and make it GPLv3. I can perfectly understand why this would make people (including Linus) very mad.

[kelnos]

If an author wants, they can leave out the "or any future version" verbiage. If the author does not, then they are explicitly saying that they want their software to be part of whatever future manifesto the FSF puts forth, including the anti-locked-bootloader manifesto present in the GPLv3.

And that's why Torvalds left out "or any future version" when licensing Linux. So I'm not sure why he's "very mad" (I doubt he actually is?); his software remains on GPLv2 like he wanted.

> The point is, nobody should be compelling you to make your products hackable.

If you want to use my GPLv3 software on your product, then yes, I am requiring that you make it hackable. If you don't want to do that, tough shit. Either do so, or freeload off someone else's software.

[pabs3]

GPLv2 mandates user-modifiable devices too, according to Conservancy at least.

[immibis]

Also according to at least one German court! (AVM Vs I don't remember. The lawsuit was about home wireless routers.)

[pabs3]

I want the law to compel you to make your products hackable. The GPL is often irrelevant for devices, the law is what matters.

[ssl-3]

You used the thought experiment as the foundation for the anti-anti-tivoization sentiment expressed. If the thought experiment is false, then the sentiment which might rest upon it is without basis.

> The point is, nobody should be compelling you to make your products hackable. If you don't want to, that's your prerogative.

I agree.

Nobody is compelled to use GPLv3 code in the appliances that they want locked-down for whatever reasons (whether good or bad) they may wish to do that. There's other routes (including writing it themselves).

They may see a sea of beautiful GPLv3 code and wish they could use it in any way they desire, like a child may walk into a candy store and wish to have all of it for free, but the world isn't like that.

We're all free to wish for whatever we want, but that doesn't mean that we're going to get it.

> But this whole "Or any future version" clause gave FSF carte blanche to just alter the deal and suddenly make it so anyone can fork a project and make it GPLv3.

This "Or any future version" part isn't part of the GPL -- of any version.

Let us review GPL v1: https://www.gnu.org/licenses/old-licenses/gpl-1.0.en.html

> Each version is given a distinguishing version number. If the Program specifies a version number of the license which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.

The GPL itself does not in any way mandate licensing any code under future versions. An author can elect to allow it -- or not.

If they specify GPL 2, then they get GPL 2. Not 3. Not 4. Only 2.

Other versions of the GPL are ~the same in this way. (You know where to find them, right? They're easy reads.)

[immibis]

The law compelling you to make your products hackable is called "right to repair". Without this law, if my toaster breaks, my only option is to buy a new toaster. But if I'm allowed to change the toaster, I can fix the toaster.

Products have worked this way since forever. Only since modern microprocessors and cryptography have evil companies been able to deliberately add roadblocks that are impossible to overcome (without replacing so much hardware that you've made a new toaster from scratch) in order to maximize revenue. This is predatory and should be illegal. The only reason I can see that you'd support this, is it you work for a company that makes a lot of money selling new toasters to replace broken ones, and if this is true, your company deserves to be shut down by the government.

[pessimizer]

> But for safety reasons, since the software controls when the toaster pops, you decide to check at boot time that the software hasn’t been modified.

"For safety reasons" is every single claim. For safety reasons, I want to block the manufacturer's software from doing what it wants. Why do the manufacturer's safety reasons overrule my safety reasons?

> This would be a gpl3 tivoization violation even though the whole thing is open source.

Copyleft has nothing to do with open source. You haven't done everything right on the software end, because the GPL isn't about helping developers. To do things right on the software end, you should keep GPL software out of your locked down device that you are using to restrict the freedom of its users.

> Would the toaster be a better product if you could change the software? Of course.

You just said that it would be an unsafe product if you could change the software. Now you're using the "don't let the perfect be the enemy of the good" trope to pretend that you would of course support software freedom in an ideal, magical, childish, naïve dream world.

> it seems to be an extreme overreach for the FSF to use their license

People can license their software how they want. Is it an extreme overreach for Microsoft to not let you take their Windows code and do whatever they want with it? Why are you even thinking about GPL code when there's so much overreach coming from Adobe? They don't let you use their code under any circumstances!

All of your reasoning is motivated, and I would recommend that people not buy your toaster.

[paxcoder]

Modifiability does not imply insecurity (though if it did, the user should still be given a choice).

A software author has the right to set terms for use of their software, including requiring that manufacturers provide end users certain freedoms.