[gl-como] Linux ed il DRM

[Alessandro Mentasti]

Posto questa mail anche se in inglese perch=E9 penso sia davvero interessan=
te...


Date: Wed, 23 Apr 2003 20:59:45 -0700 (PDT)
=46rom: Linus Torvalds <torvalds@transmeta.com>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Flame Linus to a crisp!

=2D------------------------------

Ok,
there's no way to do this gracefully, so I won't even try. I'm going to jus=
t=20
hunker down for some really impressive extended flaming, and my asbestos=20
underwear is firmly in place, and extremely uncomfortable.

    I want to make it clear that DRM is perfectly ok with Linux!=20

There, I've said it. I'm out of the closet. So bring it on...

I've had some private discussions with various people about this already, a=
nd=20
I do realize that a lot of people want to use the kernel in some way to jus=
t=20
make DRM go away, at least as far as Linux is concerned. Either by some=20
policy decision or by extending the GPL to just not allow it.

In some ways the discussion was very similar to some of the software patent=
=20
related GPL-NG discussions from a year or so ago: "we don't like it, and we=
=20
should change the license to make it not work somehow".

And like the software patent issue, I also don't necessarily like DRM mysel=
f,=20
but I still ended up feeling the same: I'm an "Oppenheimer", and I refuse t=
o=20
play politics with Linux, and I think you can use Linux for whatever you wa=
nt=20
to - which very much includes things I don't necessarily personally approve=
=20
of.

The GPL requires you to give out sources to the kernel, but it doesn't limi=
t=20
what you can _do_ with the kernel. On the whole, this is just another examp=
le=20
of why rms calls me "just an engineer" and thinks I have no ideals.

[ Personally, I see it as a virtue - trying to make the world a slightly=20
better place _without_ trying to impose your moral values on other people.=
=20
You do whatever the h*ll rings your bell, I'm just an engineer who wants to=
=20
make the best OS possible. ]

In short, it's perfectly ok to sign a kernel image - I do it myself indirec=
tly=20
every day through the kernel.org, as kernel.org will sign the tar-balls I=20
upload to make sure people can at least verify that they came that way. Doi=
ng=20
the same thing on the binary is no different: signing a binary is a perfect=
ly=20
fine way to show the world that you're the one behind it, and that _you_=20
trust it.

And since I can imaging signing binaries myself, I don't feel that I can=20
disallow anybody else doing so.

Another part of the DRM discussion is the fact that signing is only the fir=
st=20
step: _acting_ on the fact whether a binary is signed or not (by refusing t=
o=20
load it, for example, or by refusing to give it a secret key) is required=20
too.

But since the signature is pointless unless you _use_ it for something, and=
=20
since the decision how to use the signature is clearly outside of the scope=
=20
of the kernel itself (and thus not a "derived work" or anything like that),=
 I=20
have to convince myself that not only is it clearly ok to act on the=20
knowledge of whather the kernel is signed or not, it's also outside of the=
=20
scope of what the GPL talks about, and thus irrelevant to the license.

That's the short and sweet of it. I wanted to bring this out in the open,=20
because I know there are people who think that signed binaries are an act o=
f=20
"subversion" (or "perversion") of the GPL, and I wanted to make sure that=20
people don't live under mis-apprehension that it can't be done.

I think there are many quite valid reasons to sign (and verify) your kernel=
=20
images, and while some of the uses of signing are odious, I don't see any=20
sane way to distinguish between "good" signers and "bad" signers.

Comments? I'd love to get some real discussion about this, but in the end I=
'm=20
personally convinced that we have to allow it.

Btw, one thing that is clearly _not_ allowed by the GPL is hiding private k=
eys=20
in the binary. You can sign the binary that is a result of the build proces=
s,=20
but you can _not_ make a binary that is aware of certain keys without makin=
g=20
those keys public - because those keys will obviously have been part of the=
=20
kernel build itself.

So don't get these two things confused - one is an external key that is=20
applied _to_ the kernel (ok, and outside the license), and the other one is=
=20
embedding a key _into_ the kernel (still ok, but the GPL requires that such=
 a=20
key has to be made available as "source" to the kernel).

    Linus