Planning for software and source code access

← All Insights

1. Buy only what is needed

The Defense Federal Acquisition Regulation Supplement (DFARS) sets a policy for buying software. Defense Department policy is to acquire only the computer software, documentation and rights in them that are necessary to satisfy agency needs (DFARS 227.7203-1(a)). For major weapon systems or their subsystems, the acquisition plan must address strategies for software, documentation and the associated license rights, as DFARS 207.106(S-70) requires (DFARS 227.7203-1(e)).

Solicitations and contracts must specify the software and documentation to be delivered and their delivery schedules (DFARS 227.7203-1(b)). They must set or reference procedures for deciding whether deliveries are acceptable. To the extent practicable, they must establish separate contract line items for software and documentation, and require each deliverable data item to be priced separately. Offerors must identify, as far as practicable, software or documentation to be furnished with restrictions, and contractors must identify it again before delivery.

2. Protection for private investment

Offerors may not be required, as a condition of being responsive or of award, to sell or give up any rights in software developed exclusively at private expense (DFARS 227.7203-1(c)). The exceptions are the software listed in DFARS 227.7203-5(a)(3) to (6), such as corrections to government-furnished software and publicly available software. Offerors and contractors also may not be prohibited or discouraged from offering privately developed software solely because the government’s rights in it may be restricted (DFARS 227.7203-1(d)).

3. Assessing life-cycle needs

Contracting officers work closely with data managers and requirements personnel so that software requirements in solicitations are consistent with that policy (DFARS 227.7203-2(a)). Data managers or other requirements personnel are responsible for identifying the government’s life-cycle needs for software and documentation (DFARS 227.7203-2(b)(1)). Beyond performance and compatibility, the DFARS says this should consider factors such as the following. They include the offeror’s economic interests in privately developed software, including those of small businesses and nontraditional contractors, and the government’s costs to develop, acquire, maintain, store, retrieve and protect the software. The others are multiple site or shared use requirements, whether the maintenance approach needs the right to modify the software or have others modify it, and special documentation requirements.

To the maximum extent practicable, planning documents such as acquisition plans and purchase requests must address acquiring, at the right points in the life cycle, everything needed for four tasks (DFARS 227.7203-2(b)(2)(i)). The first is to reproduce, build or recompile the software from its source code and required software libraries. The others are to conduct required testing and evaluation, to integrate and deploy programs on relevant hardware, and to sustain and support the software over its life cycle. The relevant hardware includes developmental, operational, diagnostic, training and simulation environments.

4. Alternatives to source code

The assessment should consider alternatives to delivery of source code and related design details for privately developed software, as needed to meet the government’s needs (DFARS 227.7203-2(b)(2)(ii)). Examples include technical data and software sufficient to implement a modular open system approach or a similar approach. Another example is access to data or software, including access agreements for cloud-based or subscription-based products and services. Software support and maintenance provided directly by the contractor is a third.

A further example is other contracting or licensing mechanisms (DFARS 227.7203-2(b)(2)(ii)(D)). The DFARS names priced options, specially negotiated licenses, direct licensing between contractors for qualifying second sources, data escrow agreements, deferred delivery solutions and subscription agreements. When reviewing offers, data managers must balance the original assessment of needs against the prices offered (DFARS 227.7203-2(b)(3)).

5. What the contract should say

Wherever practicable, contracting officers make sure solicitations and contracts identify the types of software and the quantity of programs and documentation to be delivered (DFARS 227.7203-2(c)(1)). They also identify any multiple user or multiple site license needs, and the format and media of delivery. Each type of software or documentation is set up as a separate contract line item, which may be done through an exhibit (DFARS 227.7203-2(c)(2)). Under fixed-price contracts, the prices for each separately priced item are identified, and every deliverable has a delivery schedule, acceptance criteria and a stated place of delivery (DFARS 227.7203-2(c)(3) to DFARS 227.7203-2(c)(5)).

The negotiated terms must also provide, to the extent appropriate, that the software and rights identified in the life-cycle assessment meet three conditions (DFARS 227.7203-2(c)(6)). The software must be delivered in a digital format compatible with the programs on the relevant hardware. It must not rely on additional data or software unless that material is delivered, or commercially available, with rights sufficient for the government’s needs. Where the terms do not allow such material, the delivery must include enough information, with sufficient rights, to support maintenance and understanding of interfaces and version history.

6. Acceptance and warranties

Computer software documentation is technical data, and follows the technical data rules on conformity and acceptance (DFARS 227.7203-14(a)). Solicitations and contracts requiring delivery of software must state what the software must satisfy to be acceptable (DFARS 227.7203-14(b)(1)). Contracting officers or their representatives decide whether software tendered conforms. Except where nonconforming restrictive markings are the only problem, software that does not conform in all respects is not accepted. Correction, replacement or an equitable price reduction then follows the contract’s inspection clause, or FAR 46.407(c) to (g) if the contract has no such clause.

Software that is a component of a weapon system or major subsystem should be warranted as part of the weapon system warranty (DFARS 227.7203-14(b)(2)(i)). For other systems, the chief of the contracting office must approve any software warranty (DFARS 227.7203-14(b)(2)(ii)). Once approved, the warranty of data clause may be modified for software, or a procurement-specific clause developed. The licenses themselves are covered in how funding sets software rights.

Key terms

Life-cycle needs	The software, information and rights needed to build, test, deploy and sustain software.
Separate line item	A contract line item for each type of software or documentation to be delivered.
Modular open system approach	One listed alternative to delivery of source code.
Data escrow agreement	A licensing mechanism the DFARS lists as an alternative to delivering source code.
Weapon system warranty	The warranty that should cover software that is part of a weapon system.

Every statement above links to the document behind it. The full source list for this piece is on the sources page.

This page describes public United States government programs for general information. It is not legal, regulatory or procurement advice, and it does not address the facts of any particular case.

How Sentfore supports this

Sustainment abroad starts with the software rights planned at the outset. Sentfore works at the delivery end of defense programs in difficult environments, providing secure movement, protective security, facilities and life support. Requirements can be sent through the contact page.