commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Haifeng" <haifeng.c...@intel.com>
Subject RE: US Export classification & ECCN registration for encryption in commons?
Date Fri, 13 May 2016 05:39:29 GMT
Hi folks,
From LEGAL-250 discussion, it showed that Commons Crypto should be registered.
Shall we also add Commons Crypto to ECCN Matrix in http://www.apache.org/licenses/exports/
page (eccnmatrix.xml) the same as what Apache Taverna did?

Regards,
Haifeng

-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com] 
Sent: Monday, May 9, 2016 7:48 PM
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: US Export classification & ECCN registration for encryption in commons?

On 9 May 2016 at 11:52, Stian Soiland-Reyes <stain@apache.org> wrote:
>  My take:
>
> (But we can also ask Legal separately as LEGAL-250 got a bit long 
> thread)

+1

>
> 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/identifyi
> ng-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/identifyi
> ng-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.

Commons NET would also need to register then.

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

---------------------------------------------------------------------
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
Mime
View raw message