Page has been updated to include Apache VCL: http://www.apache.org/licenses/exports/index.html
On Tue, Jul 18, 2017 at 10:50 AM, Josh Thompson <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sorry to be late to the conversation. I discussed this in person but > forgot > to send something to the list. > > I agree that we need to go through this process. I had looked at it > several > years ago, but thought it didn't apply to us since we were only using > external > cryptographic code. However, I think I was wrong about that and that we > should have filed something before. This is heightened now with the > additional encryption of database data we added for 2.5. > > I can go ahead and start the process. > > Josh > > On Wednesday, July 12, 2017 12:06:52 PM Andy Kurth wrote: > > On Tue, Jul 11, 2017 at 8:32 PM, Henry Schaffer <[email protected]> wrote: > > > It looks to me than Andy's statement, "None of the VCL-proper source > code > > > actually does any direct encryption via mathematical or other > functions." > > > puts the VCL-proper source code into the latter category of "PMCs > > > considering including cryptographic functionality within their > > > products or *specially > > > designing their products to use other software with cryptographic > > > functionality* should take the following steps ..." [emphasis added] > > > described in the Overview. > > > > > > I don't understand how Step 1 applies, since that's for crypto > software. > > > Might we be able to skip this? > > > But Steps 2-4 look pretty straight forward and appear necessary. > > > > > > Will that do it? > > > > My understanding is that step 1 is simply to determine whether or not the > > software is controlled by ECCN 5D002, which describes any software that > > uses cryptography in one way or another. I think the answer for step 1 > is > > yes, VCL is controlled by ECCN 5D002. > > > > The scope of 5D002 is described in "EAR Category 5 Part 2 - Information > > Security": > > https://www.bis.doc.gov/index.php/documents/regulations- > docs/federal-registe > > r-notices/federal-register-2014/951-ccl5-pt2/file > > > > Pages 1 and 2 apply (up to section "A" on page 2), as well as section "D. > > SOFTWARE" beginning on page 7. > > > > Section D gives a slightly expanded definition than included on the ASF > > > > page: > > > Related Definitions: 5D002.a controls “software” designed or modified > to > > > use “cryptography” employing digital or analog techniques to ensure > > > “information security.” > > > > This is exactly what VCL is "using cryptography" for. Whether or not the > > algorithms are in the VCL-proper source code or another imported/linked > > product doesn't seem to be a factor. Unfortunately, the ASF page is very > > vague regarding this. It does, however, seem to allude to this here: > > https://www.apache.org/dev/crypto.html#faq-twocryptos > > > > To paraphrase, "Q: If a product uses AND includes 3rd-party crypto items, > > does it require one or two notifications? A: One notification, but list > > both sources." I infer from this that it's a given a notification is > > required when using any 3rd-party crypto. > > > > There are some exceptions listed in EAR 5D002. VCL doesn't seem to meet > > all of the requirements for any that I have found although exceptions > could > > possibly apply to other ASF projects. Specifically on page 2 Note 4.a.4, > > 5D002 does ****not* *apply if: > > > > The primary function or set of functions is ****not** any of the > following: > > > 4. Networking (includes operation, administration, management and > > > provisioning); > > > > I know this isn't black or white and the meaning of many of the terms > > leaves room for interpretation, but VCL's primary function is to > provision, > > and it provisions certain networking aspects, so 5D002 does > ****not***-**** > > *not** apply because of this. > > > > There's a note on the ASF page: > > > Note - the regulations covering US export control laws for encryption > were > > > changed on June 25th 2010. This page describes the previous process > which > > > should be continued until an updated version has been drawn up and > > > approved > > > by the Apache VP Legal Affairs. > > > > Actually, the latest changes happened 2016-09-20. The page also states: > > > > Fortunately, the TSU exception to these restrictions, EAR 740.13(e), > > > > > applies to cryptography of concern to the ASF. > > > > Part 740 is "License Exceptions": > > https://www.bis.doc.gov/index.php/documents/regulation-docs/ > 415-part-740-lic > > ense-exceptions/file > > Unfortunately, 740.13(e) was redacted from the latest version (page 34): > > > (e) [Reserved] > > > > What was 740.13(e) is now in 742.15(b): > > https://www.bis.doc.gov/index.php/documents/regulation-docs/ > 416-part-742-con > > trol-policy-ccl-based-controls/file > > > > (Note: 742.15 starts on page 26) > > The changes made to 740 are explained on several legal sites. Per the > > following: > > http://www.lexology.com/library/detail.aspx?g= > b6d5542e-d636-4864-843c-ac7895 > > a26450 > > > > The DOC is revising license exception TSU and Part 742.15 of the EAR to > > > > > state that publicly available encryption source code classified under > ECCN > > > 5D002 is no longer subject to the EAR once the TSU email notification > is > > > sent to BIS and the ENC Encryption Request Coordinator. Part 742.15(b) > now > > > contains the notification requirement that was previously found within > TSU > > > at Part 740.13(e). > > > > So, to make an overly long story short and back to your point -- I think > > yes, we did step 1 via this thread and we just need to do steps 2-4. :) > > > > -Andy > > > > > --henry > > > > > > On Tue, Jul 11, 2017 at 1:34 PM, Andy Kurth <[email protected]> > wrote: > > > > This thread is to discuss the pertinence of the U.S. export control > laws > > > > regarding cryptography described on the following page: > > > > https://www.apache.org/dev/crypto.html > > > > > > > > The following seems to apply to VCL: > > > > > PMCs considering including cryptographic functionality within their > > > > > products or *specially designing their products to use other > software > > > > > with cryptographic functionality* should take the following steps > > > > > > before > > > > > > > > placing such code on any ASF server, including commits to > subversion > > > > > > > > VCL has always used some cryptographic functionality and new features > > > > > > added > > > > > > > for VCL 2.5 expand the usage. The README lists requirements of > > > > php-openssl, openssh, openssl-devel, and xmlsec1-openssl. The > backend > > > > installation scripts will install a few encryption-related modules > and > > > > > > the > > > > > > > backend Perl code uses functions from the Crypt::OpenSSL::RSA and > > > > others. > > > > The frontend does the same. Encrypted strings generated from these > > > > > > modules > > > > > > > and libraries are stored in the VCL database. None of the VCL-proper > > > > source code actually does any direct encryption via mathematical or > > > > other > > > > functions. > > > > > > > > I'm hoping I'm wrong, but it sounds like we should go through all of > the > > > > steps listed on the page and that all of this should be completed > before > > > > releasing VCL 2.5 so that the README includes the proper crypto > notice. > > > > > > > > Please discuss... > > > > > > > > Thanks, > > > > Andy > > > > > > > > PS - I think the *"before placing such code on any ASF server, > including > > > > commits to subversion"* part of the guidelines is irrelevant at the > > > > > > current > > > > > > > time since encryption code has been committed -- in some cases, years > > > > > > ago. > > > > > > > We'll certainly abide by this in the future once we figure out how > > > > things > > > > need to be handled. > - -- > - ------------------------------- > Josh Thompson > VCL Developer > North Carolina State University > > my GPG/PGP key can be found at pgp.mit.edu > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties. > -----BEGIN PGP SIGNATURE----- > > iEYEARECAAYFAlluICQACgkQV/LQcNdtPQO10ACeMTmcBSgygjZOdsY1kVv4UCAC > 2KsAnAs2HYOTei1KsI6fldKHHGvWg+6A > =F7ZM > -----END PGP SIGNATURE----- > >
