incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: podling BIS notifications
Date Wed, 21 Feb 2007 05:22:14 GMT
BIS notices have to be made if a product contains encryption
functionality controlled by the EAR's 5D002 classification, or
is specifically designed to make use of a 5D002 classified item
(as would the case if the source code contains calls to OpenSSL
or JCE interfaces), or if any released package contains any other
product that is classified as 5D002 (as it would if the
Bouncy Castle jar was included in a release package).

A conservative read of the EAR would indicate that JXTA depending
on Bouncy Castle makes JXTA 5D002, so if Tuscany is specifically
designed to use JXTA then it would also be 5D002.  (The same sad
fate applies to Apache httpd 2.x modules as well, apparently,
even if they aren't designed to make use of the SSL components.)

Hence, the podling should bring it to the attention of the IPMC
when a release vote is made, and the IPMC chair should be the one
to edit the exports page and send the appropriate message to the
BIS *prior* to the release being published.  Noel can delegate that
if he wants, but whoever has the hat needs to be kept aware of
the situation.  The notice only needs to be sent once per product
when it is first considered for release and later only if the
product's encryption functionality changes.

We don't know exactly where the line needs to be drawn, since
the BIS has been very lenient or very overloaded in the
past and never (to my knowledge) taken us to task for doing
it wrong.  Or maybe we always did it right.  Nevertheless, the EAR
is the law as far as the ASF is concerned, and has to be obeyed
even if we think the law is confusing and pointless.

My guess is that ongoing development of source code bits within
subversion qualifies as an open conference, just like our mailing
lists, and thus not subject to the export controls.  It is only
when the bits appear in functioning product form that the
encryption controls apply (it is the encryption *functionality*
that is controlled, so says the regulations, since everyone knows
that encryption itself is not a secret technology). *shrug*
But being proactive on the notice is always better than being
reactive to government agents.

Note, however, that if anyone commits something like the OpenSSL
or Bouncy Castle source code and/or binaries, which are products
in and of themselves, to the subversion instance, then the PMC
must file an export notice for the subversion area even if no ASF
product has been released yet.  That is because distributing
third-party products from a public web server is the same as
exporting them.  Personally, I think it is wrong for projects to
commit code to subversion unless it is intended to be maintained
as source, but I know that some "real" projects at the ASF are too
lazy to write build scripts and instead use our subversion instance
as a binary distribution medium.

As far as timing goes, the notice should be sent as soon as
it becomes clear that the product will eventually contain code
that is designed for a given 5D002 product (i.e., anything that
uses encryption for purposes other than mere authentication).
Preferably, before that code is committed to subversion.  The real
benefit of having the exports page (aside from answering the FAQ)
is that we now have a single source link to provide to the BIS
that is independent of the product names and release versions,
and so we can easily send the notice once, before any chance of
an export occurs, and not worry about it later.

Note: For those wondering about history, we submitted the
equivalent of BIS notices for the Apache HTTP Server a long time
ago when the ASF first began, and then again when the regulations
changed, and again just last week to make the exports page the
official source link.  AFAIK, we have never received a response
from the BIS or its predecessor, but that may have been handled
by our legal rep.  Cliff has been working on making sure that our
process is officially okay.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message