Roy T. Fielding wrote:
On Jun 30, 2006, at 11:47 PM, Justin Erenkrantz wrote:
On 6/30/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
We do not distribute OpenSSL because it contains software that we
cannot distribute for reasons unrelated to export control.
I think we will end up distributing OpenSSL with our binaries.
Therefore, as Cliff indicated to us, we'll likely have to notify for
OpenSSL. -- justin
If we remove the patent-encumbered code from OpenSSL, then it isn't
OpenSSL and we cannot distribute it or anything built from it under
the TSU exception without distributing the source code exactly as built.
As others mentioned, no-idea, no-mdc2 and no-rc5 are OpenSSL's own configure
flags. I can't see how this would change our OpenSSL "sources".
As far as the source code, we have to notify that OpenSSL is used in the very
broadest sense. The fact that we might distribute a binary with these flags
(here in the US) doesn't impact the case that end users can include any subset
or the entire scope of OpenSSL. Binaries are irrelevant to the discussion.
We don't notify the OpenSSL "Product" unless that's the finished "Product" that
we ship. This is where the BIS doesn't think like software developers, they
think in terms of a specific export. And I don't forsee us providing any
download of OpenSSL-0.9.x.zip or .tgz. Only the source code of apr-util and
some binaries which are the collective Product, "apr-util" in this case.
The proposed crypto.html (or export.html) page would collect the details of
what we must *notify* the BIS of. Under TSU, we don't notify them of binaries,
we notify them of the Open Source Code "Product". Because our product would
now include OpenSSL cryptography consumed by the APR-util API, we must notify
them that the "Product" APR-util includes cryptography through our API which
is implemented using OpenSSL <pointer to source code>.
So yes - we notify them of the openssl source in the context of the "Product".
And we amend the notification source code page once apr-util consumes another
open source crypto lib. [Cliff...] This gets slightly more complex if the
crypto provider we consume is -not- open source, but is a closed-system resource
such as at the socket stack layer, or a hardware crypto product, or whatever.
[?]
We have to understand that these regulations were not written for
software developers. They were written for people inspecting crates
for things that blow people up. The notice is for *our* product and
we are only allowed to export *our* product if the entire product is
available in source form at a single location where a customs inspector
can choose to examine its totality for tiny little terrorists hidden
between the 1s and 0s.
Bingo, and to take your comment one step further, these reviewers are not
partial to a single .tgz or other method of distribution. They prefer one
pointer to the "source". That is not the same thing as putting every file
in a tarball. It means that from one authoritative page, here are the complete
sources of our Product. My proposed page gives explicit direction for them
to the trunk/ of our development, and the tarballs of external projects, that
constitute the "APR-util" product.
As dumb as it sounds, those are the rules.
The number of different identifiable products existing within a
single package is completely irrelevant to BIS -- we have to file a
notice for each type of package, not each thing within the package.
That's my question... Cliff? Is OpenSSL, in the context of being one component
of the APR-util "product", or the Apache HTTP Server "product", its own,
independent "product" that apr or httpd pmc's should be notifing the BIS of
on its own?
