Data Rights for Software Companies: What the Government Gets When It Buys Your Code

A federal agency can buy your software, pay for custom work on top of it, and still leave you owning the code. Or it can end up with the right to hand your source code to a competitor for the next contract. Which outcome you get is decided by the data rights clauses in the contract, how your code was funded, and whether you asserted and marked your rights before you delivered anything.

This guide covers the difference between commercial and noncommercial software, the rights categories under the FAR and the DFARS, the assertion and marking rules that protect you, and SBIR data rights. It is written for SaaS and software companies, where the core product is usually commercial and the risk sits in custom work and deliverables.

---

Commercial software is bought under your license

If your product is sold to the public, it is commercial computer software, and the default rules favor you.

Civilian agencies. FAR 12.212 says commercial computer software and documentation are acquired under licenses customarily provided to the public, to the extent those licenses are consistent with federal law and meet the government’s needs. FAR 27.405-3 points to the clause at FAR 52.227-19 when commercial software is acquired outside FAR Part 12.

Department of War (DoW). DFARS 227.7202-1 sets the same default, and adds that the contractor is not required to furnish technical information related to commercial software that it does not customarily provide to the public, or to relinquish or be forced to relinquish rights, except for a narrow set of items such as correction or change information the government paid for.

The catch is “consistent with federal law.” Terms like state governing law, automatic renewal, unilateral price changes and broad indemnities don’t bind the government, so your license is accepted with those parts removed. See software license terms in federal contracts for the clauses that conflict and how to write a federal addendum.

---

Noncommercial software: the funding test

Custom code written under the contract, such as integrations, adapters, a bespoke module or a government-only build, is usually noncommercial. For noncommercial software, rights follow who paid for development.

On DoW contracts, DFARS 252.227-7014 sets the categories:

Rights category	When it applies	What the government can do
Unlimited rights	Developed exclusively with government funds	Use, modify, reproduce, release and disclose it in any manner and for any purpose, including to other contractors
Government purpose rights	Developed with mixed funding	Use it within the government without restriction and release it to others for government purposes; converts to unlimited rights after five years unless another period is negotiated
Restricted rights	Developed exclusively at private expense	Use it on one computer at a time, make backup copies, modify it, and release it only in limited cases such as to support contractors under nondisclosure terms
Specifically negotiated license rights	Any, by agreement	Whatever the parties write down, as long as it is not less than limited or restricted rights

“Developed exclusively at private expense” is applied at the lowest practicable segregable level: a component, a module or a subroutine, not the whole product. If you build a new module on contract time and charge it to the contract, that module can carry government purpose or unlimited rights even though the platform under it stays restricted.

Civilian agencies use FAR 52.227-14, Rights in Data—General. Under that clause the government gets unlimited rights in data first produced under the contract, and the contractor may withhold restricted computer software and deliver form, fit and function data instead unless the contract includes Alternate III, which sets out the restricted rights the government receives when such software is delivered.

---

Assert before award

On DoW contracts, the place to protect privately developed code is the proposal. DFARS 252.227-7017 requires offerors to list, in an attachment, the noncommercial computer software and technical data they intend to deliver with less than unlimited rights, with the basis for each assertion and the rights category asserted.

That list becomes part of the contract. Items left off it are hard to protect later: after award, DFARS 252.227-7014 allows new assertions only for new information or inadvertent omissions that would not have materially affected the source selection.

A useful assertion list names the item at a segregable level, says how it was funded, states the rights category, and identifies who asserts the restriction. “Our platform” is not a useful entry; “ingest pipeline module, developed at private expense 2023–2025, restricted rights” is.

---

Mark every deliverable

An assertion only protects you if the delivered item carries the matching legend. DFARS 252.227-7014(f) prescribes the restrictive markings for each rights category, and the marking has to appear on the software and its documentation as delivered, including source files and media.

Unmarked noncommercial software delivered to DoW is presumed to be delivered with unlimited rights. Under DFARS 227.7203-10(c), you can ask the contracting officer for permission to add omitted markings within six months after delivery, but the government is not liable for any release or disclosure that happened before the markings were added. Add marking to your release checklist the same way you add a version tag.

---

Your assertion can be challenged

A rights assertion is the contractor’s statement about how something was funded. The government can test it. DFARS 252.227-7019 lets the contracting officer request written justification for an asserted restriction on computer software, and, if the justification is not adequate, challenge the assertion and issue a decision. The contractor bears the burden of showing the software was developed at private expense, and a challenge decision can be appealed under the Disputes clause.

That means the evidence matters as much as the legend: timesheets, commit history, project accounting and dated design documents that show which work was funded internally. Keep them by component, so you can show what you built before the contract and what you built on it.

The same distinction runs through all federal work: what a company asserts about itself is not the same as what has been checked. See verified vs. self-attested: what federal buyers actually check.

---

SBIR and STTR data rights

Software and technical data generated under an SBIR or STTR award get their own protection. During the protection period, the government generally may use SBIR data for government purposes but may not release it outside the government except in limited circumstances. The SBA SBIR/STTR Policy Directive sets the protection period at 20 years from the date of award. DoW uses DFARS 252.227-7018 for SBIR data rights; civilian agencies use their own SBIR rights clauses.

SBIR data rights are one reason a Phase I or Phase II award can be strategically valuable to a software company beyond its dollar size. See SBIR and STTR for software companies.

---

SaaS changes the question

When the government subscribes to a hosted service, it usually receives access, not a copy of the code, so there is often no software deliverable to which the data rights clauses attach. The questions that matter shift to:

• Government data. Who owns the data the agency puts into your service, and how it is returned or destroyed at the end of the contract. Agencies generally expect to own their data, and your terms should say so.
• Deliverables around the service. Configuration scripts, integration code, reports and documentation you deliver can still be data or software under the contract, and the rights clauses apply to them.
• Custom features. If the agency pays you to build a feature that you then ship to every customer, decide up front how it is funded and what rights are asserted, rather than finding out at the next recompete.

Data handling obligations such as FedRAMP authorization and DFARS 252.204-7012 for covered defense information sit alongside these rights terms; they govern security, not ownership.

---

Other transactions are negotiated

Other transaction agreements are not procurement contracts, so the FAR and DFARS data rights clauses do not apply by default. Intellectual property terms are whatever the agreement says. That flexibility cuts both ways: you can negotiate stronger protection than the DFARS default, and you can also sign away more than you would under a FAR contract if you don’t read the IP article closely.

---

What this means for a software company

• Treat your core product as commercial and sell it under your commercial license with a federal addendum.
• Segregate custom work. Build contract-funded code as separable modules, so the funding of each is clear.
• List every restricted item in the DFARS 252.227-7017 attachment before award, at the component level.
• Mark every delivery with the correct DFARS or FAR legend, including source files and documentation.
• Keep funding records by component so you can answer a validation request.
• Read the IP article of any OTA or nonstandard agreement line by line.
• Read the current rule text. The FAR is being rewritten under the Revolutionary FAR Overhaul, and DFARS data rights rules change through deviations and final rules. Confirm the clauses in your contract and involve government contracts counsel before you sign or deliver.

---

Where this fits

Data rights are set at award, so they belong in your proposal review alongside contract types and license terms. They come back at contract modifications that add custom work, and at recompetes, where an incumbent’s code and documentation may be handed to whoever wins next.

Score your company’s federal readiness to see how your contracts and compliance profile look next to the other categories federal buyers review.

---

Related reading

• Software License Terms in Federal Contracts: What Agencies Can’t Sign
• FAR Part 12 for Software Companies: Selling Your Product as a Commercial Product
• SBIR and STTR for Software Companies: Funded R&D as a Federal Entry Point
• Recompetes and Incumbent Transitions for Software Companies: How Follow-On Contracts Work
• Glossary: SBIR · OTA · DFARS 252.204-7012