How to Participate in Open Source While Maintaining IP Integrity

Open source software can provide significant benefits to an organization—it can decrease product development time, distribute development across a community, and attract developers to your organization—but some organizations shy away due to perceived risks and disadvantages around intellectual property (IP). Too many people fear that once they’ve incorporated open source into their products or open sourced their own code they’ve surrendered control over their most valuable assets, or even worse, left themselves vulnerable to litigation with no defensive weapons to counter the threat.

It doesn’t have to be that way. Utilizing open source doesn’t have to be an either-or decision. It’s possible to simultaneously support an open source program while maintaining an active IP program. A smart organization can avail themselves of the ease of use and constant updating of code that open source provides, they can identify aspects of their software to open source which are of interest to a broader development community or that encourage adoption of their platform, and they can protect those aspects of their software which are unique to their business or provide a competitive advantage through various IP protections.

Think of it in terms of a continuum. At one end are completely open sourced projects or products such as programming languages like Python, Rust, and Google’s Go. In the middle are products that make use of a combination of open source and proprietary code. At the far end is completely closed, proprietary software.

The key idea is to think strategically about the software, the value it can provide to the company, and whether the technology should be developed in-house. In some cases, software can provide more value to the company when it includes open source components. Here at Dropbox, for example, we use open source software in our products and we use it to help with development. Our engineers are encouraged to consider open source for build tools, compilers, and analytics tools that allow us to evaluate our products. For those types of tools, it’s nice to know we can rely on a whole community to identify weaknesses and bugs and to continuously add new features. It’s an aspect of development we don’t have to invest in ourselves.

Even here there are a few ground rules: We evaluate the code on the way in so we know what has been incorporated in our software later. And we prohibit code that is licensed under more restrictive terms that could require us to open source our product in turn.

We also contribute back to the open source community by making contributions to others’ open source projects and open sourcing some of our own projects. With each contribution, we evaluate the IP rights that we may be granting to the community. For example, when we contribute to an existing project we consider whether that contribution will require us to grant a license to one or more patents in our portfolio. Or when we open source an entirely new project we consider whether the company’s goals would be better served by maintaining it as proprietary code and protecting it through trade secret protection or patents.

For some strategic products we take a hybrid approach. We recognize the value in open sourcing the code and in preserving some IP rights so we simultaneously open source an implementation and file for a patent, scoping the patent and the license terms so the open source community can use the software without making the patent worthless to us. Licenses like the Apache 2.0 license are one way to ensure this layered protection; licensees can use your code for the particular implementation you have open-sourced, without necessarily obtaining a license to a broader idea in the patent for other uses.

Customized open source licensing agreements are also possible. For example, adding a custom patent license to an existing open source license that is silent on patent rights. Or adding a defensive termination clause that allows the patent holder to terminate a license if the licensee sues. The breadth or strength of the defensive termination clause can also be customized. Ranging from the narrower termination provisions in the Apache 2.0 license to much broader provisions that allow for termination when the licensee sues the licensor for anything, even if the lawsuit isn’t related to the open source project.

Defensive aggregators, like LOT Network and Open Innovation Network, are yet another way to participate in the open source community without exposing your company to excessive risk. Within LOT Network, for instance, members agree to license terms that provide one another with immunity from patent troll lawsuits if and only if one of the members’ patents is sold to a troll. This is particularly meaningful for the many smaller companies within the open source community, since over half of companies sued by patent trolls make less than $10M in annual revenue.

In all cases the first step is to determine the type of intellectual property you are trying to protect, and then develop a system for ensuring the vital elements remain under your company’s control and ownership. Open source doesn’t have to mean the end of ownership; used thoughtfully and with the right legal protections around it, it can be an invaluable tool for building your own intellectual property assets more rapidly and securely.