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