[cycloptic]

>That's a big security risk on an embedded system - both from an IP protection point of view

If a company is interested in "protecting their IP" by closing the source then it's questionable why they would have even wanted to use GPLv2 software at all. The OEM's IP situation is also not related to the security of the customer. Maybe it matters to the security of the OEM, but that's different.

>and also from a botnet/pwning point of view

Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased.

[nrclark]

> If a company is interested in "protecting their IP" by closing the source then it's questionable why they would have even wanted to use GPLv2 software at all. That also is not related to the security of the customer at all. Maybe it matters to the security of the OEM, but that's different.

I can't speak for other engineers. But at companies I've worked in, a common product model is "embedded Linux with GPLv2 software, and some proprietary secret-sauce binaries". At those companies, they usually do send patches to upstream open-source projects and they try to contribute. Also they usually provide full source-code on request, for everything except the proprietary stuff.

The net effect of GPLv3 has been that GNU packages basically don't exist on embedded devices any more. Which means that engineers like me don't have the professional opportunity to contribute features and patches. It sort of isolates GPLv3 projects into a walled garden, which I feel like is the opposite of what GPL was intended to foster. Instead, I can only have the professional opportunity to contribute on GPLv2 or permissive-license projects.

> Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased.

I sympathize with the intent behind this. There are also just some practical realities that are tough. At my current company, the team working on our next embedded Linux product is pretty small. We don't have infinite time or resources to make sure that our own code is 100% intrusion-resistant - all we can do is try our best.

It's a big ask for us to support _two_ methods of firmware-update (local and over-the-network) with different keys/security requirements for each. We just plain don't have the manpower to support that, not when we can be developing features to improve our product instead.

And if you have access to the filesystem, it's that much easier to comb through it and look for vulnerabilities in our network updater (for example). And it's easier to pick apart the proprietary bits with Ghidra or something. Could you do it anyways, even without our help? Maybe. But it's much harder.

Can we design a system that's robust enough to allow you to install whatever you want on your unit? Maybe. Probably. Hopefully we're already there. But I'm not going to risk my company's livelihood on it just to ship GPLv3 software, especially considering that there are almost-as-good alternatives for a lot of it. We just don't have the resources to make sure we cover every security angle on an open-box system.

[cycloptic]

We are in a bind here. If you ship GPLv2 software on a locked down device then nobody downstream has the professional opportunity to contribute, because they simply can't get any of their changes onto the device. The reason to rectify this is not "to ship GPLv3 software" the reason is because otherwise customers don't have control over their own devices.

The developers who relicensed to GPLv3 don't care that some companies won't contribute. From their perspective, any of those contributions would be unusable to them. I feel a similar way with my open source projects -- why would I as an outsider maintain code that nobody outside of your company will ever have any possible way to test in a real production scenario? It's a waste of my time. Yes I might be missing out on minor bug-fixes but I don't really care about that. Like you said, feature development is more important.

As far as firmware-updating goes, to be in compliance the user just needs to have some way to get access to the keys. You don't need to make separate keys, it can be the same method that you use.

[nrclark]

> We are in a bind here. If you ship GPLv2 software on a locked down device then nobody downstream has the professional opportunity to contribute, because they simply can't get any of their changes onto the device.

I should clarify - what I meant is that if we're shipping GPLv2 software like Busybox, then I'm able to spend billable time improving Busybox and upstreaming my patches. That's labor that could be going to GNU coreutils instead, if it was the userspace on my product. But since I'm not shipping it, that means I don't find bugs or need features very often. Which means I have way less of an opportunity to pitch in.

[cycloptic]

That's great for you. In that situation, if my company buys your product, we have zero opportunity to pitch in to Busybox and are not able to spend any of our billable time upstreaming our patches, because the device is locked down. Who wins here? It's not the project who wins, because they lost contributions. It's not my company or any of your other customers who win, because we can't contribute. It's not you who wins, because if you get a different job then you lose access to the device and can't contribute, and you also lose the billable consulting hours that you could have charged to my company. It's not your company who wins, because they lose the shared contributions from my company.

I'm not making this up either. Even in my personal life I own lots of random devices that I know for a fact are running Linux and Busybox. But I have to go out of my way to find a device that I actually have a chance to get a toolchain running on and can actually start working on patches. It's usually limited to old devices that had no security or had their security broken. So any contributions I make are limited to things that only work on insecure old legacy hardware, stuff that is not going to be of interest to your company working on the next new hotness. There is a real problem here that's in-part solved by the GPLv3, but you have to actually acknowledge that it's a problem.

[nrclark]

Just a note - I appreciate this discussion, and your point of view! Thanks for having it.

Ease of contribution is a problem for sure, and it's one that GPLv3 was intended to address. My main point is that the changes from GPLv2 actually had the opposite effect for a whole group of developers.

Instead of encouraging -more- development, I feel like maybe it's just driven developers away and onto GPLv2, MIT, or BSD equivalents. Maybe this is intended behavior, and not an accidental side-effect. I don't know. But it's hard to dispute that it reduces the pool of potential contributors to GPLv3 packages.

GPLv3 components just aren't an option for a lot of products, regardless of whether GPLv3 is better for users (I agree that it is). I think it's really harmed the FSF a lot. With fewer installations of FSF packages, the FSF sees less participation and loses some of its clout. And that makes me sad :(

[cycloptic]

People and groups that wanted to contribute but couldn't because of locked-down devices were already driven away and discouraged from development. And it was worse for them, if you own a locked-down device you can't go and decide to run FreeBSD on it to fix that. You just can't work on it at all. The GPLv3 was drafted in response to complaints about this -- specifically, companies that were shipping Linux and Busybox and were either straight-up GPL violating, or were telling users to get lost when they asked how it would be possible to get patched software on the device in any practical sense. From my perspective, there already was a wall in between those companies locking down their devices and the rest of the community. The GPLv3 only highlighted it.

[wolrah]

> It's a big ask for us to support _two_ methods of firmware-update (local and over-the-network) with different keys/security requirements for each. We just plain don't have the manpower to support that, not when we can be developing features to improve our product instead.

But you don't have to do two different systems. You can use the exact same update mechanism, just with the cryptographic validation controlled by the owner of the hardware.

Look at how Secure Boot is implemented on most x86 platforms. Default installed keys from the OEM, can not be changed from the OS, but can be disabled or replaced by the end user.

Chromebooks offer another example of how to do it well with their "Developer Mode" switches. With the switch (which is not accessible on an operating system) in the default position it will only boot Google signed images. With the switch in developer mode it notifies the user of this on every boot, but no longer verifies signatures. The device is factory reset when switching modes to ensure that the unsigned mode can not be used to compromise a stolen device.

Android phones with unlockable bootloaders work similarly, they just have a software toggle in the first-stage bootloader rather than a physical switch.

---

There are plenty of low-effort ways to provide cryptographic verifiability to end users while still following not just the letter but the spirit of the GPL.

Obviously most of us would prefer something like the first example where a user could replace the stock keys with their own and sign their own code to maintain full security when going off on their own, the second and third options are nearly trivial to implement. One switch or jumper, a single input pin, and however much code it takes to check the state of that pin when performing any boot validation.