In the United States, nearly all agencies and departments, at all levels of government, rely on open source software. Some do so as an explicit policy decision, others merely as a matter of practice. Objections around software quality and security collapsed long ago in the face of reality. But publishing open source software is a very different situation.
When agencies procure custom software, but keep the source closed, they are putting themselves at a significant disadvantage. There are some enormously compelling arguments—and some surprising arguments—in favor of agencies preemptively publishing source code.
Works of government may be public by default
Under the Copyright Act of 1976, “Copyright protection under this title is not available for any…work prepared by an officer or employee of the United States Government as part of that person’s official duties.” Although there are exceptions, it is broadly true that software developed by the federal government is in the public domain. Custom software produced for the federal government by vendors is often public domain, but not always. If the copyright is assigned to government—as it really, really should be—then it is generally public domain. (This is governed by FAR Subpart 27.4—Rights in Data and Copyrights. See also the prescribed clause in FAR Subpart 52.227-14—Rights in Data-General: “Government shall have unlimited rights in…[computer software] first produced in the performance of this contract.”)
At a state level, things are much messier. There is no consistency between states, and sometimes no consistency between agencies within a state. Custom software produced by or for state agencies might be public, or it might not be—you’d need to consult a lawyer to be sure.
Open-records laws may require you to turn source code over to requestors
Federal and state open-records laws have often been used to compel agencies to provide custom software’s source code to anybody who asks. It’s broadly true, at a state and federal level, that there are exemptions for releasing records that are otherwise prohibited by law, and every government has a law prohibiting the release of information that could undermine computer security. But if that exemption doesn’t apply, then federal agencies need to turn over the source code, which the recipient is then free to make public. Again, there are huge differences between states’ freedom of information laws, so research is necessary to know how those apply to source code in a given state.
Open source is more secure than closed-source software
People who aren’t software developers will often assume that software is more secure if the source code is kept secret. If that were true, source code would be inherently exempt from open records laws, the copyright held close by government. Source code would be treated as a state secret, stored and transferred like nuclear waste. But that’s not how we treat software, because we know that isn’t true.
A strong argument for open source’s security comes from the U.S. Department of Defense’s excellent Open Source Software FAQ, specifically their answer to “Doesn’t hiding source code automatically make software more secure?” which opens with, simply, “No.” The document goes into a great deal of detail, but suffice it to say, no less of an authority than the nation’s military thinks that it’s important for government to publish source code openly.
Open source supports agencies’ need to tell the public that they are being transparent in their work
It can be important for many agencies to help the public have confidence in their operations, and that’s especially when they issue decisions that are made by or augmented by software. Judges have often agreed with defendants’ demands that breathalyzer software source code be provided so that the defendant has a chance to prove that it contains bugs that led to an erroneous reading. Public benefits systems increasingly automate qualification decisions, and advocates are putting a corresponding amount of pressure on agencies to allow them to verify that those decisions are consistent with relevant laws and regulations. For types of software likely to be subject to such scrutiny, publishing the source code preemptively shows that the agency has nothing to hide.
Open source prevents vendors from including copyright poison pills
When government procures custom software from vendors, with government owning the copyright, unscrupulous vendors may see an opening to make some money on the back end, by including software that they already wrote and hold copyright on. They can deliver software that is 99% government-owned, but has interwoven into it a critical layer of software that’s owned by the vendor, for which they can demand licensing fees for as long as the software is in use. One way to avoid this problem is to contractually require that all software delivered by the vendor be published under an open source license, absent written permission providing exceptions.
For a high-profile example of a copyright poison pill, see Georgia v. Public.Resource.Org, the Supreme Court case that resulted from LexisNexis weaving copyrighted text throughout the Code of Georgia and to ensure that they’d receive licensing fees from anybody attempting to reproduce the state’s laws.
Open source sets up a powerful incentive to get the best work from the best vendors
Pity the software developer working at a standard-issue government consulting firm building a software product on contract with an agency. Odds are low that their code will ever make it into production, even lower that anybody will ever use it for anything at all, and basically nonexistent that anybody else will ever see a single line of code that they wrote. It’s a miserable way to make a living. What sort of work product would you deliver under those circumstances?
Incentives change substantially if the product is advertised as open source from the time that the first RFP is published to create it. Lousy vendors usually know that their work is bad. They don’t want to produce software for government that will be public, for potential future clients to see. And good vendors know that their work is good. They’re proud to have their work be public, to have something to show potential future clients. They want to put high-performing employees on those projects, who will make the vendor look good. And if the source code is on GitHub, those employees know that their daily work is being promoted to their professional network on GitHub, and available for review by potential future employers. They’re no longer toiling in obscurity, but instead working very much in public, doing their best work on behalf of an employer who wants to give them the resources to do their best work.
You can filter out lousy vendors and elevate good vendors by declaring a product to be open source from the outset.
Open source reduces risk for subsequent vendors, which reduces the dollar value of their bids
Software is never done. The vendor who gets the contract to build custom software may well not be the vendor who gets the contract to maintain it, or the vendor who gets the contract to add new functionality years later. There’s a lot of risk for vendors working on existing software if they can’t inspect it first. Is the code garbage? Is there documentation? Is it well linted? Is there good test coverage? Can developers run it in Docker on their laptops?
If vendors receive an RFP to improve existing software, and it’s trivial for them to look at the source code, and what they see is good, that reduces their risk, which in turn reduces their bid. Open source software is cheaper software.
There are vanishingly few downsides associated with government publishing source code publicly, but some substantial upsides. Agencies should default to working in the open, and reap the benefits of reduced cost, increased trust, and higher-quality results.
Comments are closed.