Government’s Release of Federally Funded Source Code: Public Domain or Open Source? Yes.
A petition was recently posted on We The People demanding that federally funded software be released under an open source license. Makes sense. The public should have access to what is technically their property.
However, TechDirt posed the question of whether it should be released under an open-source license or public domain, and I’m afraid they really missed the point.
There’s no doubt in my mind that the creator of the petition was simply asking the question “I can haz source code?” Plain and simple. Put it in context: 99% of the time when an organization (or an individual) releases software to the public, they do so under the terms of an open source license. It tells users what they can and can’t do, and tells contributors under what terms they can contribute. It’s set’s the ground rules. It’s a contract with the public. It’s a prenup for code.
So what’s the issue? Although I generally dread the phrase, in this case, government is objectively different. Under 17 U.S.C § 105 US Government Works are not subject to domestic copyright protection. It’s not technically public domain, but it’s close enough. 1 Any US citizen can use the code any way they wish. There’s simply no copyright, thus no need to license. 2 And this entire debate is a moot point if the software is a derivative work of a viral license like the GPL, the most common open source license. 3
That of course, only applies to code created by a US government employee, an increasingly rare occurrence. 4 Absent permission from the contracting officer, the US government retains unlimited rights for all work created under contract (including the right to redistribute). 5 And again a moot point if GPL derivative (and thus must be given to the Government under the GPL.)
Yet all this is very academic (not to mention dry). Waldo Jaquith and Anil Dash made a great suggestion: let’s be pragmatic here. Government doesn’t hold on to software because they are concerned about licensing. They hold on to software because they have better things to do, because it’s not within the culture, and because there’s no angry mob slamming a battering ram against the metaphorical front gates when they don’t.
I don’t think the nuances of federal procurement law is even close to the first thing we should care about here. 6 The concern is about whether feds should do the leg work to open source it or not. The question for us as developers, for the thought leaders in the space, isn’t how should the US government best license / not license software, but how can the open source community help it to do so. How can we get more software out the door? In a world of finite time, how can we make open sourcing 7 a bona fide priority?
How? For one, involvement in existing open source projects 8 would surely send a strong message that there’s latent demand here, and would give the foot soldiers political air cover to forge onward with their efforts. For another, taking ownership of the code itself, and realizing it is our code, not the government’s would surely change the tone of the debate by encouraging agencies to ship code sooner, rather than delaying release out of fear of criticism.
Put simply, it’s about what role we are going to play, not what rights we are going to receive. Let’s at least get the source code, then we can go back to our regularly scheduled holy wars over licensing.
As always, views are my own.
I’d argue that all software, even government funded software should still be licensed under a traditional open source license, to resolve any legal ambiguity when used abroad under the terms of various international copyright treaties and agreements ↩
Although citizen-contributions to that project would theoretically not be public domain, thus necessitating a license, which should be clarified in the project’s documentation at the time of release to avoid potential issues with 21 U.S.C. § 1342. ↩
Although again, technically speaking the project as a whole would be licensed under GPL, individual code not dependent on the parent project could be used as a US Government Work. ↩
FAR 52.227–14©(1)(i). Even if the contracting officer grants such rights, they do not take effect unless the contractor includes a copyright notice at the time of delivery, acknowledging the government’s sponsorship and indicating the contract number under which it was procured. See FAR 27.404(a)(5). ↩
General counsels across government already have enough ammunition to stymy progress. ↩
Often the last and least seen step in the enterprise development process. ↩
If you enjoyed this post, you might also enjoy:
- Towards a More Agile Government
- Everything a government attorney needs to know about open source software licensing
- Securing the Status Quo
- Everything an open source maintainer might need to know about open source licensing
- Five best practices in open source: external engagement
- Why open source
- Why you probably shouldn't add a CLA to your open source project
- Twelve tips for growing communities around your open source project
- 19 reasons why technologists don't want to work at your government agency
- Open source, not just software anymore
- Ten ways to make a product great
Ben Balter is Chief of Staff for Security at GitHub, the world’s largest software development platform. Previously, as a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →