A guide to open source software for procurement professionals

A new Linux Foundation whitepaper provides guidance in negotiating software contracts that have open source components.

Introduction

The first and most important step in negotiating any agreement is always to get the facts.  For example, when negotiating a software development agreement, the developers for both parties probably assume that the software will include many pre-existing components written by third parties.  If the procurement and legal personnel negotiating the agreement assume that there should be no code that is not written by the vendor, the process will be inefficient and waste a lot of everyone’s valuable time.   

If developers are confronted with ridiculous assumptions about writing software from scratch, the credibility of the procurement process is undermined, and, in the future, they will find ways to avoid or delay involving procurement and their legal counsel.

The Linux Foundation recently published a whitepaper written by Karen Copenhaver and Steve Winslow that aims to help procurement professionals and their legal counsel avoid making erroneous factual assumptions that will undermine their credibility and delay negotiations through a better understanding of software development and the use of open source software assets. This is a summary of its findings.

Software is not static

The software that will be developed will evolve as it is developed. The reality is that if we required a detailed, final specification for development before the parties can begin work, the only assurance we would have is that the results would be too late to market to be valuable. 

Agreements today have to be focused on establishing the process for working together to develop something which neither party can fully define or envision. Requiring that a fixed list of the specific software components that will be used in development be included in the agreement may not make sense to the people who will perform the work. 

They may know that the list will change often, and they do not want to amend the agreement every time they consider, include, or replace a component. A process acceptable to both parties that allows for the rapid evolution of the work to be performed will be welcomed.

Software will change over its normal life

Software is never “finished” until it is uninstalled. Constant updating is required to accommodate changes in the operating environment, including the hardware, opportunities for enhancement, and to apply patches that become available to eliminate potential security vulnerabilities. If the software is not updated, then necessary software maintenance is not occurring. Agreements should not be written based on the assumption that all development will conclude at any point before the end of the life of the software.

Software providers will not author or “own” the copyright in all of the software that is being delivered

The software will include components owned and developed by third parties and will rely on dependencies that may not be part of the distributed package of software. 

Because the software does not operate in a vacuum, components and interfaces written by third parties are necessary for the software to function. For example, applications installed on laptops use interfaces in the operating system. Without using the libraries and/or interfaces that provide access to this infrastructure, the software cannot be developed, tested, or deployed.

In addition to what is developed and delivered as part of the agreement, all software operates within one or more ecosystems of third-party dependencies that are necessary for its optimal use and performance.

The use of these dependencies will directly influence the price at which the software provider offers their software for sale. 

Tools are important to the delivery of software and solutions

Just as lawyers rely on a word processing program to write an agreement, software developers use software tools to make development more efficient. These tools are often the most complex software involved in the development project, and the amount of code in this development environment will almost always far exceed the amount of code in the developed deliverable. And these tools will change and evolve just as the software that is being developed will change and evolve. Knowing the specific facts related to the collection of tools used to develop this software is essential to avoid unworkable approaches.

Sometimes the development environment will be a third-party product that can be acquired directly from the third party. If a version of the third-party product that is being used is specified, the customer will be able to replicate and maintain that development environment should it ever be needed. 

Other times, the reason to hire a specific company to do the work is that they have a well-established, unique development environment, and, just as important, a set of highly skilled developers trained to use it.  

However, to “deliver” the entire development environment is often impractical for a number of reasons. The company asking for it to be delivered may not have sufficient equipment or technical employees even to install the software, much less maintain it. 

To deliver any code at a single point in time, without a plan for someone to maintain the code going forward, is not useful.  

The continuous delivery of code in a development environment is an enormous amount of work that must be performed by highly skilled individuals – often the same individuals who are required to complete the work you have engaged the vendor to perform.  

Requiring delivery of the development environment as a contract solution where the technical employees of both companies know that the delivered code will never be used is considered by developers as a frustrating waste of valuable resources that will delay the work everyone wants the vendor to perform.

Many of the most valuable third-party components and tools are made available under open source licenses

Most estimates suggest 70-90% of all the code in a system will be built from open source software. And even proprietary, purchased solutions that any IT organization currently uses are very likely built in large part with open source components.

Unless your technical people agree that there should be no open source code of any kind used in its development, do not ask for a representation or warranty that there will be no open source from a contractor or supplier. 

If software made available under an open source license will be used, the relevant questions you should ask should be related to the selection of the code, maintenance of the code, and compliance with the applicable license terms in your specific use case. And all of these are questions that should be asked about both open source and non-open source software. 

If your competitors are using these valuable open source assets and you do not, it will be hard to be competitive on cost, quality, maintenance, and security. One of the most important reasons to use open source is to benefit from the advantages of shared support across an ecosystem. 

Software licenses can be categorized in unlimited ways

There are many software licenses. Some are licenses that the Open Source Initiative (https://opensource.org/) has approved as consistent with the Open Source Definition (https://opensource.org/osd-annotated). There are also licenses that are similar to those licenses but that have never been approved, and some of those variations are not considered by people familiar with this terminology to be “open” or may even be of a proprietary or commercial nature. 

The SPDX License List (https://spdx.org/licenses/) has been curated by lawyers working in the open source ecosystem and identifies many of the licenses that frequently come up in reviews and negotiations.

The question is: does any practical difference arise in any specific contractual context based on exactly where a license falls on that spectrum? In our estimation, spending time and energy trying to define a separate category of Open Source Software is not helpful in reaching an agreement. Aside from how the open source ecosystem may categorize licenses, all software licensed from third parties should be evaluated under the same criteria for your project.

Some of the most essential and widely used software are provided under the GPL and other copyleft licenses

GPL-licensed software such as the GCC Compiler and the Linux operating system is used by the vast majority of companies and industries around the world. The distribution of this software usually triggers copyleft obligations to provide source code. Many businesses are built on top of the GPL-licensed Linux operating system and other copyleft software that is used in the business to provide services but are not distributed. 

A common perception of the GPL and its variants as being unworkable open source licenses is inaccurate. Keep in mind that the GPL, like all free and open source licenses, does not restrict your usage. As a recipient of GPL software, you have far more expansive license rights to use the software than you have under a proprietary software license agreement. Compliance with the GPL upon a redistribution of the code may be a factor to consider but should be compared with the fact that you would likely not have the right to redistribute proprietary software at all. 

A company can have a “no GPL policy,” yet it cannot operate in most industries without dependence upon the Linux operating system, which is GPL-licensed software.  

Unless your technical people agree that there should be no GPL or copyleft licensed code of any kind used in its development or provided in the work product, do not ask for a representation or warranty that there will be no copyleft software. Once again, the relevant questions related to the selection of the code, maintenance of the code, and compliance with the applicable license terms in the relevant use case.  

Conclusion

Lawyers and procurement professionals should not even attempt to dictate how software development will be accomplished. If negotiations hit a rough patch, take the time to confirm that the real issue is risk allocation. Make sure that the dispute is not due to insistence on facts that your technical team does not believe to be true. This is particularly difficult when longstanding corporate policies are out of step with current realities.   

To download “Fact gathering: The first and most important task in software negotiations”, click on the button below.