To listen to On DoD on your phone or mobile device, subscribe on PodcastOne or Apple Podcasts. The best listening experience on desktop can be found using Chrome, Firefox or Safari. 

As part of the 2018 National Defense Authorization Act, the Defense Department has until June to start moving much of its custom-developed software source code to a central repository and begin managing and licensing it via open source methods.

The mandate might prove daunting for an organization in which open source practices are relatively scarce, especially considering that, until recently, there was no established open source playbook for the federal government. That’s begun to change, however, with the Office of Management and Budget’s code.gov, and its DoD corollary, code.mil, run by the Defense Digital Service (DDS).

In February, code.mil underwent a “relaunch,” changing it from a GitHub-hosted, text-only, how-to guide to what its managers say is both a code repository and a full-fledged toolset for software program managers who need guidance on how to engage in open source practices within the government.

“The Github page was great for coders. The new website is great for coders, policy people, people of any background who want information on open source,” Ari Chivukula, a “policy wrangler” with the Defense Digital Service, said in an interview for Federal News Radio’s On DoD. “What we’ve learned over the past year is that people need a suite of tools that walk them through the common flows and information that they need. We’re trying to ensure accessibility for the people who want to open source their code so that the barriers are as low as possible.”

Most of the key barriers are legal and policy ones.

Chief among them: an inherent contradiction between how intellectual property traditionally works in the open source community and how it works in the U.S. government. In most cases, open source developers copyright their work and then attach an open source license to it in order to retain control over exactly how it’s modified, improved upon and distributed. But the work of federal government employees, done on official time, is generally considered public domain, and can’t be copyrighted.

“But there are a bunch of caveats to that,” said Jordan Kasper, a DDS engineer. “One of those caveats is that it’s only public domain within the boundaries of the United States, and we’re in a global community now. So if someone tried to use this code in England for example, we do have copyright protection there, and so you want to be able to attach a proper open source license. There’s a whole other aspect too, which is that DoD doesn’t really write a lot of code — most of it’s written by contractors. We want to make those things reusable too, and those aren’t public domain, they actually do retain copyright. So we also try to help people deal with that mixed bag — when there are both contractor-written and government-written things, how do you structure that open source license?”

As for contractor-written code, the NDAA mandate only applies to software for which DoD has already been granted unlimited intellectual property rights as part of its agreement with the vendor, so managers who want to open source their programs will first have to segregate any portions that are still the contractor’s intellectual property.

As for government-written code, the DDS-recommended approach is to attach a “Developer Certificate of Origin” (DCO) and attach an open source license and a statement of intent to every package of software code at the time it’s released via a public repository, even if the copyright isn’t legally enforceable within the U.S.

Kasper said the statement of intent recognizes that the government work is technically public domain, but anticipates that most participants in the open source community will abide by whatever restrictions the original developer requests, legally enforceable or not.

“People in the community want guidance on how to interact with this project,” he said. “So we say, ‘Our intent with this product is that you will treat it as an MIT license,’ for example, and that gives them some guidance on things like how the original developer wants contributions to come in. And the point of the DCO is to say that when a public contributor writes some code for an open source project, what rights do they have or don’t have? The certificate of origin says that that developer is the origin of that work product and that they’re not expecting any money from it. The point is to very clearly delineate who owns what, and it’s not owned by any company.”

In addition to shepherding DoD components though how to open source their code, DDS has also been working to tell them why they should in the first place. Most of the resistance it’s encountered involves perceptions that releasing a system’s source code to the public will make the system more vulnerable to cyber attacks.

DDS says those concerns make sense in the case of highly-sensitive national security systems, but they’re off-the-mark in many other cases, since cyber adversaries are already well-versed in scanning government systems for exploitable vulnerabilities, whether the underlying code has been open sourced or not.

Put another way, security by obscurity is usually a poor strategy.

“If you open source your code, it is a statement that you are confident about the security posture of your system,” Chivukula said. “There are security researchers who, all they do, is scan through every single public repository and check for known security vulnerabilities or new ones as they come out and then alert whoever owns the code. And so it’s a very good way to get proactive on reports and also contributions of fixes.”

A second benefit, Chivukula said, is the ability to add new capabilities to government systems much more rapidly than is commonplace today.

“There are a lot of governmental systems that are metasystems that are designed to tie into other ones,  and if you open source those systems, people can repurpose them for whatever their use is. If you have a system whose goal is to pull in data from a number of different sources and then produce reports, it’s something that the public would have a direct use for in private industry. Other governmental agencies could also, once they have it, start contributing. If they improve it in any way, they can contribute those features back, and they make the DoD product itself stronger.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.