Frequently Asked Questions (FAQ)

 

This is the MIL-OSS Open Source Software (OSS) Frequently-Asked Questions (FAQ).

General Questions

 

Where can I get official information about open source software (OSS) in the U.S. Department of Defense (DoD)?

See the DoD Chief Information Officer (CIO) Free Open Source Software (FOSS) Communities of Interest (COI) site (the URL was changed in March 2012). You can see various useful information there, in particular:

 

What are common definitions of the term "open source software"?

 

"Clarifying Guidance Regarding Open Source Software (OSS)" defines OSS as "software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of that software".

The Free Software Foundation (FSF)'s Free Software Definition defines the related term "Free software" as software in which the program's users have the "four essential freedoms":

  • The freedom to run the program, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

The Open Source Initiative (OSI)'s Open Source Definition says that "Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria..." where the criteria are:

  1. Free Redistribution. The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
  2. Source Code. The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
  3. Derived Works. The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
  4. Integrity of The Author's Source Code. The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
  5. No Discrimination Against Persons or Groups. The license must not discriminate against any person or group of persons.
  6. No Discrimination Against Fields of Endeavor. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
  7. Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
  8. License Must Not Be Specific to a Product. The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
  9. License Must Not Restrict Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
  10. License Must Be Technology-Neutral. No provision of the license may be predicated on any individual technology or style of interface.

 

All of these different definitions are attempts to clearly define the same basic concept of rights that recipients must receive with the software.

 

Is OSS commercial software?

The 16 October 2009 OSS memo explains that "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)))." In particular, under U.S. law, software is commercial if it has at least one non-government use and is licensed to the public. For more about this, see "Open Source Software Is Commercial" by David A. Wheeler (Journal of Software Technology, February 2011).

 

How can I release DoD-funded software as OSS?

The 16 October 2009 OSS memo explains that "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:
(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. For example, the Government has public release rights when the software is developed by Government personnel, when the Government receives 'unlimited rights' in software developed by a contractor at Government expense, or when pre-existing OSS is modified by or for the Government.
(3) The public release of the item is not restricted by other law or regulation, such as the Export Administration Regulations or the International Traffic in Arms Regulation, and the item qualifies for Distribution Statement A, per DoD Directive 5230.24 (reference (i))."

Guidance is available in the Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software - OSD Report, May 2011. Answers to specific questions are available in the DoD Open Source Software (OSS) Frequently Asked Questions (FAQ).

For information about understanding the data rights, see "Publicly Releasing Open Source Software Developed for the U.S. Government" by Dr. David A. Wheeler (Journal of Software Technology, February 2011).

 

Q: Is there any quantitative evidence that open source software can be as good as (or better than) proprietary software?

Yes; Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! is a survey paper that "provides quantitative data that, in many cases, using open source software / free software (abbreviated as OSS/FS, FLOSS, or FOSS) is a reasonable or even superior approach to using their proprietary competition according to various measures.. (its) goal is to show that you should consider using OSS/FS when acquiring software". It points to various studies related to market share, reliability, performance, scalability, security, and total cost of ownership.

 



Q: Does the Antideficiency act (ADA) prohibit all use of OSS due to limitations on voluntary services?


No. Relevant government authorities make it clear that the Antideficiency Act (ADA) does not generally prohibit the use of OSS due to limitations on voluntary services. Instead, the ADA prohibits government employees from accepting services that are not intended or agreed to be gratuitous, but were instead rendered in the hope that Congress will subsequently recognize a moral obligation to pay for the benefits conferred.

Part of the ADA, Pub.L. 97-258, 96 Stat. 923, is in 31 U.S.C. § 1342, Limitation on voluntary services. This statute says that, “An officer or employee of the United States Government or of the District of Columbia government may not accept voluntary services for either government or employ personal services exceeding that authorized by law except for emergencies involving the safety of human life or the protection of property. This section does not apply to a corporation getting amounts to make loans (except paid in capital amounts) without legal liability of the United States Government...”

The US Government Accountability Office (GAO) Office of the General Counsel’s “Principles of Federal Appropriations Law” (aka the “Red Book”) explains federal appropriation law. Volume II of its third edition, section 6.C.3, describes in detail this prohibition on voluntary services. Section 6.C.3.a notes that the voluntary services provision is not new; it first appeared, in almost identical form, back in 1884. The red book explains its purpose; since “an agency cannot directly obligate in excess or advance of its appropriations, it should not be able to accomplish the same thing indirectly by accepting ostensibly ‘voluntary’ services and then presenting Congress with the bill, in the hope that Congress will recognize a ‘moral obligation’ to pay for the benefits conferred...”

The red book section 6.C.3.b explains this prohibition in more detail. It states that in 1913, the Attorney General developed an opinion (30 Op. Att’y Gen. 51 (1913)) that “has become the leading case construing 31 U.S.C. § 1342... the Attorney General drew a distinction that the Comptroller of the Treasury thereafter adopted, and that GAO and the Justice Department continue to follow to this day—the distinction between ‘voluntary services’ and ‘gratuitous services.’” Some key text from this opinion, as identified by the red book, are: “[I]t seems plain that the words ‘voluntary service’ were not intended to be synonymous with ‘gratuitous service’ ... it is evident that the evil at which Congress was aiming was not appointment or employment for authorized services without compensation, but the acceptance of unauthorized services not intended or agreed to be gratuitous and therefore likely to afford a basis for a future claim upon Congress. . . .”

More recent decisions, such as the 1982 decision B-204326 by the U.S. Comptroller General, continue to confirm this distinction between “gratuitous” and “voluntary” service.

In short, the ADA’s limitation on voluntary services does not broadly forbid the government from working with organizations and people who identify themselves as volunteers, including those who develop OSS. Instead, Government employees must ensure that they do not accept services rendered in the hope that Congress will subsequently recognize a moral obligation to pay for the benefits conferred. Services that are intended and agreed to be gratuitous do not conflict with this statute. In most cases, contributors to OSS projects intend for their contributions to be gratuitous, and provide them for all (not just for the Federal government), clearly distinguishing such OSS contributions from the “voluntary services” that the ADA was designed to prevent.

Q: Does the Apache 2.0 license's indemnification clause conflict with the Antideficiency Act?


In general, no. There are circumstances that could create problems, but these are both unlikely and easily avoided.

The Antideficiency Act (ADA), Pub.L. 97-258, 96 Stat. 923, was enacted on September 13, 1982. The GAO summarizes the ADA as prohibiting "federal employees from:

  • making or authorizing an expenditure from, or creating or authorizing an obligation under, any appropriation or fund in excess of the amount available in the appropriation or fund unless authorized by law. 31 U.S.C. § 1341(a)(1)(A).
  • involving the government in any obligation to pay money before funds have been appropriated for that purpose, unless otherwise allowed by law. 31 U.S.C. § 1341(a)(1)(B).
  • accepting voluntary services for the United States, or employing personal services not authorized by law, except in cases of emergency involving the safety of human life or the protection of property. 31 U.S.C. § 1342.
  • making obligations or expenditures in excess of an apportionment or reapportionment, or in excess of the amount permitted by agency regulations. 31 U.S.C. § 1517(a)."


Indemnification clauses in software licenses can run afoul of this act if the clauses require the government to grant a possibly unlimited future liability (or any liability not already appropriated).

However, the Apache license version 2.0 does not require such broad indemnification. The Apache 2.0 license clause 9 ("Accepting Warranty or Additional Liability") instead requires that a redistributor provide indemnification only when additional conditions are met - in this case, when the redistributor provides warranty or indemnification. Clause 9 says in full, "While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability."

It is extremely unlikely that any government agency would trigger this clause by warrantying the software or indemnifying a recipient, so it is quite unlikely that this clause would ever be triggered by government action. But in any case, it would be this later action, not mere acceptance of the Apache 2.0 license, that would potentially run afoul of the ADA. This is simply the same as usual; the government typically does not warranty or indemnify software it releases, and if it did, it would have to determine that value and lawfully receive funding to do it.

There is no formal ruling on this matter, but this is a conclusion that has been previously reached by others (e.g., see "Army lawyers dismiss Apache license indemnification snafu", Fierce Government IT, March 8, 2012).

Q: Does the DoD OSS memo mandate a support vendor for Open Source Software?

No, there is no mandate for a support vendor for open source software. As noted in the article Open Source memo doesn't mandate a support vendor (by David Perera, FierceGovernmentIT, May 23, 2012), the intent "of the memo was not to issue a blanket requirement that all open source software come bundled with contractor support or else it can't be used" as explained by Dan Risacher, primary author of the October 2009 memo on open source software. In particular, "If a Defense agency is able to sustain the open source software with 'its own skills and talents' then that can be enough to satisfy the intent of the memo." In addition, "How robust the support plan need be can also vary on the nature of the software itself... For command and control software, the degree would have to be greater than for something that's not so critical to mission execution...".

All that is required by the DoD OSS 2009 memo is that "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". Note that Government program office support is specifically identified as a possibly-appropriate approach. Many programs and DAAs choose to use commercial support, and in many cases that is the best approach. However, using a support vendor is not the only approach or the best approach in all cases; system/program managers and DAAs must look at the specific situation to make a determination.

Where can I get an answer to my frequently-asked question (FAQ)?

 

The official DoD Open Source Software (OSS) FAQ has answers to many common OSS questions, and is publicly available. If you have access to it, you can see more a more recent version of it on the Intellipedia article, Open Source Software (OSS) FAQ.

The Free Software Foundation (FSF)'s Frequently Asked Questions (FAQ) about the GNU Licenses has a lot of information, focusing on the GNU General Public License (GPL) and Lesser General Public License (LGPL).

The Open Source Definition (Annotated) explains the rationale for the requirements in the Open Source Initiative (OSI)'s open source definition.

CENDI.gov's publications provide a number of answers.

 

Where are the articles from the Software Tech News / Journal of Software Technology?

Software Tech News, which was later renamed to the Journal of Software Technology, published a number of useful articles about open source software.  This journal was published by the Data and Analysis Center for Software (DACS).  As part of a reorganization, the Cyber Security and Information Systems Information Analysis Center (CSIAC) consolidated three information analysis centers (IACs), including the DACS. The CSIAC does provide the information, but fails to provide redirection links, making the information hard to find.

Here are working URLs:

 

 

How can I suggest a new FAQ entry?

Send an email to David A. Wheeler, dwheeler (at) dwheeler (dot) com. Include "xyzzy" in the subject line.