The U.S. White House Office of Management and Budget (OMB) is considering a new policy for sharing source code for software created by or for government projects. There’s a lot to love about the proposed policy: it would make it easier for people to find and reuse government software, and explicitly encourages government agencies to prioritize free and open source software options in their procurement decisions.

EFF submitted a comment on the policy through the White House’s GitHub repository (you can also download our comment as a PDF). The OMB is encouraging people to send comments through GitHub, reply to and +1 each other’s comments, and even offer direct edits to the policy via pull requests.

Public Domain with Asterisks

But wait, why is a source code policy necessary at all? Isn’t everything the federal government creates already in the public domain?

Sort of. U.S. copyright law has an exception for works created by the federal government, but that exception has always left some doubt over the copyright status of U.S.-government-created works in other countries.

To our knowledge, the government has never enforced its copyright abroad for works that would be considered public domain in the U.S; however, in some contexts, it has actively asserted that its works are copyrighted internationally. Doubts over copyright can be a stumbling block for researchers, developers, free software communities, and other people who might want to use or study government source code.

That’s why we recommend that the White House expressly dedicate code covered under the policy to the public domain internationally. As a less preferable alternative, the OMB could license the code under a permissive software license. That way, users in other countries could assuage any concerns over copyright by adhering to the terms of the license. As Creative Commons pointed out in its comment on the policy, some government agencies have assuaged this uncertainty by using CC0, a tool copyright owners can use to effectively dedicate their works to the public domain.

That all assumes you can find the source code in the first place. Right now, there’s no convenient way to procure source code for many government-owned projects. It’s technically in the public domain (with the caveat above), but that doesn’t do you much good if it’s not shared publicly in any reliable way. That’s why the proposed policy also includes launching a public repository for government source code.

What About Third-Party Code?

There’s another big problem with the public domain status of government-owned works: it doesn’t include content created by third parties. If I take a photograph as an employee of the federal government, that photograph gets no copyright protection in the United States (putting aside the question of international use). Conversely, if I take it as a work for hire for a government agency, my copyright is transferred to the government. That discrepancy is particularly relevant when discussing software, because most government software is built by contractors.

The proposed policy would require agencies to publicly share source code for some third-party software. Agencies could develop their own policies for which projects to share, so long as at least 20% of the total code is made public and shared under a license approved by the Open Source Initiative. We think that the 20% rule would be a missed opportunity, and many of our fellow commenters agree. An open-by-default policy would make the government repository a much more valuable resource to the public. We also hope that the OMB considers dedicating third-party code that is assigned to the federal government to the public domain as well, possibly alongside an appropriate free and open source software license.

Narrower Exceptions Will Protect the Policy from Abuse

The policy lays out a process for requesting permission to keep source code private, and gives specific reasons agencies can use to request an exception:

Applicable exceptions are as follows:

• The release of the item is restricted by another statute or regulation, such as the Export Administration Regulations, the International Traffic in Arms Regulation, or the laws and regulations governing classified information;
• The release of the item would compromise national security, confidentiality, or individual privacy;
• The release of the item would create an identifiable risk to the stability, security, or integrity of the agency’s systems or personnel;
• The release of the item would compromise agency mission, programs, or operations; or
• The CIO believes it is in the national interest to exempt publicly releasing the work.

Both the term “confidentiality” and that last item on the list strike us as very broad. They could effectively be used to keep any code private—that’s why we suggest omitting them.

The OMB says that it expects exceptions to be very rare. The way to keep them rare even as administrations change is to define them as narrowly and specifically as possible.

Once again, we applaud the OMB for this proposed policy and we’re eager to see it enacted. The OMB is still accepting comments and pull requests through Monday, April 18.