commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: US Export classification & ECCN registration for encryption in commons?
Date Mon, 09 May 2016 10:52:15 GMT
 My take:

(But we can also ask Legal separately as LEGAL-250 got a bit long thread)


The exception for open source means we just need to self-classify as
5D002 and send a notification email according to
http://www.apache.org/dev/crypto.html


https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items
has some updated guidance after the 2010 changes:

> 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.

By not making binary distributions with third-party JARs we would not
be INCLUDING the encryption functionality.  However we would in some
cases USE the encryption functionality.


There IS an exemption from being classified at all in
https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three



> Note 4: Category 5, Part 2 does not apply to items incorporating or using "cryptography"
and meeting all of the following:
>
> (a) The primary function or set of functions is not any of the following:
>     (1) "Information security";
>     (2) A computer, including operating systems, parts and components therefor;
>     (3) Sending, receiving or storing information (except in support of entertainment,
mass commercial broadcasts, digital rights
>          management or medical records management); or
>     (4) Networking (includes operation, administration, management and provisioning);
> > (b) The cryptographic functionality is limited to supporting their primary function
or set of functions; and
> (c) When necessary, details of the items are accessible and will be provided, upon request,
to the appropriate authority in the exporter’s
>     country in order to ascertain compliance with conditions described in paragraphs
(a) and (b) above.

meaning that say Commons Imaging would be exempt from any registration
- even if it included support for reading encrypted images.

(however some software using such a hypothetical Commons Imaging
w/crypto, and incidentally also doing sending/receiving/storing
information, WOULD need to classify)


but Commons-VFS - with support for SFTP, WebDav etc., is arguably
"Sending, receiving or storing information", and would by having
strong bindings to Apache SSHd (itself listed) and JSCH  which
encryption functionality VFS would be using.

The test dependency on Bouncy Castle is ironically not cause for
registration as VFS code is not designed to use BCProv, and do not
bundle the Bouncy Castle implementation.



Commons Crypto would be doing "information security" and  Iwould say
also need to be registered.

On 5 May 2016 at 10:45, sebb <sebbaz@gmail.com> wrote:
> Also note that there is a TSU Exception, EAR 740.13(e) - Publicly
> available encryption source code - which the dev/crypto.html page says
> applies to the ASF.
>
> I think we need to wait for guidance from Legal.
>
> On 5 May 2016 at 10:04, Benedikt Ritter <britter@apache.org> wrote:
>> Hi,
>>
>> Stian Soiland-Reyes <stain@apache.org> schrieb am Mi., 4. Mai 2016 um
>> 14:35 Uhr:
>>
>>> Hi,
>>>
>>> Sorry for spotting this..
>>>
>>>
>>> Apache Commons Crypto  is not listed on
>>> http://www.apache.org/licenses/exports/ - does it need to be?  (One
>>> would assume so..)
>>>
>>> Also it was raised that Commons VFS depends on Bouncy Castle/Apache
>>> Mina/Jetty/SSHD/Hadoop/jsch and has encryption binding for AES128 -
>>> perhaps that also needs to be listed and registered?
>>>
>>
>> Thank you for pointing this out. I've reported this as
>> https://issues.apache.org/jira/browse/CRYPTO-54. I'm not involved in VFS,
>> but I've seen that the discussion about that has already started on the
>> vote for VFS 2.0 rc1.
>>
>> Benedikt
>>
>>
>>>
>>>
>>> We only have listed:
>>>
>>> Commons Compress
>>> Commons OpenPGP
>>>
>>>
>>> See guidance on
>>> http://www.apache.org/dev/crypto.html
>>>
>>>
>>> BTW - I've raised https://issues.apache.org/jira/browse/LEGAL-250 to
>>> see if merely using a listed source as a Maven <dependency> means you
>>> also are classified - or if you would need to also bundle the
>>> dependency's binary (which I think we don't do).
>>>
>>>
>>>
>>> --
>>> Stian Soiland-Reyes
>>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>>> http://orcid.org/0000-0001-9842-9718
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message