Hi Stian, I saw you worked actively on same registration issue for Taverna. Do you have any suggestions on what steps we should take for Crypto registration? We are keenly to get a first release of Crypto.
Regards, Haifeng -----Original Message----- From: Chen, Haifeng [mailto:haifeng.c...@intel.com] Sent: Friday, May 13, 2016 1:39 PM To: Commons Developers List <dev@commons.apache.org> Subject: RE: US Export classification & ECCN registration for encryption in commons? 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:seb...@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 <st...@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 <seb...@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 <brit...@apache.org> wrote: >>> Hi, >>> >>> Stian Soiland-Reyes <st...@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-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
