Technology companies have numerous opportunities to work with federal agencies as they innovate new platforms and processes. Contrary to popular opinion, the federal government generally is not looking to take contractors’ intellectual property.
Since most major technological developments today occur in the private sector, agencies recognize they must respect contractors’ IP to ensure their continued participation in the government marketplace.
But there are traps for the unwary. Failure to comply with federal IP rules can inadvertently give the government greater rights than anticipated. It’s critical, therefore, that contractors understand what rights the federal government may have to their IP and how best to protect their interests.
Extent of Access
There is no one-size-fits-all approach to the federal government’s rights in contractors’ IP. The nature and extent of the government’s rights varies depending on what type of IP is at issue—different rules govern inventions and patentable IP, software, and technical data.
The rules also differ depending on the type of agreement, including contracts, grants, cooperative agreements, Small Business Innovation Research awards, and other transaction agreements (OTAs). Likewise, commercial and non-commercial IP items are often treated differently.
Additionally, government customers may impact the nature of the rights they will seek from contractors. Generally, Department of Defense agencies are interested in obtaining IP rights sufficient to maintain and operate the technology in the future, and civilian agencies are interested in publishing the results of their work.
The federal government’s financial contribution to the IP’s development also affects the rights it will likely receive. Generally, the more money and resources the government contributes to the IP’s development, the more rights the agency will expect in return.
Federal Rights in IP
When a federal agency obtains rights in a contractor’s IP, it generally comes in the form of a non-exclusive license. These licenses are broad, granting the right to use, modify, reproduce, release, perform, or disclose the IP within the federal government. The ability to exercise those rights outside the government is typically driven by whether the government, the contractor, or both funded the IP’s development.
If the government paid all the development costs, generally it can give the information to any third party, for any purpose, including to the contractor’s competitors for commercial purposes. On the other hand, if the contractor paid all the development costs, the government’s ability to release the information outside the government is generally very limited. If the funding was mixed, then the government can usually give the IP to third parties to use for strictly governmental purposes.
The federal government’s rights in software depends on whether the software is commercial or non-commercial. Commercial software is computer software that has been sold or licensed—or offered for sale or license—to the public for non-governmental purposes. Typically, the government obtains only a standard commercial license to commercial software, though provisions that conflict with federal law must be removed.
Non-commercial software is used only for government purposes. It often has aspects of commercial software integrated into the overall product. The part of the software that was funded by the government for non-commercial software can generally be segregated from the strictly commercial software.
Protecting IP and Data Rights
Contractors should take appropriate steps to ensure they don’t unwittingly give the government more IP rights than necessary. First, contractors should read the relevant solicitation and contract terms to understand what rights the government expects to receive under the contract.
For most government contracts, these rights are non-negotiable and are established by standard or defense federal acquisition regulation clauses. In others, especially for OTAs, the parties’ rights can be negotiated and tailored to the specific circumstances.
Once the contractor has agreed to the government’s terms, there are three key things to keep in mind—assertions, markings, and documentation.
Assertions are how the contractor places the government on notice that the government will be restricted in its use and disclosure of IP the contractor delivers during contract performance. This information is provided to the government prior to contract formation and can sometimes include options to expand the listed rights.
For example, DOD agencies will often ask for an assertion table that details all the rights the contractor will be giving to the government—sometimes even including commercial rights.
Next, the contractor must consistently mark the IP it delivers to the government so it matches what was included in the assertions. The required markings will depend on what type of IP and/or data is being delivered. For non-commercial software, the contractor will need to include the “magic words” required by the relevant FAR or DFARS clause in the exact spot as that specified in the contract.
Finally, the contractor must maintain sufficient documentation to support its claims that any assertion originally made to the government has been met because the burden is generally on the contractor to prove this matter in any dispute with the government.
Contractors should learn and follow the federal contracting rules to protect their investment and maximize their future business interests in the government and commercial markets.
This article does not necessarily reflect the opinion of Bloomberg Industry Group, Inc., the publisher of Bloomberg Law and Bloomberg Tax, or its owners.
John Prairie is a partner at Wiley Rein, where he helps government contractors navigate complex federal procurement issues.
Scott Felder is a partner at Wiley Rein, and focuses on complex intellectual property issues confronted by government contractors.
Lisa Rechden is an associate at Wiley Rein, where she counsels and represents government contractors and subcontractors.
Write for Us: Author Guidelines