From: Anonymous <nobody@replay.com>
Date: Wed, 30 Sep 1998 19:59:42 +0800
To: cypherpunks@cyberpass.net
Subject: No Subject
Message-ID: <199810010100.DAA26700@replay.com>
MIME-Version: 1.0
Content-Type: text/plain



Subject: Re: propose: `cypherpunks license' (and vague ideas for additions)

> I don't want government back doors in any software I use, but this
> kind of restriction is the wrong way to avoid them. The right way is
> through the GNU GPL,

You just pegged my bogometer.

The GNU GPL discourages the sale of proprietary software by prohibiting
anything using code covered by the license from being proprietary, and
that's right.

The proposed Cypherpunks license discourages the distribution of software
with key recovery (= government back doors) by prohibiting anything using
code covered by the license from having key recovery, and that's wrong.

Both these licenses would be trying to promote their propagators' goals
through restrictions on code re-use. However, Cypherpunks and GNU types
don't have exactly the same goals. GNU types consider the availability of
good, non-proprietary software to be paramount, whereas Cypherpunks
generally consider the use of good cryptography in useful applications to
be paramount, whether the code behind it is free or expensive, open-source
or proprietary (although proprietary code often ends up being bad crypto).
Companies will not put good crypto in useful applications if it
necessitates that they all but give up whatever intellectual property
rights they had to other parts -- even non-crypto-related parts -- of the
application, so the GPL is clearly not the best license for to promote
Cypherpunk goals.

On a different tangent, lemme suggest some vague ideas for a few potential
requirements:

Warnings about proprietary code: Authors of products using CPL-covered
code which do not release all source code must either a> clearly
demonstrate that none of the unreleased code can have a negative impact on
security or b> place a message on any marketing materials or documentation
mentioning the product's security features saying "For important warnings
about this product's security, see <url>."

CPL advert: Authors of products using CPL-covered code are required to
include with their copyright information some message like "This product
uses code covered by the Cypherpunk License for its security features. See
<url> for more information." and are requested to include references to
the site in other convenient places. This site, of course, need not be
limited to dry legalese about the license, but may include vivid
descriptions of driftnet wiretaps and other mischief perpetrated by NSA
and friends, cryptopolitical rants, or even tools for building and setting
up various cryptostuff. Note the "may;" lots of stuff requires lots of
work, and so, unless there was sort of backing from a civil-liberties
organization with staff-hours to spare or some miraculous effort of
miracle of organization...how's that secure talk client going?

Strength requirements: By default and taking into account only the
published attacks on the cryptographic primitives used, an average of at
least 2^79 operations must be required for anybody (law-enforcement or
not) to compromise the product's security features. If and only if laws
restrict this software's use or sale, a second version may be created with
lower strength, and the stronger version may operate at lower strength
when necessary for smooth interoperation, provided that the user knows
before sending any information that the connection uses weakened
encryption. The weaker version must be clearly marked as such (i.e.,
"Widget 2.4 Export" vs. "Widget 2.4").

Fact sheet: Authors of products using CPL-covered code are requested but
not required to create a sort of security fact sheet detailing the
technical aspects of the product's security features --

* algorithms and key lengths 
* a precise description of the breadth of the security features
* a description of the threat model used in the design process

-- and issues relating to trust in the product --

* authors of algorithms and code, if available
* the level of openness of the source 
* places to obtain whatever source was released 
* information on any independent analyses of the product's security 
* information on independent verifications of the fact sheet

-- followed by a summary placing this in more practical contexts. I'd
imagine any license including this would also include a form form the fact
sheets and some places to send them.

> which would enable people to check the source code of a modified
> version for anything suspicious.

Note that I'm only on one of the lists; Cc: replies to <nobody@replay.com>. :)