This article is the third installment in a series on Data Rights in Federal Contracts. We first wrote about what data rights were; then about technical data and how to protect it; and now we will discuss ownership, license rights, and the protection of rights in non-commercial computer software. Because non-commercial computer software is treated like non-commercial data under the FAR (a topic discussed at length in the prior installment of this series), we will focus now on how non-commercial software is treated under the DFARS. That said, the general principles discussed herein also apply to software under the FAR so contractors working for civilian agencies should take note as well.
First, “computer software” is defined as “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.” See DFARS 252.227-7014(a)(4). And the definition does not include computer databases or computer software documentation—those are treated somewhat differently. For such computer software to be non-commercial it must not (1) have been sold, leased, or licensed to the public; (2) offered to the public for such purposes; (3) be available for commercial sale, lease, or license in time to satisfy the contract requirements; or (4) satisfy any of the elements in 1-3 above and require only minor modification to meet the government’s requirements. If you do not meet these requirements or the definition of “computer software,” the Intellectual Property (“IP”) related to the items you produce would fall under separate FAR or DFARS clauses.
Second, as a general rule, it is critical to note that the government should never take ownership or attempt to take ownership over any IP, including non-commercial computer software. I have seen a number of procurements where the government states something like: “because this software is non-commercial software developed solely with funds under this contract, pursuant to DFARS 252.227-7014, such software is owned by the government.” This assertion, however, is patently false. Neither DFARS 252.227-7014, nor the similar FAR provisions, grant title to non-computer software, or any IP for that matter, to the government, regardless of whether the government paid for the software or its development. Instead, the title/ownership rights to the non-commercial software remains squarely in the hands of the contractor who developed the software. The government only gains certain license rights to use the software. This is similar to when a consumer buys Microsoft Word or Adobe Photoshop, that consumer does not own the Microsoft or Adobe code, it merely purchases a license to use the software according to the terms of the software license given, i.e., the text that pops up when you install software and you accept but you never actually read.
Like any consumer, the government can use the software in various ways depending on the license it is given based upon the requirements of the FAR and DFARS, but the applicable regulations do not provide any mechanism for the government to take actual ownership. This is due to the long-standing public policy that the government ownership of IP keeps that IP out of the broader economy and is a waste of resources that could otherwise be used to both grow the gross domestic product of the country, as well as lead to other advances that would be squandered if title rested with the government itself.
When it comes to the types of rights the government can be given for non-commercial computer software, generally they fall into three categories: (1) unlimited rights; (2) government purpose rights; and (3) restricted rights. The way each of these rights is assigned and the implications are the same as we discussed in the last installment of our Data Rights in Federal Contracts series. However, take note that, for computer software, “restricted rights” are generally the same as “limited rights” when it comes to technical data. Thus, all of what was discussed under “limited rights” in the last installment applies here to “restricted rights” software. The difference in regard to all of these license rights is that, instead of using the technical data legends, contractors developing software would have to use the legends found in DFARS 252.227-7014 in order to assert any restriction on the government’s rights. The failure to use the proper legend can lead to a waiver of rights and grant the government unlimited rights in your software, even if developed entirely at private expense. Thus, the contractor could inadvertently give the government a right to provide source code developed by a contractor at their own expense to another contractor who could then compete for work using that same code. Clearly, that would be a horribly inequitable result but one that could occur under the plain language of the DFARS. While the CO can allow a contractor to correct a non-conforming legend—say if the FAR legend is used on a DOD contract instead of the DFARS legend—the CO is not required to allow such a correction. Thus, it is important to get the legend right the first time.
For computer software, we recommend putting that legend in numerous places to ensure there is no question as to what items the contractor is asserting a restriction of the government’s rights. The key places for the legend would be on any physical media you deliver to the government, within any End User License Agreement pop-up language used in the software, and within the source code itself. This is especially important if parts of the code were developed at private expense while other parts were developed purely at government expense under the current contract. In those cases, you could restrict the government’s rights to use the portions of the source code that you developed at private expense and, in so doing, perhaps end up restricting the government entirely as the fully-integrated software likely relies upon the restricted rights elements to function. So, always remember that software restrictions can be placed on source code at the lowest practicable level of usability. Therefore, if you have code that was developed at private expense and can function independently, but the government is asking for you to add modules and the like, you can restrict that initial software element.
Lastly, you should always look carefully at the specific terms and clauses put in your contracts. Many times the DOD will include a requirement that the offeror, in its proposal, designate the specific items in which it plans to assert restricted rights or government purpose rights and that, if the items are not listed in the proposal, then the ability to restrict the rights to certain items can be waived. While the government can allow you to assert rights after award, they do not have to do so, especially if the government asserts that the assertion of rights would alter the award determination or where it would otherwise prejudice the government. Because of this, it is always a best practice to identify each item and to assert rights in the proposal itself to avoid conflicts and possible terminations for default.
About the author: Cy Alba is a partner with PilieroMazza and is a member of the Government Contracts and Small Business Programs Groups. He may be reached at ialba@pilieromazza.com.
