Stumbled upon this today and found it quite interesting that DoD now considers Open Source Software to be a subcategory of Commercial Software.
> As explained in detail below, nearly all OSS is “commercial computer software” as defined in US law and the Defense Federal Acquisition Regulation Supplement, and if it used unchanged (or with only minor changes), it is almost always COTS.
This should have the effect of making it easier to consider Open Source Software in make/buy trade studies.
I don't think that's a full subset. Can't a developer release a binary of their software or make it available as public domain SaaS, without it being any kind of open source?
True, but there is one major prominent exception: SQLite. The author of such programs as djbdns and qmail also eventually released those under the public domain, but SQLite is under that status while still being actively developed and widely used.
It seems CC0 may have simplified this now. The issue used to be that software enters the public domain after copyright expires & different countries interpret that different ways, which can become complicated without an explicit license document.
It's not the DoD definition. It's the US definition. The DoD simply tries to make that clear, because thinking "open source is not commercial" is a common misunderstanding.
Commercial in this context is referring to "Commercial Off The Shelf" (COTS). Something that is available on the public market, rather than being produced specially for the government. Budgets, bids, etc. often specify whether something is or should be COTS.
> Obviously, software that does not meet the U.S. government’s definition of “commercial computer software” is not considered commercial software by the U.S. government’s acquisition processes. For example, software that is released to the public as OSS is not considered commercial if it is a type of software that is only used for governmental purposes. In contracts where this issue is important, you should examine the contract to find the specific definitions that are being used. But in practice, publicly-released OSS nearly always meets the various government definitions for “commercial computer software” – and thus is nearly always considered commercial software.
In my experience as a contractor, most federal agencies are now preferring products that are built with open source software, and I think a big reason why is because realistically there’s only a handful of contracting firms big enough to fulfill a lot of these $100M+ IT contracts, and the systems need to be supported for many years, so it makes it much easier if the contractor that builds a system does so in a way that one of their competitors can come in and maintain it when the first company cuts corners to boost profits after a few years.
Open source also creates a better pathway to "organic" sustainment or emergency (I forget the term they actually use) sustainment.
In organic sustainment the system is maintained by government employees. In the emergency context, it's the ability of the government to sustain a system without needing to defer to contractors in extreme circumstances. Imagine an actual total war for the US, contract negotiations take months or years even for stupidly simple work (I'm pretty sure some systems spend more in contract negotiations than the entire rest of the system costs). Open source is an effective way to ensure the government has access to all or most of the data needed to assume responsibility for the work later on. Technically the government also purchases data rights, but that part of contracts is almost always fouled up in some subtle way that makes it near useless.
There are so many big government IT contracts that are saddled with products like MS-SQL or worse Oracle instead of postgresql or mariadb. Big multicore M$ hyper-V with per-core pricing and so on.
It's just terrible to see the $$$$$ wasted on "enterprise" stuff that isn't needed 99% of the time.
It's been that way for a very long time, because it's based on the US definition of "commercial item".
I know that the 2009 DoD policy on OSS attachment 2 part 2 spwcifically states this. It said, “In almost all cases, OSS meets the definition of ‘commercial computer software’ and shall be given appropriate statutory preference in accordance with 10 USC 2377 (reference (b)) (see also FAR 2.101(b), 12.000, 12.101 (reference (c)); and DFARS 212.212, and 252.227-7014(a)(1) (reference (d))).” The most recent version of this policy says the same thing.
Lawyer and big fan of FLOSS here; and my initial quick read suggests that this is a good categorization. Essentially it's something like "commercial" means "used in commerce and is serious and grown-up," and in the case of the DoD, isn't likely to negatively impact, e.g. sharing?
So if I publish, say, a Ruby library in GitHub and/or RubyGems.org as just some Joe Schmo developer, that is now considered to be “commercial software”?
There are, roughly, three categories of software and systems from the government perspective: COTS (commercial off the shelf), GOTS (government off the shelf), and custom.
Your open source work would fall under COTS with the expansion of "commercial" to cover open source works. It's something that is supplied from outside the government and not explicitly commissioned for the government.
GOTS might be something like a timekeeping solution that a government organization can opt to use (among various other options) that was produced for or by the government and now "sold" or distributed as a reusable system for government use.
Custom would be if they came to you to build something for their specific needs, but wasn't already a COTS/GOTS product (that isn't to say they won't take COTS/GOTS and customize it, though). Think of this as a "one-off" (or often starts that way). These might turn into COTS or GOTS products later on depending on who "owns" the system and its ability to be reused.
Yes. If it's available to the public and it has a non-government use, it is commercial. Period. It's not just "now", that is how the US law is written, and it's been that way for a long time.
There are two types of commercial software: Open Source Software and Closed Source Software.
This is intentional. The US government wants to be able to use software that is available in the commercial (non-government) world.
As pointed out by others, this isn't really a contradiction. "Commercial" here is being used in a literal sense, not as a euphemism for "proprietary," because the inquiry is about fiscal law, not about copyright law.
Simply put, government acquisitions functions differently for build, buy (specialized), or buy-off-the-economy. How the DoD looks at buy-or-build as stewards of the taxpayers' money is not too dissimilar to how a startup might look at the tradeoffs of buy-or-build as stewards of investors' money.
If your startup needs, say, a webserver, the buy-or-build question has a lot of freedom software, much of it no-cost, on the "buy" side of the question. Through that lens, I don't think it's a stretch to think of NGINX as "commercial off-the-shelf software." Neither does the DoD. And likely, neither does most of HN.
Q: Am I required to have commercial support for OSS?
Q: When a DoD contractor is developing a new system/software as a deliverable in a typical DoD contract, is it possible to use existing software licensed using the GNU General Public License (GPL)? Can the DoD used GPL-licensed software?
Q: Under what conditions can GPL-licensed software be mixed with proprietary/classified software?
Q: Can contractors develop software for the government and then release it under an open source license?
Q: Can the government release software under an open source license if it was developed by contractors under government contract?
I'm glad these questions were listed and clearly addressed. My experience has been that contractors are terrified of open source, doubly so for projects with copyleft licenses. This FAQ is really comprehensive so hopefully it can give engineers the footing to dissuade fears that project leadership may have and actually force conversations about both using FOSS (instead of homebrewing or overpriced, worse proprietary alternatives) and maybe even allowing projects to contribute to FOSS.
You're welcome. Sorry I haven't been more proactive in keeping this up to date. I have some changes and updates that I've been meaning to make. The github repo for the FAQ itself is https://github.com/risacher/DoD-OSS-FAQ
This is a great FAQ, especially for people who are responding to DoD RFPs and RFIs. Too many Federal program managers were hung up on things like "But I can't buy a support contract for this." and rejecting valid, lower cost, proposals because they used OSS rather than an expensive proprietary solution. I know at least one DoD SBIR contractor who attaches this FAQ to every RFP for this reason.
Thanks! I was one of the primary authors of the original version. We did our best to identify misunderstandings and serious questions, and then answer them... exactly what a FAQ should do.
I saw you present a version of this in probably 2016 or so at little security conference in DC (maybe platform security conference?). Anyhow your talk was a huge deal for defense contractors doing proposal work at the time (and since).
In the DoD space a standard ask in a class of proposals is for having a commercialization plan for dual use stuff. Pushing that open source is commercial created a way for contractors to have their commercialization strategy for a proposal to be 'open source it'. Lots of open source development is out there as a result of your efforts and I can't imagine that was a fun bureaucratic battle to fight. Thank you seems small, but thank you and I owe you a beverage.
A beverage sounds fun! I live in the DC area. If you're in the area, contact me at dwheeler@dwheeler.com and maybe we can find a way to "do lunch". :-)
Department of Energy has frowned upon using GPL/copyleft licenses historically, presumably around the desire to enable commercialization of a product by any contractor (including DoD). Note that this doesn’t mean you are prohibited from contributing to software with such a license, and an MoU can override such restrictions (that often end up in the site contract).
If your company has Belarusian nationals, and they have access to any of your code or infra... you most likely have been doing a jig recently about COTS/Encryption/DFARS/ITAR.
Super glad this information is being put out in a very public manner because those laws are very complex and very dangerous to run afoul of.
Stallman is an hero. A flawed hero to be sure, but an hero nonetheless. The audaciousness of the GNU project is impossible to overstate, and yet it pretty much came off.
I did an internship at NYU during the GNAT project where USAF gave money to NYU to develop an Ada 9X compiler based on GCC and required it to be licensed under the GPL.
DoD people who managed this fully understood how free software works and they purchased support from the company formed after this project (disclaimer: I was an employee).
43 comments
[ 3.1 ms ] story [ 98.9 ms ] thread> As explained in detail below, nearly all OSS is “commercial computer software” as defined in US law and the Defense Federal Acquisition Regulation Supplement, and if it used unchanged (or with only minor changes), it is almost always COTS.
This should have the effect of making it easier to consider Open Source Software in make/buy trade studies.
As for SaaS, what is in public domain? The output of the public server? There is no public domain software runnable or compilable by a third party.
“Using CC0 for Public Domain Software” https://creativecommons.org/2011/04/15/using-cc0-for-public-...
“CC0 FAQ” https://wiki.creativecommons.org/wiki/CC0_FAQ#May_I_apply_CC...
the CIO's office of the DOD is saying that if you didn't consider open source alternatives you would be in violation of the FARs.
Wow! They are basically saying you must do so if you are the federal govt. or contractor.
In organic sustainment the system is maintained by government employees. In the emergency context, it's the ability of the government to sustain a system without needing to defer to contractors in extreme circumstances. Imagine an actual total war for the US, contract negotiations take months or years even for stupidly simple work (I'm pretty sure some systems spend more in contract negotiations than the entire rest of the system costs). Open source is an effective way to ensure the government has access to all or most of the data needed to assume responsibility for the work later on. Technically the government also purchases data rights, but that part of contracts is almost always fouled up in some subtle way that makes it near useless.
It's just terrible to see the $$$$$ wasted on "enterprise" stuff that isn't needed 99% of the time.
I know that the 2009 DoD policy on OSS attachment 2 part 2 spwcifically states this. It said, “In almost all cases, OSS meets the definition of ‘commercial computer software’ and shall be given appropriate statutory preference in accordance with 10 USC 2377 (reference (b)) (see also FAR 2.101(b), 12.000, 12.101 (reference (c)); and DFARS 212.212, and 252.227-7014(a)(1) (reference (d))).” The most recent version of this policy says the same thing.
Your open source work would fall under COTS with the expansion of "commercial" to cover open source works. It's something that is supplied from outside the government and not explicitly commissioned for the government.
GOTS might be something like a timekeeping solution that a government organization can opt to use (among various other options) that was produced for or by the government and now "sold" or distributed as a reusable system for government use.
Custom would be if they came to you to build something for their specific needs, but wasn't already a COTS/GOTS product (that isn't to say they won't take COTS/GOTS and customize it, though). Think of this as a "one-off" (or often starts that way). These might turn into COTS or GOTS products later on depending on who "owns" the system and its ability to be reused.
There are two types of commercial software: Open Source Software and Closed Source Software.
This is intentional. The US government wants to be able to use software that is available in the commercial (non-government) world.
For more info, see my paper "Open Source Software is Commercial": https://csiac.org/articles/open-source-software-is-commercia...
Simply put, government acquisitions functions differently for build, buy (specialized), or buy-off-the-economy. How the DoD looks at buy-or-build as stewards of the taxpayers' money is not too dissimilar to how a startup might look at the tradeoffs of buy-or-build as stewards of investors' money.
If your startup needs, say, a webserver, the buy-or-build question has a lot of freedom software, much of it no-cost, on the "buy" side of the question. Through that lens, I don't think it's a stretch to think of NGINX as "commercial off-the-shelf software." Neither does the DoD. And likely, neither does most of HN.
In the DoD space a standard ask in a class of proposals is for having a commercialization plan for dual use stuff. Pushing that open source is commercial created a way for contractors to have their commercialization strategy for a proposal to be 'open source it'. Lots of open source development is out there as a result of your efforts and I can't imagine that was a fun bureaucratic battle to fight. Thank you seems small, but thank you and I owe you a beverage.
Super glad this information is being put out in a very public manner because those laws are very complex and very dangerous to run afoul of.
DoD people who managed this fully understood how free software works and they purchased support from the company formed after this project (disclaimer: I was an employee).
https://en.wikipedia.org/wiki/GNAT
An historic read if you're interested (mentionning why free software was choosen):
"Ada 9X project management"
https://dl.acm.org/doi/pdf/10.1145/138844.138851
By Christine M. Anderson:
https://www.af.mil/About-Us/Biographies/Display/Article/1047...