DoW Open Source Software FAQ

Last updated Jul 28th, 2026.

Frequently Asked Questions regarding Open Source Software (OSS) and the Department of War (DoW)

This page is an educational resource for government employees and government contractors to understand the policies and legal issues relating to the use of open source software (OSS) in the United States Department of War (DoW), also known as the Department of Defense (DoD). The information on this page does not constitute legal advice and any legal questions relating to specific situations should be referred to legal counsel. References to specific products or organizations are for information only, and do not constitute an endorsement of the product/company.

Defining Open Source Software (OSS)

Q: What is open source software (OSS)?

Public Law 115-232 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 such software”. The DoW has used this same definition since the 16 October 2009 memorandum from the DoD CIO, “Clarifying Guidance Regarding Open Source Software (OSS)”, and it is carried forward verbatim in the memorandum that superseded it, “Software Development and Open Source Software” (DoD CIO, 24 January 2022).

Careful legal review is required to determine if a given license is really an open source software license. The following organizations examine licenses; licenses should pass at least the first two industry review processes, and preferably all of them, else they have a greatly heightened risk of not being an open source software license:

• Open source software licenses are reviewed and approved as conforming to the Open Source Definition by the Open Source Initiative (OSI). The OSI publishes a list of licenses which have successfully gone through the approval process and comply with the Open Source Definition.
• In practice, an open source software license must also meet the GNU Free Software Definition; the GNU project publishes a list of licenses that meet the Free Software Definition.
• Fedora reviews licenses and publishes a list of “good” licenses that Fedora has determined are open source software licenses.
• Debian-legal also examines licenses (for Debian) to determine if they meet the Debian social contract; the Debian license information lists licenses that are known to pass (or not pass) these criteria.

In practice, nearly all open source software is released under one of a very few licenses that are known to meet this definition. These licenses include the MIT license, revised BSD license (and its 2-clause variant), the Apache 2.0 license, the GNU Lesser General Public License (LGPL) versions 2.1 or 3, and the GNU General Public License (GPL) versions 2 or

1. Using a standard license simplifies collaboration and eliminates many legal analysis costs.

Q: What are synonyms for open source software?

“Open source software” is also called “Free software”, “libre software”, “Free/open source software (FOSS or F/OSS)”, and “Free/Libre/Open Source Software (FLOSS)”. The term “Free software” predates the term “open source software”, but the term “Free software” has sometimes been misinterpreted as meaning “no cost”, which is not the intended meaning in this context. (“Free” in “Free software” refers to freedom, not price.) The term “open source software” is sometimes hyphenated as “open-source software”.

The DoW has chosen to use the term “open source software” (OSS) in its official policy documents.

Q: What are antonyms for open source software?

Commercially-available software that is not open source software is typically called proprietary or closed source software.

Q: Is this related to “open source intelligence”?

No. In the Intelligence Community (IC), the term “open source” typically refers to overt, publicly available sources (as opposed to covert or classified sources). Thus, Open Source Intelligence (OSINT) is form of intelligence collection management that involves finding, selecting, and acquiring information from publicly available sources and analyzing it to produce actionable intelligence.

As noted above, in software, “Open Source” refers to “software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of such software”.

Q: Is there a name for software whose source code is publicly available, but does not meet the definition of open source software?

At this time there is no widely-accepted term for software whose source code is available for review but does not meet the definition of open source software (due to restrictions on use, modification, or redistribution). Terms that people have used include “source available software”, “open-box software”, “visible-source software”, and “disclosed-source software”. (Such terms might include open source software, but could also include other software).

OSS and DoW Policy

Q: What policies address the use of open source software (OSS) in the Department of War?

The following policies apply:

1. The DoD CIO memorandum “Software Development and Open Source Software”, signed 24 January 2022, is the current DoW-wide policy on OSS. It supersedes the 16 October 2009 memorandum “Clarifying Guidance Regarding Open Source Software (OSS)” (which had itself superseded a May 2003 memo from John Stenbit). Attachment 2 of the 2022 memorandum provides detailed guidance in three areas: use of OSS, use of an open source development approach, and contribution to OSS projects. Among other things, it directs an “Adopt, Buy, Create” approach to software; confirms that OSS meets the definition of “commercial computer software” and must be given equal consideration with proprietary commercial offerings; directs that non-national-security software should be “open-by-default” and released under an OSS license unless specific conditions apply; identifies Apache-2.0, BSD, GPL, LGPL, and MIT as licenses acceptable for DoD use; and authorizes government employees to contribute to OSS projects as part of their official duties.
2. The SHARE IT Act (Source code Harmonization And Reuse in Information Technology Act, Public Law 118-187, 23 December 2024, codified at 44 U.S.C. 3501 note) requires agencies to share custom-developed code across the federal government, and requires agencies contracting for custom software development to acquire rights sufficient to enable government-wide access, sharing, use, and modification of that code. The SHARE IT Act requires government-wide sharing, which is not the same thing as public release as OSS: code stored in a private repository that is accessible to federal employees satisfies the Act. Classified code, code developed primarily for national security systems, and code of Intelligence Community elements are exempt.
3. The Federal Source Code Policy, OMB Memo M-16-21, establishes policy regarding consideration of acquiring custom-developed code, requires agencies to consider the value of publishing custom code as OSS, and established an OSS Pilot Program to release 20% of all custom-developed code as OSS. The DoD was later directed to implement this program by Section 875 of the National Defense Authorization Act for FY2018. The 2022 DoD CIO memorandum cites both as authority. (The three-year pilot term established by M-16-21 has elapsed; the underlying policy direction to consider and publish custom code as OSS has not.)
4. The Department of the Navy has issued SECNAVINST 5230.15, which is focused on ensuring that Commercial Off The Shelf (COTS) Software is supported throughout its fielded lifecycle. This instruction only applies to Navy and Marine Corps commands, but may be a useful reference for others. This SECNAVINST also applies to OSS.
5. The Open Technology Development Roadmap was released by the office of the Deputy Under Secretary of Defense for Advanced Systems and Concepts, on 7 Jun 2006. It is available at https://www.acqnotes.com/Attachments/Open%20Open%20Technology%20Development%20Roadmap%20-%20April%202006.pdf .
6. The Office of Management and Budget issued a memorandum providing guidance on software acquisition which specifically addressed open source software on 1 Jul 2004. It may be found at https://georgewbush-whitehouse.archives.gov/omb/memoranda/fy04/m04-16.html.
7. US Army Regulation 25-2, Army Cybersecurity, dated 4 April 2019, addresses open source software at paragraph 4-12 (“System and services acquisition”), which covers sustainment of open source components and approval of their use. This regulation only applies to the US Army, but may be a useful reference for others. The regulation may also be downloaded directly, though that link is version-specific and will change when the regulation is revised.
8. DA PAM 25-2-5, Army Cybersecurity: Software Assurance, dated 15 September 2021, provides Army procedures for software assurance that address OSS directly. It uses the same definition of OSS as DoW policy (paragraph 2-1.b(3)), treats OSS as one of three software product types alongside COTS and GOTS, and groups OSS licenses into the same permissive, strongly protective, and weakly protective categories used in this FAQ (paragraph 2-2.b(1)). Its glossary describes OSS as “a type of COTS software”, consistent with the treatment of OSS as commercial software described below. Paragraph 2-1.c(2) also directs that all unclassified custom-developed source code created or paid for by the Army on or after August 2016 be registered at code.mil, regardless of data rights or open source status. Like AR 25-2, this pamphlet applies only to the Army, but may be a useful reference for others. The pamphlet may also be downloaded directly, though as with AR 25-2 that link is version-specific.

In nearly all cases, OSS is commercial software, so the policies regarding commercial software continue to apply to OSS.

Q: Isn’t using open source software (OSS) forbidden by DoW Information Assurance (IA) Policy?

No. At a high-level, DoW policy requires commercial software (including OSS) to come with either a warranty or source code, so that the software can be maintained when necessary by the supplier or the government. Since OSS provides source code, there is no problem.

Specifically, the federal government’s security controls, as documented in NIST SP 800-53 revision 5 includes a control enhancement, CM-7(8). Control enhancement CM-7(8) states that an organization must prohibit “the use of binary or machine-executable code from sources with limited or no warranty or without the provision of source code”. This control enhancement is based in the need for some way to update software to fix problems after they are discovered. For commercial software, such needed fixes could be provided by a software vendor as part of a warranty, or in the case of OSS, by the government (or its contractors).

Q: What is the SHARE IT Act, and what does it require?

The Source code Harmonization And Reuse in Information Technology (SHARE IT) Act, Public Law 118-187, was enacted 23 December 2024 and is codified at 44 U.S.C. 3501 note. Its purpose is to stop the federal government from repeatedly paying to develop software it already owns.

The Act imposes four main requirements:

1. Storage and access (section 3(a)). Each agency must ensure that its custom-developed code — along with “documentation, data models, schemas, metadata, architecture designs, configuration scripts, and artifacts required to develop, build, test, and deploy the code” — is stored in at least one public or private repository, is accessible to federal employees, and is owned by the agency.
2. Rights in procurement (section 3(b)). An agency that enters into a contract for the custom development of software “shall acquire and exercise rights sufficient to enable the governmentwide access to, sharing of, use of, and modification of any custom-developed code created in the development of such software.”
3. Discoverability (section 3(c)). Agencies must make metadata about their custom-developed code publicly accessible. This is metadata about the code, not the code itself.
4. Accountability (section 3(d)). Each agency CIO, in consultation with the agency’s Chief Acquisition Officer and the Administrator of the Office of Electronic Government, must issue an agency-wide policy implementing the Act, including procedures for determining exemptions and for federal employees to gain access to repositories. Agencies report exemptions annually, and the Act directs OMB to issue government-wide best practices and the Federal Acquisition Regulation to be revised as necessary to implement it.

The SHARE IT Act complements, rather than replaces, the Federal Source Code Policy (OMB M-16-21) and Section 875 of the FY2018 NDAA. It also complements the DoD CIO’s 2022 memorandum, which independently directs that non-national-security software should be open-by-default.

Q: Does the SHARE IT Act require the government to release software as open source software?

No. This is the most common misreading of the Act, and the distinction matters.

The SHARE IT Act requires government-wide sharing. Section 3(a)(1) requires storage in “not less than 1 public repository or private repository”, and section 3(a)(2) requires that the code be accessible to federal employees. A private repository that federal employees can reach fully satisfies the Act. Public release under an open source license is one way to comply, and often a good one, but it is not what the statute compels.

Section 6 of the Act reinforces this: nothing in it “may be construed as requiring the disclosure of information or records that are exempt from public disclosure” under the Freedom of Information Act.

Separately, the DoD CIO memorandum “Software Development and Open Source Software” (24 January 2022) does direct that software developed for systems other than National Security Systems “should be open-by-default and released (under an open source software license)” unless specific conditions apply. So a DoW program may well have an obligation to consider public release — but that obligation comes from DoW policy, not from the SHARE IT Act.

Q: What software does the SHARE IT Act apply to?

The Act applies to “custom-developed code”, which section 2(3) defines as source code that is either produced in the performance of a contract with an agency or otherwise exclusively funded by the federal government, or developed by a federal employee as part of the employee’s official duties.

The definition expressly includes source code, or segregable portions of source code, “for which the Federal Government could obtain unlimited rights under part 27 of the Federal Acquisition Regulation or any relevant supplemental acquisition regulations of an agency” (emphasis added). This reaches code for which the government could have obtained unlimited rights, which is broader than the code for which it actually did.

The definition expressly excludes:

• source code that is “solely exploratory or disposable in nature”, such as code written by a developer experimenting with a new language or library; and
• commercial computer software, commercially available off-the-shelf software, and configuration scripts for such software.

Because nearly all OSS is commercial computer software (see the questions above), pre-existing OSS that the Department merely uses is outside the scope of the Act. The Act is concerned with the custom code the government pays to have written.

The Act applies prospectively. Under section 7, it reaches custom-developed code developed or revised by a federal employee on or after 21 June 2025 (180 days after enactment), or developed under a contract awarded pursuant to a solicitation issued on or after that date.

Q: What is exempt from the SHARE IT Act?

Section 4 provides two kinds of exemption.

Automatic exemptions (section 4(a)(1)) apply by operation of law and require no determination:

• classified source code;
• source code developed primarily for use in a national security system, as defined in 40 U.S.C. 11103;
• source code developed by an agency, or part of an agency, that is an element of the intelligence community, as defined in 50 U.S.C. 3003(4); and
• source code whose disclosure is exempt under the Freedom of Information Act.

Discretionary exemptions (section 4(a)(2)) may be granted by the agency CIO, in consultation with the Federal Privacy Council, where either the agency is prohibited from providing the source code under another federal law or regulation — the Act specifically names the Export Administration Regulations, the International Traffic in Arms Regulations, TSA rules on Sensitive Security Information, and laws governing classified information not already covered — or where sharing or public accessibility “would create an identifiable risk to the privacy of an individual.”

Agencies must report exemptions annually with a narrative justification for each, and those reports go to Congress.

For the DoW, the national security system and classified exemptions carve out a substantial share of the Department’s software. But note that “national security system” is a defined term in 40 U.S.C. 11103, not a synonym for “military” or “operational” — a great deal of DoW custom-developed software is not an NSS and is therefore squarely within the Act. Do not assume an exemption applies; the determination belongs to the Component CIO under the procedures required by section 3(d)(1)(A)(ii)(I).

Q: What does the SHARE IT Act change for software acquisition?

Section 3(b) is the provision with the most direct effect on contracting. It requires that an agency contracting for custom software development “acquire and exercise rights sufficient to enable the governmentwide access to, sharing of, use of, and modification of any custom-developed code created in the development of such software.”

Two points are worth drawing out. First, the obligation is not merely to acquire rights but to exercise them — rights that are acquired and then left unused do not satisfy the provision. Second, the standard is government-wide, not agency-specific: rights sufficient for the contracting agency alone are not enough.

In DoW practice, “unlimited rights” under DFARS 252.227-7014 already exceed this standard, and Government Purpose Rights may or may not, depending on the terms negotiated. Programs acquiring non-commercial software should already be planning to take delivery of source code under 10 U.S.C. 2322a and the 2022 DoD CIO memorandum; section 3(b) adds a statutory floor beneath that planning. Section 8 of the Act directs that the Federal Acquisition Regulation be revised as necessary to implement these requirements.

Q: How is the DoW implementing the SHARE IT Act?

Implementing guidance is in development. Because section 3(d)(1) requires an agency-wide policy issued by the CIO, the authoritative answer for any particular program will come from that policy and from Component CIO direction beneath it, and readers should check for current guidance rather than relying on this FAQ for implementation detail.

In general terms, the Department’s approach is expected to begin with visibility: establishing an enterprise registry of custom-developed software projects, so that the Department knows what software it has already paid to develop before it pays to develop it again. Related themes include validation of releasability determinations by Component CIOs consistent with existing policy on distribution statements and controlled unclassified information, designated repositories for components that do not already have one, and structuring software along modular open systems lines so that reusable components can be separated from those carrying dissemination restrictions.

A reporting obligation already exists independent of the SHARE IT Act: under the 2022 DoD CIO memorandum, whenever a DoD Component first releases a software codebase as OSS or for government-wide re-use, it must report that to its Component CIO.

General information about OSS

Q: Is OSS commercial software? Is it COTS?

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.

Open source software that has at least one non-governmental use, and is licensed to the public, is commercial software. If it is already available to the public and is used unchanged, it is usually COTS.

U.S. law governing federal procurement U.S. Code Title 41, Section 103 defines “commercial product” as including “a product, other than real property, that— (A) is of a type customarily used by the general public or by nongovernmental entities for purposes other than governmental purposes; and (B) has been sold, leased, or licensed, or offered for sale, lease, or license, to the general public…”. Thus, as long as the software has at least one non-governmental use, software licensed (or offered for license) to the public is a commercial product for procurement purposes.

Similarly, U.S. Code Title 41, Section 104 defines the term “Commercially available off-the-shelf (COTS) item”; software is COTS if it is (a) a “commercial product”, (b) sold in substantial quantities in the commercial marketplace, and (c) is offered to the Federal Government, without modification, in the same form in which it is sold in the commercial marketplace. Thus, OSS available to the public and used unchanged is normally COTS.

These definitions in U.S. law govern U.S. acquisition regulations, namely the Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation Supplement (DFARS). DFARS 252.227-7014, Rights in Noncommercial Computer Software and Noncommercial Computer Software Documentation (48 CFR 252.227-7014) defines “commercial computer software” as software developed or regularly used for non-governmental purposes that has been sold, leased or licensed to the public, has been offered for such sale, lease or license, will be available commercially in time to satisfy the contract’s delivery requirements, or meets one of those tests and would need only minor modification to meet the contract’s requirements.

There are many other reasons to believe nearly all OSS is commercial software:

• OSS is increasingly commercially developed and supported.
• OSS projects typically seek financial gain in the form of improvements. U.S. Code Title 17, section 101 (part of copyright law) explicitly defines the term “financial gain” as including “receipt, or expectation of receipt, of anything of value, including the receipt of other copyrighted works.”
• OSS licenses and projects clearly approve of commercial support

This is confirmed by DoW policy. The 2022 DoD CIO memorandum “Software Development and Open Source Software”, Attachment 2, paragraph 2.A(1), states that “OSS meets the definition of ‘commercial computer software’ and therefore, shall be given equal consideration with proprietary commercial offerings, in accordance with Section 2377 of Title 10, U.S.C.” (now 10 U.S.C. 3453), citing also FAR 2.101(b), 12.000, and 12.101, and DFARS 212.212, 208.74, 227.7202, and 252.227-7014(a)(1). For more discussion on this topic, see the article Open Source Software Is Commercial.

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.

Q: Why is it important to understand that open source software is commercial software?

A large body of law, regulation and policy governs commercial software, and treating OSS as something else means failing to apply it.

In particular, U.S. law (10 U.S.C. 3453, formerly 10 U.S.C. 2377, renumbered by Public Law 116-283 § 1821(a)(2)) requires a preference for commercial products for procurement of supplies or services. 10 U.S.C. 3453 requires that the head of an agency shall ensure that procurement officials in that agency, to the maximum extent practicable: acquire commercial products and services to meet agency needs; require prime contractors and subcontractors to incorporate them as components; modify requirements where doing so would let commercial products meet them; state specifications in terms that encourage offerors to propose commercial products; remove impediments to commercial acquisition from agency procurement policy; and train personnel in commercial acquisition.

The same section requires market research to determine whether commercial products are available that meet the agency’s requirements, could be modified to meet them, or could meet them if the requirements themselves were modified to a reasonable extent. That research must occur before the agency develops new specifications, and before it solicits any contract above the simplified acquisition threshold.

An agency that failed to consider open source software, and instead only considered proprietary software, would fail to comply with these laws, because it would unjustifiably exclude a significant part of the commercial market. This is particularly the case where future modifications by the U.S. government may be necessary, since OSS by definition permits modification.

Q: Are “non-commercial software”, “freeware”, or “shareware” the same thing as open source software?

No.

Do not mistakenly use the term “non-commercial software” as a synonym for “open source software”. As noted above, in nearly all cases, open source software is considered “commercial software” by U.S. law, the FAR, and the DFARS. DFARS 252.227-7014 specifically defines “commercial computer software” in a way that includes nearly all OSS, and defines “noncommercial computer software” as software that does not qualify as “commercial computer software”. In addition, important open source software is typically supported by one or more commercial firms.

As of 2021, the terms “freeware” and “shareware”, do not appear to have official definitions used by the United States Government, but historically (for example in the now-superseded DoD Instruction 8500.2) these terms have been used specifically for software distributed without cost where the Government does not have access to the original source code.

Q: How is OSS typically developed?

OSS is typically developed through a collaborative process.

Most OSS projects have a “trusted repository”, that is, some (web) location where people can get the “official” version of the program, as well as related information (documentation, bug report system, mailing lists, etc.). Users can get their software directly from the trusted repository, or get it through distributors who acquire it (and provide additional value such as integration with other components, testing, special configuration, support, and so on).

Only some developers are allowed to modify the trusted repository directly: the trusted developers. At project start, the project creators (who create the initial trusted repository) are the trusted developers, and they determine who else may become a trusted developer of this initial trusted repository. All other developers can make changes to their local copies, and even post their versions to the Internet (a process made especially easy by distributed software configuration management tools), but they must submit their changes to a trusted developer to get their changes into the trusted repository.

Users can send bug reports to the distributor or trusted repository, just as they could for a proprietary program. But what is radically different is that a user can actually make a change to the program itself (either directly, or by hiring someone to do it). Since users will want to use the improvements made by others, they have a strong financial incentive to submit their improvements to the trusted repository. That way, their improvements will be merged with the improvements of others, enabling them to use all improvements instead of only their own.

This can create an avalanche-like “virtuous cycle”. As the program becomes more capable, more users are attracted to using it. A very small percentage of such users determine that they can make a change valuable to them, and contribute it back (to avoid maintenance costs). As more improvements are made, more people can use the product, creating more potential users as developers - like a snowball that gains mass as it rolls downhill.

This enables cost-sharing between users, as with proprietary development models. However, this cost-sharing is done in a rather different way than in proprietary development. In particular, note that the costs borne by a particular organization are typically only those for whatever improvements or services are used (e.g., installation, configuration, help desk, etc.). In contrast, typical proprietary software costs are per-seat, not per-improvement or service. However, it must be noted that the OSS model is much more reflective of the actual costs borne by development organizations. It costs essentially nothing to download a file. Once software exists, all costs are due to maintenance and support of software. In short, OSS more accurately reflects the economics of software development; some speculate that this is one reason why OSS has become so common.

Q: Isn’t OSS developed primarily by inexperienced students?

No, OSS is developed by a wide variety of software developers, and the average developer is quite experienced. A Boston Consulting Group study found that the average age of OSS developers was 30 years old, the majority had training in information technology and/or computer science, and on average had 11.8 years of computer programming experience.

Q: Is open source software the same as “open systems/open standards”?

No, although they work well together, and both are strategies for reducing “vendor lock-in”. Vendor lock-in, aka lock-in, is the situation in which customers are dependent on a single supplier for some product (i.e., a good or service), or products, and cannot move to another vendor without substantial costs and/or inconvenience. Lock-in tends to raise costs substantially, reduces long-term value (including functionality, innovation, and reliability), and can become a serious security problem (since the supplier has little incentive to provide a secure product and to quickly fix problems found later).

An “Open System” is a “system that employs modular design, uses widely supported and consensus based standards for its key interfaces, and has been subjected to successful V&V tests to ensure the openness of its key interfaces” (per the DoD Open Systems Joint Task Force). Thus, open systems require standards that are widely-supported and consensus-based; standards that meet these (and possibly some additional conditions) may be termed “open standards”. Open systems and open standards counter dependency on a single supplier, though only if there is a competing marketplace of replaceable components. Indeed, according to Walli, “Standards exist to encourage & enable multiple implementations”. Many governments, not just the U.S., view open systems as critically necessary. 10 U.S.C. 4401 (formerly 10 U.S.C. 2446a) requires that a major defense acquisition program receiving Milestone A or Milestone B approval after 1 January 2019 “shall be designed and developed, to the maximum extent practicable, with a modular open system approach to enable incremental development and enhance competition, innovation, and interoperability”, and provides that other defense acquisition programs shall also be so designed and developed. DoD Directive 5000.01 treats modular and open design as a means of preserving competition, noting at paragraph 1.2.e(2) that “planning and contracting for appropriate amounts of data rights, and incorporating a modular and open design to enable upgrades, technology refreshes, and future re-competes may enhance competition throughout the life cycle”. The European Commission identifies open standards as a major policy thrust.

There are many definitions for the term “open standard”. Fundamentally, a standard is a specification, so an “open standard” is a specification that is “open”. Public definitions include the European Interoperability Framework (EIF), maintained by the European Commission, and the Free Software Foundation Europe definition of Open Standards. Bruce Perens’ “Open Standards: Principles and Practice” is another widely-cited definition; it is linked here through the Internet Archive, as Perens’ site is no longer online.

In the DoW, Joint Assessments and Standards Management (JASM) is a useful resource for identifying recommended standards (which tend to be open standards). JASM is a collection of web-based applications supporting the continuing evolution of Department of Defense (DoD) Information Technology Standards, and hosts the DoD Information Technology Standards Registry (DISR). JASM replaces the former GIG Technical Guidance Federation (GTG-F). JASM requires DoD PKI authentication and is not accessible to the general public. The Modular Open Systems Approach web page, maintained by Systems Engineering and Architecture under Research and Engineering, also provides some useful background.

Many DoW capabilities are accessible via web browsers using open standards such as TCP/IP, HTTP, and HTML; in such cases, it is relatively easy to use or switch to open source software implementations (since the platforms used to implement the client or server become less relevant). As noted by the OSJTF definition for open systems, be sure to test such systems with more than one web browser (e.g., Google Chrome, Microsoft Edge and Firefox), to reduce the risk of vendor lock-in.

Q: How does open source software work with open systems/open standards?

Open standards can aid open source software projects:

• Open standards make it easier for users to (later) adopt an open source software program, because users of open standards aren’t locked into a particular implementation. Instead, users who are careful to use open standards can easily switch to a different implementation, including an OSS implementation.
• Open standards also make it easier for OSS developers to create their projects, because the standard itself helps developers know what to do. Creating any interface is an effort, and having a pre-defined standard helps reduce that effort greatly.

Open standards aid proprietary software in exactly the same way.

OSS aids open standards, too:

• OSS implementations can help create and keep open standards open. An OSS implementation can be read and modified by anyone; such implementations can quickly become a working reference model (a “sample implementation” or an “executable specification”) that demonstrates what the specification means (clarifying the specification) and demonstrating how to actually implement it. Perhaps more importantly, by forcing there to be an implementation that others can examine in detail, resulting in better specifications that are more likely to be used.
• OSS implementations can help rapidly increase adoption/use of the open standard. OSS programs can typically be simply downloaded and tried out, making it much easier for people to try it out and encouraging widespread use. This also pressures proprietary implementations to limit their prices, and such lower prices for proprietary software also encourages use of the standard.

With practically no exceptions, successful open standards for software have OSS implementations.

So, while open systems/open standards are different from open source software, they are complementary and can work well together.

Q: How does open source software relate to the Buy American Act?

As noted by the 24 January 2022 policy memorandum from the DoD CIO, “Software Development and Open Source Software”, in almost all cases OSS is a commercial product as defined by US Law (Title 41) and regulation (the FAR).

The Buy American Act does not apply to information technology that is a commercial item, so there is usually no problem for OSS. FAR 25.103(e) exempts commercial information technology from the restriction on purchasing foreign end products, for fiscal year 2004 and subsequent fiscal year funds.

OSS Licenses

Q: What is the legal basis of OSS licenses?

Software licenses, including those for open source software, are typically based on copyright law. Under U.S. copyright law, users must have permission (i.e. a license) from the copyright holder(s) before they can obtain a copy of software to run on their system(s). Authors of a creative work, or their employer, normally receive the copyright once the work is in a fixed form (e.g., written/typed). Others can obtain permission to use a copyrighted work by obtaining a license from the copyright holder. Typically, obtaining rights granted by the license can only be obtained when the requestor agrees to certain conditions. For example, users of proprietary software must typically pay for a license to use a copy or copies. Open source software licenses grant more rights than proprietary software licenses, but they are still conditional licenses that require the user to obey certain terms.

Software licenses (including OSS licenses) may also involve the laws for patent, trademark, and trade secrets, in addition to copyright.

Export control laws are often not specifically noted in OSS licenses, but nevertheless these laws also govern when and how software may be released.

Q: Are OSS licenses legally enforceable?

Yes, in general. For advice about a specific situation, however, consult with legal counsel.

The U.S. Court of Appeals for the Federal Circuit’s 2008 ruling on Jacobsen v. Katzer made it clear that OSS licenses are enforceable, even if money is not exchanged. The court held that a copyright holder may dedicate a “certain work to free public use and yet enforce an ‘open source’ copyright license to control the future distribution and modification of that work”. On the absence of a fee it was explicit: “The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration… The choice to exact consideration in the form of compliance with the open source requirements of disclosure and explanation of changes, rather than as a dollar-denominated fee, is entitled to no less legal recognition.” The court also observed that because damages in these cases are inherently speculative, license restrictions of this kind could be rendered meaningless without injunctive relief. It determined that the OSS license at issue, the Artistic License, was an enforceable license.

In 2017, the United States District Court for the Northern District of California, in Artifex Software, Inc. v. Hancom, Inc., No. 16-cv-06982 (N.D. Cal.), issued a ruling confirming the enforceability of the GNU General Public License. The court treated the GPL as an enforceable contract, in addition to a copyright license, and held that the absence of a monetary licensing fee did not preclude a claim for damages. The ruling was a denial of a motion for summary judgement, and the parties ultimately settled the claim out-of-court.

In 2015, a series of decisions regarding the GNU General Public License were issued by the United States District Courts for the Western District of Texas as well as the Northern District of California. These decisions largely held that the GNU General Public License, version 2 was enforceable in a series of five related legal cases loosely referred to as “Versata v. Ameriprise”, although there were related suits against Versata by XimpleWare. These cases were eventually settled by the parties, but not before certain claims regarding the GPLv2 were decided. The cases are too complicated to summarize here, other than to say that the GPLv2 was clearly regarded as enforceable by the courts.

A more recent case, Software Freedom Conservancy, Inc. v. Vizio, Inc. (Superior Court of California, County of Orange, filed 2021), raises a distinct question: whether a recipient of OSS, and not only the copyright holder, may enforce the license. The Software Freedom Conservancy sued as a purchaser of Vizio televisions rather than as a copyright holder, arguing that GPLv2 and LGPLv2.1 create contractual obligations enforceable by recipients of the software as third-party beneficiaries. In December 2023 the court denied Vizio’s motion for summary judgment, holding that the breach of contract claim was not preempted by the Copyright Act. In December 2025 the court granted summary adjudication to Vizio on a separate question, holding that GPLv2 and LGPLv2.1 do not require a distributor to enable reinstallation of modified software onto the original device (an obligation that GPLv3 addresses expressly). As of this writing the third-party beneficiary question has not been finally resolved, and trial is scheduled for August 2026. Should that theory ultimately succeed, its practical significance would be considerable, since it would mean that recipients of OSS, not merely copyright holders, can enforce license terms.

“Enforcing the GNU GPL” by Eben Moglen is a brief essay that argues why the GNU General Public License (GPL), specifically, is enforceable. U.S. courts have determined that the GPL does not violate anti-trust laws. In Wallace vs. FSF, Judge Daniel Tinder stated that “the GPL encourages, rather than discourages, free competition and the distribution of computer operating systems…” and found no anti-trust issues with the GPL. Similarly, in Wallace v. IBM, Red Hat, and Novell, 467 F.3d 1104 (7th Cir. 2006), the U.S. Court of Appeals for the Seventh Circuit found in November 2006 that the GNU General Public License (GPL) “and open-source software have nothing to fear from the antitrust laws”. German courts have enforced the GPL.

Q: What are the major types of open source software licenses?

OSS licenses can be grouped into three main categories: Permissive, strongly protective, and weakly protective. Here is an explanation of these categories, along with common licenses used in each category (see The Free-Libre / Open Source Software (FLOSS) License Slide):

• Permissive: These licenses permit the software to become proprietary (i.e., not OSS). This includes the MIT license and the revised BSD license. The Apache 2.0 license is also a popular license in this category; note that the Apache 2.0 license is compatible with GPL version 3, but not with GPL version 2.
• Strongly Protective (aka strong copyleft): These licenses prevent the software from becoming proprietary, and instead enforce a “share and share alike” approach. In such licenses, if you give someone a binary of the program, you are obligated to give them the source code (perhaps upon request) under the same terms. This includes the most popular OSS license, the GNU General Public License (GPL). There are two versions of the GPL in common use today: the older version 2, and the newer version 3.
• Weakly Protective (aka weak copyleft): These licenses are a compromise between permissive and strongly protective licenses. These prevent the software component (often a software library) from becoming proprietary, yet permit it to be part of a larger proprietary program. The GNU Lesser General Public License (LGPL) is the most popular such license, and there are two versions in common use: the older version 2.1 and newer version 3. An alternative approach is to use the GPL plus a GPL linking exception term (such as the “Classpath exception”).

Q: How can you determine if different open source software licenses are compatible?

In general, legal analysis is required to determine if multiple programs, covered by different OSS licenses, can be legally combined into a single larger work. This legal analysis must determine if it is possible to meet the conditions of all relevant licenses simultaneously. If it is possible to meet the conditions of all relevant licenses simultaneously, then those licenses are compatible.

Thankfully, such analyses has already been performed on the common OSS licenses, which tend to be mutually compatible. Many analyses focus on versions of the GNU General Public License (GPL), since this is the most common OSS license, but analyses for other licenses are also available. Resources for further information include:

• GPL FAQ (Focuses on compatibility between versions of the GPL and LGPL)
• The Free-Libre / Open Source Software (FLOSS) License Slide
• Various Licenses and Comments about Them
• Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers (Software Freedom Law Center)
• Fedora Licensing

In brief, the MIT and 2-clause BSD license are dominated by the 3-clause BSD license, which are all dominated by the LGPL licenses, which are all dominated by the GPL licenses. By “dominate”, that means that when software is merged which have those pairs of licenses, the dominating license essentially governs the resulting combination because the dominating license essentially includes all the key terms of the other license. This also means that these particular licenses are compatible. The Apache 2.0 license is compatible with the GPL version 3 license, but not the GPL version 2 license. The GPL version 2 and the GPL version 3 are in principle incompatible with each other, but in practice, most released OSS states that it is “GPL version 2 or later” or “GPL version 3 or later”; in these cases, version 3 is a common license and thus such software is compatible.

This sometimes depends on how the program is used or modified. For example, the LGPL permits the covered software (usually a library) to be embedded in a larger work under many different licenses (including proprietary licenses), subject to certain conditions. However, if the covered software/library is itself modified, then additional conditions are imposed.

This need for legal analysis is one reason why creating new OSS licenses is strongly discouraged: It can be extremely difficult, costly, and time-consuming to analyze the interplay of many different licenses. It is usually far better to stick to licenses that have already gone through legal review and are widely used in the commercial world.

Q: Can OSS licenses and approaches be used for material other than software?

Yes. The Creative Commons is a non-profit organization that provides free tools, including a set of licenses, to “let authors, scientists, artists, and educators easily mark their creative work with the freedoms they want it to carry”. A copyright holder who releases creative works under one of the Creative Common licenses that permit commercial use and modifications would be using an OSS-like approach for such works. Wikipedia maintains an encyclopedia using approaches similar to open source software approaches. Creative Commons does not recommend that you use one of their licenses for software; they encourage using one of the existing OSS licenses which “were designed specifically for use with software”.

Computer and electronic hardware that is designed in the same fashion as open source software (OSS) is sometimes termed open source hardware. The term has primarily been used to reflect the free release of information about the hardware design, such as schematics, bill of materials and PCB layout data, or its representation in a hardware description language (HDL), often with the use of open source software to drive the hardware.

Software/hardware for which the implementation, proofs of its properties, and all required tools are released under an OSS license are termed open proofs(see the open proofs website for more information).

Where it is unclear, make it clear what the “source” or “source code” means.

(See GPL FAQ, “Can I use the GPL for something other than software?”.)

Q: Is it more difficult to comply with OSS licenses than proprietary licenses?

No, complying with OSS licenses is much easier than proprietary licenses if you only use the software in the same way that proprietary software is normally used. By definition, OSS software permits arbitrary use of the software, and allows users to re-distribute the software to others. The terms that apply to usage and redistribution tend to be trivially easy to meet (e.g., you must not remove the license or author credits when re-distributing the software). Thus, complex license management processes to track every installation or use of the software, or who is permitted to use the software, is completely unnecessary. Support for OSS is often sold separately for OSS; in such cases, you must comply with the support terms for those uses to receive support, but these are typically the same kinds of terms that apply to proprietary software (and they tend to be simpler in practice).

It is only when the OSS is modified that additional OSS terms come into play, depending on the OSS license. Since it is typically not legal to modify proprietary software at all, or it is legal only in very limited ways, it is trivial to determine when these additional terms may apply. The real challenge is one of education - some developers incorrectly believe that just because something is free to download, it can be merged or changed without restriction. This has never been true, and explaining this takes little time.

Q: Who can enforce OSS licenses?

Typically enforcement actions are based on copyright violations, and only copyright holders can raise a copyright claim in U.S. court. In the commercial world, the copyright holders are typically the individuals and organizations that originally developed the software. Under the current DoW contracting regime, the contractor usually retains the copyright for software developed with government funding, so in such cases the contractor (not the government) has the right to sue for copyright violation. In some cases, the government obtains the copyright; in those cases, the government can sue for copyright violation.

However, the government can release software as OSS when it has unlimited rights to that software. The government is not the copyright holder in such cases, but the government can still enforce its rights. Although the government cannot directly sue for copyright violation, in such cases it can still sue for breach of license and, presumably, get injunctive relief to stop the breach and money damages to recover royalties obtained by breaching the license (and perhaps other damages as well).

In addition, a third party who breaches a software license (including for OSS) granted by the government risks losing rights they would normally have due to the “doctrine of unclean hands”. The doctrine of unclean hands, per law.com, is “a legal doctrine which is a defense to a complaint, which states that a party who is asking for a judgment cannot have the help of the court if he/she has done anything unethical in relation to the subject of the lawsuit. Thus, if a defendant can show the plaintiff had ‘unclean hands,’ the plaintiff’s complaint will be dismissed or the plaintiff will be denied judgment.” So if the government releases software as OSS, and a malicious developer performs actions in violation of that license, then the government’s courts might choose to not enforce any of that malicious developer’s intellectual rights to that result. In effect, the malicious developer could lose many or all rights over their license-violating result, even rights they would normally have had! Since OSS licenses are quite generous, the only license-violating actions a developer is likely to try is to release software under a more stringent license… and those will have little effect if they cannot be enforced in court.

See GPL FAQ, “Who has the power to enforce the GPL?”.

Q: Do “choice of venue” clauses automatically disqualify OSS licences?

No. A “choice of venue” clause is a clause that states where a dispute is to be resolved (e.g., which court). Many OSS licenses do not have a choice of venue clause, and thus cannot have an issue, although some do.

If your contract has FAR clause 52.212-4 (which it is normally required to do), then choice of venue clauses in software licenses are undesirable, but the order of precedence clause (in the contract) means that the choice of venue clause (in the license) is superseded by the Contract Disputes Act. Thus, in many cases a “choice of venue” clause is not an insurmountable barrier to acceptance of the software delivery by the government.

For software delivered under federal contracts, any “choice of venue” clauses in the license generally conflict with the Contract Disputes Act. However, the required FAR 52.212-4(d) establishes that the contract is subject to the Contract Disputes Act of 1978, as amended (41 U.S.C. 7101-7109). Its order of precedence clause at 52.212-4(s) then resolves inconsistencies in this order: (1) the schedule of supplies or services; (2) the Assignments, Disputes, Payments, Invoice, Other Compliances, and Compliance with Laws Unique to Government Contracts paragraphs of that clause; (3) the clause at 52.212-5; and (4) addenda to the solicitation or contract, including any license agreements for computer software.

This clause establishes that the choice of venue clause (category 4) is superseded by the Contract Disputes Act (category 2), and thus the conflict is typically moot. Government lawyers and Contracting Officers are trained to try to negotiate licenses which resolve these ambiguities without having to rely on the less-satisfying “Order of Precedence”, but generally accede when licenses in question are non-negotiable, such as with OSS licenses in many cases. As always, if there are questions, consult your attorney to discuss your specific situation.

OSS and Security/Software Assurance/System Assurance/Supply Chain Risk Management

Q: Does the DoW use OSS for security functions?

Yes. The 2003 MITRE study, “Use of Free and Open Source Software (FOSS) in the U.S. Department of Defense”, for analysis purposes, posed the hypothetical question of what would happen if OSS software were banned in the DoD, and found that OSS “plays a far more critical role in the DoD than has been generally recognized… (especially in) Infrastructure Support, Software Development, Security, and Research”. In particular, it found that DoD security “depends on (OSS) applications and strategies”, and that a hypothetic ban “would have immediate, broad, and in some cases strongly negative impacts on the ability of the DoD to analyze and protect its own networks against hostile intrusion. This is in part because such a ban would prevent DoD groups from using the same analysis and network intrusion applications that hostile groups could use to stage cyberattacks. It would also remove the uniquely (OSS) ability to change infrastructure source code rapidly in response to new modes of cyberattack”.

Q: Doesn’t hiding source code automatically make software more secure?

No. Indeed, vulnerability databases such as CVE make it clear that merely hiding source code does not counter attacks:

• Dynamic attacks (e.g., generating input patterns to probe for vulnerabilities and then sending that data to the program to execute) don’t need source or binary. Observing the output from inputs is often sufficient for attack.
• Static attacks (e.g., analyzing the code instead of its execution) can use pattern-matches against binaries - source code is not needed for them either.
• Even if source code is necessary (e.g., for source code analyzers), adequate source code can often be regenerated by disassemblers and decompilers sufficiently to search for vulnerabilities. Such source code may not be adequate to cost-effectively maintain the software, but attackers need not maintain software.
• Even when the original source is necessary for in-depth analysis, making source code available to the public significantly aids defenders and not just attackers. Continuous and broad peer-review, enabled by publicly available source code, improves software reliability and security through the identification and elimination of defects that might otherwise go unrecognized by the core development team. Conversely, where source code is hidden from the public, attackers can attack the software anyway as described above. In addition, an attacker can often acquire the original source code from suppliers anyway (either because the supplier voluntarily provides it, or via attacks against the supplier); in such cases, if only the attacker has the source code, the attacker ends up with another advantage.

Hiding source code does inhibit the ability of third parties to respond to vulnerabilities (because changing software is more difficult without the source code), but this is obviously not a security advantage. In general, “Security by Obscurity” is widely denigrated.

This does not mean that the DoW will reject using proprietary COTS products. There are valid business reasons, unrelated to security, that may lead a commercial company selling proprietary software to choose to hide source code (e.g., to reduce the risk of copyright infringement or the revelation of trade secrets). What it does mean, however, is that the DoW will not reject consideration of a COTS product merely because it is OSS. Some OSS is very secure, while others are not; some proprietary software is very secure, while others are not. Each product must be examined on its own merits.

Q: What are indicators that a specific OSS program will have fewer unintentional vulnerabilities?

As noted in the Secure Programming for Linux and Unix HOWTO, three conditions reduce the risks from unintentional vulnerabilities in OSS:

1. Developers/reviewers need security knowledge. Knowledge is more important than the licensing scheme.
2. People have to actually review the code.
   • This has a reduced likelihood if the program is niche or rarely-used, has few developers, uses a rare computer language, or is not really OSS. Conversely, if it widely-used, has many developers, and so on, the likelihood of review increases. Examine if it is truly community-developed - or if there are only a very few developers.
   • Review really does happen. Several static tool vendors support analysis of OSS (such as Coverity and Sonatype) as a way to improve their tools and gain market use. There are many general OSS review projects, such as those by OpenBSD and the Debian Security Audit team. And of course, individual OSS projects often have security review processes or methods (such as Mozilla’s bounty system). If there are reviewers from many different backgrounds (e.g., different countries), this can also reduce certain risks. When examining a specific OSS project, look for evidence that review (both by humans and tools) does take place.
3. Problems must be fixed. It is far better to fix vulnerabilities before deployment - are such efforts occuring? When the software is already deployed, does the project develop and deploy fixes?

Q: Is there a risk of malicious code becoming embedded into OSS?

Yes, and the same is true of proprietary software. Binaries of either kind can be modified after release to add malicious code; that modification may be illegal, but illegality does not slow an attacker. The risk cannot be eliminated, only reduced to an acceptable level, and there are ways to do so.

The use of software with a proprietary license provides absolutely no guarantee that the software is free of malicious code. Indeed, many people have released proprietary code that is malicious. What’s more, proprietary software release practices make it more difficult to be confident that the software does not include malicious code. Such software does not normally undergo widespread public review, indeed, the source code is typically not provided to the public and there are often license clauses that attempt to inhibit review further (e.g., forbidding reverse engineering and/or forbidding the public disclosure of analysis results). Thus, to reduce the risk of executing malicious code, potential users should consider the reputation of the supplier and the experience of other users, prefer software with a large number of users, and ensure that they get the “real” software and not an imitator. Where it is important, examining the security posture of the supplier (e.g., their processes that reduce risk) and scanning/testing/evaluating the software may also be wise.

Similarly, OSS (as well as proprietary software) may indeed have malicious code embedded in it. However, such malicious code cannot be directly inserted by “just anyone” into a well-established OSS project. As noted above, OSS projects have a “trusted repository” that only certain developers (the “trusted developers”) can directly modify. In addition, since the source code is publicly released, anyone can review it, including for the possibility of malicious code. The public release also makes it easy to have copies of versions in many places, and to compare those versions, making it easy for many people to review changes. Many perceive this openness as an advantage for OSS, since OSS better meets Saltzer & Schroeder’s “Open design principle” (“the protection mechanism must not depend on attacker ignorance”). This is not merely theoretical; in 2003 the Linux kernel development process resisted an attack. Similarly, SourceForge/Apache (in 2001) and Debian (in 2003) countered external attacks.

As with proprietary software, to reduce the risk of executing malicious code, potential users should consider the reputation of the supplier (the OSS project) and the experience of other users, prefer software with a large number of users, and ensure that they get the “real” software and not an imitator (e.g., from the main project site or a trusted distributor). Where it is important, examining the security posture of the supplier (the OSS project) and scanning/testing/evaluating the software may also be wise.

The example of Borland’s InterBase/Firebird is instructive. For at least 7 years, Borland’s Interbase (a proprietary database program) had embedded in it a “back door”; the username “politically”, password “correct”, would immediately give the requestor complete control over the database, a fact unknown to its users. Whether or not this was intentional, it certainly had the same form as a malicious back door. When the program was released as OSS, within 5 months this vulnerability was found and fixed. This shows that proprietary software can include functionality that could be described as malicious, yet remain unfixed - and that at least in some cases OSS is reviewed and fixed.

Merely being released by a US firm is no guarantee that there is no malicious embedded code. First of all, being a US firm has little relationship to the citizenship of its developers and its supplier’s developers. Also, US citizens can attempt to embed malicious code into software, and many non-US citizens develop software without embedding malicious code. In practice, commercial software (OSS or not) tends to be developed globally, especially when you consider their developers and supply chains. The good news is that, by definition, OSS provides its source code, enabling a more informed evaluation than is typically available for other kinds of COTS products.

Note also that merely being developed for the government is no guarantee that there is no malicious embedded code. Such developers need not be cleared, for example. Requiring that all developers be cleared first can reduce certain risks (at substantial costs), where necessary, but even then there is no guarantee.

Most commercial software is not intended to be used where the impact of any error of any kind is extremely high (e.g., a large number of lives are likely to be immediately lost if even the slightest software error occurs). Software that meets very high reliability/security requirements, aka “high assurance” software, must be specially designed to meet such requirements. Most commercial software (including OSS) is not designed for such purposes.

Q: What is the country of origin for software?

The Customs and Border Protection (CBP) has said, in an advisory ruling, that the country of origin of software is the place where the software is converted into object code (“Software comes from the place where it’s converted into object code, says CBP”, FierceGovernmentIT), for “purposes of granting waivers of certain ‘Buy American’ restrictions in U.S. law or practice or products offered for sale to the U.S. Government.”

The CBP ruling points out that 19 U.S.C. § 2518(4)(B) treats an article as a product of a country only if it is wholly grown, produced or manufactured there, or, where it incorporates materials from elsewhere, if it has been “substantially transformed into a new and different article of commerce with a name, character, or use distinct from” what it was made from. The CBP also pointed out a ruling (Data General v. United States, 4 CIT 182 (1982)), that programming a PROM performed a substantial transformation. Under the same reasoning, the CBP determined that building an object file from source code performed a substantial transformation into a new article.

Using OSS in DoW systems

Q: Does the DoW already use open source software?

Yes, extensively. The 2003 MITRE study, “Use of Free and Open Source Software (FOSS) in the U.S. Department of Defense”, identified some of many OSS programs that the DoD is already using, and concluded that OSS “plays a more critical role in the [Department of Defense (DoD)] than has generally been recognized”.

Intellipedia is implemented using MediaWiki, the open source software developed to implement Wikipedia. This Open Source Software FAQ was originally developed on Intellipedia, using a variety of web browsers including Mozilla Firefox. Thus, even this FAQ was developed using open source software.

The DoW is, of course, not the only user of OSS. Gartner Group’s Mark Driver stated in November 2010 that, “Open source is ubiquitous, it’s unavoidable… having a policy against open source is impractical and places you at a competitive disadvantage.”

Q: Is a lot of pre-existing open source software available?

Yes. Widely-used programs include the Apache web server, Firefox web browser, Linux kernel, and many other programs. Estimating the Total Development Cost of a Linux Distribution estimates that the Fedora 9 Linux distribution, which contains over 5,000 software packages, represents about $10.8 billion of development effort in 2008 dollars.

Q: Is there an “approved”, “recommended” or “Generally Recognized as Safe/Mature” list of Open Source Software? What programs are already in widespread use?

No, the DoW does not have an official recommendation for any particular OSS product or set of products, nor a “Generally Recognized as Safe/Mature” list. The 2003 MITRE study, “Use of Free and Open Source Software (FOSS) in the U.S. Department of Defense”, did suggest developing a “Generally Recognized As Safe” (GRAS) list, but such a list has not been developed.

The United States Air Force operates a service called “Iron Bank”, which is the DoD Enterprise repository of hardened software containers, many of which are based on open source products. On approval, such containers are granted a “Certificate to Field” designation by the Air Force Chief Software Officer.

Commercial software (including OSS) that has widespread use often has lower risk, since there are often good reasons for its widespread use. The MITRE study did identify some of many OSS programs that the DoD is already using, and may prove helpful. Examples of OSS that are in widespread use include:

• Kubernetes - container orchestration suite
• Apache HTTP Server - Web server
• Mozilla Firefox - Web browser
• Apache OpenOffice - Office document suite
• OpenSSH - Secure Shell
• OpenSSL - SSL/cryptographic library implementation
• bind - DNS server
• Postfix, Sendmail - Mail servers
• gcc - Compiler suite
• GNAT - Ada compiler suite (technically this is part of gcc)
• perl, Python, PHP, Ruby - Scripting languages
• Samba - Windows - Unix/Linux interoperability
• Mailman - mailing list manager
• MySQL and PostgreSQL - Relational Database Management Systems
• GIMP - Bitmap graphics editor
• MediaWiki - Wiki engine

There are many “Linux distributions” which provides suites of such software such as Red Hat Enterprise Linux, Fedora, SUSE, Debian and Ubuntu. Other open source software implementations of Unix interfaces include OpenBSD, NetBSD, FreeBSD, and Darwin

Again, these are examples, and not official endorsements of any particular product or supplier.

Q: What are some military-specific open source software programs?

Some more military-specific OSS programs created-by or used in the military include:

• Ghidra - software reverse engineering (SRE) framework developed by the National Security Agency and released as OSS in 2019
• The Distributed Data Framework (DDF) - data integration framework developed for the Distributed Common Ground/Surface System (DCGS) Family of Systems
• Open Source Software for Imagery & Mapping (OSSIM) - geospatial image viewing (with classified plugins)
• OSSIM Mapping ARchive (OMAR) - a suite of web services built on OSSIM for cataloging, serving, and disseminating imagery. Both OSSIM and OMAR are maintained as individual repositories in the OSSIM Labs organization
• BRL-CAD - solid modeling (Army)
• REDHAWK SDR - a software-defined radio (SDR) framework
• Android Tactical Assault Kit, Civil (ATAK-CIV) - geospatial situational awareness application originally developed by the Air Force Research Laboratory, now also widely used by civil first responders (see also TAK.gov)
• OpenUxAS and OpenAMASE - cooperative decision making for multiple unmanned vehicles, and simulation of multi-vehicle missions, from the Air Force Research Laboratory
• Host Integrity at Runtime and Start-up (HIRS) and paccor - Trusted Platform Module (TPM) provisioning, attestation, and supply chain validation tools released by NSA Cybersecurity
• The National Geospatial-Intelligence Agency maintains an extensive portfolio of geospatial OSS, including GeoPackage libraries implementing the OGC GeoPackage standard across several platforms, Hootenanny for conflating multiple maps into a single seamless map, the Mobile Awareness GEOINT Environment (MAGE), and SarPy for reading, writing, and processing complex synthetic aperture radar (SAR) data in the NGA SICD format

There are many others.

Q: How can I find open source software that meets my specific needs?

One approach is to use a general-purpose search engine (such as Google) and type in your key functional requirements. If you know of an existing proprietary product meets your needs, searching for its name plus “open source source” may help.

If you are looking for an application that has wide use, one of the various lists of “open source alternatives” may help. These include:

• Open Source Alternatives (Ben Balter et al.)
• Open Source as Alternative

If you are looking for smaller pieces of code to reuse, search engines specifically for code may be helpful. Examples include:

• Google code search
• Searchcode

If you know of others who have similar needs, ask them for leads.

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.

This is in addition to the advantages from OSS because it can be reviewed, modified, and redistributed with few restrictions (inherent in the definition of OSS).

That said, this does not mean that all OSS is superior to all proprietary software in all cases by all measures. Each government program must determine its needs, and then evaluate its options for meeting those needs.

Q: When a DoW contractor is developing a new system/software as a deliverable in a typical DoW contract, is it possible to include existing open source software?

Yes, it’s possible. In nearly all cases, pre-existing OSS are “commercial products”, and thus their use is governed by the rules for including any commercial products in the deliverable. The use of commercial products is generally encouraged, and when there are commercial products, the government expects that it will normally use whatever license is offered to the public. Depending on the contract and its interpretation, contractors may be required to get governmental permission to include commercial components in their deliverables; where this applies, this would be true for OSS components as well as proprietary components. As with all commercial items, organizations must obey the terms of the commercial license, negotiate a different license if necessary, or not use the commercial item.

An alternative is to not include the OSS component in the deliverable, but simply depend on it, as long as that is acceptable to the government. This is often done when the deliverable is a software application; instead of including commercially-available components such as the operating system or database system as part of the deliverable, the deliverable could simply state what it requires.

Q: When a DoW contractor is developing a new system/software as a deliverable in a typical DoW contract, is it possible to use existing software licensed using the GNU General Public License (GPL)? Can the DoW used GPL-licensed software?

Yes. There is no DoW policy forbidding or limiting the use of software licensed under the GNU General Public License (GPL).

The DoW already uses a wide variety of software licensed under the GPL. A 2003 MITRE study, “Use of Free and Open Source Software (FOSS) in the U.S. Department of Defense”, identified many OSS programs that the DoD is already using that are licensed using the GPL. These included the Linux kernel, the gcc compilation suite (including the GNAT Ada compiler), the OpenOffice.org office suite, the emacs text editor, the Nmap network scanner, OpenSSH and OpenSSH for encryption, and Samba for Unix/Linux/Windows interoperability. This should not be surprising; the DoW uses OSS extensively, and the GPL is the most popular OSS license.

As with all commercial items, the DoW must comply with the item’s license when using the item. There are two versions of the GPL in widespread use: version 2 and version 3. The key issue with both versions of the GPL is that, unlike most other OSS licenses, the GPL licenses require that a recipient of a binary (executable) must be able to demand and receive the source code of that program, and the recipient must also be able to propogate the work under that license. The Free Software Foundation (FSF) interprets linking a GPL program with another program as creating a derivative work, and thus imposing this license term in such cases.

In most cases, this GPL license term is not a problem. After all, most proprietary software licenses explicitly forbid modifying (or even reverse-engineering) the program, so the GPL actually provides additional rights not present in most proprietary software. So if the program is being used and not modified (a very common case), this additional term has no impact. Even for many modifications (e.g., bug fixes) this causes no issues because in many cases the DoW has no interest in keeping those changes confidential.

However, if the GPL software must be mixed with other proprietary/classified software, the GPL terms must still be followed.

Q: Under what conditions can GPL-licensed software be mixed with proprietary/classified software?

Software licensed under the GPL can be mixed with software released under other licenses, and mixed with classified or export-controlled software, but only under conditions that do not violate any license. Such mixing can sometimes only occur when certain kinds of separation are maintained - and thus this can become a design issue.

The 2003 MITRE study section 1.3.4 outlines several ways to legally mix GPL with proprietary or classified software:

• Distribution Mixing – storing and transmitting GPL and other software together, such as on the same disk.
• Execution Mixing – running GPL and unrelated proprietary software at the same time on the same computer or network.
• Application Mixing – GPL software relying on other software for services, provided those services are generic (operating system services, for example) or the GPL software’s designer has explicitly exempted them as non-GPL components.
• Service Mixing – GPL software providing generic services to other software. The services must be genuinely generic, meaning the applications using them must not depend on the detailed design of the GPL software. Connecting a GPL utility to a proprietary component through a Unix pipe is one example. This is the tightest mixing possible, and it must be used carefully to keep the GPL software generic rather than bound to one proprietary component.

Often such separation can occur by separating information into data and a program that uses it, or by defining distinct layers. As long as a GPL program does not embed GPL software into its outputs, a GPL program can process classified/proprietary information without question. Thus, GPL’ed compilers can compile classified programs (since the compilers treat the classified program as data), and a GPL’ed implementation of a virtual machine (VM) can execute classified software (since the VM implementation runs the software as data). Many development tools covered by the GPL include libraries and runtimes that are not covered by the GPL itself but the GPL with a runtime exception (e.g., the CLASSPATH exception) that specifically permits development of proprietary software. A GPL’ed “engine” program can be controlled by classified data that it reads without issue. A GPL’ed program can run on top of a classified/proprietary platform when the platform is a separate “System Library” (as defined in GPL version 3). Enforcing such separation has many other advantages as well.

The U.S. government can often directly combine GPL and proprietary, classified, or export-controlled software into a single program arbitrarily, as long as the result is never conveyed outside the U.S. government. However, this approach should not be taken lightly. This approach may inhibit later release of the combined result to other parties (e.g., allies), as release to an ally would likely be considered distribution as defined in the GPL. In some cases, export-controlled software may be licensed for export under the condition that the source code not be released; this would prevent release of software that had mixed GPL and export-controlled software. When taking this approach, contractors hired to modify the software must not retain copyright or other rights to the result (else the software would be conveyed outside the U.S. government); see GPL version 3 section 2, paragraph 2 which states this explicitly. Where possible, it may be better to divide such components into smaller components in a way that avoids this issue.

It can be argued that classified software can be arbitrarily combined with GPL code, beyond the approaches described above. The argument is that the classification rules are simply laws of the land (and not “additional” rules), the classification rules already forbid the release of the resulting binaries to those without proper clearances, and that the GPL only requires that source code be released to those who received a binary. While this argument may be valid, we know of no court decision or legal opinion confirming this. Anyone who is considering this approach should obtain a determination from general counsel first (and please let the FAQ authors know!).

If a legal method for using the GPL software for a particular application cannot be devised, and a different license cannot be negotiated, then the GPL-licensed component cannot be used for that particular purpose. This also applies to proprietary software, which often have even stricter limits on if/how the software may be changed.

Q: Is the GPL compatible with Government Unlimited Rights contracts, or does the requirement to display the license, etc, violate Government Unlimited Rights contracts?

The GPL and government “unlimited rights” terms have similar goals, but differ in details. This isn’t usually an issue because of how typical DoW contract clauses work under the DFARS.

The government normally gets “unlimited rights” in software when that software is created in the performance of a contract with government funds. If such software includes third-party components that were not produced in performace of that contract, the contractor is generally responsible for acquiring those components with acceptable licenses that premit the government to use that software. Thus, the government may receive custom-developed, non-commercial software as a deliverable and receive “unlimited rights” for that new code, but also acquire only commercial rights to the third-party (possibly OSS) components. This is not uncommon.

Once the government has unlimited rights, it may release that software to the public under any terms it wishes - including by using the GPL. This is not a contradiction; it’s quite common for different organizations to have different rights to the same software. The program available to the public may improve over time, through contributions not paid for by the U.S. government. In that case, the U.S. government might choose to continue to use the version to which it has unlimited rights, or it might use the publicly-available commercial version available to the government through that version’s commercial license (the GPL in this case).

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, which bars government officers and employees from accepting voluntary services, or employing personal services beyond what law authorizes, except in emergencies involving the safety of human life or the protection of property.

The US Government Accountability Office (GAO) Office of the General Counsel’s “Principles of Federal Appropriations Law” (aka the “Red Book”) explains this provision at Volume II, section 6.C.3 of its third edition. The prohibition dates to 1884 in almost identical form, and its purpose is to stop an agency from doing indirectly what it cannot do directly: obligating beyond its appropriations by accepting ostensibly voluntary services and then presenting Congress with the bill.

Section 6.C.3.b turns on a distinction drawn by the Attorney General in 1913 (30 Op. Att’y Gen. 51), which the Red Book calls “the leading case construing 31 U.S.C. § 1342” and which GAO and the Justice Department follow to this day — the distinction between voluntary services and gratuitous services:

“[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: How can I evaluate OSS options?

Evaluate OSS the same way you would evaluate any other option, on need, cost, and risk. In some cases, the sources of information for OSS differ.

Be sure to consider total cost of ownership (TCO), not just initial download costs. Even if OSS has no cost to download, there is still a cost for OSS due to installation, support, and so on (whether done in-house or through external organizations). Be sure to consider such costs over a period of time (typically the lifetime of the system including its upgrades), and use the same period when evaluating alternatives; otherwise, one-time costs (such as costs to transition from an existing proprietary system) can lead to erroneous conclusions. Include upgrade/maintenance costs, including indirect costs (such as hardware replacement if necessary to run updated software), in the TCO.

By definition, open source software provides more rights to users than proprietary software (at least in terms of use, modification, and distribution). That said, other factors may be more important for a given circumstance.

The DoW does not have a single required process for evaluating OSS. The following externally-developed evaluation processes or tips may be of use:

• How to Evaluate Open Source Software / Free Software (OSS/FS) Programs
• OpenSource Maturity Model (OMM)
• Capgemini’s Open Source Maturity Model (OSMM)
• Top Tips For Selecting Open Source Software
• QSOS

Q: How can I migrate to OSS?

Migrating from an existing system to an OSS approach requires addressing the same issues that any migration involves.

The IDA Open Source Migration Guidelines recommend:

• before starting have a clear understanding of the reasons to migrate;
• ensure that there is active support for the change from IT staff and users;
• make sure that there is a champion for change – the higher up in the organisation the better;
• build up expertise and relationships with the OSS movement;
• start with non critical systems;
• ensure that each step in the migration is manageable.

It also suggests that the following questions need to be addressed:

• how to ensure the interoperability of systems;
• how to support mobile users;
• how to securely identify remote users;
• how to build systems that are manageable.
• ensure that security is designed in from the start and not tacked on as an after thought.

It also recommends ensuring “that decisions made now, even if they do not relate directly to a migration, should not further tie an Administration to proprietary file formats and protocols”. It also notes that OSS is a disruptive technology, in particular, that it is “a move away from a product to a service based industry”.

Q: How can I get support for OSS that already exists?

You can support OSS either through a commercial organization, or you can self-support OSS; in either case, you can use community support as an aid.

Commercial support can either be through companies with specialize in OSS support (in general or for specific products), or through contractors who specialize in supporting customers and provide the OSS support as part of a larger service. Examples of the former include Red Hat, Canonical, HP Enterprise, Oracle, IBM, SourceLabs, OpenLogic, and Carahsoft.

Some have found that community support can be very helpful. The 1997 InfoWorld “Best Technical Support” award was won by the “Linux User Community”. However, you should examine past experience and your intended uses before depending on this as a primary mechanism for support. An Open Source Community can update the codebase, but they cannot patch your servers.

Q: Am I required to have commercial support for OSS?

No, DoW policy does not require you to have commercial support for OSS, but you must have some plan for support. The 2022 DoD CIO memorandum “Software Development and Open Source Software” says, in Attachment 2, paragraph 2.F, that “OSS components of DoD systems require product support and sustainment planning as much as proprietary components. OSS components should be included in the Life Cycle Product Support Strategy (PSS), as described in DoDI 5000.87… For OSS, this strategy should address the ongoing balance between development contractor support, organic contractor logistics support, and support of the OSS community.” Paragraph 2.C(1) likewise identifies “commercial or in-house support for the OSS component” as alternative risk mitigations. Organic and in-house government support are specifically identified as possibly-appropriate approaches.

How robust that plan needs to be varies with the software. Command and control software warrants a more demanding support plan than something less critical to mission execution.

Community OSS support is never enough by itself to provide this support, because the OSS community cannot patch your servers or workstations for you. However, support from in-house staff, augmented by the OSS community, may be (and often is) sufficient. However, if you’re going to rely on the OSS community, you must make sure that the OSS community for that product is active, and that you have suitably qualified staff to implement the upgrades/enhancements developed by the community.

If you have concerns about using in-house staff, augmented by the OSS community for those components, then select and pay a commercial organization to provide the necessary support. Many programs and Authorizing Officials do 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 Authorizing Officials must look at the specific situation to make a determination.

Navy and Marine Corps commands should note an additional requirement. The answer above describes DoW-wide policy. SECNAVINST 5230.15 establishes as Department of the Navy policy that “all COTS software in use across the Department shall be vendor supported”, and paragraph 4.c applies that policy to OSS: “This policy is applicable to all Open Source Software (OSS) applications and tools licensed to the general public as well as to the Federal Government. OSS shall be treated as COTS.”

For DON commands, this changes the default. Organic support remains permissible — the instruction states that OSS support may be acquired from within the Department of the Navy or from a third party provider — but an OSS application that is not acquired under commercial vendor support requires a waiver, which must be granted by the appropriate DON Deputy CIO (Navy or Marine Corps). Waiver requests are submitted under paragraph 9 of the instruction; waivers for joint programs and systems are approved only by the DON CIO, and waiver requests, approvals, and rejections are tracked in DADMS/DITPR-DON. A DON program intending to sustain OSS with in-house staff should therefore plan for the waiver as part of its support planning, rather than assuming that a support plan alone is sufficient.

Army commands should note a different additional requirement. AR 25-2, Army Cybersecurity, provides at paragraph 4-12.a(4) that “in the case of open source or custom software, a qualified DOD software sustainment organization, such as the software centers under AMC, or vetted government contractor vendor must be engaged to properly maintain the open source components.” As with the Navy, this does not require commercial support — a government sustainment organization satisfies it — but it does mean that informal or ad hoc self-support is not sufficient for Army systems. AR 25-2 further provides, at paragraph 4-12.a(5), that “use of open source software must be approved by the AO with purview over the system or product, when the risk is above low.”

Q: How do GOTS, Proprietary COTS, and OSS COTS compare?

Government Off-the-Shelf (GOTS), proprietary commercial off-the-shelf (COTS), and OSS COTS are all ways to reuse software across multiple projects, and so all three share development and maintenance costs.

GOTS is especially appropriate when the software must not be released to the public (e.g., it is classified) or when licenses forbid more extensive sharing (e.g., the government only has government-purpose rights to the software). GOTS software should not be released when it implements a strategic innovation, i.e. when it implements novel functionality which is not already available to the public, and which significantly improves DoW mission outcomes or business processes. (Such software would often be classified.)

Unlike proprietary COTS, GOTS has the advantage that the government has the right to change the software whenever the government chooses to do so. Unfortunately, the government must pay for all development and maintenance costs of GOTS; since these can be substantial, GOTS runs the risk of becoming obsolete when the government cannot afford those costs. Also, since there are a limited number of users, there is limited opportunity to gain from user innovation - which again can lead to obsolescence. Even where there is GOTS/classified software, such software is typically only a portion of the entire system, with other components implemented through COTS components.

Proprietary COTS is especially appropriate when there is an existing proprietary COTS product that meets the need. Proprietary COTS tend to be lower cost than GOTS, since the cost of development and maintenance is typically shared among a larger number of users (who typically pay to receive licenses to use the product). Unfortunately, this typically trades off flexibility; the government does not have the right to modify the software, so it cannot fix serious security problems, add arbitrary improvements, or make the software work on platforms of its choosing. If the supplier attains a monopoly or it is difficult to switch from the supplier, the costs may skyrocket. What is more, the supplier may choose to abandon the product; source-code escrow can reduce these risks somewhat, but in these cases the software becomes GOTS with its attendant costs.

OSS COTS is especially appropriate when there is an existing OSS COTS product that meets the need, or one can be developed and supported by a wide range of users/co-developers. OSS COTS tends to be lower cost than GOTS, in part for the same reasons as proprietary COTS: its costs are shared among more users. It also often has lower total cost-of-ownership than proprietary COTS, since acquiring it initially is often free or low-cost, and all other support activities (training, installation, modification, etc.) can be competed, and the cost of some improvements may be borne by other users of the software. Its flexibility is as high as GOTS, since it can be arbitrarily modified. However, note that the advantages of cost-sharing only applies if there are many users; if no user/co-developer community is built up, then it can be as costly as GOTS.

Q: What are the risks of failing to consider the use of OSS components or approaches?

For the DoW, the risks of failing to consider the use of OSS where appropriate are of increased cost, increased schedule, and/or reduced performance (including reduced innovation or security) to the DoW due to the failure to use the commercial software that best meets the needs (when that is the case). It also risks reduced flexibility (including against cyberattack), since OSS permits arbitrary later modification by users in ways that some other license approaches do not. In addition, ignoring OSS would not be lawful; U.S. law specifically requires consideration of commercial software (including extant OSS, regardless of exactly which license it uses), and specifically instructs departments to pass this requirement to consider commercial items down to contractors and their suppliers at all tiers.

DoW contractors who always ignore components because they are OSS, or because they have a particular OSS license they don’t prefer, risk losing projects to more competitive bidders. If that competitor’s use of OSS results in an advantage to the DoW (such as lower cost, faster schedule, increased performance, or other factors such as increased flexibility), contractors should expect that the DoW will choose the better bid. This does not mean that existing OSS elements should always be chosen, but it means that they must be considered.

Q: Is there a large risk that widely-used OSS unlawfully includes proprietary software (in violation of copyright)?

No; this is a low-probability risk for widely-used OSS programs. A primary reason that this is low-probability is the publicity of the OSS source code itself (which almost invariably includes information about those who made specific changes). Any company can easily review OSS to look for proprietary code that should not be there; there are even OSS tools that can find common code. A company that found any of its proprietary software in an OSS project can in most cases quickly determine who unlawfully submitted that code and sue that person for infringement.

In addition, widely-used licenses and OSS projects often include additional mechanisms to counter this risk. The GPL and LGPL licenses specifically recommend that “You should also get your employer (if you work as a programmer) or school, if any, to sign a ‘copyright disclaimer’ for the program, if necessary.”, and point to additional information. Many projects, particularly the large number of projects managed by the Free Software Foundation (FSF), ask for an employer’s disclaimer from the contributor’s employer in a number of circumstances. The Linux kernel project requires that a person proposing a change add a “Signed-off-by” tag, attesting that the “patch, to the best of his or her knowledge, can legally be merged into the mainline and distributed under the terms of (the license).”

In practice, OSS projects tend to be remarkably clean of such issues. For example, a Code Analysis of the Linux Wireless Team’s ath5k Driver found no license problems.

When considering any software (OSS or proprietary), look for evidence that the risk of unlawful release is low. Factors that greatly reduce this risk include:

• Widespread availability and use of the software (which increases the likelihood of detection)
• Configuration management systems that record the identity of individual contributors (which acts as a deterrent)
• Licenses or development policies that warn against the unlawful inclusion of material, or require people to specifically assert that they are acting lawfully (which reduce the risk of unintentional infringement)
• Lack of evidence of infrigement (e.g., an Internet search for project name + “copyright infringement” turns up nothing). Parties are innocent until proven guilty, so if there is such a charge, investigate the charges’ merits instead of presuming guilt.

Q: Is there a large risk to DoW contractors that widely-used OSS violates enforceable software patents?

Typically not, though the risk varies depending on their contract and specific circumstance. Note, however, that this risk has little to do with OSS, but is instead rooted in the risks of U.S. patent infringement for all software, and the patent indemnification clauses in their contract.

It is difficult for software developers (OSS or not) to be confident that they have avoided software patent infringement in the United States, for a variety of reasons. Software might not infringe on a patent when it was released, yet the same software may later infringe on a patent if the patent was granted after the software’s release. Many software developers find software patents difficult to understand, making it difficult for them to determine if a given patent even applies to a given program. Patent examiners have relatively little time to review each patent, and do not have effective access to most prior art in software, which may lead them to grant patents for previously-published inventions or “obvious” inventions. The U.S. has granted a large number of software patents, making it difficult and costly to examine all of them. Recent rulings have strengthened the requirement for “non-obviousness”, which probably renders unenforceable some already-granted software patents, but at this time it is difficult to determine which ones are affected. As a result, it is difficult to develop software and be confident that it does not violate enforceable patents. The DoW has not expressed a position on whether or not software should be patented, but it is interested in ensuring that software that effectively supports its missions can be developed in a cost-effective, timely, and legal manner.

U.S. government contractors (including those in the DoW) are often indemnified from patent infringement by the U.S. government as part of their contract. This greatly reduces contractors’ risks, enabling them to get work done (given this complex environment). They can obtain this by receiving certain authorization clauses in their contracts. FAR 52.227-1 (Authorization and Consent), as prescribed by FAR 27.201-2(a)(1), inserts the clause that the “Government authorizes and consents to all use and manufacturer… of any invention (covered by) U.S. patent”. The related FAR 52.227-2 (Notice and Assistance Regarding Patent and Copyright Infringement), as prescribed by FAR 27.201-2(b), requires the contractor to report to the Contracting Officer each notice or claim of patent/copyright infrigement in reasonable written detail. Specific patents can also be authorized using clause FAR 52.227-5 or via listed exceptions of FAR 52.227-3. See also DFARS subpart 227.70–infringement claims, licenses, and assignments and 28 USC 1498.

As FAR 27.201-1 explains, 28 U.S.C. 1498 makes a suit for monetary damages in the Court of Federal Claims the exclusive remedy for patent or copyright infringement by or on behalf of the Government. No injunctive relief is available, and there is no direct cause of action against a contractor infringing with the Government’s authorization or consent, such as while performing a contract.

There are other ways to reduce the risk of software patent infringement (in the U.S.) as well:

• Some protocols and formats have been specifically devised and reviewed to avoid patents; using them is more likely to avoid problems.
• Prior art invalidates patents. Patents expire after 20 years, so any idea (“invention”) implemented in software publicly available for more than 20 years should not, in theory, be patentable. Once an invention is released to the public, the inventor has only one year to file for a patent, so any new ideas in some software must have a patent filed within one year by that inventor, or (in theory) they cannot be patented. See Prior Art and Its Uses: A Primer, by Theodore C. McCullough
• OSS can often be purchased (directly, or as a support contract), and such purchases often include some sort of indemnification.
• Various organizations have been formed to reduce patent risks for OSS. The Open Invention Network (OIN) may in some cases provide some additional protection. OIN purchases patent rights; patents owned by OIN are available royalty-free to any company, institution or individual that agrees not to assert its patents against the “Linux System” (which includes a large set of OSS projects). The Linux Foundations’ Patent Commons forum is a neutral forum where patent pledges and other commitments can be readily accessed and easily understood.

Q: How can I avoid failure to comply with an OSS license? What are good practices for use of OSS in a larger system?

The following are good practices:

• Educate all software developers that they must comply with all valid licenses - including both proprietary and open source software licenses. Explain the basic terms of the most common OSS licenses to them.
• Before including any software in a larger system (be it proprietary or OSS), review its license to ensure that the license will not impede anticipated uses.
• When including externally-developed software in a larger system (e.g., as a library), make it clearly separable from the other components and easy to update. Commercial software (both proprietary and OSS) is occasionally updated to fix errors (including security vulnerabilities), and your system should be designed so that it is relatively easy to accept these updates.
• Document from where and when any external software was acquired, as well as the license conditions, so that future users and maintainers can easily comply with the license terms.

Releasing software as OSS

Q: Has the U.S. government released OSS projects or improvements?

Yes, both entirely new programs and improvements of existing OSS have been developed using U.S. government funds. There are far too many examples to list; a few examples are:

• Security-Enhanced Linux (SELinux) - mandatory access control and other security enhancements to Linux-based operating systems, developed by the National Security Agency and merged into the mainline Linux kernel in 2003
• Apache Accumulo - distributed key-value store with cell-level access control, begun by the National Security Agency in 2008 and contributed to the Apache Software Foundation incubator in 2011, where it became a top-level project in 2012
• Apache NiFi - dataflow automation system, developed by the National Security Agency as “Niagarafiles” and contributed to the Apache Software Foundation in 2014
• VistA and Hardhats - Implementations of US Veterans Affairs’ enterprise grade health care information system
• Expect - Tool for automating interactive applications. Since Expect was developed at the National Institute of Standards and Technology by employees of the Federal Government in the course of their official duties, it is not subject to copyright protection and is in the public domain.
• Evergreen - Library Management (by the State of Georgia)
• OpenSSL - this improvement was a FIPS 140-2 evaluation (for cryptographic modules)
• bind’s implementation of DNS security (DNSSEC) - bind is a widely used Domain Name Server (DNS); the U.S. government funded security enhancements to increase security of the Internet
• GNAT Ada compiler
• Object-Oriented Data Technology (OODT) - Transparent access to distributed resources (this NASA Jet Propulsion Laboratory (JPL) project became a top level open source Apache Software Foundation project in 2011)
• BSD TCP/IP suite - Provided the basis of the Internet
• Geographic Resources Analysis Support System (GRASS) - Geographic Information System (GIS) software used for geospatial data management and analysis, image processing, graphics/maps production, spatial modeling, and visualization developed by the Army Corps of Engineers’ Construction Engineering Research Laboratory
• OSSIM - geo-spatial image processing for remote sensing, photogrammetry, and Geographic Information Systems (GIS), originally developed by Harris Corporation for the Intelligence Community.
• BRL-CAD - cross-platform combinatorial Constructive Solid Geometry (CSG) solid modeling system
• Paraview - multi-platform data analysis and visualization application, developed by Kitware Inc, for Los Alamos National Laboratory, the DoE, Army Research Labs and Sandia National Labs.

Q: What are the risks of the government releasing software as OSS?

The key risk is the revelation of information that should not be released to the public. Classified software should already be marked as such, of course. This risk is mitigated by reviewing software (in particular, for classification and export control issues) before public release.

Q: What are the risks of the government not releasing software as OSS?

If the government modifies existing OSS, but fails to release those improvements back to the main OSS project, it risks:

• Greatly increased costs, due to the effort of self-maintaining its own version
• Inability to use improvements (including security patches and innovations) by others, where it uses a “non-standard” version instead of the version being actively maintained

Similarly, if the government develops new software but does not release it as OSS, it risks:

• Greatly increased cost, due to having to bear the entire burden of development costs
• Inability to use improvements (including security patches and innovations) by others, since they do not have the opportunity to aid in its development
• Obsolescence due to the development and release of a competing commercial (e.g., OSS) project. In this case, the government has the unenviable choice of (1) spending possibly large sums to switch to the new project (which would typically have a radically different interface and goals), or (2) continuing to use the government-unique custom solution, which typically becomes obsolete and leaves the U.S. systems far less capable that others’ (including those of U.S. adversaries)
• Questions about why the government - who represents “the people” - is not releasing software (that the people paid for) back to the people.

Clearly, classified software cannot be released back to the public as open source software. However, often software can be split into various components, some of which are classified and some of which are not, and it is to these unclassified portions that this text addresses.

Q: When can the U.S. federal government or its contractors publicly release, as OSS, software developed with government funds?

“Clarifying Guidance Regarding Open Source Software (OSS)” states 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)).”

The government or contractor must determine the answer to these questions:

1. . What contract applies, what are its terms, and what decisions have been made?
2. . Do you have the necessary copyright-related rights?
3. . Do you have the necessary other intellectual rights (e.g., patents)?
4. . Do you have permission to release to the public (classification, distribution statements, export controls)?
5. . Do you have the materials (e.g., source code) and are all materials properly marked?

Source: Publicly Releasing Open Source Software Developed for the U.S. Government.

The following questions discuss some specific cases.

Q: Can government employees develop software as part of their official duties and release it under an open source license?

Not under typical open source software licenses based on copyright, but there is an alternative with the same practical effect.

Software developed by US federal government employees (including military personnel) as part of their official duties is not subject to copyright protection in the US (see 17 USC § 105). Software not subject to copyright is often called “public domain” software. Public domain software (in this copyright-related sense) can be used by anyone for any purpose, and cannot by itself be released under a copyright license (including typical open source software licenses).

However, software written entirely by federal government employees as part of their official duties can be released as “public domain” software. This is not a copyright license, it is the absence of a license. By some definitions this is technically not an open source license, because no license is needed, but such “public domain” software can be legally used, modified, and combined with other software without restriction. Thus, “public domain” software provides recipients all of the rights that open source software must provide. An example of such software is Expect, which was developed and released by NIST as public domain software. Under the DoD definition of open source software, such public domain software is open source software.

When government employees develop software as part of their official duties, it can be protected by copyright in other countries, but note that these can only be enforced outside the US. Also, there are rare exceptions for NIST and the US Postal Service employees where a US copyright can be obtained (see CENDI’s Frequently Asked Questions About Copyright).

Government employees may also modify existing open source software. If some portion of the software is protected by copyright, then the combined software work can be released under a copyright license. (See next question.)

(See also GPL FAQ, Question “Can the US Government release a program under the GNU GPL?”)

Q: Can government employees contribute code to open source software projects?

Yes, but the following considerations apply:

As stated above, software developed by government employees as part of their official duties is not subject to copyright protection in the United States. If a government employee enhances or modifies a (copyrighted) open source software program, the resulting work is a “joint work” (see 17 USC § 101) which is partially copyrighted and partially public domain. The resulting joint work as a whole is protected by the copyrights of the non-government authors and may be released according to the terms of the original open-source license.

However, the public domain portions may be extracted from such a joint work and used by anyone for any purpose. For computer software, modern version control and source code comparison tools typically make it easy to isolate the contributions of individual authors (via “blame” or “annote” functions).

(See also Free Software Foundation License List, Public Domain)

(See also GPL FAQ, Question “Can the US Government release improvements to a GPL-covered program?”)

Q: Can contractors develop software for the government and then release it under an open source license?

In many cases, yes, but this depends on the specific contract and circumstances. Under the “default” DFARS and FAR rules and processes, the contractor often keeps and exercise the rights of a copyright holder, which enables them to release that software as open source software (as long as other laws and regulations are met).

For DoW contractors, if the standard DFARS contract clauses are used (in particular DFARS 252.227-7014) then the contractor who developed the software retains the copyright to the software and has the right to release it to others, even if the software was developed exclusively with government funds. In some cases a DoW contractor may be required to transfer copyright to the government for works produced under contract (see DFARS 252.227-7020). If this is the case, then the contractor cannot release the software as OSS without permission, because the contractor doesn’t own the copyright.

Contractors for other federal agencies may have a different process to use, but after going through a process they can often release such software as open source software. If the contract includes the typical FAR 52.227-14 (Rights in data - general) clause, without any special alternatives or additions, then the contractor must make a written request for permission to assert copyright in works containing data first produced under the contract. As described in FAR 27.404-3(a)(2), a contracting officer should grant such a request only “when [that] will enhance appropriate dissemination or use” but release as open source software would typically qualify as a justification for enhanced dissemination and use. Certain FAR clause alternatives (such as FAR 52.227-17) require the contractor to assign the copyright to the government. Again, if this is the case, then the contractor cannot release the software as OSS without permission, because the contractor doesn’t own the copyright.

There are many alternative clauses in the FAR and DFARS, and specific contracts can (and often do) have different agreements on who has which rights to software developed under a government contract. The FAR and DFARS specifically permit different agreements to be struck (within certain boundaries). Thus, if there is an existing contract, you must check the contract to determine the specific situation; the text above merely describes common cases.

Contractors must still abide with all other laws before being allowed to release anything to the public. Obviously, contractors cannot release anything (including software) to the public if it is classified. The release of the software may be restricted by the International Traffic in Arms Regulation or Export Administration Regulation. The release may also be limited by patent and trademark law.

Q: Can the government release software under an open source license if it was developed by contractors under government contract?

In many cases, yes, but this depends on the specific contract and circumstances. The government can typically release software as open source software once it has “unlimited rights” to the software. The usual DoW contract clause (DFARS 252.227-7014) permits this by default. The usual federal non-DoW clause (FAR 52.227-14) also permits this by default as long as the government has not granted the contractor the right to assert copyright. If the government has received copyright (e.g., because the FAR 52.227-17 or DFARS 252.227-7020 clauses apply) then the government can release the software as open source software.

Under the DFARS or the FAR, the government can release software as open source software once it receives “unlimited rights” to that software. DFARS 252.227-7014(a)(15) defines “unlimited rights” as “rights to use, modify, reproduce, release, perform, display, or disclose computer software or computer software documentation in whole or in part, in any manner and for any purpose whatsoever, and to have or authorize others to do so”. As the Council on Governmental Relations (COGR) puts it in “Technical Data and Computer Software: A Guide to Rights and Responsibilities Under Federal Contracts, Grants and Cooperative Agreements”, this unlimited license gives the government “essentially the same rights as the copyright owner”. Because the government may both use and modify the software at will and authorize others to do the same, it can release that software under a variety of conditions, including an open source software license.

If the standard DFARS contract clauses are used (see DFARS 252.227-7014), then unless other arrangements are made, the government has unlimited rights to a software component when (1) it pays entirely for the development of it (see DFARS 252.227-7014(b)(1)(i)), or (2) it is five years after contract signature if it partly paid for its development (see DFARS 252.227-7014(b)(2)). Before award, a contractor may identify the components that will have more restrictive rights (e.g., so the government can prefer proposals that give the government more rights), and under limited conditions the list can be modified later (e.g., for error correction). Where possible, software developed partly by government funds should broken into a set of smaller components at the “lowest practicable level” so the rules can be applied separately to each one. Note, however, that this may be negotiated; if the government agrees to only receive lesser rights (such as government-purpose rights or restricted rights) then the government does not have the rights necessary to release that software as open source software.

The rules for many other U.S. departments may be very different. Contracts under the federal government FAR, but not the DFARS, often use clause FAR 52.227-14 (Rights in Data - General). By default, the government has the necessary rights if it does not permit the contractor to assert copyright, but it loses those rights if the government permits the contractor to assert copyright.

If the contractor was required to transfer copyright to the government for works produced under contract (e.g., because the FAR 52.227-17 or DFARS 252.227-7020 clauses apply to it), then the government can release the software as open source software, because the government owns the copyright. The NASA FAR Supplement (NFS) 1852.227-14 gives NASA the right, under typical conditions, to demand that a contractor assert copyright and then assign the copyright to the government, which would again give the government the right to release the software as open source software.

If there is an existing contract, you must check the contract to determine the specific situation; the text above merely describes common cases. There are many alternative clauses in the FAR and DFARS, and specific contracts can (and often do) have different specific agreements on who has which rights to software developed under a government contract. The FAR and DFARS specifically permit different agreements to be struck, within certain boundaries, and other agencies have other supplements.

If the intent of a contract is to develop software to be released as open source software, it is best to expressly include release as OSS as part of the contract. This makes the expectations clear to all parties, which may be especially important as personnel change.

Other laws must still be obeyed. Classified information may not be released to the public without special authorization to do so. The release of the software may be restricted by the International Traffic in Arms Regulation (ITAR) or Export Administration Regulation (EAR). The release may also be limited by patent and trademark law.

(See also “Publicly Releasing Open Source Software Developed for the U.S. Government” by Dr. David A. Wheeler, DoD Software Tech News, February 2011.)

Q: Is there a standard marking for software where the government has unlimited rights?

The FAR and DFARS do not currently mandate any specific marking for software where the government has unlimited rights. This can be a cause of confusion, because without any markings, a recipient is often unaware that the government has unlimited rights to it, and if the government does not know it has certain rights, it becomes difficult for the government to exercise its rights. This is important for releasing OSS, because the government can release software as OSS if it has unlimited rights.

The following marking should be added to software source code when the government has unlimited rights due to the use of the DFARS 252.227-7014 contract:

“The U.S. Government has Unlimited Rights in this computer software pursuant to the clause at DFARS 252.227-7014. Any reproduction of this computer software, or portions thereof, marked with this legend must also reproduce these markings.”

Q: Does releasing software under an OSS license count as commercialization?

In most cases, yes. U.S. law governing federal procurement U.S. Code Title 41, Chapter 7, Section 103 defines “commercial product” as “a product, other than real property, that- (A) is of a type customarily used by the general public or by nongovernmental entities for purposes other than governmental purposes; and (B) has been sold, leased, or licensed, or offered for sale, lease, or license, to the general public …”. Thus, as long as the software has at least one non-governmental use, software released (or offered for release) to the public is a commercial product for procurement purposes, even if it was originally developed using public funds.

Releasing software as OSS does not mean that organizations will automatically arise to help develop/support it. Whether or not this will occur depends on factors such as the number of potential users (more potential users makes this more likely), the existence of competing OSS programs (which may out-compete the newly released component), and how difficult it is to install/use. Thus, components that have the potential to (eventually) support many users are more likely to succeed. Similarly, delaying a component’s OSS release too long may doom it, if another OSS component is released first. If the OSS is intended for use on Linux/Unix systems, follow standard source installation release practices so that it is easier for users to install.

Q: What license should the government or contractor choose/select when releasing open source software?

It depends on the goals for the project, however, here are some guidelines:

Public domain where required by law. You must release it without any copyright protection (e.g., as “not subject to copyright protection in the United States”) if you release it at all and if it was developed wholly by US government employee(s) as part of their official duties. Otherwise, choose some existing OSS license, since all existing licenses add some legal protections from lawsuits. (The “MIT license” is similar to public domain release, but with some legal protection from lawsuits.)

Release modifications under same license. If it is a modification of an existing project, or a plug-in to it, release it under the project’s original license (and possibly other licenses). This way, the software can be incorporated in the existing project, saving time and money in support.

Consider anticipated uses. If it must work with other components, or is anticipated to work with other components, ensure that the license will permit those anticipated uses. In particular, will it be directly linked with proprietary or classified code?

Make sure it’s really OSS. Choose a license that has passed legal reviews and is clearly accepted as an OSS license. Choose a license that is recognized as an Open Source Software license by the Open Source Initiative (OSI), a Free Software license by the Free Software Foundation (FSF), and is acceptable to widely-used Linux distributions (such as being a “good” license for Fedora).

Use a widely-used existing license. Choose a widely-used existing license; do not create a new license. This eliminates future incompatibility and encourages future contributions by others. Bruce Perens noted back in 1999, “Do not write a new license if it is possible to use (a common existing license)… The propagation of many different and incompatible licenses works to the detriment of Open Source software because fragments of one program cannot be used in another program with an incompatible license.” Many view OSS license proliferation as a problem; Serdar Yegulalp’s 2008 “Open Source Licensing Implosion” (InformationWeek) noted that not only are there too many OSS licenses, but that the “consequences for blithely creating new ones are finally becoming concrete… the vast majority of open source products out there use a small handful of licenses… Now that open source is becoming (gasp) a mainstream phenomenon, using one of the less-common licenses or coming up with one of your own works against you more often than not”. As an aid, the Open Source Initiative (OSI) maintains a list of “Licenses that are popular and widely used or with strong communities”. Another useful source is the list of licenses accepted by the Google code hosting service. See the licenses listed in the FAQ question “What are the major types of open source software licenses?”.

Choose a GPL-compatible license. The GNU General Public License (GPL) is the most common OSS license; while you do not need to use the GPL, it is often unwise to choose a license incompatible with the majority of OSS. Thus, avoid releasing software under only the original (“4-clause”) BSD license (which has been replaced by the “new” or “revised” 3-clause licence), the “Academic Free License” (AFL), the now-abandoned “Common Public License” 1.0 (CPL), the “Open Software License” (OSL), or the “Mozilla Public License version 1.1” (MPL 1.1).

Choose a license that best meets your goals. Choosing between the various options - particularly between permissive, weakly protective, and strongly protective options - is perhaps the most difficult, because this selection depends on your goals, and there are many opinions on which licenses are most appropriate for different circumstances. A “permissive” license permits arbitrary use of the program, including making proprietary versions of it. A “protective” license “protects” the software from becoming proprietary, and instead enforces a “share and share alike” approach between parties. A “weakly-protective” license is a compromise between the two, preventing the covered library from becoming proprietary yet permitting it to be embedded in larger proprietary works. If the goal is maximize the use of a technology or standard in a variety of different applications/implementations, including proprietary ones, permissive licenses may be especially useful. However, if the goal is to encourage longevity and cost savings through a commonly-maintained library or application, protective licenses may have some advantages, because they encourage developers to contribute their improvements back into a single common project. In many cases, weakly protective licenses are used for common libraries, while strongly protective licenses are used for applications. Common licenses for each type are:

• Permissive: MIT, BSD-new, Apache 2.0
• Weakly protective: LGPL (version 2 or 3)
• Strongly protective: GPL (version 2 or 3)

Licenses that meet all the criteria above include the MIT license, revised BSD license, the Apache 2.0 license (though Apache 2.0 is only compatible with GPL version 3 not GPL version 2), the GNU Lesser General Public License (LGPL) versions 2.1 or 3, and the GNU General Public License (GPL) versions 2 or 3.

In some cases, it may be wise to release software under multiple licenses (e.g., “LGPL version 2.1 and version 3”, “GPL version 2 and 3”), so that users can then pick which license they will use. This can increase the number of potential users.

Q: How should I create an open source software project?

First, get approval to publicly release the software. One way to deal with potential export control issues is to make this request in the same way as approving public release of other data/documentation.

If it is an improvement to an existing project, release it to the main OSS project, in whatever format they prefer changes. Many prefer “unified diff patches”, generated by “diff -u” or similar commands. Most projects prefer to receive a set of smaller changes, so that they can review each change for correctness.

If it is a new project, be sure to remove “barriers to entry” for others to contribute to the project:

• Use a common OSS license well-known to be OSS (GPL, LGPL, MIT/X, BSD-new, Apache 2.0) – don’t write your own license
• Establish project website. Typically this will include source code version management system, a mailing list, and an issue tracker.
• Document the project’s purpose, scope, and major decisions - users must be able to quickly determine if this project might meet their needs.
• Use typical OSS infrastructure, tools, etc. Requiring the use of very unusual development tools may impede development, unless those tools provide a noticeable advantage.
• Maximize portability, and avoid requiring proprietary languages/libraries unnecessarily. The more potential users, the more potential developers.
• The released version Must run. Small-but-running is better than big-and-not.
• Establish vetting process(es) before government will use updated versions (testing, etc.)
• Determine if there will be a government-paid lead.

Some documents that may help include:

• “Producing Open Source Software: How to Run a Successful Free Software Project” by Karl Fogel
• Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software
• Free Software Project Management HOWTO
• Software Release Practice HOWTO
• Recognizing and Avoiding Common Open Source Community Pitfalls

Q: In what form should I release open source software?

OSS should be released using conventional formats that make it easy to install (for end-users) and easy to update (for potential co-developers). These formats may, but need not, be the same.

If you are releasing OSS source code for Unix-like systems (including Linux and MacOS), you should follow the usual conventions for doing so as described below:

• Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation
• GNU Coding Standards, especially on the release process
• Software Release Practice HOWTO

Q: Where can I release open source software that are new projects to the public?

You may use existing industry OSS project hosting services such as SourceForge, Savannah, GitHub, or Apache Software Foundation. Wikipedia’s “Comparison of OSS hosting facilities” page may be helpful in identifying existing hosting facilities, as well as some of their pros and cons. Each hosting service tends to be focused on particular kinds of projects, so prefer a hosting service that well-matches the project. Using industry OSS project hosting services makes it easier to collaborate with other parties outside the U.S. DoW or U.S. government.

If the project is likely to become large, or must perform filtering for public release, it may be better to establish its own website. Many of the largest commercially-supported OSS projects have their own sites.

Q: Can the government or contractor use trademarks, service marks, and/or certification marks with OSS projects?

Yes, both the government and contractors may obtain and use trademarks, service marks, and/or certification marks for software, including OSS. For example, trademarks and certification marks can be used to differentiate one version of OSS from others, e.g., to designate certain releases as an “official” version. Depending on your goals, a trademark, service mark, or certification mark may be exactly what you need.

According to the U.S. Patent and Trademark Office (PTO):

• A trademark is “a word, phrase, symbol or design, or a combination thereof, that identifies and distinguishes the source of the goods of one party from those of others.”
• A service mark is “a word, phrase, symbol or design, or a combination thereof, that identifies and distinguishes the source of a service rather than goods. The term ‘trademark’ is often used to refer to both trademarks and service marks.
• A certification mark is “any word, phrase, symbol or design, or a combination thereof owned by one party who certifies the goods and services of others when they meet certain standards. The owner of the mark exercises control over the use of the mark; however, because the sole purpose of a certification mark is to indicate that certain standards have been met, use of the mark is by others.”

For more about trademarks, see the U.S. Patent and Trademark Office (PTO) page “Trademark basics”. Note:

• You don’t have to register a trademark to have a trademark. If you claim rights to use a mark, “you may simply use the ‘TM’ (trademark) or ‘SM’ (service mark) designation to alert the public to your claim of ownership of the mark”. However, there are advantages to registering a trademark, especially for enforcement. There is a fee for registering a trademark. You may only claim that a trademark is registered if it is actually registered. For more information, see the U.S. Patent and Trademark Office (PTO) page “Should I register my mark?”
• It can sometimes be a challenge to find a good name. Using a made-up word that has no Google hits is often a good start, but again, see the PTO site for more information.
• You do have to police the trademark’s use, or you could lose it.

OSS-like development approaches within the government

Q: What are “Open Government Off-the-Shelf” (OGOTS) or “Government OSS” (GOSS)?

Software that is developed collaboratively by multiple organizations within the government and its contractors for government use, and not released to the public, is sometimes called “Open Government Off-the-Shelf” (OGOTS) or “Government OSS” (GOSS). Often there is a single integrating organization, while other organizations inside the government submit proposed changes to the integrator. In some cases access is limited to portions of the government instead of the entire government.

Reasons for taking this approach vary. In some cases, there are nationally strategic reasons the software should not be released to the public (e.g., it is classified). In some other cases, the government lacks the rights to release the software to the public, e.g., the government may only have “Government Purpose Rights” (GPR).

OGOTS/GOSS software is often not OSS; software is only OSS if it meets the definition of OSS. For example, software that can only be used for government purposes is not OSS, since it cannot be used for any purpose. However, sometimes OGOTS/GOSS software is later released as OSS. This might occur, for example, if the government originally only had Government Purpose Rights (GPR), but later the government received unlimited rights and released the software as OSS.

Some people like the term GOSS, because it indicates an intent to do OSS-like collaborative development, but within the government instead. Others do not like the term GOSS, because GOSS is not actually OSS, and they believe the term can be misleading. In either case, it is important to understand that GOSS is typically not OSS, though GOSS may be a stepping stone towards later OSS release. Since both terms are in use, the rest of this document will use the term OGOTS/GOSS.

What is Open Technology Development (OTD)? What is its relationship to OSS?

OTD is an approach to software/system development in which developers (in multiple organizations) collaboratively develop and maintain software or a system in a decentralized fashion. OTD depends on open standards and interfaces, open source software and designs, collaborative and distributed online tools, and technological agility.

OTD includes both OSS and OGOTS/GOSS. An OTD project might be OSS, but it also might not be (it might be OGOTS/GOSS instead). Even if an OTD project is not OSS itself, an OTD project will typically use, improve, or create OSS components.

Are there guidance documents on OGOTS/GOSS?

Yes:

• Open Technology Development Lessons Learned includes discussions that apply to OGOTS/GOSS and OSS with government involvement.
• Office of the Director of National Intelligence (ODNI) Government Open-Source Software (GOSS) “Handbook for Govies” includes guidance specific to OGOTS/GOSS.

Other sources of information on OSS

Q: What additional material is available on OSS in the government or DoW?

Other documents that you may find useful include:

• Code.mil: Information about Open Source Software in the DoW.
• Frequently Asked Questions About Copyright and Computer Software - Issues affecting the U.S. Government with Special Emphasis on Open Source Software, CENDI (cendi.gov).
• Government Computer Software Acquisition and The GNU General Public License by B. Scott Michel (Lt. Cmdr., PhD, USN(RC)), Eben Moglen (Software Freedom Law Center), Mishi Choudhary (Software Freedom Law Center), and Dorothy Becker (Navy OGC, SPD Patent Counsel), October 1, 2011.
• Military - Open Source Software (MIL-OSS) DoD/IC discussion list