[John & Cindy, I'm cc'ing you in case you'd care to advise us on the
following proposal. If you'd rather not be in this discussion, please
reply-to-all asking that further correspondence drop you from the addressee
list, and my apologies. The ongoing discussion is publicly available as a
CritMail archive at
"http://eros.cis.upenn.edu/~majordomo/e-lang/index.html". Past messages on
this topic are mostly in the mis-named thread "Re: Announcing E v0.7.2
(javadoc & zips still missing)". If you wish, please feel free to respond
privately to me instead. Thanks in advance, --MarkM]

Crypto efforts normally run into export problems when they need to export
crypto code or expertise originating in the US. Doug Barnes's wonderful
phrase "export jobs, not crypto" elegantly summarizes the typical solution,
but one that takes some effort to pull off.

E faces only a much simpler problem, as the relevant crypto code,
expertise, and jobs are already outside US borders -- E gets its crypto
from the Cryptix library in Australia
"http://www.systemics.com/software/cryptix-java/", and we can interface to
it using only the interfaces Javasoft already exports. We only run into a
problem because we bring the code into the US in order to build a
distribution package. The resulting package then has US cooties, and so
cannot be re-exported.

On the controversy of what crypto options E supports, I suggest we set
standards in the normal open-source way:

Anyone is free to start with our code base and modify it into one that
enables insecure protocols, like NONE, ROT13, or Blowfish-56. However,
they *should* not call the result E, and these changes will not be accepted
back into the source tree as distributed by erights.org, though we may be
perfectly happy to point at them with a properly labelled link. (Normally,
one might use trademark to turn the above "should" into a "must", but
single letters cannot be trademarked.)