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.
participants (2)
-
Anonymous -
Richard Stallman