This article is also posted to my Intelink blog.

Every so often, a government project manager asks me a question like this:

I’m looking to hire some government guys and I’m interested in young folks hacking on [my project].

So, here’s my predicament:  if they work on the code, their work becomes ‘public domain’ and not something that could be restricted by licenses (at least according to some legal advice I’ve been given).  If the work is the in public domain, I have no way of ensuring that someone won’t take the code and sell it back to the government as their own (because they could modify it and put a proprietary seal on it).

Here’s my question: is there some legal structures that can be put in place to restrict modification, use and distribution like typical software licenses for government-created works?

Here’s some ways this has been done before. Given the goal to create a collaboratively-developed software product, open-source software licensing can provide clear and effective rules-of-engagement that protect the interests of all participating stakeholders.  Which is to say, Open Source = Goodness.

It is true that software (or any media) created by federal government employees (civilian or military) in the course of their duties is not subject to copyright protection in the United States.  (q.v. 17 USC 105)    Since essentially all open-source software licenses derive their legal power from copyright law, this does present some issues.

Here are three approaches to cracking this nut:

1. Just ignore the problem and release the software as public domain.  If a vendor tries to sell it back to you under terms that are reasonable, buy it.  If the terms are unreasonable, don’t buy it.   This may seem simplistic, but often turns out to be effective, especially when the government continues to maintain the public domain version.  Examples are VA’s VistA, and  NIST’s Expect, amongst others.  If your gov’t-developed code is good enough for someone to try to sell it back to you, yer doin’ things right.
2. Create a joint work which is partly public domain, and partly copyrighted by a non-federal entity (i.e. your contractor).   A “joint work” is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole (17 USC 101). The joint work can be released under an open source license, and the government is not obligated to go out of its way to annotate which sections are public domain vs. copyrighted.  As an example, DISA signed a CRADA with the non-profit Open Source Software Institute to enhance the public-domain “CMIS” and release it as the open source “OSCMIS“.  This is easy if you have mixed government/contractor team.
3. Aggressively rely on foreign copyright (I call this ‘the NASA approach’).  The fact that the software is not protectable by copyright is only true in the United States; in foreign jurisdictions it will (generally) be copyrighted by the US Government.  It is thus completely reasonable to mark such software as both “Copyright 2014, US Government, released under LGPL” and “Work of the United States Government and not subject to copyright protection in the United States.”  Few commercial entities would build a product around IP that they could not enforce internationally.  I’m not aware of any legal requirement to mark something as a public-domain US government work (although it is a recommended best-practice).  I call this the ‘the NASA Approach’, because the NASA Open Source Agreement includes this paragraph:
   

   [The following copyright notice will be used if created by civil servants only. Government Agency will insert the year and its Agency designation and remove the bracketed language.] Copyright ” {YEAR} United States Government as represented by __________________________________________. No copyright is claimed in the United States under Title 17, U.S.Code. All Other Rights Reserved.

   As soon as the project accepts the first patch from a non-gov’t contributor, you could drop the “No copyright is claimed…” sentence.

Any of these three approaches might get you to where you need to be, depending on your situation.  As Matt Asay recently pointed out, the trend is towards more permissive licensing, and less worrying about the license in general.  So, JFDI: Just Fork & Do It.