Data Rights in Federal Contracts, in Plain Language

A first federal contract gets read for the price and the schedule. The paragraphs that decide who can do what with the drawings, the source code, and the test results usually get skimmed. Two years later the agency reissues the work as a competitive follow-on, hands your interface drawings to the bidder who undercuts you, and the question stops being academic.

Data rights are not complicated so much as unfamiliar. There are four standard license categories, two kinds of deliverable, one question about who paid for the development, and a set of steps that have to happen at specific moments. Miss the moment and you lose the protection, even when the underlying facts were entirely on your side.

The rules below are the Department of Defense rules, because DoD writes the most detailed ones and most first-time technology vendors meet them first. Civilian agencies use a simpler framework, covered near the end. None of this is legal advice for a specific contract. Read the clauses in your own award, and get counsel before you assert anything you would be unhappy to lose.

Rights are a license, not ownership

The single most common misunderstanding is that delivering technical data to the government transfers ownership of it. It does not. DFARS 227.7103-4 is explicit: the government obtains its rights through an irrevocable license granted by the contractor, and the contractor retains every right not granted. You still own the data. What the contract negotiates is the size of the government's license.

Patents run in a separate lane. Under Bayh-Dole, 35 U.S.C. 200-212 and 37 CFR 401, a small business generally keeps title to inventions made under a federal award if it discloses the invention within two months of the inventor reporting it internally and elects title within two years of that disclosure. The government keeps a nonexclusive, irrevocable, paid-up license to practice the invention worldwide. Patents cover the invention; data rights cover the recorded information. A vendor can hold a clean patent and still hand over a license to the drawings that lets a competitor build the thing.

Technical data and computer software are two different things

The DFARS splits deliverables into two families and gives each its own clause. Getting the family wrong produces the wrong legend, and the wrong legend is a defect the contracting officer can act on.

Technical data means recorded information of a scientific or technical nature, regardless of how it is recorded. Drawings, specifications, test reports, analyses, interface control documents, and software documentation all count. It does not include computer software itself, and it does not include information incidental to contract administration such as invoices and management reports. The governing clause is DFARS 252.227-7013, Rights in Technical Data.

Computer software means the programs, source code, object code, design details, algorithms, processes, flow charts, and related material sufficient to reproduce, recreate, or recompile the software. The governing clause is DFARS 252.227-7014, Rights in Noncommercial Computer Software and Noncommercial Computer Software Documentation.

Note where the documentation lands. Software documentation, meaning user manuals, installation instructions, and operating instructions, is technical data and travels under the data clause even though the thing it describes travels under the software clause. A team that delivers an installation guide with a restricted rights legend on it has used a software legend on a data deliverable.

The four license categories

Both clauses grant the government one of the same handful of licenses. Here is what each one actually permits.

Category	When it applies	What the government may do
Unlimited rights	Development funded exclusively by the government. Also applies regardless of funding to certain named categories.	Use, modify, reproduce, release, perform, display, or disclose in whole or in part, in any manner and for any purpose, and authorize others to do the same.
Government purpose rights	Development funded partly by the government and partly at private expense (mixed funding).	Anything inside the government without restriction. Outside the government only for government purposes, which includes releasing the package to competitors in a reprocurement. Commercial use is excluded.
Limited rights (technical data only)	Technical data pertaining to items, components, or processes developed exclusively at private expense.	Use within the government only. No release outside the government without the contractor's written permission, except for narrow carve-outs such as emergency repair or overhaul and release to a covered government support contractor under a non-disclosure agreement.
Restricted rights (software only)	Noncommercial computer software developed exclusively at private expense.	Use on one computer at a time, minimum backup and archive copies, modification or combination with other software, transfer to another government agency with notice, and disclosure to support service contractors under non-disclosure.
Specifically negotiated license rights	Any time the parties agree to something other than the standard categories.	Whatever the parties write down. The government may not accept less than the minimum rights it is entitled to in the always-unlimited categories.

Two details in that table carry most of the practical weight.

First, government purpose rights expire. Under both clauses the standard term is five years from the date the contract is executed, unless the parties negotiate a different period, and at the end of that term the license converts to unlimited rights automatically. Five years is a negotiable number and it is negotiated far less often than it should be.

Second, some data are unlimited no matter who paid, and DFARS 252.227-7013 lists them. The list covers form, fit, and function data; data necessary for installation, operation, maintenance, and training, other than detailed manufacturing or process data; corrections to government-furnished data; data already public without restriction; and studies, analyses, and test results delivered under the contract. Your internal manufacturing process can stay protected. The interface dimensions and the maintenance manual generally cannot.

What "developed at private expense" actually means

The DFARS defines developed exclusively at private expense as development accomplished entirely with costs charged to indirect cost pools, costs not allocated to a government contract, or any combination of the two. Independent research and development and bid and proposal costs sit in indirect pools, so work funded through IR&D counts as private expense even though those pools are recovered as allowable indirect costs on government contracts. That result surprises people every time, and it is settled.

"Developed" has its own definition and it is lower than most engineers assume. An item, component, or process is developed when it exists and its workability has been established, meaning it has been analyzed or tested enough to show a person skilled in the art a high probability that it will work as intended. Software is developed when it has been successfully operated and tested to the same standard. You do not need a production-qualified article. You need a demonstrated one.

The most useful planning rule here is that the funding determination is made at the lowest practicable segregable portion of the item, component, process, or software, not across the deliverable as a whole. A system delivered under a government contract is not automatically a government-funded system. A module built entirely on internal funds before the award keeps its private-expense status even when it ships inside a government-funded system. That is why serious vendors keep a component-level ledger recording, for each module, what funded it and when workability was established.

Asserting restrictions before award

Restrictions are not self-executing. The solicitation provision DFARS 252.227-7017, Identification and Assertion of Use, Release, or Disclosure Restrictions, requires an offeror to submit a table with its proposal listing everything it intends to deliver with less than unlimited rights. The table has four columns:

1. Technical data or computer software to be furnished with restrictions. Identify the item, component, process, or software with enough specificity that a reader knows exactly what is covered.
2. Basis for assertion. Usually "developed exclusively at private expense" or "developed with mixed funding," stated plainly.
3. Asserted rights category. Limited rights, restricted rights, government purpose rights, or a specifically negotiated license.
4. Name of person asserting restrictions. The entity claiming the restriction, which may be you, a subcontractor, or a supplier.

The successful offeror's table is attached to the contract and becomes the baseline for what may lawfully be marked. The deadline is real: assertions are due before award. After award, an assertion can be added only if it is based on new information or on an inadvertent omission that would not have materially affected the source selection decision, and the contracting officer decides that question. A vendor that forgot to list its core algorithm on the pre-award table is arguing for an exception rather than exercising a right.

Two related habits belong here. Subcontractor and supplier assertions flow up, so ask for them during teaming rather than during proposal week. And proposals themselves carry protection: FAR 52.215-1(e) prescribes the restrictive legend for use and disclosure of proposal data, and DFARS 252.227-7016 governs the government's rights in bid or proposal information. Use the prescribed text, not a homemade legend.

Markings, and the cost of getting them wrong

An assertion establishes the claim. The marking on the delivered file is what enforces it, and the clauses authorize specific legends and no others. Each legend has required fields: the contract number, the contractor name and address, and, for government purpose rights, the expiration date of the period. The SBIR legend adds the expiration of the protection period.

There are two distinct failure modes and they carry different consequences.

A nonconforming marking is one that is not in the authorized form. Homemade legends, corporate "proprietary" stamps, and confidentiality footers pulled from a commercial NDA all qualify. Under DFARS 252.227-7013 the contracting officer notifies the contractor, and if the contractor does not correct or remove the marking within 60 days, the government may ignore it or correct it at the contractor's expense.

An unmarked delivery is worse. Data delivered without a restrictive legend may be treated as delivered with unlimited rights. The cure is narrow: the contractor may ask the contracting officer for permission to add the omitted legend at its own expense, generally within six months of delivery, and only where the omission was inadvertent, the legend is one the contract authorizes, and adding it will not prejudice the government. Once the file has circulated, that last condition is where the request usually fails.

The other side of the coin is DFARS 252.227-7025, which restricts what you may do with government-furnished data bearing someone else's restrictive legend. And DFARS 252.227-7030, Technical Data, Withholding of Payment, gives the contracting officer a payment lever when delivered data do not conform to the contract's requirements.

When the government challenges your marking

The government can dispute an assertion. The process is set out in DFARS 252.227-7037 for technical data and DFARS 252.227-7019 for computer software, and it starts with a written challenge notice from the contracting officer stating the grounds for questioning the restriction.

You then have 60 days to respond with a justification supported by evidence of who funded the development. Silence is not neutral: if the contractor does not respond, the contracting officer may issue a final decision and strike the marking. If you respond and the challenge is still sustained, the decision is appealable through the normal disputes route, and the marking generally stays in place while the appeal is pending.

There is a limit on the government's side. As a general rule it may not challenge a restrictive marking more than three years after final payment under the contract or three years after delivery of the data, whichever is later, with narrow exceptions such as fraud. The evidence you would need in year three is the same component-level funding record described above.

SBIR data rights and the protection period

SBIR and STTR awards get their own category, historically implemented at DFARS 252.227-7018. During the protection period the government's rights in data and software generated under the award look much like limited and restricted rights: internal government use, emergency repair or overhaul, and release to covered government support contractors under non-disclosure, but no release to your competitors and no commercial use.

The length of that period changed and the change is the thing to get right. The SBA SBIR/STTR Policy Directive sets the protection period at 20 years from the date of award of the funding agreement. Older DFARS clause text ran five years from completion of the project under which the data were generated, and legacy clause language still circulates. Read the clause version actually incorporated into your award rather than assuming either number.

What happens at expiration is worth checking in the same reading. The SBA Policy Directive describes a royalty-free license for government purposes after the period ends. Older DoD clause text converted the government's rights to unlimited at expiration. These are meaningfully different outcomes for a company whose product is still selling in year 21.

Civilian agencies and commercial products

Outside DoD the framework is FAR Part 27 and the clause is FAR 52.227-14, Rights in Data, General. The default is unlimited rights in data first produced in performance of the contract, and there is no government purpose rights category in the FAR baseline. Protection for privately funded material exists only when the contracting officer includes Alternate II for limited rights data or Alternate III for restricted computer software, and only for material properly identified and listed. If those alternates are missing from your solicitation, raise it before proposals are due, not at delivery. Agencies including NASA and the Department of Energy add their own supplements on top.

Commercial products are treated differently again, and generously. For commercial computer software, FAR 12.212 and DFARS 227.7202 direct the government to acquire under the license customarily provided to the public, and not to demand more unless that license fails to meet its needs. For commercial technical data, DFARS 252.227-7015 gives the government unlimited rights only in the categories the clause names, such as form, fit, and function data and operation and maintenance information, with the rest governed by the customary license.

One current wrinkle: clause numbers are moving. Under the Revolutionary FAR Overhaul, agencies have been adopting revised clause text by deviation, and in the Department of Defense SBIR solicitation the assertions provision now appears as DFARS 252.227-7992 in place of 252.227-7017, with the SBIR data rights clause and its legend renumbered alongside it. The substance tracks the rules described here, but the citation may not match the one you memorized. Read the clause numbers in the solicitation in front of you.

A working checklist

For a vendor bidding federal technology work, this is the sequence that keeps rights intact.

1. Read the data rights clauses before you price the bid. They sit in Section I, and what they demand can change your cost and your teaming plan.
2. Check what the contract data requirements list actually orders. The CDRL, not the clause, sets which data you must deliver. Fewer deliverables means fewer things to protect.
3. Keep a component-level funding ledger. For each module, record what funded it and the date workability was established. Maintain it during development, not during a challenge.
4. File the assertions table with the proposal. Be specific about scope, and collect subcontractor assertions before proposal week.
5. Negotiate the government purpose rights term when it applies. Five years is the default, not a fixed rule.
6. Mark with the prescribed legend and fill in every field, including the expiration date where the legend calls for one.
7. Build the legend into the build. Put the marking in the file header, the report template, and the release pipeline, so a deliverable cannot be produced without it.
8. Answer a challenge notice inside 60 days. Silence forfeits the marking.
9. Watch for deferred ordering. DFARS 252.227-7027 lets the government order data generated during performance well after delivery, and that data carries the license category its funding earned.
10. Diary the expiration dates. Government purpose rights terms and SBIR protection periods both end on a date, and knowing when is part of knowing what your company still controls.

None of this requires a law degree. It requires knowing that the questions exist, answering them in the order the acquisition process asks them, and keeping records at the granularity the rules use. Vendors who lose rights rarely lose an argument. They miss a table, a legend, or a deadline.