Sameer Parekh writes:
> That's true. But consider the steps RSA went through in order
> to get a BXA statement that BSAFE SSL-C was not covered by US export
> restrictions. They had to prove to the US government that all bits in
> their product were of non-US origin. All questionable bits either had
> to be justified or rewritten. The less questionable material there is
> in OpenSSL, the more easily it can be used by more parties.
This may have been hashed out before I got CC'ed, but I don't see how
this applies to the OpenSSL code in the least. At the worst, by
incorporating bits from US citizens into OpenSSL, the contributing
US citizens are violating ITAR and can be prosecuted. How and why does
that affect OpenSSL? OpenSSL is not affected by US export laws. Even
if all the code in OpenSSL is of non-US origin, it still cannot be legally
re-exported from the US once it enters without US government approval.
If you take a FSF paranoia approach, for any bit of code that is
incorporated into the project, you need to have a signed document that
attests to the fact that the contributor didn't steal the cod in question
and it was his own work. If you start with an existing body of work where
these rules did not previously apply, then the entire package is can be
called into question and you should just start recoding. While I know
the great majority of code in SSLeay was written by Eric Young, there are
enough small pieces contributed by others that some piece may have been
stolen or sent unauthorized by someone on company time. You can worry
about issues like this forever, or you can just get a package out and let
the contributors worry about the consequences.
- Gordon
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
