[Top][All Lists]

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

Re: awareness + flexibility + security

From: Bas Wijnen
Subject: Re: awareness + flexibility + security
Date: Thu, 10 Nov 2005 19:02:37 +0100
User-agent: Mutt/1.5.11

On Thu, Nov 10, 2005 at 11:59:20AM -0500, Jonathan S. Shapiro wrote:
> 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.

Ok, perhaps it wasn't clear.  I wasn't trying to say it had one harmful use.
I was trying to say it had only harmful uses.

What does this chip do?  It allows people to check that a remote computer is
running unchanged code.  In other words, it allows people to restrict changing
of code ("if you change your code, you cannot use my service").  I do not see
any other use of the chip.

Now in a case like ATM machines, this may be acceptable.  But it isn't
acceptable for GNU.  The whole reason GNU was started was to prevent this and
to allow people to change the code they use.

> 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.

No, these have good uses as well (ok, birth maybe not, so we should forbid
that ;-) ).  I do not see any use of support for those chips in Hurd other
than preventing people to make derivative works.

> 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.

No no, this isn't about copying music, it's about making modifications to
software.  I also think that DRM is a very bad idea, but that's not what I was
trying to state.

> 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!

The FSF has a cery clear policy with respect to LGPL (which I suppose you mean
by "removing the restriction"): If making a piece of code GPL would only
result in lower popularity, because there is a non-free alternative which is
about as good and which people will use to restrict their user's freedoms
anyway, then and only then should software be released under the LGPL.  You
seem to suggest that this is a move towards unfreeness for the FSF.  I do not
agree with that.

> 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.

I agree, but only if the technology has uses which we want to support.  I
don't think this is the case here.

However, if I'm wrong about this, and there are acceptable uses, we need to
think deeply about it, as Marcus said.  If you have candidates, please let us

As for Marcus' remark that we may reconsider adding all the security, this is
something to discuss.  I think it would be good to include all the people he
mentions in the discussion.  At the moment I agree with Jonathan that removing
support because it just has one harmful use is not a good idea.


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see

Attachment: signature.asc
Description: Digital signature

reply via email to

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