risacher / dod-oss-faq Goto Github PK

From JITC comment: "Coordinator Comment and Justification: Suggest coming up with a more granular set of analysis criteria than “active and stable.” What characterizes a project as active and stable? Yearly updates? Monthly? 10 contributors? Hundreds? The subjectivity here is wide reaching and could lead us down a dangerous path if we do not bound the criteria.

Coordinator Recommended Change: Provide clarification as to what it means for an Open Source project to be both “active” and “stable” in order for appropriate supply chain risk analysis to be performed."

Coordinator Comment and Justification:
The paragraph “a strategic innovation is software that implements novel functionality which is not already available to the public, and which significantly improves DoD mission outcomes or business processes.” Probably will need some additional guidance for definition of what is “strategic innovation”.
Coordinator Recommended Change:
The statement is likely to invite some questions, suggest that it is included as part of FAQ mentioned in this memo (line 31-32) for clarifying guidance

"I'd love a flow-chart of how a program can make decisions on where to host your repo. IP->JAG->ISSM->etc->etc Also, I love seeing it used for more than just code, but also policy/guidance because it gives a great place to compare changes and such. that has always been so complex when getting new memo/policies and trying to figure out exactly what changed."

"I had been looking into any guidance or PAs for the use of github, but was unable to find any authorizations to use it, but i see you guys are. maybe you can point me to those authorizations?"

Comment in on updated memo says there's a definition in law somewhere, which I should reference instead of the 2009 memo

MDA comment on draft memo: "Section needs minimum decision basis of acceptance items i.e Bill of Materials, Ports and Protocols and other dependencies (JAVA runtime etc.)"

Remove Link and recommendation to CodePlex

"How does one determine which one to put? People will wonder why some are in code.gov and some are in code.mil. Would it make sense that if it is developed by DoD, then it should go to code.mil? Also where does https://github.com/deptofdefense comes in? this will be a good topic in FAQ mentioned (line 31-32) If you look at line 216-218. It appears that code.gov is for government-wide reuse purpose? Then it is not truly open source is it?
Also, should you mention “Repo One”, since it is the DoD Centralized Container Source Code Repository (DCCSCR) per DoD Enterprise DevSecOps Reference Design v1.0?"

From MDA comments on draft memo: "Section needs minimum decision basis of acceptance items i.e. complete list of all components the products dependencies."

Coordinator Comment and Justification: Existing DoD culture has created a “common sense” that any public disclosure is a risk to operational security. As a result, this strategy needs to explicitly define or reference the controls that a supervisor needs to apply in order to preserve operational security.

Coordinator Recommended Change: “Supervisors should encourage Government employees to contribute to OSS projects as part of their official duties, provided that those employees use an identity that is distrinct from their DoD ID. This allows employees to retain credit for their contributions in a future career outside the DoD, and it creates a degree of anonymity for the contribution that hinders a vigilant threat actor from linking the OSS vulnerability to any specific DoD system.”

Originator Response: Partially accept. See reasoning.

Originator Reasoning: Will add content on this topic to the DoD OSS FAQ.

"All code, scripts, configuration files, and associated documentation maintained by government projects whether released to the public or not will be maintained with cryptographically protected integrity verification to reduce security risks (e.g. digitally signed hashes of code). "

Source code for National Security Systems are arguably restricted by the International Traffic in Arms Regulations, and releasing such code is a legal thicket that is beyond the norm of what program managers are generally prepared to address. These issues are best addressed by the select judgment of component CIOs and subject-area PSAs, who can provide top-cover for PMs in specific areas where code sharing is of particular value.

From comment on draft memo: "The paragraph needs to provide minimum decision basis such as: Active, SW Lifespan, Support/Patch Schedules, CVE items, Foreign Counties, Banned Counties, Funding Entities, Project Leadership Countries."

New draft memo says: :Government employees may contribute to existing OSS projects as part of their official duties, so long as they consult with their supervisor first to ensure a common sense approach for contributions that preserves OPSEC and accounts for data rights."

New control enhancements are SI-7(13) and SI-7(14) on page 380 of the PDF at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

In an email (may 2021) I proposed the following text as recommended language for "licensing" the work of gov't employees:

“Portions of this software are works of the United States Government and are not subject to copyright protection in the Unites States. In other jurisdictions and/or subsequent to establishment of copyright protection as a Joint Work, this software is licensed under the terms of the XYZ license.”

This attempts to find a sweet spot; it's true that the works of a government employee (civilian or military) is not protected by copyright in the United States, but such a work is generally protected outside the United States under the Berne Convention and later treaties. I am proposing that we acknowledge gov't works as public domain, while still expressing a "license of intent". In theory, a third party could take this public domain software, add copyrightable material and relicense the Joint Work under other terms than the intended license. This might be annoying but doesn't prevent the government from continuing to release and maintain the OSS project, under the chosen terms - it just creates a fork under another (possibly proprietary) license.