Trump’s Group and Vizio Cases: The importance of OSS compliance

This case is interesting as it is very similar to a previous claim that the SFC has fought and won against Westinghouse (Westinghouse included the BusyBox GPL-licensed code as part of its HDTVs and didn’t provide users with access to the source code). Furthermore, the SFC had issued a public warning to Trump’s Group that they have 30 days to remedy the AGPL violation in the Mastodon software, or their rights in the software will be permanently terminated. Trump’s Group has so far ignored requests to access the AGPL source code deployed as part of the software powering their social media platform. 

In this blog post, we provide a brief historical perspective on open source license non-compliance cases, explore sample compliance inquiries and provide a single recommendation to help organizations avoid compliance issues.

Historical perspective 

In the past two decades, several companies have been in the public spotlight concerning open source license non-compliance. These companies were subject to compliance inquiries, and as a result of mishandling these inquiries, they have received negative publicity and have been subject to legal action. A common trait of these various non-compliance cases was how these companies reacted and managed the inquiries. 

• They did not know how to handle open source license compliance inquiries or handled them very poorly
• They refused to cooperate and cut off communication lines with the inquiring party 
• They ignored requests to provide compliance information and source code
• They lacked or had a poor open source compliance program
• They thought that open source licenses were not enforceable 

These behaviors are similar to what the SFC is experiencing with both Vizio and the Trump Group. Best practices inform us that none of these behaviors or approaches to resolving the issue at hand is beneficial to any party involved. 

Companies should not ignore compliance inquiries. Instead, they should acknowledge receipt of the questions, stay in constant communication with the inquirers, do their internal research, report their findings, and work to resolve the issue (if applicable) within a reasonable time frame.

Compliance inquiries 

Open source compliance inquiries can include requests for several things that vary from one case to another. As an example, compliance related questions can consist of one or more of the following:

• Access to source code following a written offer to provide source code for instance licensed under the GPL, LGPL, and the AGPL
• Updating compliance notices to include a previously undisclosed open source component found in a product or a software platform providing an online service 
• Access to source code for a previously undisclosed component found in a product or service 
• Verification of whether a specific open source component exists in a product or service
• Update to an out-of-date attribution, copyright notice, written notice, etc. 
• Provide missing files from open source packages made available as part of license obligations

Companies usually receive compliance inquiries through a dedicated email address advertised in their written offer or website.

Ensure compliance before product or service launch

The most important outcome of non-compliance cases has been that companies have to comply with the terms of the open source licenses. Therefore, it is highly recommended to ensure compliance before product ships or a service launches. 

It is essential to acknowledge that compliance is not just a legal- department exercise. Everyone within a given company has a role to play to ensure proper open source license compliance. This involvement includes establishing and maintaining consistent compliance policies, processes, guidelines, and tools to automate the process.

To that effect, companies need to implement an open source compliance program and empower their staff with software composition analysis tools that will allow them to identify all open source software used with their corresponding licenses. With such information, companies can then plan on fulfilling open source license obligations before the product or service launches and avoid any open source compliance issues. However, compliance is not a destination as development continues, therefore it is an ongoing activity that evolves with your development efforts.

Compliance is an ongoing effort

The increase of open source adoption across all industries in the past decade has caused organizations of all sizes to establish teams and programs to manage their security and compliance efforts. Managing your open source software activities (consumption, compliance, and contribution) has become a critical aspect of managing software development efforts. Organizations dedicate a team to run audits on the codebase identifying used open source code, their origin, license, and any known security vulnerabilities. The audits are automated using an SCA tool with abilities to manage both security and compliance.

Depending on the level of automation implemented, this process is often time-consuming and a significant burden on engineering teams. Time for audits is rarely planned, and dropping everything you’re doing to scan your entire codebase once a quarter is on no one’s wishlist. Our recommendation is to implement a “scan early and often” methodology. 

Continuous and automated audits have several advantages:

1. It keeps the amount of code to be scanned and analyzed minimal, allowing a more granular analysis. 
2. Frequent scanning allows to discover issues early on and provides time to re-engineer without significant delays or time penalties. 
3. It keeps your organization’s software BoM up-to-date and gives you a current view of all open source software entering your product or service stack. 
4. It eliminates the need for developers to fill out forms requesting permission to use open source software.
5. It keeps your organization ready for any corporate transaction, such as an M&A transaction, where source code audits are required.

Closing

If you’re reading this blog post and you don’t have an open source compliance program yet, we would urge you to take the first step into establishing a program to manage the consumption of open source software from a compliance and security perspective. 

The easiest way to take your first step towards this is implementing an SCA tool which automates the process.

Cumulative and periodic audits allow you to easily manage the compliance aspect and keep a good handle on tracking any security vulnerabilities, for example, Debricked scans your code at every commit. Furthermore, they allow you to discover changes to the software code base in terms of:

• New software that has been introduced
• Existing software that has been retired
• Existing software that has been upgraded to a more recent version
• The license on a software component may have changed between versions
• Existing software components may have code changes involving bug fixes or changes to functionality and architecture

If you are looking for a software composition analysis solution that helps strengthen your open source security and compliance posture with minimal effort, create an account and start using the Debricked tool today.