David A. Wheeler's Blog

Tue, 27 Oct 2009

New DoD memo on Open Source Software

The U.S. Department of Defense (DoD) has just released Clarifying Guidance Regarding Open Source Software (OSS), a new official memo about open source software (OSS). This 2009 memo should soon be posted on the list of ASD(NII)/DoD CIO memorandums. This 2009 memo is important for anyone who works with the DoD (including contractors) on software and systems that include software… and I suspect it will influence many other organizations as well. Let me explain why this new memo exists, and what it says.

Back in 2003 the DoD released a formal memo titled Open Source Software (OSS) in the Department of Defense. This older memo was supposed to make it clear that it was fine to use and develop OSS in the DoD. Unfortunately, as the new 2009 memo states, “there have been misconceptions and misinterpretations of the existing laws, policies and regulations that deal with software and apply to OSS that have hampered effective DoD use and development of OSS”.

This new 2009 memo simply explains “the implications and meaning of existing laws, policies and regulations”, hopefully eliminating many of those misconceptions and misinterpretations. A lot of the “meat” is in the Attachment 2, section 2 (guidance), so let’s walk through that:

• Point (a) says that “In almost all cases, OSS meets the definition of ‘commercial computer software’ and shall be given appropriate statutory preference…” This confirms what I’ve been saying for years (see FLOSS is commercial software). This is important in the U.S. government contracting world, because government contracts are required to prefer commercial computer software. If OSS is commercial software, then it needs to be preferred in the same way that proprietary software is preferred (compared to rebuilding everything from scratch). It also makes many decisions easy; there are lots of rules for “commercial software”, and since OSS is “commercial software”, then contractors already know what the rules are.
• Point (b) says that the DoD is “required to conduct market research… [and should] include OSS [in the research] when it may meet mission needs”. That’s a sea change all by itself — that means that people will typically need to justify not considering OSS options. What follows this statement is perhaps even more important… here we have an official government document acknowledging specific advantages OSS can have. The memo says that “There are positive aspects of OSS that should be considered”, noting “the continuous and broad peer-review enabled by publicly available source code”, “the unrestricted ability to modify software source code enables the Department to respond more rapidly to changing situations, missions, and future threats”, the reduced risk of lock-in, the possibility of lower costs, and so on. Let’s be clear: this is not a statement that the DoD will only use OSS, indeed, it clearly states that “the software that best meets the needs and mission of the Department should be used, regardless of whether the software is open source”. But it does tell people that there may be some very pointed questions if the OSS options aren’t considered, and that’s good for both the military and the taxpayer.
• Point (c) counters a weird problem specific to the DoD. DoD Instruction 8500.2 has a control called “DCPD-1 Public Domain Software Controls”. This control says that if you use a binary program, you must either have a warranty or the source code for a program. That makes sense; if there’s a defect in the program, the government wants to know that it will be fixed by someone else or have the rights to fix it themselves. Problem is, people decided to ignore the second part, and re-interpreted this control as “cannot use open source software”, which is not what it says. Hopefully this terrible misconception will start going away soon.
• Point (d) says, “The use of any software without appropriate maintenance and support presents an information assurance risk. Before approving the use of software (including OSS), system/program managers, and ultimately Designated Approving Authorities (DAAs), must ensure that the plan for software support (e.g., commercial or Government program office support) is adequate for mission need”. This actually hits at a number of issues. Some people say nonsense like “OSS has no support”, which is silly; Red Hat just entered the S&P 500, primarily through paid support. But it is true that when you use software — any software — for a critically important function, you better have a plan for maintenance and support. This isn’t unique to OSS; it’s simply a true statement in general. OSS does add additional options for how you do support, including self-support and fully competed support, but you still need to plan for it.
• Point (e) notes that there “is a misconception that the Government is always obligated to distribute the source code of any modified OSS to the public”, and then explains the real situation.
• Point (f) says that “software source code and associated design documents are ‘data’ as defined by DoD Directive 8320.02, and therefore shall be shared across the DoD as widely as possible to support mission needs…” This strikes a big blow at contractors who try to “hoard” software that the government paid to develop. In short, DoD directives already require that such software be shared with others.
• Point (g) says, “Software items, including code fixes and enhancements, developed for the Government should be released to the public (such as under an open source license) when all of the following conditions are met…”. This certainly doesn’t say that all DoD software will be released as OSS (nor would you expect that), but now the DoD is clarifying the issues to be considered before releasing software as OSS. It’s actually a simple 3-part test:
  1. “The project manager, program manager, or other comparable official determines that it is in the Government’s interest to do so, such as through the expectation of future enhancements by others.”
  2. “The Government has the rights to reproduce and release the item, and to authorize others to do so….”
  3. “The public release of the item is not restricted by other law or regulation…”

But perhaps most important is this memo’s opening statement: “To effectively achieve its missions, the Department of Defense must develop and update its software-based capabilities faster than ever, to anticipate new threats and respond to continuously changing requirements. The use of Open Source Software (OSS) can provide advantages in this regard…”. As with the later part (b), here we have an official government document acknowledging that OSS can have a significant advantage. What’s more, these potential advantages aren’t necessarily just minor cost savings; OSS can in some cases provide a military advantage. Which is a more-than-adequate justification for considering OSS, as I have been advocating for years.

I’m really delighted that this memo has finally been released. I participated in the original brainstorming meeting to create this memo (as did John Scott), and I reviewed many versions of it, but many, many other hands have stirred this pot since it began. It took over 18 months to create it and get it out; getting this coordinated was a very long and drawn-out process. My thanks to everyone who worked to help make this happen. In particular, congrats go to Dan Risacher, who led this project to its successful completion.

By the way, if you’re interested in the issue of open source software in the U.S. military/national defense, you probably should look at Mil-OSS (at least, join their mailing list, and consider going to their upcoming conference; I was a speaker at their last one). If you’re interested in the connection between open source software and the U.S. government (including the military), you might also be interested in the upcoming GOSCON conference on November 5, 2009 (I’m one of the speakers there too).

path: /oss | Current Weblog | permanent link to this entry