Open source software imparts a number of benefits, including decreasing product development time, distributing development across a community and attracting developers to your organization. However, some organizations shy away from it due to perceived risks and disadvantages around intellectual property. Once you’ve incorporated open source into your products or open sourced your own code, it’s common to worry that you’ve surrendered control over your most valuable assets, or even worse, left your organization vulnerable to litigation with no defensive weapons with which to protect yourself.
Good news: it is possible to simultaneously support an open source program while maintaining an active IP program. Smart organizations can avail themselves of the benefits of open source, identify the aspects of its software that are of interest to a broader development community—and thus good candidates for open sourcing—and protect those aspects of its software that are unique to the business or provide a competitive advantage through various IP protections.
The issues exist on a spectrum. There are 100 percent open sourced projects or products at one end, like the programming languages 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 proprietary software that is 100 percent closed. Most businesses today are somewhere in the middle. To strike an effective balance between open source and proprietary code, organizations have to think strategically about the value a piece of software provides to the company and whether it makes sense to develop it internally.
Here are six tips for helping organizations participate in open source and maintain their IP integrity.
Pick and Choose
There are instances where software is actually more valuable because it includes open source components. For example, Dropbox encourages our engineers to think about open source when working on compilers, build tools and analytics tools that enable our team to evaluate and assess our product. These tools support our development efforts. And by integrating open source components, Dropbox is engaging with a strong community to help us pinpoint weak spots, identify bugs, and maintain a steady pace of new feature releases. Not developing these capabilities exclusively in-house frees our engineers up to focus on projects that really drive the business.
Due Diligence
Of course, the push to explore open source options comes with guidelines. It’s important to vet all open source code thoroughly and keep clear documentation so, down the road, we know what’s in our code. In addition, we don’t incorporate code with restrictive licensing, because it could mean we have to open source our own product.
Give Back
Something else we keep in mind is that open source is a two-way street. The community is stronger when everyone gives and takes, which is why Dropbox gives back to the community by contributing to other open source projects and open sourcing some of our own. With each contribution, we evaluate the IP rights that we may be granting to the community by asking a series of questions. For example, will contributing to an existing open source project require us to grant licenses to patents in our portfolio? Will open sourcing a particular project achieve our goals? Or can we better achieve our goals by maintaining proprietary code that is protected?
Layered Protection
Just as many organizations adopt a hybrid approach to open sourcing, the same can also be true for specific products. There are certainly cases where there is value in open sourcing code, but some of the IP rights need to be preserved. That’s a situation in which we might open source an implementation and file for a patent at the same time. In scoping the patent and the license terms, the open source community gets access to the software but the patent retains value. Apache 2.0 is an example of a license that delivers this layered protection. It allows other organizations to use open-sourced code for a specific use case, and receive a patent license for that code, but the granting organization retains the value for the rest of what the patent covers.
Customized Agreements
Another hybrid approach is to create customized open source licensing agreements. Say you have an open source license in place that doesn’t say anything about patent rights—an organization can add a custom patent license or a defensive termination clause that gives patent holders the ability to terminate a license if the licensee sues. Termination clauses can be customized to be stronger or weaker, broader or narrower, depending on the needs of the situation. For example, an organization could make a clause broader by adding provisions that allow licensors to terminate the license if the licensee sues at all—even if the lawsuit is unrelated to the open source project.
by: Gideon Myles, Corporate Counsel