l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: awareness + flexibility + security


From: Jonathan S. Shapiro
Subject: Re: awareness + flexibility + security
Date: Thu, 10 Nov 2005 11:59:20 -0500

On Thu, 2005-11-10 at 16:40 +0100, Bas Wijnen wrote:
> At least me and Antrik have used [the GNU Freedom Principles] to
> reject supporting the TC chips.

Nonsense. You and Antrik have made an argument of the form:

  A particular feature has one harmful use, so we should remove the
  feature without regard to its benefits.

If we accept that this argument is structurally sound, then we must also
reject

  money -- because it can be used to purchase items that are both
           illegal and actually harmful.

  birth -- because some fraction of humans commit murder or other
           terrible crimes.

So far, you have presented an argument (to me, an unconvincing argument)
that DRM is bad. Ultimately, this argument is based on an axiom: that
the right to copy bits is an unalienable right. I do not share this
view, but I do understand it, and since Hurd is an FSF project this is a
fine idea for Hurd to test and integrate into its work.

However, even if I *accept* this view, it does not follow that the
TPM/TCPA chip should be rejected.

Not even FSF goes so far. For example, there is no requirement that GCC
can only be used to build free software. In a couple of other cases,
attempts *were* made to impose this restriction on the use of FSF tools.
The community has consistently rejected this stance -- to the degree
that the copyrights on various bits of runtime and library code were
modified to *remove* this restriction!

DRM is the same way. We should not implement, support, or encourage DRM.
In fact, we should *discourage* it. However, the possibility that a
third party might use a general-use core technology to implement DRM is
not a reason to blindly reject the core technology. If we adopt this
logic, we should also refuse to ship GCC, or indeed, Hurd.

shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]