As an Open Source Compliance Program Manager at VMware, I’m responsible for overseeing license compliance and mitigating potential legal risks around licensing. I’ve been at it for four plus years, after earning a master’s in law and economics and a second in international business. My passion for open source compliance and helping VMware’s engineers learn about it gets me out of bed every day.
In this blog, I’ll discuss the role of an Open Source Program Office (OSPO), the different categories of open source licenses and the legal, security and business implications of using open source software.
OSPO refresher
According to the FOSSA (Free and Open Source Software Auditing) whitepaper, “The Rise of the Open Source Program Office: A Guide to Getting Started,” an OSPO “is a cross-functional team embedded in your company that helps dictate the open source strategy and policies and is a key element in ensuring your company is prepared for future evolutions.” In my own words, an OSPO is a company’s trusted advisor for all things open source.
Having an OSPO is not yet an industry standard (although we’re getting close), and OSPOs may vary drastically in form and responsibilities. The most common goal among them is creating policies and guidelines on open source compliance.
VMware’s OSPO, which I’m proud to be part of, leads open source software (OSS) efforts and strategy, driving common values and processes across all business units for VMware’s interaction with open source communities.
Use of OSS in the enterprise
Did you know that more than 90% of companies use OSS in their products and services? That although OSS is free of charge, it’s not free of obligations when using it? Have you ever considered that when your company uses OSS there’s a spectrum of different aspects you must consider and comply with? If you fail to do so, there might be serious legal, security, customer and open source community implications.
Before discussing those implications, let’s begin with an overview of OSS licenses and their use and how an OSPO helps meet compliance standards.
OSS licenses and OSPOs’ role in compliance
The most basic copyright principle states: no one has the right to use someone else’s creation without a license.
It’s a common misconception that anyone can download open or public domain source code and use it freely. In fact, open source licenses are like any other contract. They come with terms and conditions, and enterprises using OSS must meet those terms and conditions.
A simple way for non-lawyers to think about open source licenses is to consider two major license type families: permissive and copyleft (also known as reciprocal and restrictive). Most open source licenses require you to capture and share with your end user (e.g., anyone who uses your code) the license terms and the copyright of the author. For some licenses, typically the copyleft, you are required to disclose source code. That includes the unmodified original source code, plus the modified code and, depending on the way you intend to use it (if copyleft code), your own code as well. These terms can apply to both direct and transitive dependencies.
Which may lead you to the question, “How does my team work with an OSPO to comply with open source licenses?”
Usually, an OSPO manages different tools and processes that are designed to achieve compliance. VMware’s OSPO manages open source automation and compliance tools used by our product teams to scan product builds and inventory all OSS and third-party code used and shipped in the product. OSPO performs an open source licenses compliance review, where we flag any potential non-compliance issues, and the development or product team fixes them. At the end of the compliance review, OSPO provides an Open Source License (OSL) file and the data for the OSS that we need to share source code for. With this, the team may create an Open Source Disclosure Package (ODP). Having an accurate OSL and ODP is how we comply with the open source license terms and conditions.
Security implications
Another dimension of risk management is security compliance.
Now more than ever, cybersecurity is top of mind. Recent cyber incidents and threats have caused everyone – governments, businesses, end users, etc., – to stop and think about what’s in the software they use. In 2021, the White House issued Executive Order 14028: Improving the Nation’s Cybersecurity to assist in the U.S. government’s efforts to enhance and combat cybercriminals. With the EO 14028, the software bill of materials (SBOM) is now on its way to becoming an industry standard beyond government contracts.
Delivering an SBOM as a part of your software deliverables isn’t just about complying with this emerging expectation. The SBOM gives your consumers a stronger ability to comprehend the threat surface of what they are running and better enables their action to ensure its ongoing security by applying relevant updates.
Business implications
When it comes to the OSS used and shipped with products and services, it’s common to receive these questions: What OSS and which versions are used and shipped in this product or service? What are the open source licenses? How are you using the OSS? Are you modifying it?
The current business environment, marketplace, government regulators and many more organizations are demanding the answers to these questions before moving forward with a purchase. For example, if you are OSS non-compliant, you might not be able to enter into U.S. federal government contracts. That goes for your customers too, as they may pass along your compliance risks to their customers down the line. Some open source licenses are red flagged by certain organizations. Customers may assess all the OSS components you’ve used in your products and services before closing a deal or be required to abide by a regimented open source risk management practice.
Perhaps the greatest detriment to open source non-compliance is harming your company’s reputation, resulting in a myriad of consequences, such as being considered a bad actor in the open source community. Instead, having a positive reputation built on constructive collaboration with open source communities, whose code often represents a majority of the code in a product, helps your business retain freedom of action in the marketplace.
OSPO as the trusted advisor
As my colleague Dawn Foster says, “License compliance requires strict policies and procedures, but good tooling can make it easier for your employees.” This is where an OSPO comes in – by providing compliance policies, processes and tools that help engineers understand what they need to do and why – ultimately setting the foundation for your company’s open source compliance success.
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.
