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