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
"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.
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:
- "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."
- "The Government has the rights to reproduce and release the item, and to authorize others to do so...."
- "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