Office of the DoD CIO

2021-10-28

Frequently Asked Questions regarding Open Source Software (OSS) and the Department of Defense (DoD)

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.

Defining Open Source Software (OSS)

Q: What is open source software (OSS)?

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:

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

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

Q: What are synonyms for open source software?

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

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

Q: What are antonyms for open source software?

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

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

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

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

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

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

OSS and DoD Policy

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

The following policies apply:

1. The Federal Source Code Policy, OMB Memo 16-21, establishes policy regarding consideration of acquiring custom-developed code, requiring agencies to consider the value of publishing custom code as OSS, and establishing a OSS Pilot Program to release 20% of all custom-developed code as OSS. The DoD was later directed to implement this program by Section 875 of the National Defense Authorization Act for FY2018.
2. The DoD CIO issued a memorandum titled “Clarifying Guidance Regarding Open Source Software (OSS)” on 16 October 2009, which superseded a memo May 2003 memo from John Stenbit. An update to this guidance is in coordination as of July 2021.
3. The Department of Navy CIO issued a memorandum with guidance on open source software on 5 Jun 2007. This memorandum only applies to Navy and Marine Corps commands, but may be a useful reference for others. This memo is available at http://www.doncio.navy.mil/contentview.aspx?id=312. The Department of the Navy has also issued SECNAVINST 5230.15, which is focused on ensuring that Commercial Off The Shelf (COTS) Software is supported throughout its fielded lifecycle. This SECNAVINST also applies to OSS.
4. The Open Technology Development Roadmap was released by the office of the Deputy Under Secretary of Defense for Advanced Systems and Concepts, on 7 Jun 2006. It is available at http://www.dtic.mil/dtic/tr/fulltext/u2/a450769.pdf .
5. The Office of Management and Budget issued a memorandum providing guidance on software acquisition which specifically addressed open source software on 1 Jul 2004. It may be found at http://www.whitehouse.gov/omb/memoranda/fy04/m04-16.html.
6. US Army Regulation 25-2, paragraph 4-6.h, provides guidance on software security controls that specifically addresses open source software. This regulation only applies to the US Army, but may be a useful reference for others. The regulation is available at http://www.army.mil/usapa/epubs/pdf/r25_2.pdf .

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

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

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).

General information about OSS

Q: Is OSS commercial software? Is it COTS?

As explained in detail below, nearly all OSS is “commercial computer software” as defined in US law and the Defense Federal Acquisition Regulation Supplement, and if it used unchanged (or with only minor changes), it is almost always COTS.

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

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

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

These definitions in U.S. law govern U.S. acquisition regulations, namely the Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation Supplement (DFARS). 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:

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

This is confirmed by “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.

Q: Why is it important to understand that open source software is 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:

1. “acquire commercial services, commercial products, or nondevelopmental items other than commercial products to meet the needs of the agency;
2. require prime contractors and subcontractors at all levels under the agency contracts to incorporate commercial services, commercial products, or nondevelopmental items other than commercial products as components of items supplied to the agency;
3. modify requirements in appropriate cases to ensure that the requirements can be met by 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 products in response to agency solicitations;
4. state specifications in terms that enable and encourage bidders and offerors to supply 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 products in response to the agency solicitations;
5. revise the agency’s procurement policies, practices, and procedures not required by law to reduce any impediments in those policies, practices, and procedures to the acquisition of commercial products and commercial services; and
6. require training of appropriate personnel in the acquisition of commercial products and commercial services.”

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.

Q: How is OSS typically developed?

OSS is typically developed through a collaborative process.

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

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

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

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

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

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

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

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

No, although they work well together, and both are strategies for reducing “vendor lock-in”. Vendor lock-in, aka lock-in, is the situation in which customers are dependent on a single supplier for some product (i.e., a good or service), or products, and cannot move to another vendor without substantial costs and/or inconvenience. Lock-in tends to raise costs substantially, reduces long-term value (including functionality, innovation, and reliability), and can become a serious security problem (since the supplier has little incentive to provide a secure product and to quickly fix problems found later). An “Open System” is a “system that employs modular design, uses widely supported and consensus based standards for its key interfaces, and has been subjected to successful V&V tests to ensure the openness of its key interfaces” (per the DoD Open Systems Joint Task Force). Thus, open systems require standards that are widely-supported and consensus-based; standards that meet these (and possibly some additional conditions) may be termed “open standards”. Open systems and open standards counter dependency on a single supplier, though only if there is a competing marketplace of replaceable components. Indeed, according to Walli, “Standards exist to encourage & enable multiple implementations”. Many governments, not just the U.S., view open systems as critically necessary. 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.

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

Open standards can aid open source software projects:

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

Note that open standards aid proprietary software in exactly the same way.

OSS aids open standards, too:

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

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

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

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

As noted by the 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).”

OSS Licenses

Q: What is the legal basis of OSS licenses?

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

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

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

Q: Are OSS licenses legally enforceable?

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

The U.S. Court of Appeals for the Federal Circuit’s 2008 ruling on Jacobsen v. Katzer made it clear that OSS licenses are enforceable, even if money is not exchanged.  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.

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

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

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

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

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

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

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

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

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.

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

Yes. The Creative Commons is a non-profit organization that provides free tools, including a set of licenses, to “let authors, scientists, artists, and educators easily mark their creative work with the freedoms they want it to carry”.  A copyright holder who releases creative works under one of the Creative Common licenses that permit commercial use and modifications would be using an OSS-like approach for such works.  Wikipedia maintains an encyclopedia using approaches similar to open source software approaches. 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?”.)

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

No, complying with OSS licenses is much easier than proprietary licenses if you only use the software in the same way that proprietary software is normally used.  By definition, OSS software permits arbitrary use of the software, and allows users to re-distribute the software to others.  The terms that apply to usage and redistribution tend to be trivially easy to meet (e.g., you must not remove the license or author credits when re-distributing the software).  Thus, complex license management processes to track every installation or use of the software, or who is permitte