As a VP of engineering, I have more than once scrambled to reconcile some aspect of my team’s use of open source before closing a major business agreement. While the use of open source is almost never a driver behind the acquisition of a company, more than a few deals have fallen through due to the risk of IP contamination. So here are a few tips that can be applied in your organization to avoid an open source scramble.

Step 1: Define a Policy

The approach to open source varies by business, and so should be clearly documented and communicated to an organization. I use a simple visual matrix to communicate the business policy, with the goal of providing clear direction to my engineers. A sample matrix is below.

The rows of the matrix call out the different types of licenses my organization may encounter, and the columns the different uses for the open source. The color coding denotes the action the organization should take. For example, green denotes the organization is free to use the open source, provided it is documented; yellow means the open source must be approved before using; and red means the organization will not use this open source under any circumstances.

The key in defining your policy is to strike the right balance between mitigating risk to your IP while maintaining the necessary agility for the organization.

Step 2: Educate

The only way to proactively manage open source is to engage your team in the process. The major build versus buy/use decisions are often the easiest ones to control, since they have high visibility in an organization. Unfortunately the vast majority of open source decisions get made by individual engineers while solving an immediate problem.

A simple overview of the organizational policy with a discussion on the different types of open source (e.g. copyleft, weak copyleft) is usually sufficient to enlist the team in managing the business risks. Having spent a year engaged in technical due diligence for a Fortune 100 technology company, I acquired a unique appreciation for the importance of open source management. I often use this experience to personalize the value of a policy in my team.

Step 3: Track

I use a simple spreadsheet format to track the use of open source. The goal of the spreadsheet is to have a centralized place to track the software used, its license, its use, and any obligations/implications (e.g. license attribution, re-distribution of modified source). The typical fields in the spreadsheet may include:

  • Product - The name of the open source product, ideally hyperlinked for quick lookup by an auditor.
  • License type - The type of license, again hyperlinked for lookup.
  • Version - Open source project sometimes change licenses between versions, so clear identification of the version is important.
  • Source code modified - Whether the organization modified the source code.
  • Deployed to production (hosted) - Whether the open source is deployed to a SaaS or non-production infrastructure.
  • Deployed to customer - Whether the open source is deployed to a customer environment.
  • Integration type (static / dynamic) - Whether the open source is linked to your proprietary source code via static or dynamic linking. Confession: I always have to talk to an IP attorney to understand what is considered static versus dynamic linking, since it seems to change over time and by attorney.
  • Attribution - Whether the license requires attribution in customer license agreements.
  • Publish source code - Whether the use of the open source requires the re-publishing of modified source.
    A shared document like Google Spreadsheet is a great mechanism to allow tracking of open source. You can provide edit permission to the people assigned to track open source (e.g. team leads), but ensure the document is publicly accessible by all. I would encourage enlisting a few lieutenants in the tracking of open source.

Step 4: Audit

A periodic audit is essential to maintaining a good open source bill of health. Application packaging has made it increasingly easy to unknowingly adopt open source that may be against your organization policy. For example, a developer can include a Ruby gem that is consistent with the policy, but includes one or more dependent gems that introduce risk to your IP. Furthermore, many open source projects customize standard license agreements, making it necessary to fully review the license to understand the risks and obligations.

I find a runtime audit to be the most effective way to identify gaps in your tracking, which can be implemented as just a story executed during a sprint. The goal of the audit is to identify gaps or inconsistencies between your tracking spreadsheet and the running software. A quarterly audit is often sufficient for most small organizations.

Conclusions

The reduction we see in the cost of engineering over the last decade can in a large part be attributed to the pervasive use of open source. Almost no software product is developed today without the use of hundreds of open source products. The classic build versus buy decisions of the 1990s have more become build versus use today.

When you need a comprehensive and authoritative understanding of the risk to your IP, there is no better solution than leveraging a product or service from a company that specializes in the evaluation of open source (e.g. our local Black Duck). But unfortunately, most IP scanning products are priced out of the range for regular use within a startup, and so internal manual management is almost always a requirement

The above four steps is a low-cost way to mitigate risk in your organization. But whatever approach you take, don’t wait for an M&A event or a major OEM agreement to find out if your IP is at risk.

I was a couple years out of college and working on my first patent filing when I was asked by an IP attorney to "print out the first 100 pages of the software.” I think I just about spit out my Diet Coke. Fortunately IP attorneys have come a long way since then. ;)

Related Posts: The 4 Dimensions of Scale