Five Tips For Every In-House Counsel Launching an Open Source Software Program

Used properly, Open Source Software (OSS) is an excellent tool. It saves your business time and money, enables interoperability of product platforms, and developers love it. But used improperly, it can be financially and operationally devastating. For example, the statutory damages for failure to properly adhere to the OSS copyright notice can be up to $150,000 per act of infringement. Those damages can quickly add up to serious consequences, whether preventing a sale or merger of your company or the destruction of the value of the affected products. Another serious risk is that once OSS is used in your code base and deployed in distributed products, if your tech teams are not monitoring and applying bug fixes, known vulnerabilities become Trojan horses of opportunity for bad actors. The good news is that protecting your company from these types of risks is rather simple. We have outlined below key steps and processes in-house counsel should take to work with your business stakeholders to mitigate these risks.   

1. Have a Policy

Establish a documented policy that is vetted and agreed upon by your legal, technical, and compliance teams.  Such a policy creates ground rules for the company and its developers regarding usage of OSS across its products and services.  More importantly, creating and deploying a policy forces productive discussions and deliberations between different functional groups to align on concerns, goals, and best practices for the company.

2. Be Proactive

You should always know where and how the company is using OSS.  This can be done by providing proactive guidance prior to OSS use and periodically conducting audits as part of proper IT hygiene in advance of a need for the results. 

Shortly before an impending transaction (M&A or commercial with a customer/partner) is not the time when you want to learn of non-compliance issues.  Performing such reviews strictly reactively can present several challenges: (i) this typically leaves little or no time to remediate any identified issues; and (ii) when dealing with third parties, reactive behavior and problematic results can suggest a sense of lack of sophistication/readiness, which may undermine confidence in the company or product and lead to reduction in transaction revenue.

3. Build an Iterative OSS Process into 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 incorporate it in whatever product development gate reviews/checks are used by your company for other discipline approvals, such as intellectual property (IP) product clearance, safety, quality, etc.  This is helpful to force 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 Diligence into Vendor/Component Selection Process

In-house counsel should also look upstream in the product development cycle to identify OSS used in hardware or software components being considered for incorporation into your company’s products.  Particularly in the case of procuring software or components that will be material to a product, it is critical to understand OSS exposure well in advance of integration and commercialization of that product.  And when vetting competing technologies or providers, consider the extent to which they rely on OSS and how that may impact your use of that OSS, such as imposing copyleft requirements on your own proprietary code, which can require you to publish and similarly grant free licenses to your own code.  These licensing consequences should factor into your assessment of the cost and value of such technologies and providers.  You should also consider formalizing these commercial understandings and expectations in commercial agreements with third parties, such as contractor, consulting, joint development, and software license agreements.

5. Make Adoption as Easy as Possible

Finally, a primary challenge in-house counsel may face in deploying an effective OSS program is the sheer administrative effort that the program may impose on the company’s engineering teams to keep up with tracking use of OSS and compliance with the relevant licenses, including avoiding problematic license, creating and publishing license acknowledgement reports, etc.  There are a few ways to increase the likelihood that your business stakeholders will prioritize, and your technical/product teams will cooperate with the legal team in, adopting a robust OSS program.

First, partner with your IT and InfoSec organizations.  Rather than focusing solely on the intellectual property based risks, in some cases, the potential InfoSec risks of non-compliance, such as the consequences of using out of date OSS components with known vulnerabilities, may be more compelling to your business stakeholders.  As such, your InfoSec team may be a strong co-advocate of a proactive OSS program as a means to keep up to date with known vulnerabilities and available patches.

Second, as much as possible, reduce the burden on the engineers and software developers that will be most directly impacted by OSS policies and scans and can often be overlooked by legal teams imposing policies.  The reality is that limiting the software available to your developers (i.e., due to licensing restrictions) and demanding extensive scans and resulting remediation after a build 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 aligning on a policy and adoption of a program.  Where possible, incorporate automated OSS checks into software development cycle (e.g., at build time) to raise flags and force conversations among decision makers as the work is being done.  Several software packages are commercially available to integrate with your developers’ build tools, manage your established policy decisions on product-by-product bases (after a policy has been developed), and raise any concerns in your engineering project management ticketing systems to drive compliance and remediative action.

Conclusion

The vast majority of commercially available software today includes or is based upon some amount of open source software, which can help developers and engineers more quickly and efficiently create new products.  But in-house counsel and compliance organizations should be cautious and measured to monitor and maintain their company’s use of such OSS to avoid significant risks and undesirable consequences of doing so. 

To learn more from the Mintz IP team, follow us on LinkedIn and check out our Exclusive Rights podcast.

Subscribe To Viewpoints