After quite a bit of delving into the US export requirements for
encryption-related software, I have found that we are able to
distribute 100% open source packages with identifiable source code
to anyone not in the banned set of countries. However,
a) we have to file export notices prior to each release in which
the crypto capabilities are changed;
b) we have to file export notices prior to publishing each binary
package that includes mod_ssl and the notice must include a
URL to the 100% open source version of that package;
c) each redistributor (re-exporter) of our packages must do the same
[I am unsure if that means every mirror is supposed to file as
well,
but for now I am guessing that they don't];
d) we can only distribute binary versions of openssl if we can point
to the 100% open source package from which it was built *and*
file an export notice for that package prior to our publication;
e) people who are in the banned set of countries and people in
countries that forbid encryption cannot legally download the
current httpd-2 packages because they include mod_ssl even when
it won't be used.
Given those constraints, I would prefer to separate the httpd releases
into a non-crypto package and a crypto overlay, similar to what most
of the packaging redistributors do (fink, apt, etc.).
I think the best way to accomplish that is to separate mod_ssl into
a subproject that is capable of producing overlay releases for each
release of httpd. In other words, each package would depend on an
installed instance of httpd and (depending on platform) install
mod_ssl on top along with, optionally, a specific version of openssl.
We can then limit our crypto export notices to releases of the ssl
code (where we are much more likely to remember the export process).
Thoughts? Anyone have any better ideas?
....Roy
