incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: podling BIS notifications
Date Wed, 21 Feb 2007 07:54:33 GMT
What we actually have in svn is a mvn pom which references jxta and  
bouncycastle:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/ 
services/discovery/jxta/pom.xml

The bouncycastle reference is there because jxta needs it; there is  
no direct reference from our code.

My assumption is the same as Roy's in that this makes the Tuscany  
module 5D002.

During development we publish unstable snapshots to the mvn repo at
   http://people.apache.org/repo/m2-snapshot-repository/

This would include the jxta module in binary form but would not  
include binaries for jxta or bouncycastle themselves. Being  
conservative though, my guess would be that this still meets the  
criteria for first notification as we are distributing code that uses  
a 5D002 item through a public server (people.apache.org).

Apart from this one module though, Tuscany itself does not have a  
dependency on a 5D002 item. We do include that module by default in  
one distribution which would presumably make that distribution 5D002  
(when we release it, we have not done so yet).

However, there are other distributions that do not include it and do  
not rely on it. Are there any issues with not classifying those, or  
should we be conservative and notify for all?

--
Jeremy


On Feb 20, 2007, at 9:22 PM, 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.
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message