Acceptable techniques to verify rootfs without circumventing gplv3 terms

Question

GPLv3 has clause to ensure that device manufacturers are not circumventing "freedom to run modified software by users".

3. Protecting Users' Legal Rights From Anti-Circumvention Law states:

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.

Now in practical terms, this means, a device manufacturer must not block any user from updating a GPLv3 package in rootfs image with a modified version of own.

In case of many commercial products, OEMs protect the rootfs image by using features such as dm-verity or some other signing mechanism so that device is booting with a trusted rootfs, and hardware provides the root-of-trust.

What options do OEM(s) have to ensure both below mentioned goals met?

1. Allow users to run their own modified versions of FOSS packages.
2. Ensure that the trust model of the product is met.

Can OEM take the following approach of implementing two modes to meet the above 2 goals?

Normal mode, boot with a trusted rootfs image with root-of-trust established by the hardware.

Run trust based use-cases in this mode, e.g., face recognition in a security access control camera.

Special mode, Let's say mode is activated when user toggles a hardware switch on device. On next reboot:

• A warning is presented to user and confirmation is received from user for entering special mode
• All trust based data on device is wiped off
• rootfs verification is not done
• In this mode now user is free to install his own modified version of FOSS and run it
• This mode does not support use-cases tied to hardware root-of-trust

Is this separation of modes an acceptable mechanism to remain compliant with GPLv3?

Answer 1

Interesting; let's examine your list of special-mode features.

1. A warning is presented to user and confirmation is received from user for entering special mode
2. All trust based data on device is wiped off
3. rootfs verification is not done
4. In this mode now user is free to install his own modified version of FOSS and run it
5. This mode does not support use-cases tied to hardware root-of-trust

Right now, a lot of Android phones, which are devices specifically made to run the (GPLv2) Linux kernel, and which ship with it, do something very similar. When I unlocked the bootloader of my S9, the device warned me that I was unlocking the bootloader for the first time (1) and that it would be erasing the device's memory for privacy reasons (2). (3) didn't really apply, since the device achieved trust by shipping with a bootloader that didn't allow uploading arbitrary OSes. Once I'd unlocked the bootloader I was able to upload a new recovery image to the phone, and thence a new OS (4). Android has an interface that allows applications to ask the OS if the hardware is bootloader-unlocked, and LineageOS (the most popular alternative OS build) honours this (5). That said, once the user controls the phone, it's perfectly possible to get around the issue.

So for GPLv2, it's possible to get most of what you want (1, 2, 3 or equivalent, 4, and the appearance of 5) without violating the licence. What of GPLv3? The only differences that matters here are the installation information provisions for user products in s6, aka the anti-Tivoisation provisions. As I read them, those provisions make no mention of, and thus have no issue with, requirements 1, 3, and 4. 5 is pointless, because once the user controls the device an application running on it has no way to reliably verify that the device can be trusted.

2 seems to me to be the sticky point. The issue arose during the creation of the licence; RMS, speaking in Turin in 2006, said that

GPL version three says that if they distribute a GPL-covered program in this way, they must provide you with the key necessary so that you can sign your version and make it access the same data.

It seems to me that having the device wipe itself when unlocked isn't compatible with that aim, particularly if there's no way to get this data off the device with the OS as supplied.

So as as I read it, and IANAL/IANYL and others could well read it differently, if you drop (2) and accept that (5) is a dead duck, you can do the rest of what you want and still satisfy GPLv3.