Open source software (OSS) use has become ubiquitous. More than 90% of modern software applications use at least some OSS. OSS is software governed by an open source software license (an OSS license). There is no single definition of an OSS license, but they are almost always conditional licenses, allowing the use of the software provided that the user meets certain conditions.
Most discussions about OSS license compliance focus on compliance with the OSS license applicable to a specific piece of software, which is usually found at the site where the OSS is downloaded. However, OSS compliance obligations extend to software developed by outsourced software developers and software acquired from commercial software vendors under complex commercial licensing programs.
Relevant court cases, including No. C 13-05160 SI Ximpleware Corp. v. Versata Software, Inc., No. C 13-05160 SI, (N.D. Cal. Dec. 6, 2013), provide that organizations that develop and ship products are ultimately responsible for compliance with OSS licenses, even when the software used in the development came from a commercial developer under terms guaranteeing compliance with applicable third-party licensing requirements, including warranties of compliance and non-infringement. In other words, even when you license-in software under a negotiated commercial license agreement from a vendor, you can’t shift the liability to the vendor. It is up to each distributor of software, including software embedded in hardware, to know what OSS is being distributed, and to be compliant with all applicable licenses.
So, if you make products or services that contain software, you can bet that you are using OSS, and you can be liable for any non-compliance with OSS licenses. Standard warranties of compliance and non-infringement are not enough to mitigate the risks. While your software agreements should include reps, warranties, and indemnification provisions, they must be tailored to deal with OSS-related risks.
The following post will explore the evolution of warranties related to OSS over the last 20 years, and provide recommendations for reducing the risks associated with non-compliance. It’s based on a webinar I recently conducted with FOSSA: “Reps, Warranties, and Open Source Software.” If you’re interested in this topic, I’d also point you in the direction of the on-demand recording for a more in-depth discussion.
Editor’s Note: Jim Markwith (JD/MBA) is a technology and transactional attorney. He is an internationally known expert and speaker on open source software licensing, healthcare IT, and IP transactions. As Senior Counsel for Microsoft’s Intellectual Property and Licensing team, Jim performed the IP due diligence on more than 40 Microsoft acquisitions, was Chief Counsel for CodePlex, the predecessor to GitHub, and co-authored two OSS Licenses that were approved by the Open Source Initiative (MS-RL & MS-PL). Jim advises clients on intellectual property matters, including licensing, technology procurement, and other agreements. For more information about Jim, please visit https://www.linkedin.com/in/jim-markwith-535b263/, or you can visit Markwith Law’s website at: www.markwithlaw.com. For more information on the MS-PL and MS-RL see: https://opensource.org/licenses/MS-PL https://opensource.org/licenses/MS-RL
The Evolution of Open Source-Related Warranties
When we discuss warranties in the context of OSS, there’s a tendency to focus mostly on provisions in open source software licenses. And, most open source licenses have some form of warranty disclaimer. For example, the MIT License disclaimer reads as follows:
The software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.
There’s another OSS-related category of warranties, those found in commercial software licensing agreements. These provisions are in addition to other important intellectual property-related provisions found in a master services agreement (MSA).
OSS compliance warranties in such agreements have evolved over time. The following is a quick summary of that evolution:
-
In the early 2000s, there was much concern about using any OSS in a commercial product. Commercial licensees in those days typically required the software supplier to warrant that their code was free of any OSS.
-
Around 2005, companies started lifting that blanket ban on OSS. Language from that time often included something like the following: “Licensor represents and warrants that the Deliverables shall not contain OSS, unless such software is pre-approved in writing by Licensee…” Due to the rapid increase in the usage of OSS at the time, the language was used, but rarely complied with. Such language was often negotiated out of the agreement by the vendor (licensor) because it was impractical to comply with since a software developer does not want to stop development while it seeks approval of a particular OSS component.
-
Toward the end of the decade, the use of “Excluded License” language increased. The excluded license approach bans particular categories of OSS, such as copyleft licenses, which have complex conditions of use that must be met. The approach, while still used from time to time, has its own problems. One example is that the Linux Operating System (“Linux”), which is extremely popular, is licensed under the GPL v2. Most excluded license language would not allow the use of Linux, even though in most cases, when compliant with the conditions of the GPLv2, it can be used safely.
-
Currently, and depending on the technology and type of product involved, I recommend a hybrid approach to mitigate my client’s risks, while allowing commercially compatible use of OSS where possible. Allowing the use of OSS when possible is critical for the developer to be competitive in the marketplace. Using existing OSS components can materially reduce time to market and total cost of ownership (TCO) when compared to writing new code from scratch.
Software vendors, those licensing software to software developers, have also evolved their standard licensing terms over time. In the early years of OSS, software vendors were required to stand by their code, and to provide warranties of non-compliance and non-infringement, for all code, OSS and otherwise. Modernly, more and more vendors exclude OSS from any warranties, and attempt to pass all risks associated with OSS, and sometimes all third-party software, to the licensee developer.
The growing disparity between the vendor's desire to disclaim all warranties, and the need to ensure compliance with OSS by software and hardware manufacturers, creates increased risks for those manufacturers who ship products and services containing OSS.
Best Practices for Reps and Warranties in Commercial Software Licensing Agreements
Due to the trends described above, if you start with the vendor’s standard agreement, you likely will see all warranties disclaimed and no liability on the vendor for its use of OSS. On the other hand, if the product manufacturer has its own standard agreements for licensing in software, warranties of non-infringement and compliance with OSS licenses can be included in the initial terms. More often than not, the parties end up negotiating the final terms, and where they end up depends on the knowledge of the negotiating party and ability to demand certain language in order to close the deal.
When I represent a client licensing-in software, in addition to starting with their own paper when possible, the following are a few helpful assumptions and minimum terms and conditions:
-
Assume open source makes up the majority of the code base. As I mentioned earlier, the use of OSS in software is ubiquitous. If a vendor claims they aren’t using OSS, they are likely mistaken and lack knowledge of what is in their code base. This is always a red flag.
-
Clearly state your tolerance for copyleft or other potentially excluded licenses. The use of OSS by the vendor must be consistent with your internal software development practices.
-
If you begin your negotiations with excluded license language, you may get pushback. Consideration should be made to accepting practical exceptions that would allow the safe use of OSS considering the nature of the product being developed. The end result may be a derivative of the excluded license language, combined with robust representations and warranties.
-
Require the vendor to warrant that they have listed all open source code that is in the product or deliverables, and that their use is compliant with the relevant licenses.
-
In cases where the supplier provides an inventory of their OSS usage, confirm the composition of the code using an OSS scanning tool like FOSSA. The results of the scan should generate a baseline software bill of materials which provides an accurate picture and understanding of the OSS in the code base. Understanding exactly what is in the code, versus relying on the vendor's understanding of what is in the code, is critical to your compliance.
-
There is always a possibility that your vendor might breach their warranties. Damages for copyright infringement and breach of contract can be large. Therefore, understanding the ability of your vendor to stand behind the terms of the contract and pay for damages in accordance with indemnification provisions is important. As such, the financial strength of your vendors should be considered.
Learn More About Open Source Reps and Warranties
For more information on this topic, I suggest checking out the on-demand recording of my recent webinar “Reps, Warranties, and Open Source Software.” I cover these themes in greater depth, including the specific language in licenses and warranties, details of community enforcement efforts, litigation trends, and answers to frequently asked questions.
Watch On-Demand: Reps, Warranties, and Open Source Software
About the Author: For more information about Attorney Jim Markwith, please visit the Markwith Law website at: www.markwithlaw.com, or email inquiries to: info@markwithlaw.com.
