No Subject

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

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.

Yes, exactly.  To uphold freedom for all users is right; to impose
your specific preferences on users who want to do something else is
wrong, because it takes away their freedom.

I don't like back doors, but I support users' freedom to install back
doors, for the same reason I support your freedom of speech even when
you say things I don't like.  The crucial thing is that each user
should be free to choose for perself; we must avoid giving a person,
company or government the power to choose for others.

The GNU GPL insists that everyone have the freedom to (1) see what is
inside the software they use, and (2) change it if they don't like it.

When everyone has this freedom, they can reject back doors, if they
want to.  If an otherwise-useful program has a back door, people can
tell.  (Most users would not have the training to recognize one, but
someone will spot it, and will warn the public.)  They can also remove
the back door "feature", and distribute a modified version which has
the same useful features but no back door.

If instead you make a requirement of "no government back doors", but
you permit proprietary versions whose source code is secret, what will
be the result?  If the person who makes a proprietary version obeys
your terms, it will have no government back door, but it might contain
something else bad, and no one could tell, including you.

What if someone makes a proprietary version and adds a back door?
That would violate your terms, but would you know?  Let's suppose you
do know that your code was used, either because person says so or
because you figure it out.  That does not enable you to tell that the
back door was added.  Thus, as a practical matter, you cannot enforce
this requirement the way you can enforce the GNU GPL.  (Once you know
your code was used, a violation of the GPL is blatantly obvious.)

Looking at the issue in a broader context, companies have the
resources to avoid using your code.  No matter how useful your package
may be, they can write other code to do the same job.

If you convince the users that government back doors are a bad thing,
but they think that proprietary (non-free) programs are ok, they will
always have to take it on trust that a given proprietary software
product has no back doors.  To be sure, if the product includes your
code, any back door would violate your terms (if only you knew about
it); but users will see no reason to insist on a product that uses
your code.  They may just as well choose a product that uses some
other implementation of the same feature, and that alternative
implementation may not have any prohibition on adding a back door.

If instead we convince the users that non-free software is a bad
thing, or even only that non-free crypto software is a bad thing, that
does the job much more thoroughly.  They may still choose a product
that uses some other implementation instead of your code, but if that
product is free software, they will be able to check its source for
back doors just the same.

The best way for the users to avoid *any* particular hidden misfeature
in software is to insist on using only free software.