How Legal Teams Can Support Proper Use of Open Source Software

06
Nov
2019

Marty Mellican

Open source software (OSS) – some of the best, cleanest, and most secure code in use today – permeates project development at every level. Because of its widespread use, legal counsel will encounter it in almost any business. 

While OSS is often free in price, it is never free from obligations. The security risk that open source software creates isn’t that the code is likely to be problematic. The greater risk is that you won’t know where you use it – which means that you won’t know where to patch it. How can your organization ensure that it uses OSS properly and takes proper precautions with it?

By evaluating and understanding the complex tech and intellectual property (IP) licenses and the downstream liability that are part of OSS, engineering and business teams will strengthen their processes and policies in managing open source. Here, we look at how legal teams (including both in-house and outside counsel) can help companies properly use open source software by setting policy and guiding the open source discovery process. This measured approach to OSS management respects the valuable asset that your company is tapping for commercial purposes, while protecting the company’s valuation, helping to monetize the company’s own proprietary software and products, protecting the company’s valuation, and facilitating a positive outcome in the case of a merger or acquisition. 

What is OSS? 

Open source software can be defined in multiple ways. At its core, it has “source code that anyone can inspect, modify, and enhance;” its distribution must be in compliance with various criteria. Of particular note: OSS has enforceable copyright. Open source code should not be (though commonly is) confused with code that’s in the public domain, for which the copyright has either expired or where the copyright was waived by its owner. Additionally, open source consumers owe a duty to the producers of OSS to respect their licenses and contribute to the open source community. Users must be diligent in their respect to OSS license requirements; they should also contribute code to the community or make financial contributions to open source projects.

In understanding these often-overlooked considerations, a legal department has a unique vantage point. The legal team can identify the responsibilities across an organization and identify processes to manage interdependencies. 

Software composition analysis (SCA) is an important component of OSS management. SCA – which addresses vulnerability management, license management and component management – can illustrate the impact of open source software on warranties, license agreements, and in mergers and acquisitions. A thorough software composition analysis program will not only identify open source software so that its impact can be considered. The best SCA tools and audits track down everything – not just big stuff and known vulnerabilities. In the rare event where open source software is problematic, you’ll be alerted to exactly where it’s deployed, facilitating immediate patching.

Main Considerations of OSS Compliance

Managing open source use and compliance, complete with an SCA component, is essential. The legal team plays a critical role in training staff, organization-wide, about the importance of such a program and the implications for development and sales teams – and for customers.

Mergers and acquisitions are a critical consideration for OSS compliance. If your company is likely to be bought or sold at some point in the future, understanding what a potential buyer will see is a great way to move forward. A software composition analysis scan can identify where OSS is and confirm that your company is following a proper due diligence process. If risks exist, being prepared to disclose them to the other side is important. If you’re in the position of onboarding a new technology, understanding the associated risks (and where they’ll be deployed) is crucial.

From a security perspective, comprehensive source code analysis informs a company about where it has deployed open source software. For example, Heartbleed, a security bug introduced in 2012 and disclosed publicly in 2014, is still being used – and still exposing users to significant vulnerabilities. It’s still in use not because there isn’t a patch, but because people hadn’t been tracking their usage or performing deep scans for it. Unfortunately, many companies don’t pay sufficient attention to ongoing compliance risks (and possible data breaches) that come from security issues. 

Finally, if your company will be contributing open source code to the community, protect your proprietary technology. If your staff engineer wants to distribute open source code, be sure that it has a clean contributor’s license (which governs downloading the code) and that it has all appropriate certifications from the developers.

Get Started 

Effective open source management is an iterative process. To get started, or to take the next step in an existing program, consider each of the following:

1. Create an Open Source Review Board (OSRB). Bringing together the right people – from legal, engineering, product management, and procurement – can help your organization monitor what’s coming in and be sure that all policies and procedures are followed. An OSRB can also help the legal team delegate the obligations and responsibilities that are part of open source software compliance, while also supporting training efforts for staff about the responsibilities of OSS.
2. Establish your ground rules. Put a reporting structure and policies in place with simple, clear decision trees. While this needs to be flexible to accommodate changing business models, make sure that expectations are clear, manageable, and fitting for your company. This process shouldn’t be completely owned by legal, but should be a conversation between legal, decision makers (e.g., the VP of engineering and the engineer who wants to consume the open source), and other subject matter experts.
3. Understand the value of protecting IP. Establishing a clear and precise legal structure for licenses (e.g., contributor’s license, IP policy, and bylaws) can ensure that your organization protects the IP that you use. Make sure that a contribution has the right certifications from the developers and that, if your company takes in third-party code, it is documented appropriately. A clear process will also save time for legal teams.
4. Determine the risk spectrum. Define and understand the risks present across product lines and business processes. For example, a SaaS company will be more susceptible to an Affero General Public License, while an on-premises company is more susceptible to risk in copyleft licenses. 
5. Begin with one product. Start small with your open source review process. Focus on one product or a small app before expanding. 
6. Do an OSS scan. A scan, whether in-house or through a third-party SCA review, can be a great way to kick-start a process. It’s critical that you track all of the components that make up your software. If it turns out there is a problem with a specific open source component, you know where it is deployed immediately. Scanning is also a great way to get staff to understand the scope and nature of existing OSS to make sure that you’re participating in the open source community responsibly. 
7. Begin remediation. Start with the highest priority revealed in your scan, then repeat the process. As you come across new situations, as your company grows, and as staff shares innovative ideas, be open to adjustments and improvements.

Your company’s revenue depends on its products; be sure to know where third-party code is embedded. Additional information about best practices in open source management and legal counsel’s role, view the webinar “Open Source Software: The Legal Power of Three.”