In the first post of this series, we discussed “the good” of open-source software and why federal buyers should find it attractive. However, when it comes to the federal government accepting open-source code with open arms, the reality is certainly more mixed. Faced with changing and technical regulations, government contractors need to know the major drawbacks of using open-source code in government contracts. In this second entry to our open-source series, we explore “the bad” impacts of open-source use in government contracting.
The Bad
There are many benefits to using open-source software—development speed and cost efficiency being most paramount. However, when developing software for the government, a number of regulatory and policy requirements are often more important than speedy development or cost control. Indeed, Congress has dictated key restraints on federal procurements, which, when implemented through agency regulations, hamper the use of open-source code. This is exacerbated when commercial entities with little or no knowledge of the procurement laws and regulations start to work in the government contracting space.
Many companies do not understand that regulations dealing with commercial software require specialized software licenses for government users. While regulations that govern federal procurements in the Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation Supplement (DFARS) ostensibly allow commercial companies to use their standard commercial license, there is almost always negotiation on specific points, as some clauses in commercial licenses violate laws like the Antideficiency Act in the federal context. These include indemnification clauses that require the government to possibly pay unspecified sums in the case of infringement, which are generally prohibited in commercial licenses with the federal government. Other commercial clauses may conflict with contractual requirements or FAR and DFARS requirements in the contract. Given possible issues of this nature, every license, even standard commercial licenses, must be reviewed and negotiated with the government for every contract.
What does this have to do with open-source software? If standard commercial licenses must be reviewed and negotiated to ensure compliance with law, regulation, and the contractual requirements/needs of the government, then so too must licenses for open-source components. So with more open-source components in your software, more licenses will have to be reviewed, which leads to two problems:
- Unlike with commercial licenses entered into directly with a prime contractor or subcontractor, open-source licenses are not easily amended. Indeed, many times it is impossible to know who to contact to amend the license terms or, worse, it is simply impossible to make any amendments at all. Thus, if it contains one piece of open-source code with objectionable license terms, an entire commercial software product can be unsuitable for federal government use and could potentially lead to diminishing your chances of winning a contract or losing an existing contract.
- Even if the open-source code licenses are not objectionable, the government still needs to review every license to ensure it does not violate federal law or conflict with specific contract requirements or government policy needs. This takes time, and not just for review. Many developers who use open-source code do not even review the open-source licenses themselves before development and do not know where to find the licenses the government requests. Finding the licenses often leads to more delays and can put a project in jeopardy before it begins.
Despite all “the good” open-source can provide, it is important to understand “the bad” before jumping into the federal procurement space. Many of these “bad” elements can be mitigated with a good understanding of your licenses and their requirements, as well as the risks they may pose.
