You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Gilles Scokart <gs...@gmail.com> on 2007/08/16 21:13:06 UTC
Fwd: Do we meet the definition of ECCN 5D002 ?
We have on the ivy-dev mailing a question for which we requires some help.
Since I'm subscribed to the general@i.a.o mailing list I have never
seen this subject aborded.
Thanks for your advices
---------- Forwarded message ----------
From: Gilles Scokart <gs...@gmail.com>
Date: 16 août 2007 19:35
Subject: Do we meet the definition of ECCN 5D002 ?
To: ivy-dev@incubator.apache.org
I just found [1], and I was wonderiing if we don't fall under the
definition of ECCN 5D002 for our binary distribution with deps. In
this distribution we include binaries that support https, sft and ssh (and
maybe other via vfs).
Does that fall under the definition of ECCN 5D002 ?
PS: Note that if it is the case, there are probably a lot of other
project missing in [2]
[1] http://www.apache.org/dev/crypto.html
[2] http://www.apache.org/licenses/exports/
--
Gilles SCOKART
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Do we meet the definition of ECCN 5D002 ?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 8/16/07, Gilles Scokart <gs...@gmail.com> wrote:
<snip>
> I just found [1], and I was wonderiing if we don't fall under the
> definition of ECCN 5D002 for our binary distribution with deps. In
> this distribution we include binaries that support https, sft and ssh (and
> maybe other via vfs).
>
> Does that fall under the definition of ECCN 5D002 ?
possibly
AIUI one of the problems is that the regulations are fairly opaque
the best place to ask is on the apache legal-discuss list
> PS: Note that if it is the case, there are probably a lot of other
> project missing in [2]
quite possibly
it's actually quite hard to tell. i've run a POM->RDF on the maven 2
repository but only turned up one project which turned out not to
require a license :-/
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Do we meet the definition of ECCN 5D002 ?
Posted by Gilles Scokart <gs...@gmail.com>.
Couldn't this kind of things be checked by RAT?
Also, the crypto.html [1] page is not very referenced. And it is easy
to not see it. Couldn't it be referenced more clearly from one of the
guideline/policies document, so that that new poddling project are
more directly aware of it.
[1] http://www.apache.org/dev/crypto.html
Gilles
2007/8/16, Justin Erenkrantz <ju...@erenkrantz.com>:
> On 8/16/07, Gilles Scokart <gs...@gmail.com> wrote:
> > I just found [1], and I was wonderiing if we don't fall under the
> > definition of ECCN 5D002 for our binary distribution with deps. In
> > this distribution we include binaries that support https, sft and ssh (and
> > maybe other via vfs).
>
> If you have any code which directly invokes a dependency which is
> covered by 5D002, yes, our policy is you must file a notice. APR had
> to file simply because it can optionally link against OpenSSL.
>
> From the FAQ:
> ---
> What are examples of when a crypto item is publicly accessible through
> ASF servers?
>
> The obvious example is including something like an OpenSSL binary
> within a product distribution from a /dist URL. The less obvious
> example, is the point at which a subversion repository starts to
> include code that is specially designed to work with any other 5D002
> item, whether that item is ever to be included within a product
> distribution or not. In other words, a project should send out a
> notification email just after making the decision to include code that
> is specially designed to work with crypto APIs but before actually
> committing such code. No need to worry about surprise JIRA attachments
> with such code -- only the event of committing the code to the ASF
> product repository.
> ---
>
> So, sounds like Ivy falls under the latter example.
>
> HTH. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Gilles SCOKART
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Do we meet the definition of ECCN 5D002 ?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/16/07, Gilles Scokart <gs...@gmail.com> wrote:
> I just found [1], and I was wonderiing if we don't fall under the
> definition of ECCN 5D002 for our binary distribution with deps. In
> this distribution we include binaries that support https, sft and ssh (and
> maybe other via vfs).
If you have any code which directly invokes a dependency which is
covered by 5D002, yes, our policy is you must file a notice. APR had
to file simply because it can optionally link against OpenSSL.
>From the FAQ:
---
What are examples of when a crypto item is publicly accessible through
ASF servers?
The obvious example is including something like an OpenSSL binary
within a product distribution from a /dist URL. The less obvious
example, is the point at which a subversion repository starts to
include code that is specially designed to work with any other 5D002
item, whether that item is ever to be included within a product
distribution or not. In other words, a project should send out a
notification email just after making the decision to include code that
is specially designed to work with crypto APIs but before actually
committing such code. No need to worry about surprise JIRA attachments
with such code -- only the event of committing the code to the ASF
product repository.
---
So, sounds like Ivy falls under the latter example.
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org