Two? ways people could use your code
People have brought up the argument of the two classes of possible users of a library: those who want to write a free program, and those who want to write a proprietary program. This is a valid approach, but we must consider all the terms in the equation. 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. * Some people believe in free software and will make their additions free no matter what. Whether you use copyleft makes no difference in this kind of case. * 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. 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. * 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. 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. 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.
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`
Would you be interested in publishing GNUPG, and other GNU crypto utilities and libraries under GNU LGPL? We might use the LGPL for some of these libraries. The decision depends on the details of the situation for any particular library, so I don't want to try to decide in advance.
participants (2)
-
Adam Back
-
Richard Stallman