Guidance on Software Development and Open Source Software [pdf]
dodcio.defense.gov
dodcio.defense.gov
Sounds pretty reasonable.
Fortunately Google is large enough that having a net-new dependency was quite rare.
And even in the community distros you have maintainers.
All professionally managed packages, kernel, libc, gcc/llvm postgres, python, etc etc have full time professional mainline maintainers.
And package maintainers with a high working ethos as reviewers and gatekeepers.
The problem is with leaf packages in ginornous self serviced blindly trusting huge repos like pip or cargo or younameit, npm, with huge numbers of tiny packages with no tangible responsibility whatsoever.
This is a very, very hard problem to solve without some serious coordination and effort. To do this well you need to do all kinds of things like:
1. Verifying the authenticity of the software you're looking at. Is that really libxml or has someone fed you a poisoned package? Does it have a checksum? Is the registry or repository we pulled it from adequately secured?
2. Verifying the provenance of a particular version of a package. Who made this change? Why did they make it? Is the change safe?
3. Vetting the governance of a package or library. We may know of Apache and have some confidence in the governance of that project, but what about leftpad of NodeJS/npm fame? Is that logging library we got for our Rust app off of crates.io managed by a reputable OSS developer and/or company, or are the motivations of the entities building it uncertain? Can they be bought? Bought out? Sued? Blackmailed? If you're looking at this with the mindset of a state-sponsored organization that handles anything remotely important these are not unreasonable considerations.
The list goes on and on. It helps if you're working in an ecosystem that has high level of quality standards for the libraries or software packages that are being used, but there's always more to dig up the deeper you go into a dependency tree.
I'm of the opinion that supply chain attacks can be mitigated, but never eliminated. Having many eyes on a project helps (thanks to all of you working on projects with openly available sources!). We're still a long way from making our industry's tools and development processes naturally robust to these things, though I'm excited to see more dialog around these issues.
Does MOSA includes donations to the mainteners?
No paywall in this case that I can see, nor overload, nor anything obnoxious. Heck, the site doesn't even set any cookies.
Despite its importance, this document has the format / look and feel of a procurement for bulk purchase of machine screws.
As a formal guidance memorandum this format also allows for each section and paragraph to be uniquely referenced through with a logical structure, same as legal documents.
There will almost certainly be infographics and posters made of this document’s key points and distributed around the DoD, but they’ll refer back to this as the canonical source.
Honestly if more software companies worked this way there’d be less confusion and fewer cases of building the wrong thing, loss of institutional knowledge, and duplicated effort.
Now, DoD often does provide info in much more informal formats.[1] For this issue, there is a FAQ.[2] It covers not only common misconceptions but such things as how Eben Moglen enforces the GPL and the difference between the 2-clause and 3-clause BSD licenses. There is a DoD forum on Google Groups about this.[3] The proponent of that document is active on that forum.
[1] https://www.psmagazine.army.mil/
This is preferable to a PowerPoint.
This explains why software sucks so much in some places (e.g. payroll) there - because when the only software available is bad proprietary software (you only get good software for some specific fields, like email, but bad software exists for every conceivable need), the DoD prefers to spend extravagant amounts of taxpayer money on purchasing that existing solution over developing their own.
As a F/OSS developer I am ideologically opposed to my work ever being used by the US' DoD or any of its organizations. Has anyone successfully built F/OSS products with a license that disallows use by military organizations, and if so - what is involved in maintaining that situation?
Also, the DoD in particular has sovereign immunity, so if they infringe your copyright, you somehow find out about it, and you sue them for it in the US, they can just refuse the lawsuit. The best you could do in that case is something like a WTO lawsuit, which, well, I don't think you can get by with less than a million dollars in legal fees. You could sue somebody like Boeing or Lockheed Martin but you're still going to have one hell of an uphill battle there. However, those organizations would probably prefer not to spend tens of thousands of dollars to fight your lawsuit, so they may comply with the license even if they would probably win in court.
The federal government has waived its sovereign immunity via statute for specific kinds of lawsuits, including for copyright infringement via 28 U.S.C. 1498(b).
There is also a school of thought that says that copyright infringement violates the Fifth Amendment's takings clause, but that has yet to be endorsed (or rejected) convincingly at a federal level.
> The best you could do in that case is something like a WTO lawsuit
There are WTO disputes, but these can only be brought by one WTO member (e.g., a sovereign government) against another and generally the outcome of WTO disputes does not involve compensation.
Quite an interesting conundrum, this - but I suppose one that is simply the state of things: if you want your stuff to be free and open, you cannot release it to the world and expect/demand that it will not be weaponized, as is the case with any and all technology. Sobering.
Simple: stop being a F/OSS developer, and only license your non-F/OSS software to the organizations you choose.
In my mind the alternative to the police and an army isn't peace but the rule of the strongest.
Ask any pacifist country that stood in Hitlers way.
(That said I never signed up for "peacekeeping" missions abroad how much I'd like to try to serve in the field: I'm principled too)
You can add a clause to the licence saying "the following people/organisations are specifically prohibited from using this code: US DoD, etc" - you may want to word this better to prevent loopholes, but that's the gist of it.