[Committee-d] DRM And Authentication Issue Draft Text
David Turner
novalis at fsf.org
Mon May 15 19:21:16 EDT 2006
On Mon, 2006-05-15 at 00:01 -0700, Seth David Schoen wrote:
> I refer everyone to this thread
>
> http://lwn.net/Articles/178950/
>
> as well as to my earlier message about a developer whose software
> is used by another party in the course of a scheme that restricts
> users of a device.
I create a device which, on start-up, downloads some software from
somewhere. How have I not distributed that software? This isn't even
Grokster, where the users have to specifically request what to download
-- here, I know exactly what users are going to end up with.
> First, I think it's clear that there are important situations in which
> nobody who is distributing GPLv3-covered software will have a close
> relationship with someone who is enforcing a DRM-ish policy -- yet the
> policy will still get enforced and the entity enforcing it will still
> get a benefit and be able to deter people from modifying the software.
I don't see any where there's not secondary infringement on the part of
the drm-ist.
> Third, I'm not sure that the notions of recommended context of use
> or a normal implication that a user has some information are clear
> enough concepts to provide useful guidance to software developers,
> or to be enforced in court. I worry that a court would be puzzled
> about the definition and scope of these concepts.
Can you think of a way to rephrase this?
> Fourth, I'm not sure about the general situation in which someone
> sets up a computer system to restrict someone else and exactly which
> kinds of power relationships the GPLv3 does or should try to prohibit
> GPL-covered software from being used in furtherance of.
Manifesto: Users of a piece of software must have the ability to modify
that software and run it on any device they own, limited only by
processing power, memory, i/o, etc.
To some extent, this is outside GPLv3's control -- there are some
devices whose manufacturers don't distribute or promote GPL software for
use on them.
But when a manufacturer runs GPL software on a device, you should be
able to run any GPL software you like on that device.
> If [signing keys] _don't_ have to be distributed, then there is a
> property of certain binaries that a user can't reproduce in the
> user's own binaries -- the evidence of authenticity of the binaries.
> If that evidence is used by some system to restrict the user's
> freedom, the user does not necessarily have a technological means to
> beat the system.
Any time a GPL program is distributed, everyone doing the distribution
needs a license to do it. It's possible that more than one person could
be responsible for any given act of distribution -- that's why both the
person running the auction house and the person selling the tapes could
be liable in Cherry Auction. So, when there's distribution of GPL
software, the GPL can place requirements.
Any device manufacturer who wants to use a GPL operating system needs to
be distributing that operating system -- either directly on the device,
or via a stript which runs on device initialization. So, we can prevent
device manufacturers from restricting users.
Some parties don't distribute any GPL software in any way, but wish to
restrict users. They need to know that users have a computer which will
do what they expect (that is, a "Trusted" computer). The operating
system on this device could have only secure boot, curtained memory, and
remote attestation -- that's sufficient for a platform on which to run a
TPM-based DRM system but for the analog hole. Each of these is
independently useful. Still, this separates the interests of the DRM
people from the device people. The device people can't add DRM features
because they're distributing the (GPL) operating system. And there's a
collective action problem which makes each device manufacturer less
likely to be the first ones to put a TPM in their device -- it will cost
money, but will provide no benefit until a critical mass of people have
one.
Also, the DRM people have to trust the operating system manufacturer.
Why can't they make a deal with them? After all, the features they need
are not themselves DRM. Well, "recommended or principle context of use"
probably doesn't stop this. But there's got to be some language we can
write that prevents collusion. If someone perverts a signature, fine --
we can't stop that. But so long as any party can unilaterally defect at
no cost, I think the license can help fight DRM.
More information about the Committee-D
mailing list