src/app/components/policy-guide/docs/compliance/compliance-procurement/compliance-procurement.template.html
<h1><a id="Building_and_Buying_Custom_Software_1"></a>Building and Buying Custom Software</h1>
<p>Section 3.1 of the Source Code Policy requires that:</p>
<blockquote>
<p>In meeting their software needs, covered agencies must conduct [a] three-step analysis […] intended to leverage existing solutions – consistent with principles of category management and shared services – and suitable commercial solutions, while mitigating unnecessary spending on custom-developed software solutions.
</p>
</blockquote>
<p>The three steps are:</p>
<ol>
<li>Conduct Strategic Analysis and Analyze Alternatives;</li>
<li>Consider Existing Commercial Solutions; and</li>
<li>Consider Custom Development</li>
</ol>
<p>Below are tips that your agency can use to apply these steps effectively.</p>
<h2><a id="Step_1_Conduct_Strategic_Analysis_and_Analyze_Alternatives_15"></a>Step 1: Conduct Strategic Analysis and Analyze Alternatives</h2>
<blockquote>
<p>Step 1 (Conduct Strategic Analysis and Analyze Alternatives): Each agency must conduct research and analysis prior to initiating any technology acquisition or custom code development. The strategic analysis should consider not only agency mission and operational needs, but also external public initiatives and interagency initiatives such as Cross-Agency Priority Goals. Having conducted the strategic analysis, agencies shall then conduct an alternatives analysis, evaluating whether to use an existing Federal software solution or to acquire or develop a new software solution. The alternatives analysis shall give preference to the use of an existing Federal software solution</p>
</blockquote>
<p>The purpose of Step 1 is to ensure that your agency – not just your acquisition team, but also your technology team, program management team, and leadership, among others – has a complete strategic view of what offerings exist before determining that an acquisition is in fact required.</p>
<p>Further, Step 1 is meant to ensure that agencies do market research to discover what Federal and non-Federal solutions are already available before buying or building software.</p>
<h3><a id="_Things_to_consider_during_Step_1__23"></a><em>Things to consider during Step 1:</em></h3>
<ul>
<li>Consult your agency's mission statement to broaden your strategy beyond the immediate project requirements.</li>
<li>As required in the policy, also consider relevant "external public initiatives and interagency initiatives such as Cross-Agency Priority Goals" for the same reason.</li>
<li>Review OFPP memorandum M-16-12 "Improving the Acquisition and Management of Common Information Technology: Software Licensing" and consult with your agency's appointed Software Manager.</li>
</ul>
<h2><a id="Step_2_Consider_Existing_Commercial_Solutions_29"></a>Step 2: Consider Existing Commercial Solutions</h2>
<blockquote>
<p>Step 2 (Consider Existing Commercial Solutions): If an agency's alternatives analysis concludes that existing Federal software solutions cannot efficiently and effectively meet the needs of the agency, the agency must explore whether its requirements can be satisfied with an appropriate commercially-available solution
</p>
</blockquote>
<p>As with Step 1, the purpose of Step 2 is to develop your agency's strategic view of the marketplace prior to initiating an acquisition. Agencies should remember in surveying the marketplace of commercial solutions that many commercial solutions can be extended through custom code to satisfy your requirements entirely (see discussion of hybrid solutions below).</p>
<h3><a id="_Things_to_consider_during_Step_2__35"></a><em>Things to consider during Step 2:</em></h3>
<ul>
<li>Open Source Software may meet the definition of "commercial computer software" and may also be included in a commercial solution in accordance with FAR 2.101(b). For example, Open Source Software that "[h]as been offered for sale, lease, or license to the general public" may be considered "commercial" for purposes of a federal acquisition. Be sure to consult your agency's policy regarding Open Source Software acquisitions.</li>
<li>It is important to apply category management principles, which give preference to best-in-class solutions, in your analysis. Agencies must use <a class="default-link" href="https://software.cio.gov/introduction/">Category Management Policy 16-1</a> for this analysis.</li>
</ul>
<h2><a id="Step_3_Consider_Custom_Development_40"></a>Step 3: Consider Custom Development</h2>
<blockquote>
<p>Step 3 (Consider Custom Development): If an agency's alternatives analysis concludes that an existing Federal software solution or commercial solution cannot adequately satisfy its needs, the agency may consider procuring custom-developed code in whole or in conjunction with existing Federal or commercial code. When commissioning new custom-developed software, agencies must consider the value of publishing custom code as OSS and negotiate data rights reflective of its value-consideration. Agencies must also obtain sufficient rights to fulfill this policy's objectives related to Government-wide code reuse and the open source pilot program.
</p>
</blockquote>
<p>Having determined that no Federal or commercial solutions exist that completely meet their needs, agencies may build or buy custom software.</p>
<p>In doing so, the most important thing to remember is that the Federal Source Code Policy requires agencies to "acquire and enforce rights sufficient to enable Government-wide reuse" when contracting for the custom development of code. With respect to release, the Federal Source Code Policy's Pilot Program requires agencies to release at least 20 percent of new custom-developed code each year as open source software. While agencies are encouraged to release a greater percentage of code, if doing so is beneficial to the government, agencies are not required to release more than 20 percent of code.</p>
<p>Accordingly, consider the following during the acquisition lifecycle:</p>
<h3><a id="Presolicitation_50"></a>Presolicitation</h3>
<p>Once your agency has determined that custom code development is necessary, it is important to actively communicate that government reuse and open source, as appropriate, are core to the requirements of your project from the outset. Whether during an RFI or industry day, relay to potential vendors early and often that your agency intends to receive appropriate rights for government re-use and/or open source.</p>
<p>Your acquisition strategy should allow the agency to determine which software modules or components should be built separately. In the spirit of modular development, the technical and licensing approach can be tackled per component to maximize public benefit.</p>
<h3><a id="Solicitation_Negotiation_and_Award_56"></a>Solicitation, Negotiation, and Award</h3>
<h4>Government code reuse</h4>
<p>Agencies must obtain unlimited rights to all custom-developed code first produced in the performance of the contract.</p>
<p>The Federal Acquisition Regulation's (FAR) General Rights in Data clause – FAR 52.227-14 – provides for "unlimited rights" in data first produced in the performance of the contract, which generally covers custom-developed code. This includes both the right to share the custom-developed code with other agencies and, as explained below, the right to publicly release the code for reuse subject to restrictions in an open source license However, if an agency is not seeking, or able, to obtain the rights to publicly release the code, the rights license should still provide, at a minimum, the Government's rights to share the custom-developed code with other agencies. Rights for government reuse outside the unlimited rights clause may be accomplished by using the limited rights notice under Alternate II of the 52.227-14 clause. In enforcing such data rights, agencies should ensure that deliverables do not contain markings that limit rights of distribution within the contracting agency or bureau only.</p>
<p>A number of agencies have already developed supplementary contract clauses to further address and clarify the government's rights. Agencies, in particular those visiting this issue for the first time, can benefit from comparing their practices and contract clauses with others and standardizing where possible.</p>
<p>As one example, the Department of Defense has developed a license rights clause for noncommercial computer software where the parties look to the source of funds used to develop computer software as the basis for establishing associated reuse rights by the government.</p>
<p>If the government exclusively funds the development of the code, the clause would give the agency an <em>unlimited rights</em> license in noncommercial technical data, noncommercial computer software and noncommercial computer software documentation.</p>
<p>If the development is exclusively funded by the contractor, the agency usually acquires a restricted rights license in noncommercial computer software.</p>
<p>The DFARS 252.227-7013 and -7014 clauses specifically provide for this determination to be made at the lowest practicable portion of software, which allows the Department of Defense to assert reuse rights in a hybrid solution involving both commercial and custom code.</p>
<p>If an agency is interested in taking advantage of the DFARS language, it could consider a deviation in accordance with FAR Subpart 1.4 to follow the relevant Defense Federal Acquisition Regulation Supplement.</p>
<p>As a best practice, consider expressly asserting in the solicitation (and resulting contract) that unlimited rights attach to all code furnished in the performance of the contract, unless the parties expressly agree otherwise in the contract. This practice can help to avoid disputes after contract award as to whether triggers in the standard clauses (<em>e.g.</em>, "first produced in the performance of the contract" or "developed exclusively with government funds") have been met.</p>
<h4>Open source software</h4>
<p>If applicable, identify the requirement for open-source software in the solicitation. If you have a preferred open source license, specify it in the solicitation. For various licensing options (<em>e.g.</em>, adoption of an existing open source license or negotiation of a waiver), please refer to the licensing advice provided on <a class="default-link" href="http://code.gov/">Code.gov</a>.</p>
<p>The FAR's unlimited rights clause establishes the basic right for the Government to publish custom-developed code first produced in the performance of the contract publicly for reuse subject to restrictions in an open source license.</p>
<p>If an agency intends to publish software as open source, it should not include Alternate IV to the clause, which would provide the contractor a blanket permission to assert copyright. A contractor's request for permission to assert copyright under FAR 52.227-14 should be denied in instances where the agency intends to publish code as OSS. A contractor, if given such permission, could assert its copyright interests against third parties interested in using and contributing to custom-developed code released by the Government. In all instances, even where a contractor is given permission to assert copyright, the Government must preserve the right to share code with other agencies and those contractors retained by the agencies to modify, refresh, or otherwise use the code by or on behalf of the Government.</p>
<h4>Other considerations</h4>
<h4>Identify all deliverables and asserted restrictions</h4>
<ul>
<li>For commercial data/software, the contractor needs to provide a copy of the proposed commercial license agreement to the contracting officer prior to contracting;</li>
<li>For noncommercial data/software, the contractor needs to identify prior to contracting, often in proposals, the data that will be delivered with restrictions (FAR 27.404-3b; DFARS 252.227-7017);</li>
<li>The solicitation and contract must specify delivery of the data package and source code. The agency should include additional data requirements clauses in the FAR to permit flexibility in ordering additional deliverables.</li>
</ul>
<h4><a id="Make_sure_that_your_contractor_holds_to_the_software_and_data_rights_requirements_and_require_the_contractor_to_provide_all_licenses_for_software_dependencies_as_part_of_the_deliverables_97"></a>Make sure that your contractor holds to the software and data rights requirements, and require the contractor to provide all licenses for software dependencies as part of the deliverables:</h4>
<ul>
<li>Ensure that all deliverables are appropriately marked with the applicable restrictive legends;</li>
<li>If contractor omits restrictive markings, data or software delivered without restrictive markings, the Government is deemed to have received unlimited rights in the deliverable (the Government may allow the contractor to correct the error according to certain procedures);</li>
<li>If delivery is made with restrictive markings that are not authorized by the contract, the marking is characterized as nonconforming (contract contains procedure for correcting nonconforming markings);</li>
<li>Agencies should also require delivery of the source code and other relevant materials and associated documents, which is specified in the contract requirements.</li>
</ul>
<h4><a id="Hybrid_Solutions_104"></a>Hybrid Solutions:</h4>
<p>Appropriately, agencies often contract for the delivery of solutions that are a hybrid of commercial and custom-developed code. Hybrid solutions entail a mix of rights; agencies may have unlimited rights to custom-developed parts of the solution but restricted rights to the rest. Because of this added complexity, contracts for hybrid solutions warrant closer attention to make sure that unlimited rights are being secured for the custom code and that the code is actually delivered.</p>
<p>Agencies should not give up unlimited rights to government reuse of the segment of the solution involving custom code unless an appropriate basis is established for doing so. One such basis may exist if the custom code qualifies as a minor modification to commercial computer software, which by law and regulation is considered a commercial item in which the government takes restricted rights. Another such basis may be the negotiation of Government Purpose Rights, as defined in the DFARS.</p>
<h3><a id="Contract_Administration_110"></a>Contract Administration</h3>
<p>After contract award, agencies should watch for unauthorized or incorrect markings that seek to limit the Government's rights, such as by limiting reuse rights to the acquiring agency, and agencies should take advantage of the procedures provided in FAR 27.404-5 to cancel such markings.</p>
<p><strong>GLOSSARY</strong></p>
<table class="table table-striped table-bordered">
<tbody>
<tr>
<td>Data</td>
<td>"Data" means 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 52.227-14 (a)]</td>
</tr>
<tr>
<td>Computer software</td>
<td>"Computer software" means (i) Computer programs that comprise a series of instructions, rules, routines, or statements, regardless of the media in which recorded, that allow or cause a computer to perform a specific operation or series of operations; and (ii) Recorded information comprising source code listings, design details, algorithms, processes, flow charts, formulas, and related material that would enable the computer program to be produced, created, or compiled. Does not include computer databases or computer software documentation. [FAR 52.227-14 (a)] <br /><br />"Computer software" means 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 252.227-7014(a)(4)]</td>
</tr>
<tr>
<td>Unlimited rights</td>
<td>"Unlimited rights" means the right of the Government to use, disclose, reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, in any manner and for any purpose, and to have or permit others to do so. [FAR 52.227-14 (a)] <br /><br /> "Unlimited rights" means rights to use, modify, reproduce, perform, display, release, or disclose technical data in whole or in part, in any manner, and for any purpose whatsoever, and to have or authorize others to do so. [DFARS 252.227-7014(a)(16)]</td>
</tr>
<tr>
<td>Government purpose rights</td>
<td>"Government purpose" means any activity in which the United States Government is a party, including cooperative agreements with international or multi-national defense organizations or 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. "Government purpose rights" means the rights to— (i) Use, modify, reproduce, release, perform, display, or disclose computer software or computer software documentation within the Government without restriction; and (ii) Release or disclose computer software or computer software documentation outside the Government and authorize persons to whom release or disclosure has been made to use, modify, reproduce, release, perform, display, or disclose the software or documentation for United States government purposes.[DFARS 252.227-7014(a)(11-12)]</td>
</tr>
</tbody>
</table>