PDF Version

This article focuses on contractor licenses that grant “Restricted Rights” in “Noncommercial Software” to the federal Government under Defense Federal Acquisition Regulation Supplement (“DFARS”) 252.227-7014.  DFARS 252.227-7014 only applies to “Noncommercial Computer Software,” meaning software that is licensed to or developed for the Government, but that is not also licensed to the public.  In contrast to the commercial world, where software licensors generally set the terms under which they wish to license their products, DFARS 252.227-7014 dictates such terms, and codifies required license grants for software developed for the U.S. Department of Defense (“DoD”).  Under DFARS 252.227-7014, even if a licensor develops Noncommercial Software at private expense, the licensor must at least grant Restricted Rights to the Government — although title and ownership of the software always remain with the contractor licensor.

Given the complexity of modern software in its many forms, and the myriad ways for creating software, this regulation faces several challenges.  For one thing, the regulatory language reflects very old development paradigms, and it is not easy to update the language frequently to keep it current with modern techniques.  Second, the regulation may be at odds with the Government’s general policy of encouraging private expense development of software for Government use, because it conflicts with licensors’ natural desire to protect their source code IP.  Finally, relatively recent hosting schemes involving Software as a Service (“SaaS”) and virtual machine (“VM”) environments may not fit comfortably within the regulatory language.

Overview

Within the ambit of the term “Noncommercial Computer Software,” DFARS 252.227-7014 further categorizes software that is developed 1) exclusively with Government funds, 2) exclusively at private expense, or 3) with a mixture of Government funds and private expense.  The regulation establishes the particular rights that a contractor must grant to the Government, based on this funding categorization.  This results in four sets of rights that apply to Noncommercial Computer Software:

• Unlimited Rights.  This grant of rights applies to software developed exclusively with Government funds.  Under a grant of Unlimited Rights, the Government can exercise the rights to use, modify, reproduce, release, perform, display, or disclose the software to anyone without restriction.  The Government gains all rights in the software, short of actual ownership.

• Government Purpose Rights.  This grant of rights applies to software developed with mixed Government and private funds.  Under a grant of Government Purpose Rights, the Government can exercise the rights to use, modify, reproduce, release, perform, display, or disclose the software within the Government without restriction.  The Government may also disclose the software outside the Government, but only for limited purposes such as when the Government makes a sale to a foreign government.

• Restricted Rights.  This grant of rights applies to software developed exclusively with private funds.  Under a grant of Restricted Rights, the Government’s rights are limited, whereby the Government may i) use the software on one computer or terminal at a time, ii) transfer the software to another Government agency, iii) make minimum copies for backup, iv) modify the software only for its own use or backup, and v) allow its contractors to maintain the software.

• Special License Rights.  This grant of rights can be for any of the three categories of funding.  The specific rights granted are flexible as established by mutual agreement of the licensor and the Government, except that the Special License Rights may not be more restrictive to the Government than are the Restricted Rights.

Restricted Rights and Source Code Control

A software licensor that develops a product at its own expense will naturally be very protective of the IP pertaining to that product, and in particular the source code.  One would think that the policy of DFARS 252.227-7014 would be to incentivize developers to assume the risk and expense to produce software for Government use.  The regulation severely undercuts that incentive, however, if the developer cannot keep the source code baseline confidential.  The Restricted Rights clause thus works against a policy of entrepreneurial development by requiring that the Government must have a right to modify software developed at private expense.  Even if the contract does not expressly identify the source code as a deliverable, the Restricted Rights regime includes an implied obligation to supply the source code for software maintenance purposes.  Moreover, the contract may have deferred delivery or deferred ordering clauses that could permit the Government to capture the source code during or after contract performance.  Thus, the Restricted Rights clause is out of step with the private development world.  Further, because under DFARS 252.227-7014, the Government and contractor may not establish special license terms that can diminish the Restricted Rights clause, there is no wiggle room in the context of a contract to fully protect the contractor’s source code developed at private expense.  As counterbalance, DFARS 252.227-7014 does include some — albeit limited — protection for the licensor, in that the released source code may be subject to nondisclosure restrictions. 

As a result of the Restricted Rights clause, the Government’s right to modify the source code will cause the source code baseline to diverge.  That is, there will be at least two versions of the source code: the original baseline maintained by the contractor, and the modified baseline controlled by the Government.  To further muddy the waters, if a third-party support contractor then creates the modifications for the Government, that contractor might assert ownership rights over the modifications in the derivative work unless that contractor is carefully restricted via an NDA or other agreement that controls the rights in any modifications made to the original licensor’s software.  Thus, it seems that the only way a contractor may completely protect its investment is by making sure that the software is classified as “Commercial Computer Software” rather than “Noncommercial Computer Software.”  Under DFARS 252.227-7014, “Commercial Computer Software” is software that is developed or used for non-Governmental purposes and has been licensed or offered for license publicly.  Most importantly, Commercial Computer Software is not subject to the license grant requirements of DFARS 252.227-7014, and thus escapes any requirement to release source code.  Classifying software as Commercial Computer Software may require some advance planning, but unless the licensor builds the software in accordance with very specific Government requirements, it would seem possible to utilize at least part of the software for commercial use.  For example, if the licensor has built a tactical mapping program for military applications, such mapping software may be adaptable for commercial use.  At a minimum, the developer could abstract the code and make it modular so that the underlying libraries and utilities provide generic functions that the developer could commercially license.  That way, at least part of the software will not be subject to the release requirements of DFARS 252.227-7014 Restricted Rights.

SaaS and VM Environments

More and more software products are becoming cloud-based, and licenses need to reflect the actual underlying SaaS nature of such applications.  Licensees also popularly use multiple VMs (i.e., software-based virtual “computers”) that run on a single physical computer.  The language of DFARS 252.227-7014, in contrast, seems to contemplate earlier software delivery paradigms and environments.  For example, DFARS 252.227-7014(a)(15)(i) establishes Government rights to:

“Use a Computer Program with one computer at one time.  The program may not be accessed by more than one terminal or central processing unit or time shared unless otherwise permitted by this contract”

This language seems to harken back to the 1980s, when software was delivered as self-contained “shrinkwrap” products for use on one computer at a time, or as mainframe stand-alone products accessed by simple “dumb” terminals or time-shared.  Such language is awkward when referring to SaaS products that are accessed by multiple browsers simultaneously via individual user accounts.  The language also does not fit nicely with VM environments where one multi-CPU computer may host a number of virtual computers, each of which can run its own copy of the software. 

Thus, there is a need for license provisions that reflect the reality of the underlying software implementation and hosting environment.  For example, a licensor may wish to offer subscription licenses for software that it hosts on a remote server computer that is accessible to the Government users via the Internet.  The DFARS 252.227-7014 Restricted Rights clause includes no provisions that expressly permit that licensing option.  A concept like “use on one computer at a time” might be better stated as “use via a single, named user account.”  Likewise, the DFARS 252.227-7014 Restricted Rights clause includes the right to transfer software to another Government agency, and may not make sense for SaaS software.  What would be better would be a provision to allow the transfer of user account(s) to another Government agency.  Licensors could probably work around the DFARS 252.227-7014 language via a Special License Rights agreement with the Government; however, we suggest that it is time to update the Restricted Rights language in light of modern practices.

The use of hosted SaaS software is also problematic with regard to the DFARS 252.227-7014 requirement for the Government or its support contractors to have the right to modify the software and its source code.  If the system is actually hosted on a licensor remote server, then it would certainly be difficult for the Government or its support contractors to take charge of modifying the remotely hosted software.  The language of DFARS 252.227-7014 simply does not contemplate this type of hosting environment.

Software Markings

Section DFARS 252.227-7014(f) requires that all software that is licensed with restrictions (i.e., with Government Purpose Rights, Restricted Rights, or Special License Rights) must be marked with particular legends that are specified in the regulation.  Failing to mark deliverable software with such legends may cause the licensor to lose its licensing restrictions, effectively creating a grant of Unlimited Rights.  Therefore, it is critical to adhere to the marking requirements, even if the software is a SaaS product hosted by the licensor (that the licensor does not even physically deliver to the Government).  One way to handle this for SaaS products is to mark the legend on the opening home page of a web application when accessed by a user browser.  Nonetheless, to adhere to DFARS 252.227-7014, all types of products must be marked with the legends, preferably on both the source code and object code copies of the software (wherever physically installed).  Finally, we note that restricted software with the above markings must also be specifically listed in an attachment to the contract between the licensor and the Government.  Licensors must be aware of these rules or risk losing valuable ownership rights in their products.

Third-Party Libraries

In modern software development, it is rare that software developers create 100 percent of their products with in-house components.  More often, the final products include embedded third-party libraries in the final deliveries made to the Government.  Though the entire product development is still at private expense, the contracting licensor may not be able to offer the licensing of such third-party libraries to the Government under Restricted Rights.  It is axiomatic that one cannot license rights that one does not own, and thus third-party libraries are governed by their own licenses.  Because the third-party libraries are most likely commercial products, however, this may not ultimately be a critical issue, and the libraries may be excluded from the Restricted Rights clause as discussed above.  This must be made clear in the software license, though, and all components that cannot be subject to the Restricted Rights clause must be clearly identified, as should any alternative license provisions for such components.  DFARS 252.227-7014(d) states that the contractor must provide a statement of the license rights obtained for such third-party software in a form acceptable to the Government.

Observations and Practical Tips

New regulatory language would be the best way to ameliorate the above-referenced deficiencies.  Until that happens, however, the problems may be remedied both with software design strategies and careful legal advice.  As noted, the entire DFARS 252.227-7014 Restricted Rights issue may be avoided by classifying the software as Commercial Computer Software (which the DoD is bound to acquire under standard commercial computer licenses with limited exceptions under DFARS 227.7202).  Thus, developers should look for commercial applications for their products, and should also abstract generic library functions so that they might be offered to the public as separate commercial modules.  On the legal side, to the extent possible, licensors should negotiate with the Government to establish Special License Rights regimes to avoid issues arguably arising from archaic DFARS 252.227-7014 language.  This is particularly true for SaaS products, where specially negotiated contract clauses could establish Government rights that make sense, and where the parties expressly agree that the rights granted do not create restrictions that are in excess of the permissible limits of Restricted Rights.  For example, grants of rights for individual named users could be argued as equivalent to the single-use restriction of DFARS 252.227-7014, thus protecting the licensors as much as possible and promoting the private development of cloud-based software.