Today, even brick-and-mortar companies often have a lot of software in their products. Software is the backbone of most organizations, and everyone uses it. And, the vast majority of the components in modern applications are open sourced.
So, why does open source license compliance matter? Just like proprietary source, open source software (OSS) is governed by the license associated with that software. The continuum of open source licenses extends from strong copyleft (which places many restrictions on the use of the licensed code) to permissive (which has very few). But, regardless of where that license is on the continuum, it’s considered a conditional license.
From a legal perspective, a conditional license says that you have the freedom to use the covered software as long as you meet certain conditions. If you don’t meet those conditions, you’re not licensed, and your use could lead to allegations of copyright infringement and/or breach of contract. Consequently, if you don’t know what open source you’re using and you’re not compliant with the applicable licenses, you could face litigation.
However, the sheer volume of different open source components in modern applications can make managing license compliance quite challenging. That’s why there’s a growing need for organizations of all types and sizes to develop an open source license compliance program.
Editor's Note: This post is written by Jim Markwith JD/MBA (pictured above), a technology and transactions attorney and the Managing Partner of Markwith Law PS.
Challenges with Modern OSS License Compliance
I work with a variety of clients, ranging from smaller startups to large, global enterprises. And, the specific nature of license compliance challenges tends to vary based on company size.
For my smallest and most early-stage clients, a common challenge is finding the right starting point to develop a license compliance program. If the organization has only a handful of developers and no in-house counsel, it might lack the bandwidth or expertise to create and implement license compliance policies.
For smaller companies that do have a license compliance program, the biggest challenge tends to be balancing compliance with the need to develop products quickly. There’s always a push to get products to market sooner, but this urgency can lead companies to cut corners. Sometimes, that manifests in open source reviews going by the wayside. The product is released, and then there are questions about OSS.
For larger companies, acquisitions can pose compliance challenges because they often result in new development teams entering the organization. The acquired company may have different theories and concepts about open source, and their engineering teams may not be used to integrating compliance into software development. Ideally, pre-acquisition technical due diligence would reveal any compliance issues impacting the actual product(s), but educating new teams on your compliance policies and the rationale behind them is quite important. Instructing engineering teams that they must do something without the reasoning behind it doesn’t usually fly.
Another concern for large companies, especially ones that have been around a while, is managing compliance across legacy products and product lines. If the organization hasn’t historically prioritized license compliance, it might have to make some tough decisions. Do you start with the 20-year-old legacy product in maintenance mode? Or the product that’s going to ship in six months? (If a legacy product is 20 years old and it’s been around for that long without litigation, it has less risk than a new product that’s about to launch and has more scrutiny.)
Ingredients of a Successful License Compliance Program
Regardless of company size, the most successful open source license compliance programs are generally built around three pillars: people, processes, and tools.
People: You need to involve the right stakeholders to help craft, implement, and enforce license compliance policies. This starts with getting buy-in from engineering and executive team leadership. If engineering and executive management don’t understand how important compliance is, they will be less likely to appropriately resource the program, or to communicate to the rest of the company that compliance is an obligation, not optional.
It’s particularly important that you collaborate with engineering leadership to ensure your compliance processes and procedures are consistent with their approach to software development. OSS license compliance that conflicts with engineering processes can not only slow product development but discourage buy-in.
Of course, staffing for an open source license compliance program can vary significantly depending on the size of a company. A larger organization might have an open source committee or open source program office (OSPO) to manage compliance decisions, staffed by one or more lawyers and engineering leads (and, sometimes, even a dedicated Head of Compliance). In contrast, a small startup with a handful of engineers might delegate compliance to a single developer who works with an outside counsel who has open source expertise. In the latter case, the two would collaborate on developing compliance policies, and the developer would be responsible for managing the day-to-day.
Processes: You should have clear, defined, and consistent processes for areas like:
- How and where compliance checks are conducted during the software development lifecycle (the earlier in the product life cycle the better)
- Escalating difficult questions about specific licenses. (I.e. perhaps you come across a new open source license that has not been reviewed or is not covered by your existing policies — you’ll want to have a clear process for running this by your OSS committee.)
- Fulfilling license notice and attribution requirements
- Responding to license compliance inquiries from customers and the general public
- Employee education and training
Tools: Given the volume of open source code in modern applications, it’s very hard to achieve compliance at scale without automation. That’s where software composition analysis tools like FOSSA come in. These tools integrate with software development workflows and automatically produce an inventory of your open source components and their licenses. They also make it easy for organizations to implement license compliance policies by flagging components on your list of prohibited licenses.
The Future of Open Source License Compliance Programs
Recent court holdings, including XimpleWare Corp. v. Versata Software Inc. et al., Case No. 13-cv-05160-SI (N.D. Cal. 2014), have increased the urgency around open source license compliance. Essentially, recent courts have held that if you develop and ship products containing open source software, you as the product owner and manufacturer are responsible for open source license compliance, not your vendors or contractors supplying the software.
The practical impact of the recent decisions is that product manufacturers can’t rely on agreements and warranties with their vendors and contractors assuring compliance with open source licenses, as it is the product manufacturer that will be held liable for non-compliance. This puts a premium on internal compliance programs for companies shipping products built with open source.
About the Author
Jim Markwith (JD/MBA) is a technology and transactions attorney and the Managing Partner of Markwith Law PS. Before entering private practice, Jim was SVP and Chief Intellectual Property Counsel for Allscripts Healthcare, Senior IP Counsel at Microsoft and GE Healthcare IT, and Corporate Counsel, Worldwide Products and Marketing at Adobe Systems. His clients range from startups to global technology leaders. His practice focuses on technology and commercial transactions, healthcare IT, data & IP protection and licensing, open source software compliance, general counsel services, HIPAA & privacy compliance, and M&A.
