Official websites use .gov
Secure .gov websites use HTTPS
Office of the DoD CIO
2021-10-28
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 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.
Public Law 115-232 defines OSS defines OSS as “software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of such software”. This definition is essentially identical to what the DoD has been using since publication of the 16 October 2009 memorandum from the DoD CIO, “Clarifying Guidance Regarding Open Source Software (OSS)”.
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:
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 3. Using a standard license simplifies collaboration and eliminates many legal analysis costs.
“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 DoD has chosen to use the term “open source software” (OSS) in its official policy documents.
Commercially-available software that is not open source software is typically called proprietary or closed source software.
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”.
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).
The following policies apply:
In nearly all cases, OSS is commercial software, so the policies regarding commercial software continue to apply to OSS.
No. At a high-level, DoD 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 IA 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).
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). 40 CFR, Section 252.227-7014 Rights in Noncommercial Computer Software and Noncommercial Computer Software Documentation defines “Commercial computer software” as “software developed or regularly used for non-governmental purposes which: (i) Has been sold, leased, or licensed to the public; (ii) Has been offered for sale, lease, or license to the public; (iii) Has not been offered, sold, leased, or licensed to the public but will be available for commercial sale, lease, or license in time to satisfy the delivery requirements of this contract; or (iv) Satisfies a criterion expressed in paragraph (a)(1)(i), (ii), or (iii) of this clause and would require only minor modification to meet the requirements of this contract.”
There are many other reasons to believe nearly all OSS is commercial software:
This is confirmed by “Clarifying Guidance Regarding Open Source Software (OSS)” (2009) and the Department of the Navy “Open Source Software Guidance” (signed June 5, 2007). 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.
It is important to understand that open source software is commercial software, because there are many laws, regulations, policies, and so on regarding commercial software. Failing to understand that open source software is commercial software would result in failing to follow the laws, regulations, policies, and so on regarding commercial software.
In particular, U.S. law (10 USC 2377) requires a preference for commercial products for procurement of supplies or services. 10 USC 2377 requires that the head of an agency shall ensure that procurement officials in that agency, to the maximum extent practicable:
Similarly, it requires preliminary market research to determine “whether there are commercial services or commercial products or, to the extent that commercial products suitable to meet the agency’s needs are not available, nondevelopmental items other than commercial items available” that “(A) meet the agency’s requirements; (B) could be modified to meet the agency’s requirements; or (C) could meet the agency’s requirements if those requirements were modified to a reasonable extent.” This market research should occur “before developing new specifications for a procurement by that agency; and before soliciting bids or proposals for a contract in excess of 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.
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.
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.
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.
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. DoD Directive 5000.1 states that open systems “shall be employed, where feasible”, and 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 those of the European Interoperability Framework (EIF), the Digistan definition of open standard (based on the EIF), and Bruce Perens’ “Open Standards: Principles and Practice”.
In the DoD, the GIG Technical Guidance Federation is a useful resource for identifying recommended standards (which tend to be open standards). The GTG-F is a collection of web-based applications supporting the continuing evolution of the Department of Defense (DoD) Information Technology Standards. The DDR&E, Advanced Capabilities Modular Open Systems Approach web page also provides some useful background.
Many DoD 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.
Open standards can aid open source software projects:
Note that open standards aid proprietary software in exactly the same way.
OSS aids open standards, too:
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.
As noted by the 16 October 2009 policy memorandum from the DoD CIO, in almost all cases OSS is a commercial item 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. As stated in FAR 25.103 Exceptions item (e), “The restriction on purchasing foreign end products does not apply to the acquisition of information technology that is a commercial item, when using fiscal year 2004 or subsequent fiscal year funds (Section 535(a) of Division F, Title V, Consolidated Appropriations Act, 2004, and similar sections in subsequent appropriations acts).”
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.
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. It noted 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… Open source licensing has become a widely used method of creative collaboration that serves to advance the arts and sciences in a manner and at a pace that few could have imagined just a few decades ago… Traditionally, copyright owners sold their copyrighted material in exchange for money. The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties… 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. Indeed, because a calculation of damages is inherently speculative, these types of license restrictions might well be rendered meaningless absent the ability to enforce through injunctive relief.” In short, it determined that the OSS license at issue in the case (the Artistic license) was indeed an enforceable license.
In 2017, the United States District Court for the Northern District of California, in Artifex Software, Inc. v. Hancom, Inc., issued a ruling confirming the enforceability of the GNU General Public License. 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.
“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, 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.
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):
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:
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.
Note that 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.
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. Note that 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?”.)
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.
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 DoD 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?”.
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 Clause 52.212-4(d) establishes that “This contract is subject to the Contract Disputes Act of 1978, as amended (41 U.S.C. 7101-7109).” Furthermore, 52.212-4(s) says: “(s) Order of precedence. Any inconsistencies in this solicitation or contract shall be resolved by giving precedence in the following order: (1) the schedule of supplies/services; (2) the Assignments, Disputes, Payments, Invoice, Other Compliances, and Compliance with Laws Unique to Government Contracts paragraphs of this clause; (3) the clause at 52.212-5; (4) addenda to this 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.
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”.
No. Indeed, vulnerability databases such as CVE make it clear that merely hiding source code does not counter attacks:
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 DoD 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 DoD 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.
As noted in the Secure Programming for Linux and Unix HOWTO, three conditions reduce the risks from unintentional vulnerabilities in OSS:
The use of any commercially-available software, be it proprietary or OSS, creates the risk of executing malicious code embedded in the software. Even if a commercial program did not originally have vulnerabilities, both proprietary and OSS program binaries can be modified (e.g., with a “hex editor” or virus) so that it includes malicious code. It may be illegal to modify proprietary software, but that will normally not slow an attacker. Thankfully, there are ways to reduce the risk of executing malicious code when using commercial software (both proprietary and OSS). It is impossible to completely eliminate all risks; instead, focus on reducing risks to acceptable levels. 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.
Note that 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.
Note that 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.
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) says that, “An article is a product of a country or instrumentality only if (i) it is wholly the growth, product, or manufacture of that country or instrumentality, or (ii) in the case of an article which consists in whole or in part of materials from another country or instrumentality, it has been substantially transformed into a new and different article of commerce with a name, character, or use distinct from that of the article or articles from which it was so transformed.” 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.
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 DoD 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.”
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.
No, the DoD 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:
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.
Some more military-specific OSS programs created-by or used in the military include:
There are many others.
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:
If you are looking for smaller pieces of code to reuse, search engines specifically for code may be helpful. Examples include:
If you know of others who have similar needs, ask them for leads.
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.
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.
Yes. There is no DoD policy forbidding or limiting the use of software licensed under the GNU General Public License (GPL).
The DoD 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 DoD uses OSS extensively, and the GPL is the most popular OSS license.
As with all commercial items, the DoD 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 DoD 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.
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:
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). Note that 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. Note that this also applies to proprietary software, which often have even stricter limits on if/how the software may be changed.
The GPL and government “unlimited rights” terms have similar goals, but differ in details. This isn’t usually an issue because of how typical DoD 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).
No. Relevant government authorities make it clear that the Antideficiency Act (ADA) does not generally prohibit the use of OSS due to limitations on voluntary services. Instead, the ADA prohibits government employees from accepting services that are not intended or agreed to be gratuitous, but were instead rendered in the hope that Congress will subsequently recognize a moral obligation to pay for the benefits conferred.
Part of the ADA, Pub.L. 97-258, 96 Stat. 923, is in 31 U.S.C. § 1342, Limitation on voluntary services. This statute says that, “An officer or employee of the United States Government or of the District of Columbia government may not accept voluntary services for either government or employ personal services exceeding that authorized by law except for emergencies involving the safety of human life or the protection of property.”
The US Government Accountability Office (GAO) Office of the General Counsel’s “Principles of Federal Appropriations Law” (aka the “Red Book”) explains federal appropriation law. Volume II of its third edition, section 6.C.3, describes in detail this prohibition on voluntary services. Section 6.C.3.a notes that the voluntary services provision is not new; it first appeared, in almost identical form, back in 1884. The red book explains its purpose; since “an agency cannot directly obligate in excess or advance of its appropriations, it should not be able to accomplish the same thing indirectly by accepting ostensibly ‘voluntary’ services and then presenting Congress with the bill, in the hope that Congress will recognize a ‘moral obligation’ to pay for the benefits conferred…”
The red book section 6.C.3.b explains this prohibition in more detail. It states that in 1913, the Attorney General developed an opinion (30 Op. Att’y Gen. 51 (1913)) that “has become the leading case construing 31 U.S.C. § 1342… the Attorney General drew a distinction that the Comptroller of the Treasury thereafter adopted, and that GAO and the Justice Department continue to follow to this day—the distinction between ‘voluntary services’ and ‘gratuitous services.’” Some key text from this opinion, as identified by the red book, are:
“[I]t seems plain that the words ‘voluntary service’ were not intended to be synonymous with ‘gratuitous service’ … it is evident that the evil at which Congress was aiming was not appointment or employment for authorized services without compensation, but the acceptance of unauthorized services not intended or agreed to be gratuitous and therefore likely to afford a basis for a future claim upon Congress. . . .”
More recent decisions, such as the 1982 decision B-204326 by the U.S. Comptroller General, continue to confirm this distinction between “gratuitous” and “voluntary” service.
In short, the ADA’s limitation on voluntary services does not broadly forbid the government from working with organizations and people who identify themselves as volunteers, including those who develop OSS. Instead, Government employees must ensure that they do not accept services rendered in the hope that Congress will subsequently recognize a moral obligation to pay for the benefits conferred. Services that are intended and agreed to be gratuitous do not conflict with this statute. In most cases, contributors to OSS projects intend for their contributions to be gratuitous, and provide them for all (not just for the Federal government), clearly distinguishing such OSS contributions from the “voluntary services” that the ADA was designed to prevent.
OSS options should be evaluated in principle the same way you would evaluate any option, considering need, cost, and so on. 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 DoD does not have a single required process for evaluating OSS. The following externally-developed evaluation processes or tips may be of use:
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:
It also suggests that the following questions need to be addressed:
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”.
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.
No, DoD policy does not require you to have commercial support for OSS, but you must have some plan for support. The 2009 DoD CIO memo on open source software says, in attachment 2, 2(d), “The use of any software without appropriate maintenance and support presents an information assurance risk. Before approving the use of software (including OSS), system/program managers, and ultimately Designated Approving Authorities (DAAs), must ensure that the plan for software support (e.g., commercial or Government program office support) is adequate for mission need.” Note that Government program office support is specifically identified as a possibly-appropriate approach.
As noted in the article Open Source memo doesn’t mandate a support vendor (by David Perera, FierceGovernmentIT, May 23, 2012), the intent “of the memo was not to issue a blanket requirement that all open source software come bundled with contractor support or else it can’t be used… If a Defense agency is able to sustain the open source software with ‘its own skills and talents’ then that can be enough to satisfy the intent of the memo.” In addition, “How robust the support plan need be can also vary on the nature of the software itself… For command and control software, the degree would have to be greater than for something that’s not so critical to mission execution…”.
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 DAAs 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 DAAs must look at the specific situation to make a determination.
Government Off-the-Shelf (GOTS), proprietary commercial off-the-shelf (COTS), and OSS COTS are all methods to enable reuse of software across multiple projects. Thus, they are all strategies for sharing the development and maintenance costs of software, potentially reducing its cost.
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 DoD mission outcomes or business processes. (Note that such software would often be classifed.)
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.
For the DoD, 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 DoD 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.
DoD 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 DoD (such as lower cost, faster schedule, increased performance, or other factors such as increased flexibility), contractors should expect that the DoD 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.
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:
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 DoD 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 DoD) 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 noted in FAR 27.201-1, “Pursuant to 28 U.S.C. 1498, the exclusive remedy for patent or copyright infringement by or on behalf of the Government is a suit for monetary damages against the Government in the Court of Federal Claims. There is no injunctive relief available, and there is no direct cause of action against a contractor that is infringing a patent or copyright with the authorization or consent of the Government (e.g., while performing a contract).”
There are other ways to reduce the risk of software patent infringement (in the U.S.) as well:
The following are good practices:
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:
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.
If the government modifies existing OSS, but fails to release those improvements back to the main OSS project, it risks:
Similarly, if the government develops new software but does not release it as OSS, it risks:
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.
“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:
The government or contractor must determine the answer to these questions:
Source: Publicly Releasing Open Source Software Developed for the U.S. Government.
The following questions discuss some specific cases.
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. Note that under the DoD definition of open source software, such public domain software is open source software.
Note that 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?”)
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?”)
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 DoD 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 DoD 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.
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 DoD contract clause (DFARS 252.227-7014) permits this by default. The usual federal non-DoD 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 noted in “Technical Data and Computer Software: A Guide to Rights and Responsibilities Under Federal Contracts, Grants and Cooperative Agreements” by the Council on Governmental Relations (COGR), “This unlimited license enables the government to act on its own behalf and to authorize others to do the same things that it can do, thus giving the government essentially the same rights as the copyright owner.” In short, once the government has unlimited rights, it has essentially the same rights as a copyright holder, and can then use those rights to release that software under a variety of conditions (including an open source software license), because it has the use and modify the software at will, and has the right to authorize others to do so.
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.)
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.”
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.
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.
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:
Some documents that may help include:
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:
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. DoD 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. Note that many of the largest commercially-supported OSS projects have their own sites.
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):
For more about trademarks, see the U.S. Patent and Trademark Office (PTO) page “Trademark basics”. Note:
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.
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.
Yes:
Other documents that you may find useful include: