Executive Summary

This report documents the results of a short email-mediated study by The MITRE Corporation on the use of free and open-source software (FOSS) in the U.S. Department of Defense (DoD). FOSS is distinctive because it gives users the right to run, copy, distribute, study, change, and improve it as they see fit, without having to ask permission from or make fiscal payments to any external group or person. The autonomy properties of FOSS make it useful for DoD applications such as rapid responses to cyberattacks, for which slow, low-security external update processes are neither practical nor advisable, and for applications where rapid, open, and community-wide sharing of software components is desirable. On the other hand, the same autonomy properties complicate the interactions of FOSS with non-FOSS software, leading to concerns—some valid and some not—about how and where FOSS should be used in complex DoD systems.

The word free in FOSS refers not to fiscal cost, but to the autonomy rights that FOSS grants its users. (A better word for zero-cost software, which lacks such rights, is "freeware.") The phrase open source emphasizes the right of users to study, change, and improve the source code—that is, the detailed design—of FOSS applications. Software that qualifies as free almost always also qualifies as open source, and vice versa, since both phrases derive from the same set of software user rights formulated in the late 1980s by Richard Stallman of the Free Software Foundation .

The goals of the MITRE study were to develop as complete a listing of FOSS applications used in the DoD as possible, and to collect representative examples of how those applications are being used. Over a two-week period the survey identified a total of 115 FOSS applications and 251 examples of their use .

To help analyze the resulting data, the hypothetical question was posed of what would happen if FOSS software were banned in the DoD. Surprisingly, over the course of the analysis it was discovered that this hypothetical question has a real-world analog in the form of proprietary licenses that if widely used would effectively ban most forms of FOSS . For the purpose of the analysis, the effects of the hypothetical ban were evaluated based on how FOSS is currently being used in survey examples. In the case of niche-dominating FOSS products such as Sendmail (ubiquitous for Internet email) and GCC (a similarly ubiquitous compiler), a large amplification factor must also be taken into account when estimating such impacts. The actual levels of DoD use of such ubiquitous applications is likely to be hundreds, thousands, or even tens of thousands of time larger than the number of examples identified in the brief survey.

The main conclusion of the analysis was that FOSS software plays a more critical role in the DoD than has generally been recognized. FOSS applications are most important in four broad areas: Infrastructure Support , Software Development , Security , and Research . One unexpected result was the degree to which Security depends on FOSS. Banning FOSS would remove certain types of infrastructure components (e.g., OpenBSD ) that currently help support network security. It would also limit DoD access to—and overall expertise in—the use of powerful FOSS analysis and detection applications that hostile groups could use to help stage cyberattacks. Finally, it would remove the demonstrated ability of FOSS applications to be updated rapidly in response to new types of cyberattack . Taken together, these factors imply that banning FOSS would have immediate, broad, and strongly negative impacts on the ability of many sensitive and security-focused DoD groups to defend against cyberattacks.

For Infrastructure Support , the strong historical link between FOSS and the advent of the Internet means that removing FOSS applications would result in a strongly negative impact on the ability of the DoD to support web and Internet-based applications. Software Development would be hit especially hard for languages such as Perl that are direct outgrowths of the Internet, and would also suffer serious setbacks for development in traditional languages such as C and Ada. Finally, Research would be impacted by a large to very large increase in support costs, and by loss of the unique ability of FOSS to support sharing of research results in the form of executable software.

Neither the survey nor the analysis supports the premise that banning or seriously restricting FOSS would benefit DoD security or defensive capabilities. To the contrary, the combination of an ambiguous status and largely ungrounded fears that it cannot be used with other types of software are keeping FOSS from reaching optimal levels of use. MITRE therefore recommends that the DoD take three policy-level actions to help promote optimum DoD use of FOSS:

1. Create a "Generally Recognized As Safe" FOSS list. This list would provide quick official recognition of FOSS applications that are (a) commercially supported, (b) widely used, and (c) have proven track records of security and reliability—e.g., as measured by speed of closures of CERT reports in comparison to closed-source alternatives. Initial applications for consideration would include, but not be limited to, the set of 115 already-used applications identified by the survey in Table 2, plus other widely used tools such as Python (http://www.python.org/ ) that did not appear in this first set of results. In formulating the list, quick consideration should be given in particular to high value, heavily used infrastructure and development tools such as Linux ,OpenBSD , NetBSD , FreeBSD , Samba , Apache , Perl , GCC ,GNAT , XFree86 , OpenSSH , bind , and sendmail .
2. Develop Generic, Infrastructure, Development, Security, & Research Policies. The DoD should develop generic policies both to promote broader and more effective use of FOSS, and to encourage the use of commercial products that work well with FOSS. A good example of the latter is the Microsoft Windows Services for UNIX product, which relies on FOSS (GPL ) software to reduce development costs and dramatically increase its power. A second layer of customized policies should be created to deal with major use areas. For Infrastructure and Development, these policies should focus on enabling easier use of GRAS products such as Apache, Linux, and GCC that are already in wide use, but which often suffer from an ambiguous approval status. For Security, use of GPL within groups with well-defined security boundaries should be encouraged to promote faster, more locally autonomous responses to cyber threats. Finally, for Research the policies should encourage appropriate use of FOSS both to share and publish basic research, and to encourage faster commercial innovation.
3. Encourage use of FOSS to promote product diversity. FOSS applications tend to be much lower in cost than their proprietary equivalents, yet they often provide high levels of functionality with good user acceptance. This makes them good candidates to provide product diversity in both the acquisition and architecture of DoD systems. Acquisition diversity reduces the cost and security risks of being fully dependent on a single software product, while architectural diversity lowers the risk of catastrophic cyber attacks based on automated exploitation of specific features or flaws of very widely deployed products.

The author is deeply grateful to the following people, all of whom were gracious enough to review earlier versions of this document and make major contributions to the creation of this revised and greatly expanded version: Ira Rubinstein, David A. Wheeler, Tony Stanco, Frank Petroski, John D. Ramsdell, Bill Neugent, David H. Lehman, Robert F. Nesbit, Fritz Schulz, Dawn Meyerriecks, Flayo Kirk, Jan S. McNutt, Robert E. Cole, Robert Shepherd, William Curtis, Asghar Noor, and Jesse Pirocchi. The author would also like to thank all the MITRE and non-MITRE respondents who helped in the survey. In reverse alphabetical order these contributors include: Jim Van Zandt, Rob Wittman, Shawna Wimpy, George Wilson, Darryl Washington, Nathan Vuong, Gene Vogt, Gary Vecellio, Colin Valentine, Paul Valente, Stephen Upton, Porter Taylor, P Supko, Ed Shrum, Dan Scholten, Jacques Sabrie, Bryan Russina, Jarret Rush, Jeff Ross, Maureen Robinson, Frederick Potts, Bryant Obando, Doug Norman, John Morris, Mike McClimens, Mark Maybury, John Maurer, Karen Mason, Bill Mack, Dan Lowen, Daniel Loehr, Amlan Kundu, Anita King, Stephen Jones, Dan Jones, Mike Jay, David Jacobs, DeAnn Iwan, Bill Horton, Lee Hobbins, Jean Henchey, Ray Haller, Paul Grund, Steven Gosnell, Bob Goldsmith, James Finegan, Allen Epps, Alexander Enzmann, Perry Engle, Darren Dusza, Peter Dugan, Emil Derenzo, Ken Christy, Dave Burgess, Chuck Boeckman, CDR Christopher Biow, Carl Benkley, Matt Beebe, Scott Barman, Richard Baldwin, Pete Attas, Douglas Atkinson, Jon Anderson, and Dock Allen. Finally, I would like to thank the following people, also listed in reverse alphabetical order, for providing post-release corrections to report: David N. Welton, W. Craig Trader, Larry Sevilla, David Neeley, Melchior Franz, Alan Knowles, and Lee Doolan.

— Terry Bollinger, The MITRE Corporation

To receive the most recent version of this MITRE Corporation document, or to recommend any additions or changes to the document, please contact Terry Bollinger at terry@mitre.org .

List of Figures

List of Tables

1. Introduction
1. Purpose

This report documents the results of a short email-mediated study by The MITRE Corporation on the use of free and open-source software (FOSS) in the U.S. Department of Defense (DoD) . The goals of the MITRE study were to develop as complete a listing of FOSS applications used in the DoD as possible, and to collect representative examples of how those applications are being used. Over a two-week period the survey identified a total of 115 FOSS applications and 251 examples of their use (Table 2).

2. Document Overview

This document is extensively linked both internally and to relevant external web sites. To use the links, simply click on the underlined words or phrases in the electronic version. The paper version of the document also shows the addresses of external as both footnotes and as references in Appendix E. Please note that certain links to locations in Appendix F will not work if you do not have a copy of the separate file that contains that appendix.

Section 1 (this section) provides background information on FOSS, an overview of how the survey was conducted, and a summary of results. Section 2 provides an analysis of the survey results, focusing on understanding the types of FOSS users identified in the survey. Finally, Section 3 provides three major recommendations, which can also be found in the Executive Summary at the very beginning of this document.

The survey data and data breakdowns are provided in the form of six appendices. Appendix A lists the full set of 115 FOSS applications identified in the survey, and breaks them down by application area. Appendix B provides descriptions of the individual FOSS applications, with links to the examples of use identified for each tool. Appendix C provides a detailed breakdown by application area of which FOSS licenses are used by the identified applications. Appendix D is a lengthy appendix that provides the full text of every license used by the identified tools, as well as additional related licenses and license information. Appendix E summarizes references from the document, which can also be found as linked footnotes throughout the document. Finally, Appendix F contains a Sensitive But Unclassified (SBU) table of all the example uses of FOSS found in the survey. It is contained in a separate file.

3. Background: Questions and Answers About FOSS
1. What is Free and Open-Source Software (FOSS)?

Free and open-source software (FOSS) is software that gives users the right to run, copy, distribute, study, change, and improve it as they see fit, without them having to ask permission from or make additional payments to any external group or person. The word free in FOSS refers not to fiscal cost, but to the autonomy rights that FOSS grants its users. (A better word for zero-cost software, which lacks such rights, is "freeware.") The phrase open source emphasizes the right of users to study, change, and improve the source code—that is, the detailed design—of FOSS applications. Software that qualifies as free almost always also qualifies as open source, and vice versa, since both phrases derive from the same set of software user rights formulated in the late 1980s by Richard Stallman of the Free Software Foundation .

2. What is GPL Software?

The General Public License (GPL) is the original FOSS license, and GPL software is simply FOSS software that is covered by the GPL. The GPL was developed in the late 1980s by Richard Stallman as a way to convert his concept a software user’s Bill of Rights into a legally meaningful way to share and develop software. Since all FOSS originates directly or indirectly from Stallman’s original set of software user rights, the GPL tends to be the most accurate representation of the underlying principles of FOSS development.

The implications of this close link between the GPL and the underlying principles of FOSS can be seen in its overwhelming dominance among FOSS products. For example, over half of the software in the popular Red Hat Linux operating system is licensed under the GPL, and sites that support FOSS projects typically report that over 70% of their projects use the GPL. The results of the survey done for this report also support the dominance of the GPL, with 52% of the 115 identified applications being licensed wholly or predominantly under the GPL, and the next most popular type of license (BSD ) comprising a mere 6% of the total.

The most distinctive aspect of the GPL is its focus on the right of the software user to make autonomous decisions about how to use the software. GPL clauses ensure that individual users always retain the right to decide if, when, and how to use the software. For example, users always have the right to choose where and how to install GPL software, to analyze how it works, to change it, to decide if and when to release such changes, and even whether to sell original or modified GPL software at whatever price the market will bear. (Without the addition of distinguishing features or services, however, that market price will generally very low, since others can also sell or make copies of the same GPL software.) At no point in this process are GPL users required to ask for permission or guidance from outside entities or authorities, or to pay them additional fees, since the GPL itself provides all of the authorization required.

Another important and controversial Stallman innovation in the GPL was his use of transitive user rights to help ensure the rapid expansion of both the GPL user community and of the overall collection of GPL software. Transitive user rights mean that if anyone creates a new product that is based on the detailed design (source code) of an earlier GPL product, then they must provide any subsequent users of the new product with the same user rights that they had. In other words, the new work must also be placed under the GPL. Stallman realized that without this constraint the set of user rights provided by the GPL would evaporate over time as intermediate developers either neglected or explicitly chose not to convey the same level of autonomy to subsequent generations of users. Insisting on transitive user rights prevents this from happening, and ensures continued propagation of user rights. To balance the inclusive effect, however, Stallman made sure that it applied only when extensive, detailed use of the earlier GPL software was going on. It does not apply, for example, to those who are simply using (executing) GPL software, or to software that simply happens exists on the same system as GPL software.

Stallman in effect postulated that if individual programmers were given the autonomy to use GPL fully, and that if such rights could always be conveyed all subsequent developers, the result would be explosive growth in both the number of participants and the capabilities of the resulting set of software. Stallman’s implicit postulate was largely validated over the course of the 1990s by the subsequent emergence of the World Wide Web, whose software components used and depended more upon GPL than on any other type of license. The full implications of Stallman’s work are yet to be seen, but via the Internet his principles have already had global consequences.

3. What is Open Source Software?

Open source software is FOSS that uses any license approved by the Open Source Initiative (OSI) in their convenient list of open source licenses . The OSI list is based on the open source definition , which in turn is heavily based on Stallman’s list of software user rights , but with the addition of several additional criteria intended to ensure fairness of the licenses. Both sets of criteria result in the selection of nearly identical sets of licenses, despite such differences.

4. Can FOSS Be Mixed with Proprietary Software?

A common assumption about FOSS licenses such as GPL is that their transitive user rights means they cannot be used with non-FOSS (e.g., government or proprietary) software. However, this is generally not the case; such mixing can generally be done in various ways. For example, even GPL with its strong protection of transitive user rights provides a number of mechanisms to allow such mixing (Figure 1). Microsoft provides a good example of an innovative use of one such mixing strategy in their Windows Services for Unix (SFU) product. This product uses proprietary software to build an initial bridge between Windows and UNIX operating systems, and then adds in GPL tools and utilities to extend greatly its overall emulation of UNIX. Users benefit from the extended functionality provided by the GPL components, while Microsoft benefits by avoiding the cost and time of re-developing the tools as proprietary software.

Figure 1 . Strategies for Mixing GPL and Proprietary Software

(a) Distribution Mixing – GPL and other software can be stored and transmitted together. Example: GPL software can be stored on the same computer disk as (most kinds of) proprietary software.

(b) Execution Mixing – GPL and other software can run at the same time on the same computer or network. Example: GPL and (unrelated) proprietary applications can be running at the same time on a desktop PC.

(c) Application Mixing – GPL can rely on other software to provide it with services, provided either that those services are either generic (e.g., operating system services) or have been explicitly exempted by the GPL software designer as non-GPL components. Examples include GPL applications running on proprietary operating systems or wrappers, and GPL applications that use proprietary components explicitly marked as non-GPL. Windows Services for UNIX 3.0 is a good example of commercial use of GPL application mixing.

(d) Service Mixing – GPL can provide generic services to other software. These services must be genuinely generic in the sense that the applications that use them must not depend on the detailed design of the GPL software to work. An example is linking a GPL utility to a proprietary software component by using the Unix "pipe" mechanism, which allows one-way flow of data to move between software components. This is the tightest form of mixing possible with GPL and other types of software, but it must be used with care to ensure that the GPL software remains generic and is not tightly bound to any one proprietary software component.

Note: GPL does not permit mixing of licenses when new software is directly derived from GPL source code;
such derived products must be licensed under GPL.

Since most FOSS licenses are similar in concept to the GPL, the mixing strategies listed in Figure 1 generally apply to other FOSS licenses as well. However, novel licenses should always be checked for unusual qualifiers or constraints. A number of FOSS licenses such as BSD provide additional ways to mix software types, such as through constrained direct integration of binary software into proprietary software.

5. Can FOSS Be Sold Commercially?

All of the major FOSS licenses, including GPL, permit commercial sale of FOSS software and products. The catch, however, is that since anyone can sell or copy the same software as you, the prices for FOSS products tend to be very low in the absence of other distinguishing features or services. In the late 1990s companies such as Red Hat and VA Software began to develop ways to provide commercial services in support of FOSS software products such as the Linux operating system. In the FOSS business model, such companies benefit from reduced long-term costs of supporting a large, complex code base, but they must also compensate for their loss of product uniqueness by stressing customer services and various forms of innovation in terms of new products and services. From a business support perspective the availability of companies that directly support FOSS products provides much the same kind of product and support continuity that organizations expect from proprietary software products.

6. How do FOSS Licenses Compare to Each Other?

As of mid 2002, nearly three dozen software licenses qualified as being open source , and thus FOSS, according to the defining criteria of the Open Source Initiative . In practice, however, only a small number of these licenses are widely used. Furthermore, less frequently used licenses are often based on or closely similar to more commonly used licenses. Table 1 summarizes a number of differences between four of the most important FOSS licenses. Additionally, the table includes the related concept of public domain software and an example of a proprietary software license that is notable for precluding the use of FOSS software.

Table 1 . A Comparison of FOSS and Related Licenses

License: Property			GPL	LGPL		BSD & MIT	Apache	Public Domain	Microsoft MIT4 EULA
a. Can be stored on disk with other license types			ü	ü		ü	ü	ü	(bans FOSS)5
b. Can be executed in parallel with other license types			ü	ü		ü	ü	ü	(bans FOSS)5
c. Can be executed on top of other license types			ü	ü		ü	ü	ü	(bans FOSS)5
d. Can be executed underneath other license types			ü 1	ü		ü	ü	ü	(bans FOSS)5
e. Source can be integrated with other license types				ü		ü	ü	ü	(bans FOSS)5
f. User decides if and when to publish derived code			ü 2	ü		ü	ü	ü	ü
g. Software can be sold for a profit			ü	ü		ü	ü	ü	ü
h. Binary code can be replicated by users as desired			ü	ü		ü	ü	ü
i. Binary code can be redistributed as desired			ü 3	ü		ü	ü	ü
j. Binary code can be used as desired by users			ü	ü		ü	ü	ü
k. New users always receive source code of derived works			ü	ü 6
l. New users receive full source modification rights for derived works			ü	ü 6
m. New users receive full redistribution rights for derived works			ü	ü 6
n. Binary code can be released without source code						ü	ü	ü	ü
o. Derived code can have a different type of license				7				ü
p. Original source can be incorporated into closed source products								ü
1 Provided that both programs are fully and independently usable in other unrelated contexts. 2 Provided that the binary code has not been previously released to the public. 3 Provided that source code is always redistributed along with the binary code. 4 The proprietary Microsoft MIT EULA is not related to the similarly named MIT (X/MIT) license. 5 Specifically bans use of: GPL, LGPL, Artistic, Perl, Mozilla, Netscape, Sun Community, and Sun Industry Standards. 6 The rights granted by LGPL do not necessarily extend to the applications linked into an LGPL library. 7 The LGPL does permit re-licensing under GPL as a special case, but not re-licensing under any other license type.
License Acronyms:
GPL –	GNU General Public License	(Microsoft) MIT –			Mobile Internet Toolkit
LGPL –	GNU Lesser General Public License	(X/MIT) MIT –			Massachusetts Institute of Technology
BSD –	Berkeley Software Distribution	EULA –			End-User License Agreement
MPL –	Mozilla Public License	FOSS –			Free and Open-Source Software

Properties (a) through (e) in the table examine the ability of a license to co-exist with other types of software, e.g., the ability of FOSS licenses to co-exist with proprietary software. In this category, the most exclusive license is easily the Microsoft MIT EULA license , which prohibits a number of FOSS licenses from co-existing on the same platform as the EULA software. No other FOSS or proprietary license encountered during the survey came close to this level of exclusivity. The GPL takes a very distant second place for exclusivity, since it forbids design-time incorporation of GPL source code into non-GPL source code. However, unlike the Microsoft MIT EULA, the GPL places no constraints on software simply running on the same system, and actually goes out of its way not to intrude on other licenses outside of that context. The GPL even allows non-GPL software to use GPL software as long as the two programs are not inextricably linked to each other (that is, they can both be used independently in other contexts). The GNU Lesser GPL (LGPL) is even more accommodating, allowing software to be directly incorporated into non-free software. The BSD and Apache license are still more accommodating by allowing distribution in binary form only. Finally, and not surprisingly, the most permissive category of all is public domain software, which allows essentially any use.

Properties (k) through (m) point out the flip side of the somewhat restrictive nature of the GPL: Its ability to ensure that later generations of users will inherit exactly the same rights to use, change, and redistribute GPL software as the first generation of users.

4. Overview of the DoD FOSS Survey

The data for the DoD FOSS survey was collected by email. The goal of the survey was to identify as complete a listing of the FOSS applications in use within the DoD as possible, and to document a diverse and representative set of examples of how these FOSS applications are being used. Over a two-week period the survey identified a total of 115 FOSS applications and 251 documented examples of how these applications are being used in the DoD. For purposes of completeness and comparison, a small number of cases were included in which the applications clearly do not meet FOSS criteria, but are related to FOSS in terms of availability of source code or use of FOSS-like processes for sharing work within limited communities. All such examples are noted as such, and should not be confused with applications that are unambiguously FOSS.

The set of 115 applications should include the majority of FOSS applications currently in use within the DoD, as judged by the increasing rate towards the end of the study at which new data points matched previously identified applications. The 251 examples of FOSS use are highly diverse both in terms of the DoD organizations represented and the types of applications. The set of examples likely includes most "big program" uses of FOSS, since explicit decisions to use FOSS in large programs generally led to multiple identifications of such programs in the survey responses. However, the examples clearly represent only the tip of an iceberg in terms the total number of facilities, operators, developers, researchers, and contractors using FOSS applications to support DoD work. For example, the GPL GCC compiler dominates C-language software development globally, and it has few competitors. This dominance makes it likely that the total instances of use of GCC by DoD software developers is hundreds or more likely thousands of times larger than the nine examples identified over the course of this short survey. The categories of FOSS applications that are most likely to have such large amplification factors are software development, web support, and network administration, which are all areas where FOSS applications are traditionally strong.

5. Survey Details

The detailed results of the survey are available in the form of a Sensitive But Unclassified (SBU) Appendix F. By placing this document and Appendix F in the same folder with the original filenames, Appendix F recipients can use hyperlinks from this document to access relevant data.

6. Analysis Approach

To help analyze the resulting data, the hypothetical question was posed of what would happen if FOSS software were banned in the DoD. Surprisingly, over the course of the analysis it was discovered that this hypothetical question has a real world analog in the form of proprietary licenses that if widely used would effectively ban most forms of FOSS . A corollary question is what the impact of banning the GPL alone would be, although many FOSS licenses are too much like GPL to make this distinction easy. The survey found that the GPL sufficiently dominates in DoD applications (Table 9) for a ban on GPL to closely approximate a full ban of all FOSS.

7. Summary of Results

The main conclusion of the analysis was that FOSS software plays a far more critical role in the DoD than has been generally recognized. The value of FOSS to the DoD appears to be greatest in four broad categories: Infrastructure Support , Software Development ,Security , and Research .

1. Infrastructure Support

While commercial equivalents Infrastructure FOSS applications are generally available, banning FOSS products would nonetheless result in a significant short-term cost spike as low-cost FOSS networking and web applications are replaced purchased proprietary equivalents. Ironically, there is no evidence that such a conversion would result in performance benefits. Since much of the infrastructure of the Internet was created under the FOSS model, its infrastructure applications such as Apache are generally older, more functionally mature, and less likely to fail than much more recent proprietary equivalents.

2. Software Development

A FOSS ban would have an especially negative impact on DoD software development. Development projects that use FOSS versions of the C and Ada programming languages would face costly translations to proprietary compilers and run time support packages. For the latter case of Internet-based languages such as Perl , recovery would be especially difficult since there are no immediately available commercial equivalents.

3. Security

One of the more unexpected results of the survey was the degree to which DoD security depends on FOSS applications and strategies. Banning FOSS in this area 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 as ban would prevent DoD groups from using the same analysis and network intrusion applications that hostile groups could use to stage cyberattacks. It would remove the uniquely FOSS ability to change infrastructure source code rapidly in response to new modes of cyberattack. More interestingly, the GPL turns out to be particularly well suited to use in security environments because of such environments include an existing well-defined ability to protect and control release of confidential information. This existing awareness largely removes the risk of premature release of GPL source code by developers, while maximizing the ability of those same developers to full use of the autonomy of decision provided by the GPL.

4. Research

DoD research would also be seriously damaged by a ban on FOSS. In this case, both cost and capabilities are important factors. Research efforts often use FOSS to extend limited budgets and allow them to focus more quickly on their research agendas. In terms of capabilities, FOSS provides resources such as mathematical software and the ability to link PCs into supercomputers for which there are no equivalent commercial alternatives. Finally, the FOSS method itself provides a form of "active publishing" that researchers use to share not just printed results, but software that can be immediately used to support further work.

2. Analysis of FOSS Survey Results
1. Types of DoD FOSS Users

The survey showed that the majority of DoD FOSS users are simply using the software without modifying the source, and in most cases without even looking at it. Such users are unaffected by the FOSS licenses of those applications. However, there are also cases where a project may choose to use FOSS licenses, or where the implications of the licenses need to be understood. The main categories of DoD FOSS users identified in the survey are described below.

1. Operational Use rs

As anticipated, the majority of the users in the survey only used their applications operationally – that is, without looking at or using the source code for them. Examples include using Linux, Apache, OpenBSD, and a variety of security applications.

2. Scripting and Basic Code Development Users

This category was also large. It includes using language and scripting applications such as Perl, GCC, bash, and JBoss to write simple scripts and code packages. Perl in particular was the single most widely used FOSS application in the survey. In terms of licensing, this category is similar to operational except for one difference: any libraries of parts that are used should be checked to make sure that they do not use licenses (e.g., the GPL) that would inadvertently require the new software to be FOSS also.

3. Advanced Code Development Users

This is a much smaller category that mostly includes cases where large, complex library routines (e.g., scientific and parallel processing routines) need to be incorporated into new software. While it may be worth doing this kind of work under a FOSS model, such decisions should not be made accidentally, but should be decided ahead of time.

4. FOSS Sponsors

Finally, the smallest group of DoD projects consisted of those that had explicitly decided to use a FOSS model to promote non-DoD development work on their project. The two main examples of this in the survey are SELinux (Secure Linux), which is a FOSS effort sponsored by the NSA, and CVW (Collaborative Virtual Workspace), which was initially developed by The MITRE Corporation for DoD use. While small numerically, this category is interesting because it demonstrates examples of the DoD and its associates using a FOSS model to help promote software advances in a larger overall community.

2. Observations

Some of the more surprising results of the data are given below.

1. FOSS Software is Vital to DoD Information Security

The survey identified 44 examples where organizations involved in DoD Security use FOSS software. The FOSS communities contribute to DoD security in two ways. Firstly, it has produced infrastructure software such as OpenBSD with low rates of software failure combined with early and rapid closure of security holes, which makes such systems useful as the security linchpins in broader security strategies. Secondly, the FOSS communities have had a long-term fascination with developing more and more sophisticated applications for identifying and analyzing security holes in networks and computers, resulting in FOSS products such as SARA and Snort that are invaluable to in-depth analyses of security risks.

The incentive for creating network analysis applications is different, but still deeply embedded in the psychology of FOSS development. In this case there is a strong competitive thread to FOSS developers that encourages them both to demonstrate flaws in the systems of others, while proving the reliability of their own systems. This gaming psychology tends to produce an "arms race" mentality in which both the strategies for analyzing weaknesses and the ability to defend against attacks are constantly improving.

Yet another important way in which FOSS contributes to security is by making it possible to change and fix security holes quickly in the face of new modes of cyberattack. This ability, which allows rapid response to new or innovative forms of cyberattack, is intrinsic to the FOSS approach and generally impractical in closed source products.

2. DoD Web Infrastructures Would Be Hit Hard

Infrastructure was the single largest category of DoD use of FOSS applications (see Table 3). This is in part because the Internet itself developed around a largely FOSS approach, with many of its most mature and widely used components (e.g., Apache ,Sendmail , or Qmail ) being FOSS. Consequently, it is difficult to construct an effective web or Intranet without relying on at least some minimal level of FOSS applications, as reflected by the large number of examples of FOSS infrastructure reliance identified by the survey. If rigorously enforced, a full ban on the use of FOSS web components within the DoD would result in at least a temporary shutdown of many or most of its web-based network and services. Even when commercial equivalents to FOSS web products are available, the relative immaturity of the commercial equivalents could increase risks for DoD infrastructures.

3. DoD Research Relies Heavily on FOSS for Synergy

For some components of the DoD research community, FOSS software acts as a sort of "active publication" medium in which important results are posted in the form of software and collectively improved by the entire community. This effect is especially strong in numeric processing and simulation, where FOSS products provides some of the best processing methods and software available anywhere. A ban on FOSS software here would both slow the exchange of ideas and make certain types of research (e.g., research based on supercomputer networks of low-cost PCs) impractical.

4. Cost Is Seldom the Only Reason for Choosing FOSS

More often than not, the strongest deciding factors for choosing FOSS products were capability and reliability, with cost being an important but secondary factor. In the small number of cases where groups chose to use FOSS software purely for cost reduction reasons, they were more likely to be disappointed by issues such as incompatibility with closed source systems that they were attempting to replace or complement.

5. Software Development Would Be Hit Hard

FOSS languages and applications such as GCC for the C language and GNAT for Ada have become so endemic in software development that a full, rigorously enforced ban on using FOSS could bring affected DoD software development projects to a halt. Such a ban would also remove a number of widely used program development applications such as CVS and GDB . The impact of a ban would be even more severe for development in languages such as Perl , which is a relatively recent language that has become an integral part of the Internet, and which is also widely to build "glue code" for integrating software applications. While commercial alternatives exist for older languages such as C and Ada, they are generally neither as mature or as portable across platforms as the FOSS equivalents. In the case of languages such as Perl that originated as FOSS, commercial alternatives do not exist, and applications would need to be translated into other languages.

3. An Analysis of Approaches to DoD FOSS Policy

In this section, a number of possible approaches to DoD FOSS policy are described and briefly analyzed for their likely consequences.

1. Approach #1: Ban All DoD Use of FOSS

The implementation of a DoD policy that bans any use of FOSS products would likely have interesting (and largely negative) short-term and long-term impacts on DoD cost, reliability, and capability. Figure 2 shows a notional estimate of such impacts on DoD FOSS users.

Figure 2 . Likely Impacts on Users of Banning FOSS



The short-term impacts would be the most serious. These impacts reflect both that the DoD already makes significant use of FOSS applications, and that a number of FOSS capabilities (particularly in the areas of high-end computing, security, and Internet-oriented software development) and security) are not readily available from closed-source COTS products. Short-term impacts on security would be especially bad due to the need to replace reliability- and security-focused systems such as OpenBSD with COTS systems that often have notable security and reliability issues . Over the long term, however, security would probably gradually improve as the closed-source COTS vendors continue to fix bugs and security flaws that were already absent from the FOSS products that they replaced.

Costs would also take a significant short-term hit as the low-cost and no-cost FOSS components are replaced with purchased proprietary products. Overall costs would then likely come down during an interim period. However, in the long term removing FOSS would remove an important source of price and quality competition. Without the constant pressure of low-cost, high-quality FOSS product competing with the closed-source products, the closed-source vendors could more easily fall into a cycle in which their support costs balloon and costs are passed on to their locked-in customers.

Capability would be negatively affected in both the short and long term, especially for high-end scientific and research computing that would lose resources such as libraries of high-quality mathematical software and support for high-end computing . Software development could become a difficult process, since the GCC family of compilers for C, C++, and other languages has become so prevalent that few similarly platform-independent alternatives exist. Development and support of Ada programs would be similarly affected, since the FOSS GNAT compiler dominates the Ada language in much the same way that GCC dominates C.

Ironically, a thoroughly rigorous and systematic ban on DoD use of FOSS could also affect a number of proprietary product that rely on FOSS products that permit incorporation of FOSS into their closed-source products. For example, Microsoft Office uses the FOSS zlib collection of data compression software, and thus could technically be banned as a product that incorporates FOSS software.

Finally, it should be noted simply using GPL software in combination with proprietary or closed-source government software does not have any affect the licensing of the non-GPL software. The GPL only requires that new source code that directly incorporates GPL software be made GPL, which is not the case for operational (e.g., infrastructure and security) use of GPL applications.

2. Approach #2: Limbo Status

At present, FOSS is neither approved nor disapproved in most parts of the DoD. This limbo status makes program, project, and developer decisions regarding FOSS difficult. Developers are often aware of the benefits of FOSS products for certain types of applications, but are unwilling to share that knowledge with their supervisors or commanding officers for fear that they will be told that they are using "unapproved" applications.

This de facto limbo-status policy of the DoD towards FOSS is unfortunate, since based on the way in which FOSS are being used, it is likely that the DoD would benefit from more use of FOSS rather than less. For example, although the FOSS Apache web server is mature, capable, and has an superior track record as measured the number of security holes on public tracking sites such as CERT , it is sometimes avoided on DoD sites simply because site administrators are unsure of its status. In such cases, a policy that explicitly permits the use of Apache would likely result in both improved overall reliability and lower costs for the DoD.

3. Approach #3: Selective FOSS Approvals

In this scenario, selected well-known and well-established FOSS products such as Apache, OpenBSD, GCC, GNAT, and Red Hat Linux would be selectively approved for DoD-wide use.

This approach would have immediate and largely beneficial effects, since many of these programs are already heavily in use in the DoD and have many users and supporters already in place. Approval would allow immediate broader use of such applications by users who for the most part will already be familiar with how to install and use them. Costs would drop in both the short and long term as more costly applications are replace by FOSS products such as Apache that are almost universally considered to be higher quality. Reliability and security would also improve, given that several of these well-known products already have established track records in these areas. Finally, capabilities would improve as the capabilities of these systems are distributed to more and more sites, and in some cases used to upgrade older systems. For example, Linux can often be used to increase the reliability and performance of older systems that are not capable of upgrading to new, much heavier-weight versions of Windows.

The main disadvantage of this approach would be that the selective approval process would likely overlook many of the smaller but highly important niche uses of FOSS, such as some of the security and numeric processing applications.

4. Approach #4: Security, Infrastructure, Research, and Development

This approach would provide DoD approval for using FOSS products in four general areas: Infrastructure Support, Software Development, Security, and Research. Rather than providing a fixed list, this approach would provide broad guidelines for selecting FOSS products in each of the areas, as well as specific lists of pre-approved products.

For Infrastructure Support , users would be able to select widely used and commercially supported FOSS applications such as Linux , Apache , OpenBSD , and other applications related to supporting the information infrastructure of an enterprise. A list of recommendations would be provided, but would not be exclusive. Groups would be able to choose other Infrastructure FOSS products if they meet the overall criteria for acceptable Infrastructure FOSS products. This category would never involve any kind of software development, and so would be unaffected by the special licenses of FOSS.

For Software Development , relevant FOSS applications such as Perl ,CVS , GCC , GNAT ,JBoss , Emacs , and others would be listed explicitly, and others allowed if they meet overall criteria for such applications. In contrast to Infrastructure and Security, users would be required to know and understand the particulars of the FOSS licenses of their applications, so that they are away of areas that could invoke FOSS licenses. For example, the LGPL license used with the C libraries of the GCC compiler does not involve FOSS licenses for any software developed, but there are other examples of C libraries that use GPL licenses that would affect software that uses them. Users of Development FOSS products should be aware in particular of the status of any library software that they use. Invoking a FOSS license could be done intentionally, such as to make better use of a community of like-minded developers outside of a government organization, but it should never be invoked accidentally (e.g., by not checking to see whether a library of components is under the LGPL or GPL).

An example of an area where explicit FOSS development policies would be useful is in the selection and use of FOSS software libraries. This need to be selected with some care, since for example libraries that use the GPL may require that software developed using those routines be GPL also. The GNU Scientific Library (GSL) , for example, contains many useful scientific routines, but was not used by any of the respondents. One respondent indicated that he had specifically avoided the GSL because of its use of GPL. While choosing to use GPL libraries may be appropriate if the goal is to contribute new features to a broader community, such libraries may be conversely be inappropriate when such release is not the desired goal.

For Security , users would similarly have a list of known, recognized products to use for non-development applications, plus guidelines for selecting other products. Guidelines for selecting Security FOSS products would be more stringent than for Infrastructure, since many security-related FOSS products could damage a system or network if used improperly.

Approval for Research use of FOSS would be similar to that for Development, but with more emphasis and leeway for sharing results and contributing to a community of developers. As with Development, though, software should not be made FOSS accidentally, but only by an explicit (and approved) decision to do so.

5. Approach #5: Advocating FOSS Products

There is a point of diminishing returns in all things, and in the case of FOSS, trying to force people to use FOSS products when it is not their own choice is likely well past that point. This is especially true since many of the highest quality FOSS products seem to show up in areas such as infrastructure, security, development, and research. All of these areas share the feature that they include people who are interested in pushing the limits of what they can do with a system or software, rather than simply using the software operationally. In contrast, desktop applications have tended to stay more stubbornly in the realm of closed-source COTS, at least for now.

In short, FOSS seems to work best when people come to it, and not vice-versa. In the study, one of the small number of negative reactions to using a FOSS product (GCC) came as a result of force-fitting it into a situation where compatibility with a closed source compiler was more important than the low cost of the GCC compiler. Anecdotal evidence tends to confirm the idea that using FOSS products only to "save money" is not necessarily a good idea , especially if the fit to the problem is not that good. Such products are best chosen because they have features that are desirable for how they will be used.

4. Conclusions

Based on the above analysis, the FOSS policy approach that appears most likely to benefit the DoD would be a combination of the third (selective approvals) and fourth (security, infrastructure, research, and development based) approaches. The resulting recommendation is summarized in the next and final section of this report.

3. Recommendations

Neither the survey nor the analysis supports the premise that banning or seriously restricting FOSS would benefit DoD security or defensive capabilities. To the contrary, the combination of an ambiguous status and largely ungrounded fears that it cannot be used with other types of software are keeping FOSS from reaching optimal levels of use. MITRE therefore recommends that the DoD take three policy-level actions to help promote optimum DoD use of FOSS:

1. Create a "Generally Recognized As Safe" FOSS list. This list would provide quick official recognition of FOSS applications that are (a) commercially supported, (b) widely used, and (c) have proven track records of security and reliability—e.g., as measured by speed of closures of CERT reports in comparison to closed-source alternatives. Initial applications for consideration would include, but not be limited to, the set of 115 already-used applications identified by the survey in Table 2, plus other widely used tools such as Python (http://www.python.org/ ) that did not appear in this first set of results. In formulating the list, quick consideration should be given in particular to high value, heavily used infrastructure and development tools such as Linux ,OpenBSD , NetBSD , FreeBSD , Samba , Apache , Perl , GCC ,GNAT , XFree86 , OpenSSH , bind , and sendmail .
2. Develop Generic, Infrastructure, Development, Security, & Research Policies. The DoD should develop generic policies both to promote broader and more effective use of FOSS, and to encourage the use of commercial products that work well with FOSS. A good example of the latter is the Microsoft Windows Services for UNIX product, which relies on FOSS (GPL ) software to reduce development costs and dramatically increase its power. A second layer of customized policies should be created to deal with major use areas. For Infrastructure and Development, these policies should focus on enabling easier use of GRAS products such as Apache, Linux, and GCC that are already in wide use, but which often suffer from an ambiguous approval status. For Security, use of GPL within groups with well-defined security boundaries should be encouraged to promote faster, more locally autonomous responses to cyber threats. Finally, for Research the policies should encourage appropriate use of FOSS both to share and publish basic research, and to encourage faster commercial innovation.
3. Encourage use of FOSS to promote product diversity. FOSS applications tend to be much lower in cost than their proprietary equivalents, yet they often provide high levels of functionality with good user acceptance. This makes them good candidates to provide product diversity in both the acquisition and architecture of DoD systems. Acquisition diversity reduces the cost and security risks of being fully dependent on a single software product, while architectural diversity lowers the risk of catastrophic cyber attacks based on automated exploitation of specific features or flaws of very widely deployed products.

Here would commence Appendix A through F which covers the specific FOSS software used by US DoD, where used, contacts, and each complete license. Not providing these Appendices reduces the file size by approx 400kB. Those interested can go to the source www.disa.mil/pao/dodfoss.html.

o0o