The trouble with the federal source code policy, and what to do about it: Part Four
This is the fourth article in a four-part series looking at the federal source code policy. Read Parts One, Two, and Three.
If you’re still reading, you’re probably wondering whether the federal source code policy is salvageable, or whether it should just be scrapped. In fact, in hindsight, there’s a really straightforward fix. In this post, I finally offer my solution to fixing the federal source code policy. Before I do, I will quickly recap and address one lingering flaw.
Recap
In the last two posts, I explained that, to be successful, OMB needed to:
- Adopt an open-by-default posture instead of adhering to technology neutrality for custom-developed code.
- Redefine the scope of the policy to expressly exclude commercial-item acquisition and return to a more sensible definition of custom-developed code.
But before I get to the solution, I need to address why relying on Unlimited Rights was not enough and how dual licensing can be used to help the government achieve its goals.
The problem with unlimited rights and open-source licensing
As we discussed in the last post, (a) unlimited rights are already available for non-commercial items that are first produced under federal contract and (b) unlimited rights already allow for public disclosure of source code.
But there’s a tricky problem with unlimited rights: they don’t always jibe with existing open-source licenses, and public reuse is not always possible with unlimited rights. Although a full treatment of the nuances of open-source licensing is beyond the scope of these posts, it is important to understand that open-source licenses typically include constraints on the redistribution of the source code and derivative works that conflict with unlimited rights, so unlimited rights can create challenging license conflicts and headaches. In other words, although unlimited rights may be theoretically useful for governmentwide reuse, they’re not especially helpful for public reuse.
And like the problem with commercial items, the problem reveals the solution. Instead of relying exclusively on unlimited rights to do the heavy lifting to promote reuse, the government should have simply embraced open-source licensing as the vehicle for promoting reuse through dual licensing.
Rather than creating a new method of inventorying, a new licensing model, and a new method of discovery for reuse, the government should simply have insisted that custom-developed code be licensed with an open-source license in addition to unlimited rights (where appropriate). Requiring agencies and contractors to use an open-source license at the time of development solves for government-wide reuse and public reuse.
In essence, the biggest policy flaw of the federal source code policy was trying to create a “government version” of open source to achieve governmentwide reuse. Ironically, the federal source code policy is effectively the government enshrining “Not Invented Here” into a formal statement of policy. Sharing code within and across organizations is not an easy problem, but it’s at least one with a sizeable infrastructure and community out there. Trying to roll our own government-only, somewhat-open-source model was a mistake.
How to fix the federal source code policy
Now that all of the puzzle pieces have been discussed, it’s time to offer the final formulation of the fix to the federal source code policy:
After the 20% pilot program sunsets in August 2019, the government should change its policy to (1) adopt a narrower definition of custom-developed code and expressly exclude commercial items (and minor modifications to commercial items) from the policy; (2) for custom-developed code, abandon technology neutrality and explicitly implement an Open Source by Default mandate; and (3) require dual licensing of custom-developed code: open-source licensing in addition to unlimited right.
This is both narrower and broader than the existing policy. It’s narrower in terms of sweep; fewer things would fall under the definition of custom-developed code (and that’s good!). It’s also broader in that it would establish a baseline expectation that all custom-developed source code would be open by default.
If OMB took this approach, it would still work with the existing unlimited rights framework of the FAR. It would also mean than minor modifications to commercial software (including, incidentally open-source software because it’s commercial software, too) could continue to be exempt from the policy. And most importantly, it would set the flag in the ground that the default position of the government is that custom-developed, purpose-built software for the government be freely available for reuse, by government and the public writ large.
Doing so would require some political will to acknowledge a departure from the technology neutrality memorandum. It would also require political will insofar as it might cut into the margins of companies that use non-governmental funds to build government-specific solutions outside of a contract and then force the government to pay multiple times for that same code.
The former should be easy; it’s really not even that much of a departure. The latter is definitely a bit harder. But isn’t that really the point anyway?
Conclusion
At the time of the development of the federal source code policy none of this seemed obvious (except for the 20% pilot program, which was always ridiculous). But in hindsight, it seems obvious that OMB made a fatal error in trying to hold onto the technology-neutrality principle and to define custom-developed code in a way that departs from its traditional meaning.
By adopting an open-by-default rule, mandating open-source licenses for custom-developed code, and otherwise maintaining a clear preference for commercial items, OMB could make the federal source code policy a much better deal for both government and the American public.
All it would take is a little political will, and some clear thinking.
