www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: ECCN page: http://www.apache.org/licenses/exports/ - broken links
Date Thu, 05 May 2016 17:42:05 GMT
Thanks for finding a somewhat reasonable explanation, although still
transitivity is unclear. I think the important distinction is "encryption
functionality" and "encryption item".

My take: encryption functionality is encryption algorithms and code around
that. An encryption item is anything including or using encryption
functionality.

Please correct me if my deduction below then is reasonable as to what is
NOT ECCN controlled.

So if you don't "use the encryption functionality" of an item (a
dependency), and don't include the dependency in the distributions, then
you are in the clear, even if the dependency itself is an "encryption item"

That is the loophole :)

So for instance, you would be fine to have a Maven <dependency> on Apache
Derby without using any of its encryption features (e.g. for secure
client/server connection), as long as you don't include Derby in any
ASF-provided distribution (Derby itself being an "encryption item" as it is
on our ECCN list).

On the other side, if you have code integrating with the BouncyCastle APIs,
that alone means you are ECCN controlled, even if you don't embed anything.

If you bundle the HttpComponent jars in your dist, then you are ECCN
controlled.

However if you integrate with Apache HttpComponent as a <dependency>, and
only use it for accessing http:// URLs, then you are fine - although you
are using HttpComponents, you don't use its "encryption functionality".

Shaded JARs in Maven (e.g. including HttpComponents) would presumably also
be encryption items that should be listed? I notice no reference to our
Maven repository.
On 5 May 2016 6:26 a.m., "Alex Harui" <aharui@adobe.com> wrote:

>
>
> On 5/4/16, 10:11 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
>
> >
> >But do any of them have crypto *implementations*?
>
> I don't know, but this page [1] makes me think there is more to it than
> whether there is an "implementation" in the bundle, although I guess it
> also depends on your definition of "implementation".
>
> "Almost all items controlled under Category 5, Part 2 of the EAR are
> controlled because they include encryption functionality. Items may be
> controlled as encryption items even if the encryption is actually
> performed by the operating system, an external library, a third-party
> product or a cryptographic processor. If an item uses encryption
> functionality, whether or not the code that performs the encryption is
> included with the item, then BIS evaluates the item based on the
> encryption functionality it uses.
>
> Similarly, if the item includes encryption functionality, even if the
> encryption functionality is not used by the item, then BIS evaluates the
> item based on the included encryption functionality."
>
> [1]
> https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-en
> cryption-items
>
> -Alex
>
>

Mime
View raw message