What if you could get 24/7 maintenance, R&D, and debugging for the software that drives your business, all at no cost to you? Sounds pretty good, right? Lots of companies think so, and they have started making serious use of Open Source Software, or “OSS.” As its name implies, OSS has underlying source code that anyone can view and modify. Because of this transparency, groups of programmers all over the world can make constant updates to OSS programs and release the improvements back to the public, all for the common good.
On the surface, OSS solutions sound like they would be great for use in government contracting: low cost, low maintenance, high yield. Of course, there’s a catch. The licensing system and access issues associated with OSS could throw a wrench into your plans for its use in performing your government work. You’ve got to make sure you know what’s going on with your OSS before you incorporate it into your deliverables.
So can I use it or not?
For a while, both the government and contractors were iffy on the question of whether federal agencies ‒ especially the Department of Defense (DoD) ‒ were allowed to accept deliverables that included OSS. DoD Instruction 8500.2 severely limits the government’s ability to use software products “commonly known as freeware or shareware.” Widespread misconceptions about the nature, security, and capabilities of OSS also contributed to its underuse in government work.
Meanwhile, private sector companies were reporting tremendous monetary savings and increased strategic agility stemming directly from the ease of access and near-constant improvement of processes associated with OSS solutions. The government eventually realized that it was doing itself a disservice by allowing the confusion over OSS to fester, so in 2009 the DoD released a memorandum that clarified the agency’s position on the use of OSS and officially sanctioned its acquisition and integration into government systems.
What counts as OSS?
One of the most important things the DoD’s memo did was define what counts as OSS for government purposes. “Open Source Software,” the memo states, “is software for which the human-readable source code is available for use, study, reuse, modification, enhancement, and redistribution by the users of that software. In other words, OSS is software for which the source code is ‘open.’”
Thus, the terms “freeware and shareware” do not encompass OSS, since the DoD defines those terms as applying only to software whose original source code is not available to the government. So long as a program’s source code is available, it’s fair game for integration into government systems and usually treated no differently than other “commercial items” and “commercial computer software” under the FAR and DFARS.
But not so fast ‒ not all OSS is created equal.
Just because a program’s source code is open and available for use by the public, it doesn’t mean the program can be picked up and used without restriction. OSS is not public domain software. Rather, just like traditional proprietary software, OSS is released for use under product-specific licenses, and the terms of those licenses can vary wildly from one program to another.
Some “permissive” licenses can be fairly developer-friendly and allow programmers to modify the subject OSS and claim the resulting improved or hybrid material as a new, proprietary product. More “protective” licenses, however, may keep modified OSS from becoming proprietary or even require that the source code for new binaries be rendered up upon request.
If you are planning to use or modify OSS under a government contract, it is crucial that you understand the nature of the licenses associated with that OSS and, where appropriate, inform the government about those licenses. Failing to do so could result in unintended consequences that could crash your intended course of performance.
How to sell your Contracting Officer on an OSS solution.
Even with the new guidance from DoD, your KO may still have lingering doubts about OSS. Many people, for instance, still believe that OSS is more susceptible to hacks and malware attacks than proprietary software. In reality, the opposite is true. The fact that anyone can review the source code for an OSS program actually makes it easier to spot both vulnerabilities and harmful bugs. It is also easier to deal with these issues when you find them; since any competent programmer can fix the problems, there is no need to wait for a proprietary owner’s clearance or action.
KO’s may also worry that they won’t have anyone to blame or hold responsible in the event OSS breaks down or fails to function as promised. This worry is easily dealt with; just offer an independent warranty or service plan that puts you on the hook to make good if the government discovers a problem.
Of course, if you’re working on a deliverable that is sensitive, confidential, or classified, you may be in a trickier spot ‒ especially if the OSS you want to use is covered by a “protective” license that would require disclosure of any modifications made. Again, it is important that you understand what kinds of rights restrictions you’re working with and whether they’re going to cause headaches for the government down the road.
Know your rights, and watch your step.
The transparent and dynamic nature of OSS makes it a very attractive option for use in many programming contexts, and government contexts are no exception. As with any tool, though, you need to make sure that the OSS you’re considering is the right choice for the job at hand. So long as you keep yourself informed about the capabilities and conditions associated with the OSS you want to use, and keep the government in the loop, you should be able to keep your business out of trouble.
Latest posts by Ryen Rasmus (see all)
- Cut to Commercial: The Government’s Commercial Item Rules - February 18, 2015
- Can We Do That? Open Source Software in Government Contracting - September 10, 2014
- MARK My Words: What You Need to Know about the Government’s IP Marking Requirements - July 22, 2014