What you need to know about the 2009 DOD OSS Memo

In mid-October, the U.S. Department of Defense CIO released a memo on the use of open source software in the DOD. The Clarifying Guidance Regarding Open Source Software (OSS) was hailed as tremendous leap forward for open source software in the US Government. And indeed it is. At its heart, the memo is fairly simple. The basic points are:

  • This is not formal policy, just a clarification of policy that already exists.
  • OSS is COTS (Commercial, Off-the-Shelf Software) and the same rules that apply to regular software apply to OSS. In other words: you cannot disqualify an open source software product just because it is open source.
  • Further, the memo reminds us that COTS software has special status in DOD procurements, because you’re supposed consider commercial alternatives before writing your own.

The memo has been under development for 18 months, and can trace its lineage to the DOD-commissioned report by MITRE. You can think of the 2007 Navy memo as a kind of prototype for this document, which applies to all of DOD.

The memo’s Attachment 2, though, grows more bold, offering several specific benefits that open source software can offer the DOD:

  • OSS benefits from broader peer review.
  • OSS provides more agility than its proprietary counterparts.
  • OSS reduces barriers to entry and exit for a particular vendor.
  • OSS is net-centric. (!)
  • OSS can be cost-effective when the final deployment size is unknown.
  • OSS mitigates the risk of sole proprietorship, as we’ve seen in government-owned software.
  • OSS is uniquely suited for research and development.

Not sure I could have said it better myself.

Almost more interesting than the OSS memo is the FAQ, which includes legal, procurement, and practical advice for those in the DOD who wish to use OSS, or start their own OSS project. In the FAQ, we learn:

  • The government can release government-funded software under an open source license. So even if the government pays a contractor to write software on its behalf, it has the right t release that software under an open source license.
  • Government employees can contribute to OSS projects.
  • Government employees cannot release software under OSS licenses, because the U.S. copyright protection is not provided to any work created by the United States Government. The government *may*, however, release the software in the public domain.

And I’ll finish with a lovely passage from the memo that declares:

Software source code and associated design documents are ‘data’ as defined by DoD Directive 8320.02 (reference (h)), and therefore shall be shared across the DoD as widely as possible to support mission needs.

Although the memo seems to be innocuous on its face, albeit useful to OSS advocates in the DOD, it seems to open more doors for open source in government than many of us expected.