Best Practices for Open Collaboration Communities¶
There are a few practices we have learned or developed that may be helpful for all open source communities.
Be Open and Be Public¶
We often use the word “open” to mean many things: an open source license, open and transparent discussions, open community, openly available source code on a public repository. “Open” may seem an obvious practice for open source communities, but there are some recommendations for communities.
First, communities should strive to keep their technical conversations open and public. If private conversations happen within communities, that’s normal, but it is recommended that community decisions and outcomes should become publicly available. It is important for our projects to make information available transparently and publicly as the private exchange of technology or technical information may not meet the “publicly available” requirement according to the EAR.
Please note also the discussion earlier and further below in this article, regarding some permitted non-public actions that occur in the context of “standards-related activities.”
One question that has come up has to do with exchanges of information related to security issues under a security disclosure process. As a best practice, projects may want to consider making exchanges like this public upon availability of fixes, and not limit this information to only a confidential disclosure list.
Exchanging technical ideas and knowledge, and having a technical debate are hallmarks of open source communities where the best technical solutions should rise to the forefront. These exchanges may be uncomfortable to have in public at times, but our communities who strictly hold to this principle are often the most successful at building transparent and trusting communities. There may be disagreements, but everyone knows the discussion is happening in public and transparently - there are many positive benefits to public, open collaboration beyond just meeting requirements of the EAR.
Use standard cryptography for encryption¶
It is generally best to avoid non-standard cryptography that is also not publicly available for encryption in an open source project.
If your open source software project decides to provide or perform encryption functionality classified under ECCN 5D002 and implements a form of non-standard cryptography, then you may need to deliver a notification of encryption to the BIS and the NSA according to the EAR requirements. EAR § 742.15(b)(2) [1] describes these requirements:
Send an email to crypt@bis.doc.gov and enc@nsa.gov.
The email should contain either the URL of the publicly available encryption source code, or a copy of the source code itself. Typically we would expect that open source projects would select the first option.
If you provided a URL to a site where you posted the source code on the Internet, you must notify by email again each time the Internet location is changed, but you are not required to notify them of updates or modifications made to the encryption source code at the previously notified location.
If you provided a copy of the source code, and you update or modify the source code, you must also provide additional copies to each of them each time the cryptographic functionality of the source code is updated or modified.
As you will see in The Linux Foundation’s notices, [2] we suggest a few additional details as best practices:
Make publicly available copies of the notices that were delivered to BIS and NSA, in order to increase transparency and visibility of compliance. This also helps with your community of downstream users who may wonder “do they send notices?” You can prevent concerns by making the notices themselves public.
Include contact information and, where applicable, the name of the particular legal entity or company that is responsible for the project.
Establish a system to ensure that you maintain evidence, for a medium- to long-term period of time, that the notification emails to BIS and NSA were in fact delivered. Relying solely on an individual’s “Sent” mailbox records may not be preferable if a question arises in the future, or if that individual loses access to that Sent mailbox.
If you are unsure whether your open source software project uses encryption based on non-standard cryptography, or if you know that it might in the future, you might also consider delivering a notice out of an abundance of caution.
Ensure corresponding encryption source code is publicly available¶
If you are distributing publicly available encryption software in object code form, then you will also want to ensure that it is publicly available in source code form as well.
Maintainers of the project, who are most familiar with the project’s code, should review to see if there are instances where encryption functionality is distributed in binary or object code form. Where it is, consider first if that is necessary. Distributing in source code form may be a preferred approach—not only for export compliance purposes, but also so that downstream users are not dependent on trusting a “black box” binary, and can easily build it themselves from source code.
If it is necessary to distribute encryption software in binary or object code form, then ensure that the corresponding source code is publicly available. [3] The easiest way to do this is to make available the source code for that version of the encryption software yourself, as part of the project’s own code. (In fact, depending on the applicable open source license, this may be necessary or at least useful in complying with that open source license as well!)
In addition to manual review, there are [4] some scanning tools with varying degrees of ability to scan source code and detect usage of encryption functionality. No automated scanning tool is likely to be a perfect detector of all applicable uses, but these may be helpful in identifying copies of encryption software in a large codebase.
