A look at what's new in kernel development.

Welcome to the new diff -u! We're experimenting with a shorter, more frequent, single-subject format for this feature, which also may evolve over time. Let us know what you think in the comments below.

Recently there's been an effort to add support for digital rights management (DRM) into the Linux kernel. The goal of DRM is to prevent users from making copies of music, video and other media that they watch on their own computers, but it also poses fundamental questions about the nature and fate of general-purpose computers.

Sean Paul, from the ChromeOS developer team, submitted a patch to enable DRM encryption running through certain pieces of DRM hardware, including exynos, mediatek and rock chip. The patch itself is not new—ChromeOS has been using it in-house for years. However, if these DRM patches could get into the official kernel tree, any Linux system running on the proper hardware—not just ChromeOS systems—could support DRM controls.

The code was highly targeted to make it through the gauntlet of kernel patch submission. It didn't go so far as to implement features that would take control away from the user. All it did was implement encryption via High-bandwidth Digital Content Protection (HDCP) and allow the user to turn on and off the hardware that would use the encrypted HDCP data stream.

In other words, the patch theoretically implemented just a general-purpose cryptographic feature that might be used for something other than DRM. And as Daniel Vetter put it in the mailing list discussion, any full DRM implementation also would need an unlockable boot-loader, as well as a variety of userspace code. At that point, he said, "yes, then you don't really own the machine fully."

Pavel Machek didn't like this at all and felt that accepting even Sean's relatively generic patch would encourage hardware vendors to install locked-down versions of Linux at the factory, thus preventing users from altering the OS themselves. He added, "That is evil, and a direct threat to Free Software movement."

Pavel also pointed out that any normal user who was not on a vendor-controlled, DRM-locked system, would get no benefit whatsoever from Sean's patch. On an unlocked system, there was simply no reason to enable the feature at all.

And so, even though the patch only enables features that are already present in a system's hardware, and even though as implemented it would be an optional kernel feature, there is already strong opposition to it because of the threat that such a patch might undermine the future availability of user-controlled computers and the likely proliferation of Linux systems that violate the spirit, if not the letter, of the GPL.

But in spite of this threat, it's still possible that this patch, or something similar, could go into the kernel. As Alan Cox pointed out during the discussion, the code simply needs to implement a feature that has a general-purpose use. If the code's only value is to lock down systems, Linus Torvalds would be unlikely ever to accept it. But, if the hardware has some other legitimate purpose, and if the encryption keys are held by the actual user and not the vendor, a patch to enable it could successfully make it through.