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. ....Roy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
