CopperheadOS: Security features, installing apps, and more (opensource.com)

Licenses placing significant restrictions on usage of the code compared to permissive ones.

> OpenBSD considers copyleft licenses to be less free than BSD licenses, but does not assert that they're non-free.

They consider them less free to the point that OpenBSD and FreeBSD are very actively purging GPL code even when it means doing a lot of work or accepting compromises. I do think they get commonly referred to as not free nowadays.

https://wiki.freebsd.org/GPLinBase

I wouldn't previously have used as strong a term as "(technically) synonymous". I would have said they are "similar but not the same", or suchlike.

But you have a track record of being well-informed about free and open source software licensing, so I will reconsider my view in the light of this comment of yours and the one above, and will re-read and re-think a few FSF essays when I get the chance. Thanks for the reply :)

> I don't think it tells us much about whether there's a difference in how freedom to use is treated by the two terms.

Again, your take on the matter is different to mine. And again, I'll consider revising my view in the light of yours; thanks :)

> (and I don't think the FSF would argue that the DFSG is a free *software* license). The DFSG and the Open Source Definition are basically identical but one refers to free software and the other to open source.

Sorry, I should have written with more clarity on several fronts here.

I was not suggesting that the DFSG is a license of any kind: it isn't. Apologies for the misinterpretability of my remark.

Rather, I was emphasising that the DFSG (which closely resembles the OSD, as is probably so widely understood by LWN readers that I didn't think it bore mentioning) precludes the GFDL. Which is *almost* as if the OSD precluded the GFDL. Which illustrates the point I was trying to make that "open", even under something very much like the OSI's definition, is technically *not* synonymous with "free" under the FSF's definition.

This is the closest thing to a counter-example to your claim that I could come up with. I admit the reasoning is slightly tortuous. Perhaps better counter-examples exist, but if not, then that fact speaks well of your claim :)

https://www.gnu.org/philosophy/free-sw.en.html

> The freedom to redistribute copies must include binary or executable forms of the program, as well as source code, for both modified and unmodified versions. (Distributing programs in runnable form is necessary for conveniently installable free operating systems.) It is OK if there is no way to produce a binary or executable form for a certain program (since some languages don't support that feature), but you must have the freedom to redistribute such forms should you find or develop a way to make them.

If developers can't distribute their modified versions, users are close to forbidden from using modified versions. Few people have the capability and hardware to build this kind of software, especially regularly to keep up with security updates, while securing their own signing keys and not ever losing access to them. Fewer still have the capability to make changes to it on their own.

A non-commercial clause solely for distribution is considered by the FSF to make software non-free and is the clause that's needed for CopperheadOS to have any resemblance of a business model.

Users should be able to choose to buy a device offering more secure verified boot not relying on state. Ideally, they would be able to order devices with their own public key burned into the hardware, rather than only having the option of buying devices like the Pixel 2 where they can unlock the bootloader, flash their public key to tamper resistant storage, flash their build and then lock the bootloader again to enable verified boot.

> There's nothing stopping you from providing an unbroken, immutable root of trust for a GPL v3 device - you just need to trust the device OWNER not to abuse it!

Immutable means the key has to be hard-wired rather configured as state. The rollback indexes for rollback protection can be irreversible via blowing fuses rather than using state, if it's not necessary to support development or installing other operating systems. A device using state for these is always going to be less secure than it could be without it.

The Pixel 2 / Pixel 2 XL use the Replay Protected Memory Block for storing the configured public key and rollback indexes, which works, but is more vulnerable to exploitation or tampering.

Since GPL3 forbids that, GPL3 code cannot be included in an OS supporting an immutable, unbroken chain of trust from hardware since it would be unusable on some of the device targets.

Even when there's a configurable key, everything leading up to the boot stage supporting configuration of the key needs to be verified from a hard-wired hardware root of trust. The early boot stages cannot permit signing with a custom key since they need to work towards the point where they can load a custom key from state.

CopperheadOS cannot include GPL3 code not owned by Copperhead because it would rule out supporting the most secure verified boot setups. It's not about preventing the device owner from "abusing" the feature. We don't care about that at all. It's an OS focused on hardening to improve privacy and security, and the GPL3 forbids a key part of that hardening by limiting the implementation to the security properties offered by the Pixel 2 approach.

Any partner making or wanting a device meant to be as secure as possible is going to be unwilling to give up some verified boot security to support using GPL3 code when they have other options. It would make CopperheadOS useless for the niches where it's targeting and isn't an option at all.

I think putting a significant limit on verified boot security is quite clearly a major usage restriction. It rules out using GPL3 code in many security-critical niches, especially when anti-tamper is important like many embedded devices.

It's perfectly fine to decide that the ends justify the means but it's disingenuous to pretend that there's no value in an immutable, unbroken chain of trust for verified boot.