Torvalds versus GPLv3 DRM restrictions


Author: Joe Barr

Linus Torvalds, father of the Linux kernel, has fleshed out his unhappiness with GPLv3 in three recent posts on the Linux Kernel Mailing List (LKML).Torvalds previously stated that the kernel will remain under the licensing terms of GPLv2.

Yesterday, Tovalds offered his opinion as to where the battle over DRM should take place:

I would suggest that anybody who wants to fight DRM practices seriously
look at the equivalent angle. If you create interesting content, you can
forbid that _content_ to ever be encrypted or limited.

In other words, I personally think that the anti-DRM clause is much more
sensible in the context of the Creative Commons licenses, than in software
licenses. If you create valuable and useful content that other people want
to be able to use (catchy tunes, funny animation, good icons), I would
suggest you protect that _content_ by saying that it cannot be used in any
content-protection schemes.

Afaik, all the Creative Commons licenses already require that you can’t
use technological measures to restrict the rights you give with the CC
licenses. The “Share Alike” license in particular requires all work based
on it to also be shared alike, ie it has the “GPL feel” to it.

If enough interesting content is licensed that way, DRM eventually becomes
marginalized. Yes, it takes decades, but that’s really no different at all
from how the GPL works. The GPL has taken decades, and it hasn’t
“marginalized” commercial proprietary software yet, but it’s gotten to the
point where fewer people at least _worry_ about it.

As long as you expect Disney to feed your brain and just sit there on your
couch, Disney & co will always be able to control the content you see. DRM
is the smallest part of it – the crap we see and hear every day
(regardless of any protection) is a much bigger issue.

The GPL already requires source code (ie non-protected content). So the
GPL already _does_ have an anti-DRM clause as far as the _software_ is
concerned. If you want to fight DRM on non-software fronts, you need to
create non-software content, and fight it _there_.

I realize that programmers are bad at content creation. So many
programmers feel that they can’t fight DRM that way. Tough. Spread the
word instead. Don’t try to fight DRM the wrong way.

In a later post, Tovalds replied to Pierre Ossman, who suggested the GPL can
currently be thwarted by DRM measures:

> The point is not only getting access to the source code, but also being able
> to change it. Being able to freely study the code is only half of the beauty
> of the GPL. The other half, being able to change it, can be very effectively
> stopped using DRM.

No it cannot.

Sure, DRM may mean that you can not _install_ or _run_ your changes on
somebody else’s hardware. But it in no way changes the fact that you got
all the source code, and you can make changes (and use their changes) to
it. That requirement has always been there, even with plain GPLv2. You
have the source.

The difference? The hardware may only run signed kernels. The fact that
the hardware is closed is a _hardware_ license issue. Not a software
license issue. I’d suggest you take it up with your hardware vendor, and
quite possibly just decide to not buy the hardware. Vote with your feet.
Join the OpenCores groups. Make your own FPGA’s.

And it’s important to realize that signed kernels that you can’t run in
modified form under certain circumstances is not at all a bad idea in many

For example, distributions signing the kernel modules (that are
distributed under the GPL) that _they_ have compiled, and having their
kernels either refuse to load them entirely (under a “secure policy”) or
marking the resulting kernel as “Tainted” (under a “less secure” policy)

Notice how the current GPLv3 draft pretty clearly says that Red Hat would
have to distribute their private keys so that anybody sign their own
versions of the modules they recompile, in order to re-create their own
versions of the signed binaries that Red Hat creates. That’s INSANE.

Btw, what about signed RPM archives? How well do you think a secure
auto-updater would work if it cannot trust digital signatures?

I think a lot of people may find that the GPLv3 “anti-DRM” measures aren’t
all that wonderful after all.

Because digital signatures and cryptography aren’t just “bad DRM”. They
very much are “good security” too.

Babies and bathwater..

And finally, in yet another response to Ossman and others on the LKML, he wrote:

> So taking open software and closed hardware and combining it into something
> that I cannot modify is ok by you?

But you CAN modify the software part of it. You can run it on other

It boils down to this: we wrote the software. That’s the only part _I_
care about, and perhaps (at least to me) more importantly, because it’s
the only part we created, it’s the only part that I feel we have a moral
right to control.

I _literally_ feel that we do not – as software developers – have the
moral right to enforce our rules on hardware manufacturers. We are not
crusaders, trying to force people to bow to our superior God. We are
trying to show others that co-operation and openness works better.

That’s my standpoint, at least. Always has been. It’s the reason I
chose the GPL in the first place (and it’s the exact same reason that I
wrote the original Linux copyright license). I do _software_, and I
license _software_.

And I realize that others don’t always agree with me. That’s fine. You
don’t have to. But I licensed my project under a license _I_ agreed with,
which is the GPLv2. Others who feel differently can license under their
own licenses. Including, very much, the GPLv3.

I’m not arguing against the GPLv3.

I’m arguing that the GPLv3 is wrong for _me_, and it’s not the license I
ever chose.


  • Legal