You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Roy T. Fielding" <fi...@gbiv.com> on 2007/02/21 01:29:19 UTC
podling BIS notifications
I noticed yesterday that James Snell was being very proactive
and submitted the correct BIS notification for Abdera.
<http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/
200702.mbox/raw/%3c45D7AB04.1070200@gmail.com%3e>
However, please note that Abdera is not yet an Apache Project,
even though it is a released product, and that the responsible
party is the Incubator PMC. I have corrected the information on
the exports page accordingly, which will show up on the live site
after 5:11pm PST. There is no need to correct the notice.
In the future, it is generally better for such notices to be
submitted by an ASF officer and from an apache.org address.
If the NSA chooses to knock on your door, we want you to be able
to put the right hat on while talking to them.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: podling BIS notifications
Posted by Luciano Resende <lu...@gmail.com>.
Hi Roy
On a similar subject, Apache Tuscany is going to have similar
dependencies and we are trying to find out what's the right way to file the
notification. Could you please help us on the following thread :
http://www.mail-archive.com/general%40incubator.apache.org/msg12626.html
--
Luciano Resende
http://people.apache.org/~lresende
On 2/20/07, Roy T. Fielding <fi...@gbiv.com> wrote:
>
> I noticed yesterday that James Snell was being very proactive
> and submitted the correct BIS notification for Abdera.
>
> <http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/
> 200702.mbox/raw/%3c45D7AB04.1070200@gmail.com%3e>
>
> However, please note that Abdera is not yet an Apache Project,
> even though it is a released product, and that the responsible
> party is the Incubator PMC. I have corrected the information on
> the exports page accordingly, which will show up on the live site
> after 5:11pm PST. There is no need to correct the notice.
>
> In the future, it is generally better for such notices to be
> submitted by an ASF officer and from an apache.org address.
> If the NSA chooses to knock on your door, we want you to be able
> to put the right hat on while talking to them.
>
> ....Roy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: podling BIS notifications
Posted by James M Snell <ja...@gmail.com>.
Notta problem... I'd rather stick to writing code anyway ;-). Thanks
for the correction.
- James
Roy T. Fielding wrote:
> I noticed yesterday that James Snell was being very proactive
> and submitted the correct BIS notification for Abdera.
>
> <http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200702.mbox/raw/%3c45D7AB04.1070200@gmail.com%3e>
>
>
> However, please note that Abdera is not yet an Apache Project,
> even though it is a released product, and that the responsible
> party is the Incubator PMC. I have corrected the information on
> the exports page accordingly, which will show up on the live site
> after 5:11pm PST. There is no need to correct the notice.
>
> In the future, it is generally better for such notices to be
> submitted by an ASF officer and from an apache.org address.
> If the NSA chooses to knock on your door, we want you to be able
> to put the right hat on while talking to them.
>
> ....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
Re: podling BIS notifications
Posted by Jeremy Boynes <jb...@apache.org>.
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
Re: podling BIS notifications
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Feb 20, 2007, at 10:55 PM, Cliff Schmidt wrote:
> +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.
> See http://www.apache.org/dev/crypto.html#faq-additionalemails.
Yep, I oversimplified.
>> 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:
Ah, rats, I was hoping that it wasn't classified as 5D002 until
the code was in functional form, since that is what the definitions
in 772 and 740 would indicate. But you are right that what matters
more is what BIS folks consider.
> http://www.apache.org/dev/crypto.html#faq-firstnotification
> http://www.apache.org/dev/crypto.html#faq-public
>
> If any of these FAQs could be more clear, let me know.
Actually, I think it would be clearer as a step-by-step decision
process rather than a FAQ. I'm not volunteering any more, though.
> ...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?
Umm, my bad -- I read the definition on their summary page and followed
how it was used by other companies. The definition in section 734
(c) "Items subject to the EAR" consist of the
items listed on the Commerce Control List (CCL)
in part 774 of the EAR and all other items which
meet the definition of that term. For ease of
reference and classification purposes, items
subject to the EAR which are not listed on the
CCL are designated as "EAR99."
is more clear. So, our software would only be EAR99 if it were not
publicly available, since making non-5D002 software publicly
available means the items is not "subject to the EAR", so that is
only a concern for redistributors that distribute modified versions.
Not our problem. I'll fix the page. Damn spaghetti regs.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: podling BIS notifications
Posted by Cliff Schmidt <cl...@gmail.com>.
On 2/20/07, Roy T. Fielding <fi...@gbiv.com> 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.
See http://www.apache.org/dev/crypto.html#faq-additionalemails.
> 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:
http://www.apache.org/dev/crypto.html#faq-firstnotification
http://www.apache.org/dev/crypto.html#faq-public
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.
+1
...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.
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: podling BIS notifications
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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