The trouble with the federal source code policy, and what to do about it: Part Three
This is the third in a four-part series looking at the federal source code policy. Read Part One and Part Two.
In the last post, we covered why OMB should have adopted an open-by-default approach for custom-developed code. In this post, I explain why existing regulations get us most of the way to a better policy. [Warning: this post involves wonky discussions of procurement regulations.]
The “odd” definition of custom-developed code
At the heart of the federal source code policy is the idea of sharing custom-developed code. Indeed, one of the stated objectives of the policy is to:
Require agencies to obtain appropriate Government data rights to custom-developed code, including at a minimum, rights to Government-wide reuse and rights to modify the code.
Take a moment and think through what “custom-developed code” means. To me, it implies a few things: (1) an existing solution doesn’t exist; (2) the new solution is meeting a particular need for the government customer; and (3) the government customer’s paying for it.
The definition in the first draft of the federal source code policy got it pretty close: “Software source code that is written to fulfill a specific purpose that is not already addressed by existing programs or COTS solutions. For the purposes of this policy, custom code development must be fully funded by the Federal Government and is either developed by a contracting entity for use by the Federal Government, or developed by covered agency employees in the course of their official duties.”
Existing solution doesn’t exist? Check. New solution meeting a particular need for the government customer? Check. Government customer’s paying for it. Check.
But that’s not what found its way into the final version of the policy. Instead, the final version reads: “custom-developed code is code that is first produced in the performance of a Federal contract or is otherwise fully funded by the Federal Government[; or] code developed by agency employees as part of their official duties.”
Existing solution doesn’t exist? Kinda. New solution meeting a particular need for the government customer? Sorta. Government customer’s paying for it. Check.
You may wonder why OMB went with this funky definition of “custom-developed code.” To answer that requires discussion of the existing Federal Acquisition Regulation’s (FAR) rules on Unlimited Rights in Data.
Unlimited Rights in Data and the FAR
The FAR is a very, very long document that covers the rules of the road for federal procurement. In those rules, the FAR establishes contract “clauses” that need to be included in certain federal contracts. One of those clauses is the so-called Unlimited Rights clause found in FAR 52.227–14.
That FAR clause provides that the government has “unlimited rights” in computer software when it is “first produced in the performance of this contract.” What are unlimited rights? Well:
“Unlimited rights” means the rights of the Government to use, disclose, reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, in any manner and for any purpose, and to have or permit others to do so.
In other words, under existing federal procurement rules, the government already has the legal right to publish source code that is “first produced” in performance of a federal contract.
[Note: there is a difference between civilian and defense rules on this. Under the Department of Defense’s procurement rules, unlimited rights are only available if the federal government fully funds the development of the source code.] [Also note: I know some reasonable folks who argue that unlimited rights does not include the ability of the government to re-license software under a formal open source license. In the meantime, though, it’s sufficient to say that the code can be published openly.]
If you have this clause, and someone first produces software in the performance of a federal contract, the government already has the legal right to reuse that software. That’s a big deal, and why most of the emphasis of the existing federal source code policy is on executing on that existing legal right. The clause isn’t always available for use though, particularly when dealing with “commercial items.”
Commercial Items and Custom-Developed Code
During the formation of the federal source code policy, some voices in the technology industry were deeply (and I submit rightly) concerned about the interplay between the definition of custom-developed code and “commercial items.” In the next post, I’ll provide a path forward, but before we do, it’s important to understand why it’s important.
Under different provisions of the FAR, the Unlimited Rights clause does not apply to the procurement of “commercial items.” Existing law requires the government, when procuring commercial items, to accept terms and conditions that are “consistent with customary commercial practice.” And Unlimited Rights do not fit that bill.
Accordingly, some folks were deeply concerned with the original definition of custom-developed code and its interaction with “commercial items.” Specifically, the concern was a hypothetical where a contractor offered commercial software, but then built a specific feature that was first created for the government customer. Would this newly created custom-developed code be subject to Unlimited Rights or open sourcing? That would be a departure from a traditional understanding of commercial-item acquisition and would need more clarity from OMB. In other words, this hypothetical would have created real headaches for everyone involved.
Fortunately, OMB could have avoided this headache if it embraced existing procurement rules. To wit, under the existing definition of “commercial item,” if a newly created feature for commercial solutions is a “minor modification[] of a type not customarily available in the commercial marketplace made to meet Federal Government requirements,” it’s still considered a commercial item. See FAR 2.101.
This makes sense even in the context of open-source software. In general, if you are using an existing open-source library, and you make a specific extension or change to the software to implement the government’s solution, it would be odd to insist that the government could disregard the underlying open-source license. There, as a commercial item, the open-source license should have been accepted as term and condition consistent with customary commercial practice.
The solution was right there the whole time. Rather than redefine custom-developed code to fit into the sweep of the Unlimited Rights clause, OMB should have kept its original definition of custom-developed code, but expressly excluded commercial items from the policy.
Getting to the solution
Despite their concern about the interplay between custom-developed code and commercial items, this interplay actually points the way forward for government to achieve its goals under the federal source code policy. But Unlimited Rights isn’t enough; to really succeed, OMB needed to get slightly further upstream. We’ll cover how to do that in the next and final post.
