Software Acquisition

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: DODI 5010.44 IP Acquisition and Licensing Section 1.2

 

Integrate Intellectual Property (IP) planning fully into acquisition strategies and product support strategies to protect core DoD interests over the entire life cycle. Seek to acquire only those IP deliverables and license rights necessary to accomplish these strategies, bearing in mind the long-term effect on cost,competition, and affordability.

 

Weapon and information systems acquired by DoD in support of the warfighter are, and will be, increasingly dependent on technology for its operation, maintenance, modernization, and sustainment. Acquiring and licensing the appropriate IP is vital for ensuring the systems will remain functional, sustainable, upgradable and affordable. Because balancing the interests of the U.S. Government and industry in IP can be diffcult, early and effective understanding, planning, and communications between the U.S. Government and industry is critical, as is ensuring delivery, acceptance, and management of the necessary IP deliverables (e.g., technical data and computer software), with appropriate license rights. The DoD requires fair treatment of IP owners, and seeks to create conditions that encourage technologically advanced solutions to meet DoD needs.

Reference Source: DODI 5010.44 Section 1.2.b

 

The following core principles govern the DoD acquisition, licensing, and management of IP:

 

1. Integrate IP planning fully into acquisition strategies and product support strategies to protect core DoD interests over the entire life cycle. Seek to acquire only those IP deliverables and license rights necessary to accomplish these strategies, bearing in mind the long-term effect on cost, competition, and affordability.
2. Ensure acquisition professionals have relevant knowledge of how IP matters relate to their official duties. Cross-functional input and coordination is critical to planning and life-cycle objectives.
3. Negotiate specialized provisions for IP deliverables and associated license rights whenever doing so will more effectively balance DoD and industry interests than the standard or customary license rights. This is most effective early in the life cycle, when competition is more likely.
4. Communicate clearly and effectively with industry regarding planning, expectations and objectives for system upgrade and sustainment. Avoid requirements and strategies that limit the DoD’s options in accessing vital technology and commercial solutions available from industry.
5. Respect and protect IP resulting from technology development investments by both the private sector and the U.S. Government.
6. Clearly identify and match data deliverables with the license rights in those deliverables. Data or software deliverables are of no value unless and until the license rights to use it are attached, and the U.S. Government actually obtains and accepts those deliverables.

Reference Source: USD(A&S) Acquisition Strategy Template

Summarize the Technical Data Rights Strategy for meeting product life-cycle data rights requirements and to support the overall competition strategy. Include:

• Strategy by which the government will have access to (not necessarily ownership of) the source code to support future analysis and use. This strategy should include mechanisms to stipulate and enforce that proprietary software not be included in the software baseline without PM office approval, and that it be included in the baseline in a manner that preserves modularity of the software and does not unnecessarily intermix proprietary and non-proprietary software.
• How the government will have access to information sufficient to have technical insight into what code goes into the build of the software, such as: build automation software, engineering data, drawings, models, and Bills of Materials (BOM).
• Additional sources of software data to support the product support life cycle strategy, which may include baseline documentation data, analysis data, cost data, test software and harnesses, test data, results of reviews, performance data. Consider data that would be needed to support activities such as training, Information Assurance protection, open architecture, configuration management, engineering, technology refreshment, and reliability management.
• When the government takes delivery of software source code, the government should ensure that all additional artifacts necessary to compile, test, secure, deploy, and operate the software are delivered as well. These artifacts can include (but may not be limited to): scripts, tools, databases, libraries, and other software executables.

Life Cycle Sustainment Plan (LCSP)/Product Support Strategy: Certain IP and rights will be necessary to execute the sustainment plan. Examine how the LCSP plans to satisfy each of the Integrated Product Support Elements and ensure that the IP Strategy seeks the rights and deliverables needed to execute these plans. Early in the acquisition process, specific support strategies may not have been decided. In this situation, it is critical to obtain the IP rights and deliverables that keep sustainment options open. If depot maintenance is required, more technical data and computer software requirements may exist than for other maintenance concepts. Also, development of logistics plans can illuminate the technical data and software required for effective life-cycle support.

Request for Proposals (RFP): The IP Strategy should map to contract requirements in the RFP(s). If it does not, offerors will be unable to meaningfully propose to these requirements, and the Air Force risks not being able to meet its life cycle needs. For example, the Statement of Work (SOW) in a product development contract should require, along with the development activities, the creation and delivery of the associated technical data and computer software. Because these issues can dominate life-cycle decisions later, evaluation factors related to IP and life-cycle support, as well as associated agreements, should be included.

Contract: Within the contract, technical data and computer software requirements found in the SOW must be delivered by inclusion of a Contract Data Requirement List (CDRL), DD Form 1423, in the contract attachments. CDRLs state, among other things, format and content of the deliverable. It is a best practice to ensure that the CDRLs are mapped to deliverable requirements in the SOW so that the contractor is required by the contract to deliver all required technical data and computer software.

Engineering Documents such as the System Engineering Plan (which addresses topics like Modular Open System Architecture needs), test plans, technical baseline documentation (such as interface control documents, item specifications, and various performance requirements), software documentation, and other engineering documents.

Other Documents like the Program Protection Plan and Financial Documents (e.g., Program Objective Memorandum and budget requests) can include information relevant to the IP Strategy, including references to critical program information, costs for data and storage, and additional information regarding development, production, and sustainment.

Evaluating IP as part of Source Selection Process

Step 1: In determining whether to include IP rights as an evaluation factor, the PMO should consider the nature of the contract, including:

• Does the contract involve development of a new system?
• Does the contract involve modifications to an existing system or major components/subcomponents? If so, are they minor modifications?
• Do we plan to compete follow-on work, sustainment, or upgrades for the system, components, or sub- components?
• Was the development of an existing system, components, or subcomponents funded by the Government, a contractor, or both?
• Is the system a commercial item?
• How would IP rights be evaluated?
• Does evaluating IP rights give one competitor an advantage or unduly restrict competition?
• If separately evaluating IP rights is not appropriate or practical, can IP rights be considered as part of an- other factor?

Step 2: Some questions to ask to determine whether Data Rights is a discriminator:

• How would you evaluate?
• Would there be a clear winner (i.e., does someone have an advantage going into the process)?

Step 3: Some basics to consider on creating a discriminator:

• For an item that was developed exclusively at private expense (and the concomitant assertions of limited/restricted rights), the Government can evaluate the impact on (a) other evaluation factors, (b) the effects on competition for the item if it is to be procured in substantial quantities in the future, and (c) its effect on the total value of the proposal, including potential life-cycle costs (10 USC 2305; 41 USC 253b; DFARS 227.7103-10; DFARS 227.7203-10).
• Although assertions can be challenged as part of the evaluation process, it is probably better to evaluate the impact of those assertions on the Government’s requirements as opposed to challenging the assertions themselves in the pre-award stage, unless resolution of the assertion is essential for completion of the procurement (DFARS 227.7103-13; DFARS 227.7203-13).

Data rights can be used as a discriminator in a variety of ways:

1. Technical Factor

• IP rights can be evaluated as part of the Government’s evaluation of technical proposals during either tradeoff analysis or lowest price technically acceptable source selections. In the case of the former, the Government will evaluate the extent to which offeror’s proposed IP rights satisfy the Government’s min-imum needs. In the case of the latter, the Government would evaluate whether the offeror’s proposed IP rights satisfy the Government’s minimum needs. In either case, those minimum needs and their pedigree must be clearly stated in the RFP so as to demonstrate that those minimum needs are not unduly restric-tive of competition.
• If an offeror proposes to deliver IP rights associated with a commercial item, the Government should first validate that the item satisfies the definition of a commercial item. If so, then the Government should evaluate the IP rights proposed to determine whether it meets the agency’s needs and does not violate Federal procurement law.

2. Past Performance Factor

• The questionnaires associated with past performance references should ask about the offeror’s past performance with respect to issues such as affixing nonconforming/unjustified markings to
• deliverables and refusing to deliver content along with the IP rights it proposed to provide to that reference prior to award.
• The Government should review all relevant information in the Contractor Performance Assessment Re- porting System for any instances where the offeror affixed nonconforming/unjustified markings to deliverables, or refused to deliver content along with the IP rights it proposed to provide to that reference prior to award.

3. Price-Based Evaluation Factor

• Price must be evaluated in every source selection. If the offeror fails to propose a fixed price for IP rights where the RFP required a price be proposed, that failure to conform to material terms and conditions of the RFP means the proposal is unacceptable and may not form the basis for award. If the proposed IP rights will be furnished under a cost-reimbursable Contract Line Item Number (CLIN), the Government must perform a cost realism analysis of those proposed costs and adjust the proposed costs upward as appropriate. If the proposed IP rights will be furnished under a fixed price CLIN and the Government stated it would perform a price realism analysis of that CLIN, then it must do so. In either case, the Government must demonstrate its evaluation of the offeror’s proposed technical approach was consistent with the offeror’s proposed costs or prices.
• Offerors can be given a price credit for proposing to deliver greater IP rights and/or greater IP than the Government’s minimum needs. But such a credit must be expressly identified in the RFP. Upon demand, the Government must be able to explain how it calculated the amount of that credit.

Reference Source: Air Force Data Rights Guidebook

To prevent “vendor lock” and promote competition/organic sustainment, the PMO should:

1. Establish an IPT, consisting of a cross-functional team of SMEs and led by a data manager with a strong background in IP and IP rights. IPT members should be knowledgeable in technical data and computer soft- ware, IP rights, the system’s architecture (both hardware and software), and why the data are needed.
2. Issue a data call to identify what data are necessary for sustainment and future competition of the system or subsystems. Consider whether specially negotiated licenses could be used effectively to support the product support strategy. Figures 1 and 2 present flow charts that the IPT could use to determine the deliverables and required rights.
3. Conduct a Data Requirements Review Board in accordance with DoD 5010.12-M to ensure the data and software requirements in the IP Strategy are authenticated. Questions to be presented include: “What data are needed? Why the data are needed? For what purpose will the data be used?”
4. Conduct a cost analysis and determine the most cost effective means for maintaining, upgrading, and managing the system over its life cycle. Consider options including the original equipment manufacturer (OEM), other sources, or government activities.
5. Include the IPT’s plan to promote competition in the Acquisition Strategy and the LCSP, addressing all functional areas (i.e., logistics, engineering, cost, program management, risks, testing, and contracting documents (SOW/RFP/Contract/CDRLs)).
6. Develop the proper CDRLs for technical data and computer software (e.g., source code, object code, executable code, and documentation).
7. Prior to entry into Milestone A or B, integrate the IP Strategy into the RFP and any applicable programmatic documents. Within the Source Selection Plan, consider requiring delivery of technical data, computer software, contract and management data the IPT has identified as necessary, and evaluation factor(s) assessing the associated rights the offeror proposes to provide.
8. When drafting the SOW, RFP, and contract:
   • Include specific language in the RFP explaining the technical data and computer software requirements, including whether the PMO will need to provide data or source code to other companies or government activities;
   • Require offerors to implement a Modular Open Systems Approach to acquire a system with severable modules that the program can compete separately and interfaces developed to open standards (see sections 1.1.5. and 1.1.6. discussing Modular Open Systems Approaches);
   • Require, via CDRLs, delivery of all mandatory technical data and computer software. For example, include CDRLs with data item descriptions requiring delivery of interface control documents and application programming interfaces (e.g., for computer software IEEE STD 12207);
   • Require offerors to include in their proposals a list/table mapping CDRLs to rights the Air Force would receive in the deliverables;
   • Include the Deferred Delivery clause (DFARS 252.227-7026), which allows the Air Force to defer delivery of identified technical data or computer software deliverables, as well as the Deferred Ordering clause (DFARS 252.227-7027) in the model contract if appropriate;
   • Include in the RFP the mandatory Data Rights Assertions clause (DFARS 252.227-7017), which requires offerors to identify all noncommercial technical data and computer software that will be delivered to the Air Force with less than UR;
   • Consider modifying the data rights assertions requirements (e.g., via special H clause, to mandate that offerors provide assertions for commercial technical data and commercial computer software in the same format as for noncommercial deliverables and submit any licenses for commercial software with their proposal); and
   • Ensure a CDRL requiring delivery of a data accession list is included in the model contract.
9. Prior to releasing the RFP, conduct an Industry Day to clearly articulate requirements for technical data and computer software delivery and the associated rights desired. Provide industry with opportunities to offer feedback on all IP issues.
10. Use industry feedback to revise the RFP.
11. Thoroughly train all members of your technical evaluation team to ensure understanding of the requirements and evaluation factors related to technical data, computer software, and associated rights.
12. Engage in meaningful discussions during the evaluation to ensure the evaluation team understands the offerors’ proposed delivery of technical data, computer software, and associated rights.
13. After award, create a spreadsheet (see Figure 3 as an example) to list the Work Breakdown Structure (WBS) elements of the new system. Each element will map to:
    • The data or software needed (depot, intermediate, organizational maintenance)
    • The specific drawing number or computer software source code version
    • The specific IP rights license to that drawing or computer software source code version
14. Before acceptance of deliverables, the PMO reviews all data rights markings on the technical data or computer software to identify any nonconforming or unjustified markings. If the deliverables contain any non- conforming or unjustified markings, the PMO should pursue contractual remedies to address the contractor’s failure to meet contract requirements and require the contractor to provide properly marked (or unmarked) documents.