[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.
What if we set up a Linux machine in a free country like Ireland, and build the distribution there by Telnet? Over Telnet we'd instruct this machine to fetch the crypto code from Australia. The download URLs at http://www.erights.org would then point at this machine. The normal argument against Telnet-oriented export workarounds doesn't apply, because no crypto expertise is coming from the US keystrokes.
Does anyone see any problems with this scenario?
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.)
If it's not secure, it may look like E, but it isn't E.