You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "Roy T. Fielding" <fi...@gbiv.com> on 2006/07/01 00:26:20 UTC
Re: Proposed Crypto Notification process
On Jun 30, 2006, at 5:37 AM, Justin Erenkrantz wrote:
> On 6/30/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> Nope. We don't ship OpenSSL the product, we ship APR-util the
>> product which
>> happens to link to OpenSSL, and therefore, ***APR.apache.org/
>> crypto.html***
>> resolves to www.apache.org, and openssl.org/sources. APR-util is
>> the product
>> that creates a dependency/binding to openssl.
>
> Once again, incorrect. We have to notify BIS that we are distributing
> source code from a third-party product. Therefore, the BIS guidelines
> state that we have to notify that we are distributing OpenSSL (as part
> of our binaries).
Please, let's not have this discussion again on APR when it has already
been resolved for httpd. We just have to follow through with the docs.
I'll do that once I get the other procedural documentation crap off
my plate (OpenSolaris).
We do not distribute OpenSSL because it contains software that we
cannot distribute for reasons unrelated to export control.
We must notify the BIS for each distinct product that we distribute that
is under 5D002 export control for which we qualify for the TSU
exception by
providing the complete source code along with that product.
Including an OpenSSL binary within another package does not create
a separate project -- it only creates an obligation to provide the
source
with that product, which is kind of hard because OpenSSL cannot be
distributed by us in the form that is supplied by openssl.org.
That is why we don't distribute OpenSSL.
> Once again, this is false. OpenSSL is its own independent project and
> we are shipping its libraries. Therefore, we need to do two separate
> notifications: one for APR-util and one for OpenSSL. -- justin
APR-util is not shipping OpenSSL. In any case, we would only need
to do separate notifications if we distributed OpenSSL as a stand-alone
product with its own packaging.
....Roy
Re: Proposed Crypto Notification process
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Cliff Schmidt wrote:
> I've seen my name mentioned a lot in this thread...hopefully the
> "Crypto FAQ" that I just sent to this list will answer most of the
> questions referred to me in this thread. If not, I'll try to get to
> the others.
>
> BTW, I think David Reid's projects RDF idea is a great one. I'll try
> to follow up on his legal-discuss thread tomorrow.
+++1. If David can describe what the resulting project-html page can be named,
e.g. {tlp}.a.o/export.html then there is no reason to freeze activity or put
off notification for APR-util. We'll just manually generate the information
(or use a manual pass at the .rdf source from David's sample) initially and
pursue the automation as we move forward.
I do want to notify in such a way that any BIS reviewer would not have to dig
through several dozen projects to secure the information; per-domain data
gives us the fine grained management, while the rdf collection at p.a.o/ would
provide the high level summary. Win-win. Thanks for spearheading this David!
Bill
Re: Proposed Crypto Notification process
Posted by Cliff Schmidt <cl...@gmail.com>.
I've seen my name mentioned a lot in this thread...hopefully the
"Crypto FAQ" that I just sent to this list will answer most of the
questions referred to me in this thread. If not, I'll try to get to
the others.
BTW, I think David Reid's projects RDF idea is a great one. I'll try
to follow up on his legal-discuss thread tomorrow.
Cliff
On 7/4/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 7/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > 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?
>
> I'm going to jump in here just to ensure that the rationale for my
> current viewpoint is clear and - hopefully - can either be confirmed
> or debunked.
>
> My interpretation from Cliff is that OpenSSL is its own product and
> that we have to perform notification for it since our product (be it
> APR or HTTP Server) uses this other product that has crypto
> functionalities. We can include the BIS notice for OpenSSL in the one
> email we send along with our notification.
>
> Likewise, the issue, as I understood it, was that *all* downstream APR
> developers (Subversion, log4j, etc.) will now have to notify BIS about
> their own products whenever they release as they now have a dependency
> upon BIS-notifiable code. Hence, they have to notify BIS about their
> own projects and APR-util and OpenSSL now too. Yikes.
>
> Of course, Cliff can (should!) reply too - but that's the impression I
> got from him when talking about this during ApacheCon. This is why I
> mentioned in my earlier email that we'll need to notify regarding
> OpenSSL too and why our downstream devs will have to do likewise. I'd
> *really* love to be wrong on this - so that we don't have to notify
> for OpenSSL and that other projects don't have to notify for APR too;
> but Cliff seemed pretty clear on this.
>
> *shrug* -- justin
>
Re: Proposed Crypto Notification process
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Cliff;
I realize you've done your best to create crystal clear answers to Justin's
and my questions below at the http://www.apache.org/dev/crypto.html page.
But your followup to this post would be most valuable so we can close this
cycle and complete our notification. Call this a final sanity check ;)
----
William A. Rowe, Jr. wrote:
> Justin Erenkrantz wrote:
>> On 7/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>>> 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?
>>
>> My interpretation from Cliff is that OpenSSL is its own product and
>> that we have to perform notification for it since our product (be it
>> APR or HTTP Server) uses this other product that has crypto
>> functionalities. We can include the BIS notice for OpenSSL in the one
>> email we send along with our notification.
>
> That's the question, isn't it? Do we include OpenSSL in our BIS notice for
> our "APR-util" product? Or send a BIS notice for "OpenSSL". Since we don't
> produce the "OpenSSL" product, and I don't see us offering an "OpenSSL"
> download (only that there would be an openssl binary on some platforms that
> don't ship openssl as part of their base installation), I don't expect the
> later makes any sense. This is after I read Roy's comments on the "product"
> orientation for the regulations, and then heard Cliff's comments on how the
> BIS views a "product" and how they view the relationship of components
> (short answer; show us all the code, wherever it resides, in one notice, and
> then you can keep releasing it and distributing binaries of it.)
>
>> Likewise, the issue, as I understood it, was that *all* downstream APR
>> developers (Subversion, log4j, etc.) will now have to notify BIS about
>> their own products whenever they release as they now have a dependency
>> upon BIS-notifiable code. Hence, they have to notify BIS about their
>> own projects and APR-util and OpenSSL now too. Yikes.
>
> Right, so does svn provide four notices, of the "OpenSSL product", the
> "APR-util product", the "httpd product", and the "svn product"?
>
> No... that would be asinine ;-) The send a single notice for the svn product
> once, that points to the dev trunk of svn (where all new crypto is first
> introduced) and pointers to the dist trees of httpd, apr-util (as this is
> increasingly unbundled from httpd) and OpenSSL.
>
> When a project ships on a dependency of another project, the dist tree seems
> so much more sane. (They only distribute a 'shipped' version of the dependent
> libraries they require). But the moment new crypto code hits, it should be at
> the location that BIS was told of (dev trunk/).
>
>> Of course, Cliff can (should!) reply too - but that's the impression I
>> got from him when talking about this during ApacheCon. This is why I
>> mentioned in my earlier email that we'll need to notify regarding
>> OpenSSL too and why our downstream devs will have to do likewise. I'd
>> *really* love to be wrong on this - so that we don't have to notify
>> for OpenSSL and that other projects don't have to notify for APR too;
>> but Cliff seemed pretty clear on this.
>
> +1 Yup - let's pause for his comments.
>
> Cliff made it clear our notification includes OpenSSL. We've
> interpreted him differently on how ;)
I'll rephrase this; our notification includes OpenSSL only if we ship OpenSSL,
e.g. complete binary packages (we expect we would do this down the road.)
Likewise downstream users will be required to notify about apr-util, OpenSSL,
mod_ssl and httpd only if they ship a complete binary stack (as some of our
windows 3rd party friends already do, fortunately for their headaches, they
do so from Canada and elsewhere.)
But an external 'httpd module' type of project wouldn't have to notify
of httpd/mod_ssl/apr_util/OpenSSL unless they ship that whole stack for
their own binary distribution. But if their code uses the https:// feature
of httpd, or the apr_ssl_socket feature of apr-util, their own code becomes
crypto-enabled, and therefore subject to notification requirements. Right?
Re: Proposed Crypto Notification process
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
[ping]
Cliff;
I realize you've done your best to create crystal clear answers to Justin's
and my questions below at the http://www.apache.org/dev/crypto.html page.
But your followup to this post would be most valuable so we can close this
cycle and complete our notification. Call this a final sanity check ;)
----
William A. Rowe, Jr. wrote:
> Justin Erenkrantz wrote:
>> On 7/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>>> 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?
>>
>> My interpretation from Cliff is that OpenSSL is its own product and
>> that we have to perform notification for it since our product (be it
>> APR or HTTP Server) uses this other product that has crypto
>> functionalities. We can include the BIS notice for OpenSSL in the one
>> email we send along with our notification.
>
> That's the question, isn't it? Do we include OpenSSL in our BIS notice for
> our "APR-util" product? Or send a BIS notice for "OpenSSL". Since we don't
> produce the "OpenSSL" product, and I don't see us offering an "OpenSSL"
> download (only that there would be an openssl binary on some platforms that
> don't ship openssl as part of their base installation), I don't expect the
> later makes any sense. This is after I read Roy's comments on the "product"
> orientation for the regulations, and then heard Cliff's comments on how the
> BIS views a "product" and how they view the relationship of components
> (short answer; show us all the code, wherever it resides, in one notice, and
> then you can keep releasing it and distributing binaries of it.)
>
>> Likewise, the issue, as I understood it, was that *all* downstream APR
>> developers (Subversion, log4j, etc.) will now have to notify BIS about
>> their own products whenever they release as they now have a dependency
>> upon BIS-notifiable code. Hence, they have to notify BIS about their
>> own projects and APR-util and OpenSSL now too. Yikes.
>
> Right, so does svn provide four notices, of the "OpenSSL product", the
> "APR-util product", the "httpd product", and the "svn product"?
>
> No... that would be asinine ;-) The send a single notice for the svn product
> once, that points to the dev trunk of svn (where all new crypto is first
> introduced) and pointers to the dist trees of httpd, apr-util (as this is
> increasingly unbundled from httpd) and OpenSSL.
>
> When a project ships on a dependency of another project, the dist tree seems
> so much more sane. (They only distribute a 'shipped' version of the dependent
> libraries they require). But the moment new crypto code hits, it should be at
> the location that BIS was told of (dev trunk/).
>
>> Of course, Cliff can (should!) reply too - but that's the impression I
>> got from him when talking about this during ApacheCon. This is why I
>> mentioned in my earlier email that we'll need to notify regarding
>> OpenSSL too and why our downstream devs will have to do likewise. I'd
>> *really* love to be wrong on this - so that we don't have to notify
>> for OpenSSL and that other projects don't have to notify for APR too;
>> but Cliff seemed pretty clear on this.
>
> +1 Yup - let's pause for his comments.
>
> Cliff made it clear our notification includes OpenSSL. We've
> interpreted him differently on how ;)
I'll rephrase this; our notification includes OpenSSL only if we ship OpenSSL,
e.g. complete binary packages (we expect we would do this down the road.)
Likewise downstream users will be required to notify about apr-util, OpenSSL,
mod_ssl and httpd only if they ship a complete binary stack (as some of our
windows 3rd party friends already do, fortunately for their headaches, they
do so from Canada and elsewhere.)
But an external 'httpd module' type of project wouldn't have to notify
of httpd/mod_ssl/apr_util/OpenSSL unless they ship that whole stack for
their own binary distribution. But if their code uses the https:// feature
of httpd, or the apr_ssl_socket feature of apr-util, their own code becomes
crypto-enabled, and therefore subject to notification requirements. Right?
Oh, if OpenSSL is truly a stand-alone notification, shouldn't the foundation
simply provide that notice already and be done with it? (Doesn't absolve apr,
httpd, etc of providing notice about their crypto product, of course.)
binaries for apr
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 4, 2006, at 5:54 PM, William A. Rowe, Jr. wrote:
> Roy T. Fielding wrote:
>> I don't see any reason why apr-util would distribute OpenSSL in any
>> form -- it needs to compile against the installed SSL library
>> (perhaps
>> a card) for the same reasons as httpd.
>
> Again - you tout the perspective for an OS which is 'feature complete'
> (e.g., includes the compiler tools.) For OS's which rarely include
> the compiler tools, binaries make sense. There is no reason that the
> APR project might not provide APR, APR-util binaries at some point,
> and
> if that means there's a dependency on libcrypto.so/libssl.so, then
> perhaps
> those two dependent files as well with appropriate notification.
>
> FWIW, we have had requests for apr binaries. Nobody's quite
> bothered yet
> since in the 0.9 family we really didn't expect people to install
> 'apr'.
> With 1.x we transition to an 'installed apr' model. Perhaps by
> 2.0, we
> will genuinely expect folks to obtain apr independent of the
> application
> they are installing.
I have no doubt that apr will be distributing its own binary packages
soon.
However, I think we need a more intelligent design than "compile
every possible library and bundle with the distribution." Shared
libraries should not include independent shared libraries. Instead,
the installation process can be made such that it late binds with
whatever has already been installed. Someone installing APR is capable
of following an instruction that says "No SSL library detected; you
must install one first, perhaps from one of the following locations ..."
The same will need to be done for all the DB options anyway.
....Roy
Re: Proposed Crypto Notification process
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
>
> I don't see any reason why apr-util would distribute OpenSSL in any
> form -- it needs to compile against the installed SSL library (perhaps
> a card) for the same reasons as httpd.
Again - you tout the perspective for an OS which is 'feature complete'
(e.g., includes the compiler tools.) For OS's which rarely include
the compiler tools, binaries make sense. There is no reason that the
APR project might not provide APR, APR-util binaries at some point, and
if that means there's a dependency on libcrypto.so/libssl.so, then perhaps
those two dependent files as well with appropriate notification.
FWIW, we have had requests for apr binaries. Nobody's quite bothered yet
since in the 0.9 family we really didn't expect people to install 'apr'.
With 1.x we transition to an 'installed apr' model. Perhaps by 2.0, we
will genuinely expect folks to obtain apr independent of the application
they are installing.
I'm mostly responding so that Cliff's aware that several alternatives exist.
> I think we are going in circles, largely because the wrong questions
> are being asked. We do not distribute OpenSSL *today*. If we *do*
> decide to distribute OpenSSL, then we need to file a notice for
> OpenSSL and point people to openssl.org in that notice.
I agree with you 90%. The 10% is that pointing the product's notice that
ships openssl for that dependency can simply land in our ASF-product notice.
I think Justin's and my ping pong which just landed on Cliff's side of the
table should resolve this.
> Regardless, we also have to file a notice for httpd and another for apr-util.
Yes
> All of that has to wait until we have sufficient documentation in
> place, namely a "/licenses/export.html" page that includes the
> destination disclaimers and table of exported products/ECCN/source-link,
Yes
> and then a sources page for each project that describes the contents
> per version released.
Well, once a {tlp}.a.o/licenses/export.html exists, the master reference
of projects.a.o/licenses/export.html would bring this all full circle. No
cart before the horse puzzle, the master collection can happen after APR-util
closes their notification requirement.
Re: Proposed Crypto Notification process
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
I am quite certain that the regulation is one notice per type of package
we export (product name x crypto capabilities). What is unclear is the
meaning of the "link to sources" within that notice. I think it is
sufficient for the link to httpd's "sources" to include a link to
OpenSSL's sources page as one example of an SSL library, since the
source
dependency of mod_ssl on "any SSL library" is how we became 5D002
classified. Telling BIS that httpd "includes" OpenSSL would be false.
I don't see any reason why apr-util would distribute OpenSSL in any
form -- it needs to compile against the installed SSL library (perhaps
a card) for the same reasons as httpd. Assuming that will be the case,
apr-util's notice requirements will be the same as httpd.
I think we are going in circles, largely because the wrong questions
are being asked. We do not distribute OpenSSL *today*. If we *do*
decide to distribute OpenSSL, then we need to file a notice for
OpenSSL and point people to openssl.org in that notice. Regardless,
we also have to file a notice for httpd and another for apr-util.
All of that has to wait until we have sufficient documentation in
place, namely a "/licenses/export.html" page that includes the
destination disclaimers and table of exported products/ECCN/source-link,
and then a sources page for each project that describes the contents
per version released.
....Roy
Re: Proposed Crypto Notification process
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On 7/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> 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?
>
> My interpretation from Cliff is that OpenSSL is its own product and
> that we have to perform notification for it since our product (be it
> APR or HTTP Server) uses this other product that has crypto
> functionalities. We can include the BIS notice for OpenSSL in the one
> email we send along with our notification.
That's the question, isn't it? Do we include OpenSSL in our BIS notice for
our "APR-util" product? Or send a BIS notice for "OpenSSL". Since we don't
produce the "OpenSSL" product, and I don't see us offering an "OpenSSL"
download (only that there would be an openssl binary on some platforms that
don't ship openssl as part of their base installation), I don't expect the
later makes any sense. This is after I read Roy's comments on the "product"
orientation for the regulations, and then heard Cliff's comments on how the
BIS views a "product" and how they view the relationship of components
(short answer; show us all the code, wherever it resides, in one notice, and
then you can keep releasing it and distributing binaries of it.)
> Likewise, the issue, as I understood it, was that *all* downstream APR
> developers (Subversion, log4j, etc.) will now have to notify BIS about
> their own products whenever they release as they now have a dependency
> upon BIS-notifiable code. Hence, they have to notify BIS about their
> own projects and APR-util and OpenSSL now too. Yikes.
Right, so does svn provide four notices, of the "OpenSSL product", the
"APR-util product", the "httpd product", and the "svn product"?
No... that would be asinine ;-) The send a single notice for the svn product
once, that points to the dev trunk of svn (where all new crypto is first
introduced) and pointers to the dist trees of httpd, apr-util (as this is
increasingly unbundled from httpd) and OpenSSL.
When a project ships on a dependency of another project, the dist tree seems
so much more sane. (They only distribute a 'shipped' version of the dependent
libraries they require). But the moment new crypto code hits, it should be at
the location that BIS was told of (dev trunk/).
> Of course, Cliff can (should!) reply too - but that's the impression I
> got from him when talking about this during ApacheCon. This is why I
> mentioned in my earlier email that we'll need to notify regarding
> OpenSSL too and why our downstream devs will have to do likewise. I'd
> *really* love to be wrong on this - so that we don't have to notify
> for OpenSSL and that other projects don't have to notify for APR too;
> but Cliff seemed pretty clear on this.
+1 Yup - let's pause for his comments.
Cliff made it clear our notification includes OpenSSL. We've interpreted him
differently on how ;)
Re: Proposed Crypto Notification process
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 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?
I'm going to jump in here just to ensure that the rationale for my
current viewpoint is clear and - hopefully - can either be confirmed
or debunked.
My interpretation from Cliff is that OpenSSL is its own product and
that we have to perform notification for it since our product (be it
APR or HTTP Server) uses this other product that has crypto
functionalities. We can include the BIS notice for OpenSSL in the one
email we send along with our notification.
Likewise, the issue, as I understood it, was that *all* downstream APR
developers (Subversion, log4j, etc.) will now have to notify BIS about
their own products whenever they release as they now have a dependency
upon BIS-notifiable code. Hence, they have to notify BIS about their
own projects and APR-util and OpenSSL now too. Yikes.
Of course, Cliff can (should!) reply too - but that's the impression I
got from him when talking about this during ApacheCon. This is why I
mentioned in my earlier email that we'll need to notify regarding
OpenSSL too and why our downstream devs will have to do likewise. I'd
*really* love to be wrong on this - so that we don't have to notify
for OpenSSL and that other projects don't have to notify for APR too;
but Cliff seemed pretty clear on this.
*shrug* -- justin
Re: Proposed Crypto Notification process
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
> On Jun 30, 2006, at 11:47 PM, Justin Erenkrantz wrote:
>
>> On 6/30/06, Roy T. Fielding <fi...@gbiv.com> 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?
Re: Proposed Crypto Notification process
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/1/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> 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.
> That means we have to distribute the modified OpenSSL library as
> something
> else *not* called OpenSSL (because otherwise we are violating the
> OpenSSL
> license). In any case, none of our users want a modified OpenSSL --
> they
> can download the real thing on their own. What we should be
> redistributing
> is a post-install DLL relinking tool so that they can link our windows
> binary with whatever they install for SSL, but I have no idea how.
Well, removing the patent encumbered bits is just a configure flag to OpenSSL.
http://www.openssl.org/support/faq.html#LEGAL1
So, it doesn't require any code changes to the OpenSSL library itself
- just how we'd build it. So, I don't see how that'd violate
OpenSSL's license... -- justin
Re: Proposed Crypto Notification process
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jun 30, 2006, at 11:47 PM, Justin Erenkrantz wrote:
> On 6/30/06, Roy T. Fielding <fi...@gbiv.com> 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. I know
> that the Win32 binaries will certainly be including the appropriate
> OpenSSL DLLs. I think what OtherBill's plan was to remove the
> patent-encumbered code from our OpenSSL builds we do - at least on
> Win32. I'd expect the same for other platforms as well - especially
> since OpenSSL is usually bundled as a static library not a dynamic
> library. (Some platforms ship it as a DSO, but that's only relatively
> recently.)
>
> 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.
That means we have to distribute the modified OpenSSL library as
something
else *not* called OpenSSL (because otherwise we are violating the
OpenSSL
license). In any case, none of our users want a modified OpenSSL --
they
can download the real thing on their own. What we should be
redistributing
is a post-install DLL relinking tool so that they can link our windows
binary with whatever they install for SSL, but I have no idea how.
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. 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.
....Roy
Re: Proposed Crypto Notification process
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 6/30/06, Roy T. Fielding <fi...@gbiv.com> 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. I know
that the Win32 binaries will certainly be including the appropriate
OpenSSL DLLs. I think what OtherBill's plan was to remove the
patent-encumbered code from our OpenSSL builds we do - at least on
Win32. I'd expect the same for other platforms as well - especially
since OpenSSL is usually bundled as a static library not a dynamic
library. (Some platforms ship it as a DSO, but that's only relatively
recently.)
Therefore, as Cliff indicated to us, we'll likely have to notify for
OpenSSL. -- justin