How to protect your business when using open source software


“By focusing on compliance and preventing future compliance risks, litigation can be handled as a last resort for open source software disputes. However, disputes around the OSS occur.

Today’s software is built like a Lego model. Instead of an individually developed string of code, multiple building blocks of existing code are used to create a codebase. Some of these building blocks are developed in-house by the software vendor. Others are developed by third-party commercial software vendors. And many of them come from open source projects.

When you are a business integrating this codebase into your final product, you must take precautions to minimize the risk that each type of code presents to you and your customers. This is what is meant by protecting your software supply chain. It’s also how you maximize the value of the code for you and your customers. Each type of code has its own set of benefits and risks that must be understood and managed. This article discusses only one type of these building blocks: open source software (OSS).

The benefits of using OSS are significant; it can speed up development cycles, it allows for specialization in key areas, and it taps into the knowledge of a wider variety of individuals. Like any code, the use of OSS carries certain risks. The one you’ve probably heard the most about is security, like Log4J Where Spring4Shell. These headlines should be enough for every OSS user to sit up and take notice, but they are not the only sources of risk. Let’s take a look at a few other risks, though they’re (thankfully) unlikely to make the headlines.

  • Business risks: M&A due diligence requests; contractual guarantees; limitations on go-to-market models.
  • Commercial, development and operational risks: reliance on competitor or hostile party code or orphaned/dead project; lack of ultimate responsibility for code quality; poor support; break from version to version; version-to-version changes of license rights.
  • Licensing and Compliance Risks: use of OSS beyond the scope of the license; license violation resulting in copyright infringement; viral infection of proprietary code; patent risks; combining components under incompatible licenses; award notice and non-compliance; violation of licenses for “third party” components.
  • Remediation risks: code correction (removal, rewrite or replacement of code); legal redress; risk mitigation/allocation.

Despite this long list of risks, the good news is that a simple set of best practices can help you manage and mitigate them all. These practices are generally referred to as the OSS licensing program.

Know your code and your obligations

The first step to securing your code is to identify the code you are currently using. It might sound daunting, but with the various Software Composition Analysis (SCA) tools on the market, your hardest job is actually deciding which one is right for you. And depending on your specific needs, you may end up using more than one tool. The process you run is less important than the output you get. Ideally, your result should include three elements:

  1. The first is a software nomenclature (SBOM). An SBOM provides a detailed inventory of the software components you use. The SBOM identifies components, versions, and associated licenses, centralizing the information needed to manage your OSS building blocks. An SBOM enables software vendors to respond to requests for detail of your software content, whether requested by customers at the time of a product sale or by potential buyers at a merger and acquisition event. . SBOMs are also key to complying with Biden administration guidelines Executive Order on Improving the Nation’s Cybersecurity. Creation and maintenance of SBOMs can be automated with a comprehensive SCA program, which supports component, license, and vulnerability management.
  2. Once you have your SBOM, you can move on to creating your notice or attribution sheets. This is one of the main requirements of any OSS license. It lets downstream users know where you got the OSS by identifying and giving attribution credit to people who developed the OSS.
  3. After review/award file, you can start tracking license types apply to which OSS elements in your solution. This allows you to start confirming that you have complied with all aspects of the OSS license, understanding what they have and where they are exposed.

After developing the SBOM, developing the notice/attribution file, and understanding the different license types associated with the OSS you are using, the final step is to ensure that your hard work does not require be repeated. To do this, you need to establish and enforce an easy-to-follow policy for your engineers when considering adding additional OSS to your products.

Develop an Open Source Policy and Be Brief

Your organization should have a clear policy on the use of open source software, with the aim of defining what can be used and how. Essentially, it specifies which risks are and are not acceptable. This policy becomes a fundamental guide for the developers doing the work. The policy should therefore be brief, manageable and available early in the development process.

Expand business opportunities, while minimizing legal risks

Addressing each of these risks costs time and money. Investment can be minimized and businesses can be supported with effective preventive measures.

Obtaining organizational buy-in for legal initiatives is often difficult. But if you approach the chief technology officer (CTO), chief financial officer (CFO), or your engineering department early with a full explanation of how minimizing legal risk can expand business opportunities, you may find an opening. more efficient for conversations and for the budget. .

With the right policies and analytics tools in place, developers have a more efficient and secure way to develop products. Being knowledgeable about third-party licensing obligations and developing software accordingly the first time is far better than having to invest time and money in patching and re-engineering. The gain is twofold: creating value for the organization while guarding against security and compliance risks. This approach can help turn risks into opportunities.

Avoid disputes

By focusing on compliance and preventing future compliance risks, litigation can be handled as a last resort for open source software disputes. However, disputes around the OSS occur. This actually happens more than one might assume, but in most cases it is settled behind closed doors. When publicly tested, the GNU General Public License (GPL) has been determined as an enforceable license. High-profile cases filed to enforce open source licenses have varied significantly. For example, Patrick McHardy, formerly of the Netfilter project, identified interpretations of the GPL that were often not accepted, but against which a conformance claim could be made in order to threaten the application; his actions were seen as “to profit from”. In a very different case, which may set a precedent for copyright and open source contract issues more broadly, the Software Freedom Conservatory filed a right to repair lawsuit against Vizio regarding the GPL copyright license in the manufacturer’s TV products. The lawsuit seeks to force Vizio to share the source code with all users. Progress with this case, as reported in ZDNet“makes it the first case to show that individual consumers have rights to source code as third-party beneficiaries of the GPL.”

Seize the opportunity

Open source software is a tool that, when used correctly, can provide tremendous value. As the legal landscape around it evolves, a proactive and streamlined approach to managing open source software can contribute to success.

Image by Marty Mellican


Comments are closed.