An “escape hatch” in GPLv3 could pacify Linux kernel hackers and others concerned with anti-DRM language in the proposed license, says Free Software Foundation Europe representative Ciaran O'Riordan. O'Riordan encourages interested parties to speak up prior to November's release of the third and possibly final draft.

O'Riordan shares his thoughts in an insightful, interesting essay published over at KernelTrap this morning.

According to O'Riordan, the current (second) draft of the GPLv3 allows “additional permissions” to be added. Thus, the thousands of Linux copyright holders could adopt a version of the license “additionally permitting” users to withhold any keys or passwords required to run user-modified Linux firmware on devices. This would allow the continued use of the kernel in devices where user modifications are not desirable, such as cell phones and DVRs (digital video recorders) commonly sold as one component of a service offering.

Interestingly, “additional permissions” can be removed by downstream distributors. This seems to have two main implications. First, a developer could choose to remove the exception before distributing a version of the kernel with their patches. This would ensure that the developer's work could not be used in DRM-encumbered devices, while at the same time preventing the work from ever being added to the mainline kernel.

Second, the Linux kernel community itself could choose to remove the additional permissions later — to fork the kernel, essentially — should a situation arise in which that seemed prudent. Examples cited by O'Riordan include governmental anti-piracy legislation mandating that software be locked to hardware, hardware manufacturer consortia such as the DVD consortium, and more widespread use of the hardware-as-service-component business model used by TiVo and others.

O'Riordan also discusses the possible use of ROMs (read-only memory) in situations where companies do not want users to modify their products. Of course, ROMs would also prevent in-field firmware updates or bug fixes, possibly leading to disastrously expensive product recalls.

O'Riordan's interesting essay can be found at KernelTrap, here.

Additional perspective on the various reasons that embedded developers might want to prevent user modifications can be found in this recent exchange between Alan Cox of Red Hat and Thomas Gleixner of TimeSys.