A Decision Framework for Selecting Licensing Rights for Noncommercial Computer Software in the DoD Environment

Charlene Gross

July 2011

TECHNICAL REPORT / CMU/SEI-2011-TR-014, ESC-TR-2011-014

Acquisition Support Program (ASP)

http://www.sei.cmu.edu

Acknowledgements

The author wishes to extend special recognition to all of the Army participants who attended workshop sessions on Acquiring Rights to Computer Software and Technical Data. Their willingness to engage in frank discussions about real world experiences with noncommercial software licensing issues provided a strong foundation for this report. The author would also like to acknowledge Jon Gross, Stephen Blanchette, and Cecilia Albert for their thoughtful and incisive comments.

Abstract

A major acquisition challenge for a program where computer software is a critical element of the system is the upfront determination of an appropriate licensing rights strategy. This report describes standard noncommercial software licensing alternatives as defined by U.S. government and Department of Defense (DoD) regulations. It also suggests an approach for objectively identifying agency needs for license rights and the appropriate license type for systems with noncommercial computer software or as standalone software in the DoD environment. There are three standard license types for noncommercial computer software: Unlimited, Government Purpose, and Restricted. Each of these license types for noncommercial computer software conveys different rights to the agency. This report presents distinguishing characteristics of the three standard license types, a method to develop the supporting rationale or traceability for DoD agency needs, a high-level description of circumstances that fall outside of standard license types, and a discussion of the importance of deliverables as necessary components for implementing license rights.

1 Introduction

A major acquisition challenge for a program where computer software is a critical element of the system is the upfront determination of an appropriate licensing rights strategy. Making a decision on licensing strategy is a U.S. Department of Defense (DoD) acquisition activity that requires a forward-looking approach. It also requires an understanding of intellectual property ownership, knowledge of the computer software license types and the rights each of them grants, and expected DoD agency needs for systems with noncommercial computer software or as a standalone application throughout the entire product life cycle. This report provides information about standard licensing alternatives that are available for noncommercial computer software rights as defined by U.S. Government and DoD regulations. It also suggests an approach for objectively identifying agency needs for license rights and the appropriate license type for systems with noncommercial computer software or as standalone software applications in the DoD environment.

There are two general categories for software referenced in Defense Federal Regulation Acquisition Supplement (DFARS)-commercial and noncommercial. "Commercial computer software" means software developed or regularly used for non-governmental purposes which (1) has been sold, leased, or licensed to the public; (2) has been offered for sale, lease, or license to the public; or (3) 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 [DFARS 252.227.7014 (a) (1) 2011]. Commercial software could be open source, freeware, or proprietary off-the-shelf software. "Noncommercial computer software" means software that does not qualify as commercial computer software under paragraph (a) (1) of this clause defined above [DFARS 252.227-7014 (a) (14) 2011]. In other words, noncommercial computer software has not been licensed or offered for license to the public.

While commercial software provides the government with the same licenses as those customarily provided to the public, noncommercial computer software does not have a public license by definition. There are three standard license types for noncommercial computer software-Unlimited, Government Purpose, and Restricted. Each of these license types conveys different rights to the agency that is acquiring the noncommercial computer software. For those instances where the government and the acquirer cannot agree on licensing terms as conveyed by a standard license, a license with Specifically Negotiated Rights can be negotiated. This type of agreement is not one of the three standard types because it varies based on negotiations. The DFARS notes that this is unusual [DFARS 227.7203-5 2011].

In addition to providing licensing information for noncommercial computer software, the objectives of this report are to

1. present four initial questions and develop a matrix to display the distinguishing characteristics of the three standard license types

2. demonstrate a method to develop the supporting rationale or traceability for DoD agency needs and elaborate by focusing on needs related to Scope of Use

3. provide a high level description of circumstances that fall outside of standard license types

4. describe the importance of deliverables such as source code, test environments, or other tools that may be necessary to use the license rights that have been granted

This report does not provide a comprehensive treatment of all legal and contractual information related to license rights for noncommercial computer software and should not be construed as an authoritative legal reference. Rather, it provides considerations for program managers (PMs) and other technical staff who must ensure development and maintenance of noncommercial computer software for systems or as standalone applications. The Army Strategic Software Improvement Program (ASSIP) funded development of this report, which supports definition and communication of the software engineering and management events and deliverables necessary to be included in the request for proposal (RFP) for software-reliant systems. [1]

For more detailed information about DoD regulations and contract clauses concerning rights to computer software, refer to the DFARS Part 227—Patents, Data, and Copyrights, Subpart 227.72—Rights to Noncommercial Computer Software and Computer Software Documentation; and DFARS Part 252—Solicitation Provisions and Contract Clauses, Section 252.227. Contracting officers and legal resources can provide invaluable and more detailed information on interpretation and negotiations.

2 Core Principles of Noncommercial Computer Software Ownership and Licensing

DoD does not "own" the technical data and computer software included in deliverables, even if the Department paid for 100 percent of the development costs [OUSD AT&L 2001].

2.1 Why You Need a License for Noncommercial Computer Software

Current U.S. law considers computer software to be intellectual property (IP)-property (as an idea, invention, or process) that derives from the work of the mind or intellect-and subject to copyright protection. Under U.S. law, the author of a work is automatically the owner of the copyright in the work. If an employee creates a work as part of his civilian employment, the civilian employer is the "author" for copyright purposes [Friedman 1997].

This "work for hire" concept has led many government managers to assume that noncommercial computer software that the government funds and contractors produce under contract is government property. However, the government does not own the noncommercial computer software even if it paid for 100 percent of the development cost [OUSD AT&L 2001]. DoD has established specific regulations concerning noncommercial computer software that provide "rights to use" while preserving the original developer's ownership of the intellectual property. The purpose of these regulations is to support wider markets and profits for developers, thus minimizing DoD's portion of development costs.

Instead of receiving ownership, the government obtains a license that conveys a scope of rights. In the case of commercial software, those rights are the same as those generally available to the public. However, DFARS defines multiple license types for noncommercial computer software for systems or as standalone applications that DoD acquires; and each license type conveys varying levels of rights to the government. This report focuses on the licensing rights for noncommercial computer software because of the complexities that must be considered to determine the best licensing decision and the longer impact on cost, sustainment, and capabilities.

DoD policy for noncommercial computer software is "to acquire only the computer software and computer software documentation and the rights in such software or documentation, necessary to satisfy DoD agency needs" [DFARS 227.7203-1 2011]. Selection of the appropriate licensing strategy requires sifting through a very large haystack of needs and requirements. The needle you are looking for in that haystack is the appropriate noncommercial computer software licensing strategy to meet the changing DoD agency needs and expectations that could occur throughout the product life cycle.

2.2 When and Why You Need a Noncommercial Computer Software License Strategy

Operationally, understanding DoD agency needs and the impact of available license types requires a careful plan or method (i.e., a strategy). The DoD agency must complete this daunting exercise of determining agency needs across the whole product life cycle prior to release of the solicitation. For the DoD community, the licensing strategy for noncommercial computer software is part of the Data Management Strategy (DMS). The DMS is included in the Acquisition Strategy, which must be completed prior to the solicitation. "DFARS requires major programs to develop a long-term strategy integrating data requirements across all functional disciplines, to include logistics. While the title is Data Management Strategy, the content should include the approach to managing intellectual property issues relating to any computer software as well" [DAU 2009].

Based on this strategy, the responding contractor will provide a list of all noncommercial computer software products that have restrictions as part of the proposal and prior to award of a contract. Regarding proprietary assertions, "there is no DFARS provision for contractors, after contract award, to withhold data deliverables required by contract by asserting they are proprietary. The only mechanism is to list such items on the assertions list and then properly mark in accordance with the DFARS when submitted" [DAU 2009].

2.3 Noncommercial Computer Software Licenses and Associated Rights You Can Obtain

Each of the three standard types of noncommercial software licenses—unlimited, government purpose, or restricted—grants a scope of rights to the government. The following quoted information from DFARS describes the license rights that are granted to the government under each standard noncommercial license type.

"DFARS 252.227-7014—Rights in Noncommercial Computer Software and Noncommercial Computer Software Documentation.

(b) Rights in computer software or computer software documentation. The Contractor grants or shall obtain for the Government the following royalty free, world-wide, nonexclusive, irrevocable license rights in noncommercial computer software or computer software documentation. All rights not granted to the Government are retained by the Contractor.

(1) Unlimited rights. The Government shall have unlimited rights in-

(i) Computer software developed exclusively with Government funds;

(ii) Computer software documentation required to be delivered under this contract;

(iii) Corrections or changes to computer software or computer software documentation furnished to the Contractor by the Government;

(iv) Computer software or computer software documentation that is otherwise publicly available or has been released or disclosed by the Contractor or subcontractor without restriction on further use, release or disclosure, other than a release or disclosure resulting from the sale, transfer, or other assignment of interest in the software to another party or the sale or transfer of some or all of a business entity or its assets to another party;

(v) Computer software or computer software documentation obtained with unlimited rights under another Government contract or as a result of negotiations; or

(vi) Computer software or computer software documentation furnished to the Government, under this or any other Government contract or subcontract thereunder with-

(A) Restricted rights in computer software, limited rights in technical data, or government purpose license rights and the restrictive conditions have expired; or

(B) Government purpose rights and the Contractor's exclusive right to use such software or documentation for commercial purposes have expired.

(2) Government purpose rights.

(i) Except as provided in paragraph (b) (1) of this clause, the Government shall have government purpose rights in computer software developed with mixed funding.

(ii) Government purpose rights shall remain in effect for a period of five years unless a different period has been negotiated. Upon expiration of the five-year or other negotiated period, the Government shall have unlimited rights in the computer software or computer software documentation. The government purpose rights period shall commence upon execution of the contract, subcontract, letter contract (or similar contractual instrument), contract modification, or option exercise that required development of the computer software.

(iii) The Government shall not release or disclose computer software in which it has government purpose rights to any other person unless-

(A) Prior to release or disclosure, the intended recipient is subject to the use and non-disclosure agreement at DFARS 227.7103-7; or

(B) The recipient is a Government contractor receiving access to the software or documentation for performance of a Government contract that contains the clause at DFARS 252.227-7025, Limitations on the Use or Disclosure of Government Furnished Information Marked with Restrictive Legends.

(3) Restricted rights.

(i) The Government shall have restricted rights in noncommercial computer software required to be delivered or otherwise provided to the Government under this contract that were developed exclusively at private expense.

(ii) The Contractor, its subcontractors, or suppliers are not required to provide the Government additional rights in noncommercial computer software delivered or otherwise provided to the Government with restricted rights. However, if the Government desires to obtain additional rights in such software, the Contractor agrees to promptly enter into negotiations with the Contracting Officer to determine whether there are acceptable terms for transferring such rights. All noncommercial computer software in which the Contractor has granted the Government additional rights shall be listed or described in a license agreement made part of the contract (see paragraph (b)(4) of this clause). The license shall enumerate the additional rights granted the Government.

(iii) The Contractor acknowledges that-

(A) Restricted rights computer software is authorized to be released or disclosed to covered Government support contractors;

(B) The Contractor will be notified of such release or disclosure;

(C) The Contractor (or the party asserting restrictions, as identified in the restricted rights legend) may require each such covered Government support contractor to enter into a non-disclosure agreement directly with the Contractor (or the party asserting restrictions) regarding the covered Government support contractor's use of such software, or alternatively, that the Contractor (or party asserting restrictions) may waive in writing the requirement for a non-disclosure agreement;

(D) Any such non-disclosure agreement shall address the restrictions on the covered Government support contractor's use of the restricted rights software as set forth in the clause at 252.227-7025, Limitations on the Use or Disclosure of Government-Furnished Information Marked with Restrictive Legends, and shall not include any additional terms and conditions unless mutually agreed to by the parties to the non-disclosure agreement; and

(E) The Contractor shall provide a copy of any such non-disclosure agreement or waiver to the Contracting Officer, upon request."

In addition to the standard licenses, DFARS 252.227-7014 Rights in Noncommercial Computer Software and Noncommercial Computer Software Documentation describes two additional licensing and rights constructs:

(4) Specifically negotiated license rights.

(i) The standard license rights granted to the Government under paragraphs (b)(1) through (b)(3) of this clause, including the period during which the Government shall have government purpose rights in computer software, may be modified by mutual agreement to provide such rights as the parties consider appropriate but shall not provide the Government lesser rights in computer software than are enumerated in paragraph (a)(14) of this clause or lesser rights in computer software documentation than are enumerated in paragraph (a)(13) of the Rights in Technical Data--Noncommercial Items clause of this contract.

(ii) Any rights so negotiated shall be identified in a license agreement made part of this contract.

(5) Prior government rights. Computer software or computer software documentation that will be delivered, furnished, or otherwise provided to the Government under this contract, in which the Government has previously obtained rights shall be delivered, furnished, or provided with the pre-existing rights, unless-

(i) The parties have agreed otherwise; or

(ii) Any restrictions on the Government's rights to use, modify, reproduce, release, perform, display, or disclose the data have expired or no longer apply."

2.4 What You Need in Addition to a Noncommercial Computer Software License and the Associated Rights

The primary subject of this report concerns licensing rights for noncommercial computer software for systems or as standalone applications. However, the selection of license rights and inclusion of the appropriate contract clauses in the RFP and contract are not sufficient to execute the license rights. It is critical to obtain deliverables that are also necessary for implementing license rights. DoD policy states that "solicitations and contracts shall . . . establish separate contract line items, to the extent practicable, for the computer software or computer software documentation to be delivered under a contract and require offerors and contractors to price separately each deliverable data item" [DFARS 272.7203-3(b) 2011].

The DFARS definition of computer software provides clues of types of deliverables that could be required. "'Computer software' [is] computer programs, source code, source code listings, object code listings, design details, algorithms, processes, flow charts, formulae and related material that would enable the software to be reproduced, recreated, or recompiled. Computer software does not include computer data bases or computer software documentation" [DFARS 252.227.7014(a) (4) 2011]. "The standard license in computer software documentation conveys unlimited rights" [DFARS 227.7203-5 2011]. Despite the numerous items included in the definition of computer software, this documentation is not delivered unless specified in the contract. Items that a manager believes are necessary to develop, reproduce, and maintain the software across the product life cycle must be explicitly called out in the Contract Data Requirements List (CDRL). Examples of important CDRLs for software acquisitions include (but are not limited to) [GSAM Version 3.0 2000]:

- software and interface requirements specifications

- software and interface design descriptions

- database descriptions

- software product specifications

- source code listings

- test plans/descriptions/reports

- software development plans

- software programming manuals

- software users manuals

- software maintenance manuals

- software architecture description

2.5 Resources to Help You Understand Rights to Noncommercial Computer Software

This report cannot cover all of the guidance available on licensing of noncommercial computer software or all of the events that might impact a licensing strategy. Discussions should include not only the technical personnel who understand the software aspects of the project, but also a contracting officer and legal staff. These functional elements are crucial to ensuring that the software licensing strategy meets contractual, legal, and technical needs of the government for noncommercial computer software.

Codified material includes the Federal Acquisition Regulation (FAR), which provides acquisition regulations related to noncommercial computer software across all government agencies; and the DFARS that supplements the FAR for DoD acquisitions. The DFARS contains DoD-wide policies, delegations of FAR authorities, deviations from FAR requirements, and policies and procedures. The DFARS also covers the DoD-unique process for acquiring intellectual property license rights governing technical data or computer software that is developed or delivered under a contract. The Defense Acquisition Guidebook provides the acquisition workforce with discretionary best practices based on multiple sources, including in the DoD Directive 5000.01 and DoD Instruction 5000.02, US Code, Public Law provisions, FAR, and DFARS.

3 Organizing Choices for Selecting a Noncommercial Computer Software Licensing Strategy

DoD policy is to acquire only the computer software and computer software documentation, and the rights in such software or documentation, necessary to satisfy agency needs [DFARS 227.7203-1 2011].

Meeting DoD agency needs for licensing rights to noncommercial computer software for systems or as standalone applications requires an understanding of what is different about each license or set of rights, an understanding of the full system life cycle, and the ability to evaluate and prioritize licensing impacts based on possible future scenarios. Before attempting to make a decision on a particular licensing strategy for noncommercial computer software, an acquiring organization needs to understand the licensing terms and rights conveyed to the government and retained by the contractors. The extent of rights that each license type conveys ranges from relatively few restrictions to multiple restrictions.

At the most basic level, four distinguishing characteristics-Scope of Use, Access or Transfer, Commercial Prospects, and Funding Source-are prominent in differentiating license rights for noncommercial computer software. For those technical managers who need to have a starting point in the software licensing decision process, it is important to understand these characteristics and how these characteristics are treated.

3.1 Scope of Use

Who needs to use or modify the product at various times of the life cycle and to what extent?

This report uses Scope of Use to refer to the extent to which the software license grants the government and/or its agent the rights to modify, reproduce, release, perform, display, or disclose noncommercial computer software.

The three examples below suggest how DoD agencies' needs related to Scope of Use can lead to the selection of a specific software license type.

1. The DoD agency may need the flexibility to authorize multiple contractors, including those who are competitors of the original developer, to modify the software up to and including developing derivative works across the life cycle. This Scope of Use example supports the selection of Unlimited Rights. See Table 1 for review of Unlimited Rights/License related to Scope of Use.

2. The DoD agency may need to plan for future involvement of competing contractors but can support near-term limits on that involvement in exchange for possible cost reductions. This Scope of Use example supports the selection of Government Purpose Rights. See Table 1for review of Government Purpose Rights/License related to Scope of Use. Note: Government Purpose Rights are negotiated for a mutually agreed-upon length (nominally five years). After the GPR period expires, the government receives Unlimited Rights.

3. The DoD agency may need the continuity of relying on the contractor who has developed a very specific software product except for activities to service contracts and emergency repairs/overhaul. This Scope of Use example supports the selection of Restricted Rights. See Table 1 for review of Restricted Rights/License related to Scope of Use.

Table 1 displays the three standard noncommercial computer software license types and the different ways that rights related to Scope of Use are treated under each license.

Table 1: Treatment of Scope of Use by Licensing Types

STANDARD NONCOMMERCIAL COMPUTER SOFTWARE LICENSE TYPES

Unlimited Rights

Government Purpose Rights

Restricted Rights

DISTINGUISHING CHARACTERISTIC OPTIONS BY LICENSE TYPE

Scope of Use

Any use for any purpose by anyone the Government authorizes

Inside Government—disclosure required if other than contractor or subs of the government contract

Outside Government for government purposes only—only with express written permission of contractor/developer

Reverts to unlimited rights after GPR expires

Permission to diagnose, modify or merge software; respond to tactical situations and perform emergency repairs. Notification to rights owner and no reverse engineering

3.2 Access or Transfer

What restrictions on access by terminals and central processing units or on transfer to other government agencies are acceptable?

Access or Transfer refers to availability for use within the DoD agency and conditions of transfers to other agencies. Restrictions on internal access (e.g., CPU installation) and on transfer to other agencies (with or without destruction of existing copies) play an important role in the long-term usefulness of the product. The need to physically access the software product and acceptable rules governing transfer to other agencies require careful consideration.

The three examples below suggest how DoD agency needs related to Access or Transfer can lead to the selection of a specific software license type.

1. The DoD agency may need broad access to the noncommercial computer software via multiple terminals and CPUs and/or plans for concurrent usage across multiple governmental and nongovernmental organizations. This Access or Transfer example supports the selection of Unlimited Rights. See Table 2 for review of Unlimited Rights/License related to Access or Transfer.

2. The DoD agency may need broad access via multiple terminals and CPUs but can limit transfers of the software only within the government for a negotiated period of time and still meet objectives. This Access or Transfer example supports the selection of Government Purpose Rights. See Table 2 for review of Government Purpose Rights/License related to Access or Transfer. These restrictions last for the negotiated Government Purpose Rights period. Note: Government Purpose Rights are negotiated for a mutually agreed-upon length (nominally five years). After the GPR period expires, the government receives Unlimited Rights.

3. The DoD agency may need access to no more than one terminal or CPU at a time, to one government agency at a time, and to contractors only performing service contracts in support of this or a related contract. This Access or Transfer example supports the selection of Restricted Rights. See Table 2 for review of Restricted Rights/License related to Access or Transfer.

Table 2 displays the three standard noncommercial computer software license types and the different ways that rights related to Scope of Use and Access or Transfer are treated under each license.

Table 2: Treatment of Scope of Use and Access or Transfer by Licensing Types

STANDARD NONCOMMERCIAL COMPUTER SOFTWARE LICENSE CHOICES

Unlimited Rights

Government Purpose Rights

Restricted Rights

DISTINGUISHING CHARACTERISTIC OPTIONS BY LICENSE TYPE

Scope of Use

Any use for any purpose by anyone the Government authorizes

Inside Government—disclosure required if other than contractor or subs of the government contract

Outside Government for government purposes only—only with express written permission of contractor/developer

Reverts to unlimited rights after GPR expires

Permission to diagnose, modify or merge software; respond to tactical situations and perform emergency repairs. Notification to rights owner and no reverse engineering

Access or Transfer

Inside and Outside Government—No Limit

Inside Government—transfer to other agencies without restriction on access; contractors and subs working on government contract can access; reverts to unlimited rights after GPR expires

One agency at a time

Destroy copies when transferred to another agency

3.3 Commercial Prospects

Are there any plans that the software or system with software will be developed or used for commercial purposes?

Commercial Prospects refers to plans by either the government or the developer to bring the product to the commercial marketplace. The government may wish to commercialize or authorize others to commercialize a noncommercial computer software product. The government may also recognize that it is in its interest to allow the developer time to commercialize the product. "Generally, software is commercialized through owner licensing either directly to end-users or to an entity that will further develop and distribute it themselves. In some cases, commercialization may mean collaborating with an industry partner to improve the software and make it suitable for distribution" [McMaster University 2008].

The three examples below suggest how DoD agency needs related to Commercial Prospects can lead to the selection of a specific software license type.

1. The DoD agency may need to take direct advantage of commercializing the noncommercial computer software as soon as feasible. This Commercial Prospects example supports the selection of Unlimited Rights. See Table 3 for review of Unlimited Rights/License related to Commercial Prospects.

2. The DoD agency may need to encourage possible commercial benefits to support industry competition and stimulate bidding on a government contract for a negotiated time period. This Commercial Prospects example supports the selection of Government Purpose Rights. See Table 3 for review of Government Purpose Rights/License related to Commercial Prospects. Note: Government Purpose Rights are negotiated for a mutually agreed-upon length (nominally five years). After the GPR period expires, the government receives Unlimited Rights.

3. The DoD agency may need to agree that only the developer will commercialize the product with no restriction on time period. This Commercial Prospects example supports the selection of Restricted Rights. See Table 3 for review of Restricted Rights/License related to Commercial Prospects.

Table 3 displays the three standard noncommercial computer software license types and the different ways that rights related to Scope of Use, Access or Transfer, and Commercial Prospects are treated under each license.

Table 3: Treatment of Scope of Use, Access or Transfer, and Commercial Prospects by Licensing Types

STANDARD NONCOMMERCIAL COMPUTER SOFTWARE LICENSE CHOICES

Unlimited Rights

Government Purpose Rights

Restricted Rights

Distinguishing Characteristics

DISTINGUISHING CHARACTERISTIC OPTIONS BY LICENSE TYPE

Scope of Use

Any use for any purpose by anyone the Government authorizes

Inside Government—disclosure required if other than contractor or subs of the government contract

Outside Government—only with express written permission of contractor/developer

Reverts to unlimited rights after GPR expires

Permission to diagnose, modify or merge software; respond to tactical situations and perform emergency repairs. Notification to rights owner and no reverse engineering

Access or Transfer

Inside and Outside Government—No Limit

Inside Government—transfer to other agencies without restriction on access; contractors and subs working on government contract can access; reverts to unlimited rights after GPR expires

One agency at a time

Destroy copies when transferred to another agency

Commercial Prospects

Government commercialize or authorize others to commercialize

Contractor/developer commercializes during GPR; reverts to unlimited rights after GPR expires

Solely contractor/developer

3.4 Funding Source

Who is going to fund or has funded the noncommercial computer software development and to what extent?

Funding Source refers to the source of funds used to develop the noncommercial computer software either as a standalone item or as part of a system. The three levels of funding associated with the standard noncommercial computer software license types are government funding only (associated with Unlimited Rights), government funding mixed with contractor private expense (associated with Government Purpose Rights), and private expense only (associated with Restricted Rights). Specifically Negotiated Agreements allow modification by mutual agreement of available rights when the terms of other licensing rights are not satisfactory. However, the government cannot accept lesser rights than those granted by Restricted Rights [DFARS 252.227-7014 (b) (4) (i) 2011].

To ensure that the funding determination is balanced and that both the government and contractor receive credit for funding contributions, "the determination of the source of funds used to develop computer software should be made at the lowest practicable segregable portion of the software or documentation (e.g., a software sub-routine that performs a specific function)" [DFARS 227.7203-4 License Rights—(b) Source of funds determination 2011].

The three examples below suggest how DoD agency needs related to Funding Source can lead to the selection of a specific software license type.

1. The DoD agency may need to provide all of the funds for the noncommercial computer software development. This Source of Funds example supports the selection of Unlimited Rights. See Table 4 for review of Unlimited Rights/License related to Funding Source.

2. The DoD agency may need to provide some funding, along with the supplier, who is also providing funding for the noncommercial computer software development. This Source of Funds example supports the selection of Government Purpose Rights. See Table 4 for review of Government Purpose Rights/License related to Funding Source. Note: Government Purpose Rights are negotiated for a mutually agreed-upon length (nominally five years). After the GPR period expires, the government receives Unlimited Rights.

3. The DoD agency may need to plan on the supplier providing all funding for the noncommercial computer software development. This Source of Funds example supports the selection of Restricted Rights. See Table 4 for review of Restricted Rights/License related to Funding Source.

Table 4 displays the three standard noncommercial computer software license types and the different ways that rights related to Scope of Use, Access or Transfer, Commercial Prospects, and Funding Source are treated under each license.

Table 4: Treatment of Scope of Use, Access or Transfer, Commercial Prospects, and Funding Source by Licensing Types

STANDARD NONCOMMERCIAL COMPUTER SOFTWARE LICENSE CHOICES

Unlimited Rights

Government Purpose Rights

Restricted Rights

DISTINGUISHING CHARACTERISTIC OPTIONS BY LICENSE TYPE

Scope of Use

Any use for any purpose by anyone the Government authorizes

Inside Government—disclosure required if other than contractor or subs of the government contract

Outside Government—only with express written permission of contractor/developer

Reverts to unlimited rights after GPR expires

Permission to diagnose, modify or merge software; respond to tactical situations and perform emergency repairs. Notification to rights owner and no reverse engineering

Access or Transfer

Inside and Outside Government—No Limit

Inside Government—transfer to other agencies without restriction on access; contractors and subs working on government contract can access; reverts to unlimited rights after GPR expires

One agency at a time

Destroy copies when transferred to another agency

Commercial Prospects

Government commercialize or authorize others to commercialize

Contractor/developer commercializes during GPR; reverts to unlimited rights after GPR expires

Solely contractor/developer

Funding Source

Solely Government funding

Mixed funding

Private expense

3.5 Putting the Distinguishing Characteristics Together

As illustrated in the previous sections, DoD agency needs support the eventual rationale for selecting a licensing strategy for noncommercial computer software. Table 5 shows the complete table with all distinguishing characteristics present.

Table 5: Treatment of Scope of Use, Access or Transfer, Commercial Prospects, and Funding Source by Licensing Types

STANDARD NONCOMMERCIAL COMPUTER SOFTWARE LICENSE CHOICES

Unlimited Rights

Government Purpose Rights

Restricted Rights

Distinguishing Characteristics

DISTINGUISHING CHARACTERISTIC OPTIONS BY LICENSE TYPE

Scope of Use

Any use for any purpose by anyone the Government authorizes

Inside Government—disclosure required if other than contractor or subs of the government contract

Outside Government—only with express written permission of contractor/developer

Reverts to unlimited rights after GPR expires.

Permission to diagnose, modify or merge software; respond to tactical situations and perform emergency repairs. Notification to rights owner and no reverse engineering

Access or Transfer

Inside and Outside Government—No Limit

Inside Government—transfer to other agencies without restriction on access; contractors and subs working on government contract can access; reverts to unlimited rights after GPR expires.

One agency at a time

Destroy copies when transferred to another agency

Commercial Prospects

Government commercialize or authorize others to commercialize

Contractor/developer commercializes during GPR; reverts to unlimited rights after GPR expires.

Solely contractor/developer

Funding Source

Solely Government funding

Mixed funding

Private expense

It is possible that the government has a clear understanding of its needs related to a specific distinguishing characteristic such as Scope of Use. However, it is also possible that the government will need to conduct a more detailed review of product life cycle considerations to understand the underlying needs that point the government in a certain direction.

For example, what future events might occur that would require the government to need maximum flexibility in types of work they can authorize a competing contractor to do? Can a shortened life cycle overcome concerns on dependence on the original developer and restricted rights? What changes in technology could make commercialization by the developer a viable venture? The next section suggests a structured approach to identify the underlying drivers for DoD agency needs that point the government in a certain licensing direction.

4 Decision Drivers to Identify Agency Noncommercial Computer Software Licensing Needs—Scope of Use Focus

Data managers or other requirements personnel are responsible for identifying the government's minimum needs [DFARS 227.7203-2(b) (1) 2011].

Contracting officers shall work closely with data managers and requirements personnel to assure that computer software and computer software documentation requirements included in solicitations are consistent with the policy expressed in 227.7203-1 [DFARS 227.7203-2(b) (1) 2011].

DoD policy clearly states that its policy is "to acquire only the computer software and computer software documentation, and the rights in such software or documentation, necessary to satisfy agency needs" [DFARS 227.7203-1 2011]. This section suggests a systematic and objective approach to identifying the government's minimum needs for noncommercial computer software licensing rights. The approach is demonstrated in this section using the Scope of Use characteristic as a focus. The approach as described for Scope of Use can be equally applied to Access or Transfer, Commercial Prospects, and Funding Source.

Using this approach, data managers and other requirements personnel can document the progression from DoD agency programmatic and performance expectations to license strategy selection. The approach also allows for forward and backward traceability from agency expectations to ultimate selection, as well as facilitating revisions in the case of change. The approach can be used as-is, modified to suit different program types or circumstances, or completely redefined.

4.1 Taxonomy to Support Noncommercial Computer Software Licensing Strategy Discussions

A systematic and objective approach to identifying DoD agency expectations for systems with software can benefit from a common set of terms and discussion topics related to acquisition of noncommercial computer software. A review of the literature did not reveal an existing tool to meet these requirements. However, the Taxonomy of Software Development Risks provides a foundation tool with a software orientation that can be used to develop the common set of terms and discussion topics needed for the licensing discussion [Dorofee et al 1996] [2]. Appendix B shows this original taxonomy.

Minor modification of the Taxonomy of Software Development Risks added key software acquisition topics to generate discussion of DoD agency expectations. This modification resulted in the Modified Taxonomy for Software Acquisition Life Cycle Discussion in Table 6. It retains the original classes, elements, and attributes of the Taxonomy of Software Development Risks, and adds a new class entitled Software Criticality. This class consists of Scale, Reliance, and Complexity elements. Other additions are 3 elements and 16 attributes for Program Constraints that account for acquisition-specific topics, 2 attributes for Development Environment, and 8 attributes for Product Engineering. Additions to the original taxonomy are displayed in UPPERCASE.

Table 6: Modified Taxonomy for Software Acquisition Life Cycle Discussion

A. Product

Engineering

B. Development Environment

C. Program Constraints

D. Software

Criticality

1. Requirements

a. Stability

b. Completeness

c. Clarity

d. Validity

e. Feasibility

f. Precedent

g. Scale

h. VERIFIABILITY

i. INTEROPERABILITY

j. TECHNICAL MATURITY

1. Development Process

a. COMPLIANCE

b. OWNERSHIP

c. Suitability

d. Process control

e. Familiarity

f. Product control

g. Measurement

1. Resources

a. Schedule

b. Staff

c. Budget

d. Facilities

1. SCALE

a. SOFTWARE AS PROPORTION OF SYSTEM

b. IMPACT ON MAJOR SOFTWARE COMPONENT

2. Design

a. Functionality

b. Difficulty

c. Interfaces

d. Performance

e. Testability

f. Hardware constraints

g. Non-developmental software

2. Development System

a. Capacity

b. Suitability

c. Usability

d. Familiarity

e. Reliability

f. System support

g. Deliverability

2. Contract

a. Type of contract

b. Restrictions

c. Dependencies

d. ACQUISITION STRATEGY

e. SOLICITATION

f. SOFTWARE LICENSING

2. RELIANCE

a. MISSION

b. SYSTEM

3. Code and Unit Test

a. Feasibility

b. Testing

c. Coding/ implementation

3. Management Process

a. Planning

b. Project Organization

c. Management Experience

d. Program Interfaces

3. Program Interfaces

a. Customer

b. Associate Contractors

c. Subcontractors

d. Prime contractor

e. Corporate Management

f. Vendor

g. Politics

3. COMPLEXITY

a. SPECIFIC SYSTEM

b. COMMUNITY OF INTERACTING SYSTEMS

4. Integration and Test

a. Environment

b. Product

c. System

d. CERTIFICATIONS

e. SYSTEM OF SYSTEMS

4. Management Methods

a. Monitoring

b. Personnel Management

c. Quality Assurance

d. Configuration Management

4. PROGRAM OFFICE CAPABILITY

a. SOFTWARE EXPERTISE

b. PROGRAM AND PROJECT MANAGEMENT EXPERTISE

c. UNDERSTANDING OF ACQUISITION RESPONSIBILITIES

d. MONITORING PROCESSES

5. Engineering Specialties

a. Maintainability

b. Reliability

c. Safety

d. Security

e. Human Factors

f. Specifications

g. SUSTAINMENT

h. AVAILABILITY

i. DEPLOYMENT

5. Work Environment

a. Quality attitude

b. Cooperation

c. Communication

d. Morale

5. CHAIN OF COMMAND

a. CONSISTENCY

b. LEVEL OF COMMUNICATIONS

c. FEASIBILITY OF EXPECTATIONS

d. ALLOCATION OF RESPONSIBILITY

6. POLICY AND MANDATES

a. EXTERNAL CONSTRAINTS

b. POLITICAL CONSTRAINTS

c. THREAT MITIGATION

d. TECHNOLOGIES

e. MULTIPLE GUIDELINES AND PRACTICES

4.2 From Expectations to a Needs-Based Noncommercial Computer Software Licensing Strategy

The suggested process begins not by picking a licensing strategy and then justifying it. Rather, it begins by determining DoD agency expectations for noncommercial systems with software or as standalone applications. These expectations could be operational, programmatic, budgetary, or technical. The Modified Taxonomy for Software Acquisition Life Cycle Discussion can serve as a prompt for determining all of the areas where DoD agency expectations might be present. These expectations could relate to what the DoD agency expects to gain, how the DoD agency expects to support the mission, expected events across the life cycle, etc.

Using Scope of Use as the focus, this section will use the following steps to illustrate the progression from DoD agency expectations to DoD agency needs for noncommercial computer software license rights:

1. Identify DoD agency expectations that cover the whole life cycle for the systems with software.

2. Construct one or more high-level statements that describe the DoD agency's plan to meet each expectation.

3. Identify and prioritize the necessary software-related capabilities that the DoD agency must have to be successful with its plan. These capabilities will become decision drivers.

4. Select all software license types that support each decision driver (capability) and determine the best overall option by reviewing the priorities of the decision drivers and the license types that most often satisfy the decision drivers.

The intent of the following notional examples is to show various expectations that could inform the needs of an agency. The examples do not represent any particular program nor are they examples from existing programs. Rather, they are individual topics suggested in the Modified Taxonomy of Software Acquisition Life Cycle Discussion and were selected to generate discussion about expectations, plans, and capabilities. The purpose is to show how to arrive at a meaningful decision driver to select the appropriate noncommercial computer software license. The weights assigned to decision drivers in these examples are notional and do not represent either a particular program or set of circumstances. Results for each example are notional. It is also important to note that expectations, plans, capabilities, and priorities may change as discussions evolve.

Notional Example 1: Software Criticality—Reliance

Expectation: The DoD agency expects fulltime availability of the system and software because the mission is highly reliant on the software.

Plan: The DoD agency will plan for 24x7 uptime in operations and availability during the life of the system, regardless of force location in the world.

Capability/Decision Drivers: To support the plan, the government must have these capabilities:

- access to all code, tools, test scripts, etc. to repair defects

- legal rights to perform any necessary work or authorize others to do it

- authority to engage competing contractors, if necessary, to perform work, including creating derivative works

- qualified talent available during life cycle that knows how to work with the software

Priority Assigned: High Priority

Notional Example 2: Program Constraints—Contract

Expectation: The contractor who is awarded the contract can do the work and is financially sound.

Plan: The government will ensure access to software product regardless of contractor status.

Capability/Decision Drivers: To support the plan, the government must have:

- ability to allow newly hired contractor to perform work on software if contractor fails in performance

- ability to re-compete without losing progress to date if original contractor goes out of business

- access to source code such as through escrow regardless of contractor status

Priority Assigned: Medium Priority

Notional Example 3: Product Engineering—Design

Expectation: Many of the software components will be candidates for future reuse.

Plan: The government must ensure the ability to reuse software components in any fashion required by the system.

Capability/Decision Drivers: To support the plan, the government must have:

- ability to modify software in any manner to support new functionality

- rights that will allow maximum flexibility in changes as software is reused

- capability to change across product life of decades

Priority Assigned: Medium Priority

Notional Example 4: Product Engineering—Integration and Test

Expectation: Integral to the system design will be integration with other systems.

Plan: The government must ensure that all conditions for software changes to support integration can be met in a timely manner.

Capability/Decision Drivers: To support the plan, the government must have:

- ability to obtain support to modify software at any point in the life cycle to ensure integration

- authority to change software as other systems are integrated within SOS

Priority Assigned: High Priority

Notional Example 5: Product Engineering—Engineering Specialties

Expectation: The government expects to sustain the software with internal resources.

Plan: The government will allocate sufficient resources to perform all aspects of sustainment of the system until disposal.

Capability/Decision Drivers: To support the plan, the government must have:

- ability to correct, adapt, and enhance software years after delivery

- internal tools and talent to perform required work

Priority Assigned: High Priority

Table 7 is a work aid to show how one might display the expectations, plan, capability/decision drivers, and the results by license type that can support the licensing selections. It is important to remember that Contracting Officers and Legal can provide the best advice on the appropriate selections.

When reviewing the results, note that placing an X in every cell in a row means that the decision driver can be satisfied by any license. Likewise, where no row in a given example contains an X, further review will be necessary to determine if the DoD agency expectation or plan is feasible.

Table 7: Display of Expectations, Plans, and Decision Drivers

NOTIONAL DISPLAY OF EXPECTATIONS, PLANS, AND DECISION DRIVERS

MAPPED TO NONCOMMERCIAL COMPUTER SOFTWARE LICENSE RIGHTS

STANDARD LICENSE TYPES

Unlimited

Rights

Government

Purpose Rights

Restricted

Rights

DOD AGENCY NEED FOR SCOPE OF USE

RIGHTS OBTAINED FOR

SCOPE OF USE

Any use for any purpose by anyone that the Government authorizes

Inside Government—disclosure required if other than contractor or subs of the government contract

Outside Government—only with written permission

Only permission to diagnose, modify or merge software; respond to tactical situations and perform emergency repairs

NOTIONAL EXAMPLE 1

High Priority

RELIANCE EXPECTATION: The DoD agency expects fulltime availability of the system and software because the mission is highly reliant on the software.

High Priority

RELIANCE PLAN: The DoD agency will plan for 24x7 uptime in operations and availability during the life of the system, regardless of force location in the world.

CAPABILITY/

DECISION DRIVERS

Criticality—access to all code, tools, test scripts, etc

X

X

Criticality—legal rights to perform any necessary work or authorize others to do it

X

(after GPR period)

Criticality—authorize competing contractor to modify work, including creating derivative works

X

(after GPR period)

Criticality—qualified talent available during the entire life cycle

X

X

X

NOTIONAL EXAMPLE 2

Medium

Priority

CONTRACT EXPECTATION: The contractor awarded the contract will be capable and financially sound.

Medium

Priority

CONTRACT PLAN: The government will ensure access to software product regardless of contractor status.

CAPABILITY/ DECISION DRIVERS

Contract—ability to allow newly hired contractor to perform work on software if contractor fails to perform

X

X

Contract—ability to re-compete without losing progress to date if original contractor goes out of business

X

(after GPR period)

NOTIONAL EXAMPLE 3

Medium Priority

DESIGN EXPECTATION: Many of the software components will be candidates for future reuse.

Medium Priority

DESIGN PLAN: The government must be able to reuse components in any fashion required by the system.

CAPABILITY/ DECISION DRIVERS

Design—ability to modify software in any manner to support new design

X

(after GPR period)

X

Design—rights that will allow maximum flexibility in changes as software is reused

X

(after GPR period)

Design—capability to change across product life of decades

X

(after GPR period)

X

NOTIONAL EXAMPLE 4

High Priority

INTEGRATION/TEST EXPECTATION: Integral to the system design will be integration with other systems.

High Priority

INTEGRATION/TEST PLAN: The government must ensure that all conditions for software changes to support integration can be made in a timely manner.

CAPABILITY/ DECISION DRIVERS

Integration/Test—ability to obtain support to modify software at any point in the life cycle to ensure integration

X

(after GPR period)

Integration/Test—authority to change software as other systems change within SOS

X

X

NOTIONAL EXAMPLE 5

High Priority

ENGINEERING SPECIALITIES EXPECTATION: The government expects to sustain the software with internal resources.

High Priority

ENGINEERING SPECIALITIES PLAN : The government will allocate sufficient resources to perform all aspects of sustainment of the system until disposal.

CAPABILITY/ DECISION DRIVERS

Operations—ability to correct, adapt, and enhance software years after delivery

X

X

Operations—tools and talent to perform required work over several years

X

X

X

If there is no agreement between the government and the developer on a standard license, or the government wants to obtain rights in noncommercial computer software in which it does not have rights, the parties can agree to a Specifically Negotiated License. Described in the DFARS as an unusual situation [DFARS 227.7203-5], the major limitations of this type of license are that the government cannot accept less than restricted rights, and the intellectual property owner is not required to give more than restricted rights.

5 Other Considerations

Other considerations that are addressed by the DFARS that can affect noncommercial licensing rights strategies generally relate to specific entities and/or circumstances that a technical manager may encounter in the course of running the project. This section provides a high-level description of these considerations and references to their coverage in DFARS. These considerations relate to and include:

- subcontractor rights in computer software

- disclosure or release to foreign governments, foreign contractors, or international organizations

- contracts under the Small Business Innovative Research Program

- contracts for special works

Subcontractor rights for software they developed. Subcontractors receive the same protection for their rights to computer software as the prime contractor receives. The government can deal directly with subcontractors in matters related to validation of asserted restrictions. In addition, prime contractors must include specified clauses such as Rights in Noncommercial Computer Software and Noncommercial Computer Software Documentation in subcontractor contracts without modification [DFARS 252.227.7014 2011]. Lastly, the prime contractor cannot require the subcontractor to relinquish rights greater than those obtained by the government in the prime's contract [DFARS 227.7203-15 2011].

Disclosure or release to foreign governments, foreign contractors, or international organizations . Disclosure or release to these entities is subject to Federal export controls and other national security laws or regulations. If these laws and regulations are met, DoD can release computer software if it holds unlimited rights. If a license includes restrictions, DoD must observe the requirements for use and non-disclosure agreements [DFARS 227.7203-16 2011].

Contracts under the Small Business Innovative Research (SBIR) Program. The contractor must mark the computer software with an SBIR data rights legend. The government receives rights for government purposes for a period beginning at award and ending five years after completion of the project. After the period expires, the government receives unlimited rights to SBIR data [DFARS 227.7104 2011].

Contracts for special works. Per Rights in Special Works [DFARS 252.227-7020 2011], the government may have a specific need to control noncommercial computer software distribution. One method of controlling distribution is to obtain assignment of the copyright. The specific software or documentation in which the government must own or control copyright must be identified in a special contract requirement. If the government needs control of all of the computer software, it will use DFARS 252.227-7020 exclusively. The contractor retains use and disclosure rights [DFARS 227.7205 2011].

6 Conclusion

The information in this report illustrates the tremendous responsibility that falls to data managers and other requirements personnel at the beginning of an acquisition-a time when there are major decisions in multiple areas. Evolving a licensing strategy for noncommercial computer software requires:

- awareness of the rules of software ownership

- an understanding of the program's current status and future possibilities

- the ability to distinguish among the types of noncommercial computer software licenses available in the DoD environment

- insight into the choices that each of those licenses represents

- the ability to formulate a rationale for DoD agency needs, based on in-depth knowledge and an understanding of acquisition and the life cycle

If the noncommercial computer software licensing strategy is flawed, consequences that will appear later in the product life cycle can be additional costs, schedule delays due to legal issues, and risks to continued operation. DoD managers, contracting officers, and legal staff who apply a structured approach can evolve a well-supported decision for licensing needs of noncommercial computer software development.

7 References

[DAU 2009]

Defense Acquisition University. Defense Acquisition Guidebook. Chapter 5—Life-Cycle Logistics, Section 5.1.6. 2009.

[DFARS 2011]

Department of Defense. Defense Federal Acquisition Regulation Supplement (DFARS) 227.72--Rights in Computer Software and Computer Software Documentation. Revised January 2011.

[DFARSa 2011]

Department of Defense. Defense Federal Acquisition Regulation Supplement (DFARS) Part 252—Solicitation Provisions and Contract Clauses, Subpart 227. Revised January 2011.

[Dorofee et al 1996]

Dorofee, A. J., Walker, J. A., Alberts, C. J., Higuera, R. P., Murphy, R. L., and Williams, R. C. Continuous Risk Management Guidebook. Software Engineering Institute, Carnegie Mellon University, 1996.

[FAR 2010]

U.S. Government Printing Office. Code of Federal Regulations (CFR), Title 48--Federal Acquisition Regulations System. Chapter 1--Federal Acquisition Regulation (FAR). Revised October 2010.

[Friedman 1997]

Friedman, Marc S. Esq and Taylor, Lindsey H. Basics of Intellectual Property Protection for Software under U.S. Law. Computer Forensics Online, (1997).

[GSAM Version 3.0 2000]

U.S. Air Force Software Technology Support Center. Guidelines for Successful A cquisition and Management of Software Intensive Systems (GSAM), Version 3, Chapter 12. May 2000

[McMaster University 2008]

McMaster University. Software FAQs. Hamilton, Ontario, Canada. 2007-2008.

[OUSD AT&L 2001]

Under Secretary Of Defense for Acquisition, Technology and Logistics. Intellectual Property: Navigating Through Commercial Waters—Issues and Solutions When Negotiating Intellectual Property With Commercial Companies. Version 1.1. October 2001.

[Szeliga 2009]

Szeliga, Keith. Protecting Your Proprietary Rights. Pp. 36-48. Contract Management. July 2009.

Appendix A—Selected DFARS Definitions[3], [4]

Commercial computer software: 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 [DFARS 252.227-7014 (a) (1) 2011].

Computer program: a set of instructions, rules, or routines, recorded in a form that is capable of causing a computer to perform a specific operation or series of operations [DFARS 252.227-7014 (a) (3) 2011].

Computer software: computer programs, source code, source code listings, object code listings, design details, algorithms, processes, flow charts, formulae, and related material that would enable the software to be reproduced, recreated, or recompiled. Computer software does not include computer databases or computer software documentation [DFARS Subpart 252.227-7014 (a) (4) 2011].

Computer software documentation: owner's manuals, user's manuals, installation instructions, operating instructions, and other similar items, regardless of storage medium, that explain the capabilities of the computer software or provide instructions for using the software [DFARS Subpart 252.227-7014 (a)(5) 2011].

Data : recorded information, regardless of form or the media on which it may be recorded. The term includes technical data and computer software. The term does not include information incidental to contract administration, such as financial, administrative, cost or pricing, or management information [FAR Subpart 27.401, FAR 52.227-12010].

Developed: means that (i) a computer program has been successfully operated in a computer and tested to the extent sufficient to demonstrate to reasonable persons skilled in the art that the program can reasonably be expected to perform its intended purpose; (ii) computer software, other than computer programs, has been tested or analyzed to the extent sufficient to demonstrate to reasonable persons skilled in the art that the software can reasonably be expected to perform its intended purpose; or (iii) computer software documentation required to be delivered under a contract has been written, in any medium, in sufficient detail to comply with requirements under that contract [DFARS Subpart 252.227-7014 (a)(7) 2011].

Government purpose: any activity in which the United States Government is a party, including cooperative agreements with international or multi-national defense organizations, sales, or transfers by the United States Government to foreign governments or international organizations. Government purposes include competitive procurement, but do not include the rights to use, modify, reproduce, release, perform, display, or disclose computer software or computer software documentation for commercial purposes or authorize others to do so [DFARS 252.227-7014 (a)(11) 2011].

Noncommercial computer software: software that does not qualify as commercial computer software under paragraph (a) (1) of DFARS 252.227-7014 [DFARS 252.227-7014 (a) (14) 2011].

Technical data: data other than computer software, which are of a scientific or technical nature [FAR Subpart 27.401—Definitions 2010].

Appendix B—Taxonomy of Software Development Risks[5]

Class

-->

A. Product Engineering

1. Requirements
a. Stability

b. Completeness

c. Clarity

d. Validity

e. Feasibility

f. Precedent

g. Scale

B. Development Environment

1. Development Process
a. Formality

b. Suitability

c. Process Control

d. Familiarity

e. Product Control

C. Program Constraints

1. Resources

a. Schedule

b. Staff

c. Budget

d. Facilities

Element

-->

2. Design
a. Functionality

b. Difficulty

c. Interfaces

d. Performance

e. Testability

f. Hardware Constraints

g. non-Developmental Software

2. Development System
a. Capacity

b. Suitability

c. Usability

d. Familiarity

e. Reliability

f. System Support

g. Deliverability

2. Contract
a. Type of Contract

b. Restrictions

c. Dependencies

Attribute

-->

3. Code and Unit Test
a. Feasibility

b. Testing

c. Coding/Implementation

3. Management Process
a. Planning

b. Project Organization

c. Management Experience

d. Program Interfaces

3. Program Interfaces
a. Customer

b. Associate Contractors

c. Subcontractors

d. Prime Contractor

e. Corporate Management

f. Vendors

g. Politics

4. Integration and Test
a. Environment

b. Product

c. System

4. Management Methods
a. Monitoring

b. Personnel Management

c. Quality Assurance

d. Configuration Management

5. Engineering Specialities
a. Maintainability

b. Reliability

c. Safety

d. Security

e. Human Factors

f. Specifications

5. Work Environment
a. Quality Attitude

b. Cooperation

c. Communication

d. Morale

Footnotes

[1] ASSIP is a long-term partnership among the Assistant Secretary of the Army (Acquisition, Logistics, and Technology) (ASA(ALT)); the Army's Program Executive Officers (PEOs) and the Software Engineering Institute (SEI) to dramatically improve the acquisition of software-intensive systems. The Army's Software Engineering Centers (SECs), Training and Doctrine Command (TRADOC), Army Test and Evaluation Command (ATEC), and the Army CIO-G6 also participate in ASSIP. The ASSIP is focused on acquisition programs, people, production/sustainment, and institutionalizing continuous improvement.

[2] The Taxonomy of Software Development Risks is based on Bloom's Taxonomy of Learning Domains.

[3] Defense Federal Acquisition Regulation Supplement (DFARS) 227.72--Rights in Computer Software and Computer Software Documentation. Revised 20 January 2011.

[4] Code of Federal Regulations (CFR), Title 48--Federal Acquisition Regulations System. Chapter 1--Federal Acquisition Regulation (FAR). Revised as of October 1, 2010.

[5] Dorofee, A. J., Walker, J. A., Alberts, C. J., Higuera, R. P., Murphy, R. L., and Williams, R. C. Continuous Risk Management Guidebook. Software Engineering Institute, Carnegie Mellon University, 1996.

Copyright 2011 Carnegie Mellon University

This material is based upon work supported by the United States Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.

Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense.

This report was prepared for the

SEI Administrative Agent

ESC/XPK

5 Eglin Street

Hanscom AFB, MA 01731-2100

NO WARRANTY

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

This material has been approved for public release and unlimited distribution except as restricted below.

Internal use:* Permission to reproduce this material and to prepare derivative works from this material for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works.

External use:* This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other external and/or commercial use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu.

For information about SEI publications, please visit the library on the SEI website (www.sei.cmu.edu/library).

* These restrictions do not apply to U.S. government entities.

REPORT DOCUMENTATION PAGE

Form Approved

OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

1. agency use only

(Leave Blank)

2. report date

July 2011

3. report type and dates covered

Final

4. title and subtitle

A Decision Framework for Selecting Licensing Rights for Noncommercial Computer Software in the DoD Environment

5. funding numbers

FA8721-05-C-0003

6. author(s)

Charlene Gross

7. performing organization name(s) and address(es)

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213

8. performing organization

report number

CMU/SEI-2011-TR-014

9. sponsoring/monitoring agency name(s) and address(es)

HQ ESC/XPK

5 Eglin Street

Hanscom AFB, MA 01731-2116

10. sponsoring/monitoring agency report number

ESC-TR-2011-014

11. supplementary notes

12a distribution/availability statement

Unclassified/Unlimited, DTIC, NTIS

12b distribution code

13. abstract (maximum 200 words)

A major acquisition challenge for a program where computer software is a critical element of the system is the upfront determination of an appropriate licensing rights strategy. This report describes standard noncommercial software licensing alternatives as defined by U.S. government and Department of Defense (DoD) regulations. It also suggests an approach for objectively identifying agency needs for license rights and the appropriate license type for systems with noncommercial computer software or as standalone software in the DoD environment. There are three standard license types for noncommercial computer software: Unlimited, Government Purpose, and Restricted. Each of these license types for noncommercial computer software conveys different rights to the agency. This report presents distinguishing characteristics of the three standard license types, a method to develop the supporting rationale or traceability for DoD agency needs, a high-level description of circumstances that fall outside of standard license types, and a discussion of the importance of deliverables as necessary components for implementing license rights.

14. subject terms

noncommercial software licensing alternatives, noncommercial computer software, and noncommercial software rights in DoD environment

15. number of pages

40

16. price code

17. security classification of report

Unclassified

18. security classification of this page

Unclassified

19. security classification of abstract

Unclassified

20. limitation of abstract

UL

NSN 7540-01-280-5500

Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z39-18 298-102

Table of Contents

Acknowledgements

Abstract

1 Introduction

2 Core Principles of Noncommercial Computer Software Ownership and Licensing

2.1 Why You Need a License for Noncommercial Computer Software

2.2 When and Why You Need a Noncommercial Computer Software License Strategy

2.3 Noncommercial Computer Software Licenses and Associated Rights You Can Obtain

2.4 What You Need in Addition to a Noncommercial Computer Software License and the Associated Rights

2.5 Resources to Help You Understand Rights to Noncommercial Computer Software

3 Organizing Choices for Selecting a Noncommercial Computer Software Licensing Strategy

3.1 Scope of Use

3.2 Access or Transfer

3.3 Commercial Prospects

3.4 Funding Source

3.5 Putting the Distinguishing Characteristics Together

4 Decision Drivers to Identify Agency Noncommercial Computer Software Licensing Needs—Scope of Use Focus

4.1 Taxonomy to Support Noncommercial Computer Software Licensing Strategy Discussions

4.2 From Expectations to a Needs-Based Noncommercial Computer Software Licensing Strategy

5 Other Considerations

6 Conclusion

7 References

Appendix A—Selected DFARS Definitions[3], [4]

Appendix B—Taxonomy of Software Development Risks[5]

Footnotes