1998-10-14 - overlapping aims – cypherpunks/FSF (Re: Two? ways people could use your code)

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: rms@gnu.org
Message Hash: 01e218489c1627a896a12a279909b5d779cddf25fe3bae5fd721b9cf473032cc
Message ID: <199810141057.LAA28762@server.eternity.org>
Reply To: <199810140046.UAA06980@psilocin.gnu.org>
UTC Datetime: 1998-10-14 11:36:35 UTC
Raw Date: Wed, 14 Oct 1998 19:36:35 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Wed, 14 Oct 1998 19:36:35 +0800
To: rms@gnu.org
Subject: overlapping aims -- cypherpunks/FSF (Re: Two? ways people could use your code)
In-Reply-To: <199810140046.UAA06980@psilocin.gnu.org>
Message-ID: <199810141057.LAA28762@server.eternity.org>
MIME-Version: 1.0
Content-Type: text/plain




Richard Stallman writes:
> There are actually three classes of possible projects that might use
> code you have written:
> 
> * Those who want to make a free program.
> * Those who want to make a proprietary program.
> * Those who don't have strong views about the matter.
> 
> So let's look at each of these three cases, considering two available
> choices (copylefting, or not copylefting), and how the decision
> affects the goals of encouraging use of encryption, discouraging back
> doors, and encouraging users' freedom.

I see this as a two separate, overlapping aims thing.

Aim 1, get lots of crypto out there, quality a secondary issue.

Motivation: try to ensure enough people use and know about crypto, so
that enough people understand how objectionable it is when governments
try to outlaw crypto.  Of course encourage use of strong crypto,
published, unpatented algorithms, and published source code where this
doesn't interfere with deployment.

Aim 2, try to encourage people to publish all source code.

Motivation: to give end-users more flexibility, and more freedom to do
what they want and change as they want the software they use.  I use
almost exclusively linux myself by choice.

> * Often at companies, and sometimes at universities, people are dead
>   set on making a proprietary program.  This program may be capable of
>   doing a job, but its users will not have freedom, and they will have
>   to take it on faith that there are no backdoors.
> 
>   Copylefting your code says this project cannot use it.  Most likely,
>   the project will spend some extra money to write their own code, and
>   the outcome for the public will be much the same.  They might do a
>   worse job, or a better job.  There's some chance they would not do
>   the project; whether that is a loss for the public is not clear.  

Most deployed crypto is commercial, most used software is commercial.
(Insert proprietary instead of commercial if this makes it clearer
what I mean).

Therefore it seems to me that successes in getting crypto put in
commercial software which would not otherwise be there are important.

Your average linux/unix/GNU hacker is well above average in technical
competence, and can look after himself.  He can get the source for
pgp, check it to some extent, and understand the issues.  He is not
the target for the deployment.

The target for deployment is the mass market end-user (think windows95
users).  At present it is a statement of reality that most end-users
are using windows95.

>   It could mean less use of encryption; but if you also care about
>   avoiding secret back doors, and about users' freedom, you won't
>   see this as an unambiguous loss.

Surreptitious company inserted unpublished back doors are rare I
think, much more likely is crypto-incompetence leading to
unintentional weakness.  Cypherpunks also have had some successes in
cracking weak systems as a way to encourage the vendors to fix the
problems.  Encouraging open source, and published protocols,
especially for crypto components is a good idea as it encourages peer
review.

> * Often at universities, and sometimes at companies, people decide to
>   write a program but don't think about whether to make it free
>   software.  They may not care, they may dislike thinking about the
>   issue, they may simply not understand that there is an issue.
> 
>   In these cases, they will probably judge your code by its features,
>   not by its distribution terms.  If they want to use your code, and
>   your terms say that's permitted only if their program is free,
>   they'll say, "Ok, I'll make it free, and use your code."
> 
>   In this kind of case, using copyleft will produce a benefit: more
>   freedom for the end user, who can check, rather than trust, that
>   there are no back doors in the program.

Agree.

> Conclusion: if you care *only* about more use of encryption, and
> *absolutely not* about secret back doors or users' freedom, then you
> would find it a better strategy not to copyleft.

The secret doors we are concerned to fight against are being
engineered by governments.  Usually they are out in the open (clipper,
KRAP, etc).

> But if you care about encouraging use of encryption, about
> discouraging back doors, and about freedom for software users,
> copyleft (such as the GNU GPL) is a good way of promoting all of these
> goals together.

GNU GPL not a bad way to further these two goals simultaneously, but I
think BSD (or I think you say that X11 license is better) is better
for the purpose.

Or GNU LGPL (Library GPL) I think is a good compromise position: it
allows use in proprietary software without requiring the rest of the
code to be GNU GPLed, and it encourages free access to the crypto
portion (if we are talking about crypto libraries and tools).

Would you be interested in publishing GNUPG, and other GNU crypto
utilities and libraries under GNU LGPL?  And adopting this for crypto
code as a general GNU strategy?  There are other libraries, so it
should qualify.  (Tom Zerucha wrote a OpenPGP implementation using
SSLeay, and I think said he would public domain his software).

Adam
-- 
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`





Thread