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

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.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to