incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Schmidt" <>
Subject Re: podling BIS notifications
Date Wed, 21 Feb 2007 06:55:50 GMT
On 2/20/07, Roy T. Fielding <> wrote:
> 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.

+1 to everything above -- although, rather than saying a later notice
needs to be sent out when the encryption functionality changes, I'd
put it as, "a later notice needs to be sent when any information on
the prior notice has changed"...but this would typically only be the
case for changes in manufacturer to some included crypto component.

> 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

No -- the BIS folks consider open source development in between
releases to be the same as beta releases.  There is a separate license
just for betas, but the TSU one is simpler.  This is why we send the
TSU notification prior to starting to commit encryption code to SVN.
This is also covered in the FAQs:

If any of these FAQs could be more clear, let me know.

> 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.

...although, speaking of the exports page, I noticed that there is now
software with an ECCN of "EAR99".  I'm not aware of any software we
distribute at Apache that meets this category.  Can anyone tell me
what the rationale is for this?

> 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.

We've had a bunch of notices sent from other projects sent over the
last 9 months or so, but no BIS audits.  Hearing stories from them
about their typical audits, I'd be shocked if they ever thought it was
worth their time to audit us.  I suppose they might ping us if our
email notification link was broken or there was some info just missing
in the email.


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

View raw message