Open-source code is all the rage. With developers at Fortune 500 companies and hobbyists alike using it to make better products and cut development costs, it is ubiquitous in the commercial market, and government contractors are catching the buzz. Faced with ever-evolving software regulations, though, they need facts before dealing with a federal buyer. In this short blog series, we will walk through the key benefits, drawbacks, and risks associated with the use of open-source code in government contracting, especially at the federal level. Indeed, when it comes to the use of open-source software, all contractors should be aware of the “good,” the “bad,” and the “ugly.”
The Good
The open-source evolution in software development makes sense from a corporate perspective. After all, if there is a piece of open-source code that already has the functionality you are seeking, why not use it? The benefits of shorter development time and lower costs are not just attractive to consumers or for-profit entities—they are a tantalizing prospect for the federal government.
This is especially true as the government seeks to bring in more non-traditional contractors from hot commercial technology corridors. Those companies use open-source routinely, and when they look to bring their commercial products to the government, they often have open-source code imbedded in them. In fact, much of the commercial software from small to mid-sized non-traditional developers has dozens of different open-source components, all working together to make an inexpensive and highly effective product.
Additionally, as open source moved into the mainstream it has changed. For the government buyer, these changes are undoubtedly positive. The idea of open-source software was born out of idealistic pursuits, as a way to make it so that every software developer could share their expertise and insights collectively and produce software which is best suited for the tasks without the stranglehold of corporate ownership, locked-down proprietary code, and limited license rights. For this reason, many of the original open-source licenses required that any developer using it put additions into the public domain to be shared and used by others in the grand co-development utopia. Governments are not keen on having the code to their software open to the public, so the early stages of open-source code did not lend themselves to government use.
More recently, however, this has changed as many of the open-source licenses no longer require publication of derivative code. This has helped open-source expand beyond its original reach, since companies and individuals can use open-source code to jumpstart projects while still monetizing that development. The move away from full collaboration on open-source projects means the government’s concerns about publication of its own software are no longer an issue (in most cases) and, thus, the government can begin to take advantage of the lower cost and faster development that open-source allows. While contractors still have to prove that the open-source licenses they use do not run counter to law or policy goals, the latest iteration of open-source development should steer clear of any major hurdles, and both the contractors and the government can take full advantage of open-source’s benefits.
That said, and as alluded to above, there are some drawbacks to open-source use, and we will discuss some of the major issues in our next installment.
For more information on the use of open-source code in federal procurements, please contact a member of PilieroMazza’s Cybersecurity & Data Privacy Group.
Isaias “Cy” Alba, IV, the author of this blog, is a Partner in the Firm’s Government Contracts practice group.
