Five tips for every in-house lawyer launching an open source software program | Mintz – Viewpoints on Intellectual Property

0

Used correctly, Open Source Software (OSS) is a great tool. It saves your business time and money, enables product platform interoperability, and developers love it. But used improperly, it can be financially and operationally devastating. For example, statutory damages for failure to comply with the OSS copyright notice can be up to $150,000 per act of infringement. This damage can quickly lead to serious consequences, whether it is preventing a sale or merger of your company or destroying the value of the products concerned. Another serious risk is that once OSS is used in your code base and deployed in distributed products, if your technical teams do not monitor and apply bug fixes, known vulnerabilities become horses. Trojan of opportunities for bad actors. The good news is that protecting your business against these types of risks is quite simple. Below, we’ve outlined the key steps and processes for in-house legal counsel to work with your company’s stakeholders to mitigate these risks.

1. Have a policy

Establish a documented policy that is reviewed and approved by your legal, technical, and compliance teams. Such a policy creates ground rules for the company and its developers regarding the use of OSS in all of its products and services. Most importantly, creating and deploying a policy forces productive discussions and deliberations across different functional groups to align with business concerns, goals, and best practices.

2. Be proactive

You should always know where and how the company uses OSS. This can be done by providing proactive guidance before using OSS and performing periodic audits as part of good IT hygiene before results are needed.

Shortly before an impending transaction (M&A or commercial with a client/partner) is not the time when you want to be aware of non-compliance issues. Conducting such reviews in a strictly reactive manner can present several challenges: (i) it usually leaves little or no time to resolve identified issues; and (ii) when dealing with third parties, reactive behavior and problematic results may suggest a sense of lack of sophistication/preparedness, which may undermine trust in the company or product and result in reduced revenue from transaction.

3. Integrate an iterative OSS process into the product development cycle

In many cases, it will be easier to stay ahead of OSS issues by treating OSS compliance like other legal or compliance approvals and integrating it into any product development reviews/audits used. by your company for other disciplinary approvals, such as intellectual property (IP), product clearance, safety, quality, etc. This is useful for forcing discussions early in the product development process and keeps your product management and engineering teams accountable for proper OSS usage and compliance.

4. Incorporate OSS due diligence into the vendor/component selection process

In-house legal counsel should also look upstream in the product development cycle to identify open source software used in hardware or software components that are being considered for integration into your company’s products. Particularly in the case of purchasing software or components that will be essential to a product, it is critical to understand open source exposure well in advance of integrating and releasing that product. And when reviewing competing technologies or vendors, consider the extent to which they rely on OSS and the impact this may have on your use of that OSS, such as imposing copyleft requirements on your own proprietary code, which may require you to publish and similarly grant free licenses to your own code. These licensing implications should be factored into your assessment of the cost and value of these technologies and vendors. You should also consider formalizing these business understandings and expectations in commercial agreements with third parties, such as subcontracting, consulting, joint development, and software licensing agreements.

5. Make adoption as easy as possible

Finally, one of the biggest challenges that in-house lawyers can face when deploying an effective OSS program is the sheer administrative effort the program can impose on corporate engineering teams to track OSS usage. and compliance with relevant licenses, including avoiding licensing issues, creating and publishing license acknowledgment reports, etc. There are several ways to increase the likelihood that your business stakeholders will prioritize and that your technical/product teams will cooperate with the legal team to adopt a robust OSS program.

First, partner with your IT and InfoSec organizations. Rather than focusing solely on intellectual property risks, in some cases potential InfoSec non-compliance risks, such as the consequences of using outdated OSS components with known vulnerabilities, may be more compelling to your business stakeholders. As such, your InfoSec team can be strong advocates of a proactive OSS program as a means of keeping abreast of known vulnerabilities and available fixes.

Second, as much as possible, reduce the burden on software engineers and developers who will be most directly impacted by OSS policies and analytics and who can often be overlooked by legal teams enforcing policies. The reality is that limiting the software available to your developers (i.e. due to licensing restrictions) and requiring in-depth reviews and resulting fixes after a release can create a lot of work and distract teams from their ongoing product development efforts. This can create friction with engineering/developer groups and lead to resistance or delay in policy alignment and program adoption. Wherever possible, embed automated OSS checks into the software development lifecycle (e.g., at build time) to signal and force conversations between decision makers as work is done. Several software packages are commercially available to integrate with your developers’ build tools, manage your established policy decisions on a product-by-product basis (after a policy has been developed), and raise any concerns in your management systems. engineering projects to ensure compliance and corrective action.

Conclusion

The vast majority of commercially available software today includes or is based on some amount of open source software, which can help developers and engineers create new products faster and more efficiently. But internal boards and compliance organizations must be careful and measured to monitor and maintain their company’s use of such free software to avoid significant risks and undesirable consequences.

Share.

Comments are closed.