J Harper wrote: > > > 1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, but > > > for embedded software, especially in the security domain, it's a > > killer. I'm supposed to allow users to modify the software that runs > > on their secure token? And on a small platform where there won't be > > such things as loadable modules, or even process separation, the > > (L)GPL really does become viral. This is, I think, why Red Hat > > releases eCos under a non-GPL (but still open source) license. > > We're aware of these issues. How do other people on the group feel?
I think this applies more generally, but especially for crypto software, because of the legal environment and the complicated usage to which it is often put. Placing any burdens of a non-technical nature on the user is generally a downer. Crypto-newbies are often unsure and under rather intense pressure to get something out. If uncertainties of code licensing issue are added, it can have a marked effect on the results. The general result is a choice between no crypto and poorly done crypto. (Rarely is good crypto done in the first instance.) Opinions differ on this point, but I generally err on the side of recommending less than perfect crypto, which can be repaired later on at a lower cost. It's a lot easier to sell a manager on "replacing poor crypto" when it becomes needed than on "we need to add a crypto layer." For that reason, we (Cryptix) have always placed all our code under a BSD style licence, except a few cases where it has been placed under public domain (AES). Our view has always been, "with crypto, the least barriers the better." In essence, "get it out there" is the mantra. iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]