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. It’s because of these benefits that we at Dropbox love open source. However, some organizations shy away from it due to perceived risks and fears around lost intellectual property (IP) rights. You’re not alone if you’re worried that once you’ve incorporated open source into your products or open sourced your own code that you’ve surrendered control over your most valuable assets, or worse, left your organization vulnerable to litigation with no defensive weapons to counter the threat. We too had that concern when we embarked on formalizing our open source program.
Good news: it doesn’t have to be an either-or decision. It’s possible to simultaneously support open source while maintaining an active IP program. Smart organizations can avail themselves of the benefits of open source—decreased development time, community supported development and code review, platform adoption—and use various IP strategies to protect those aspects of its software that are unique to the business or provide a competitive advantage. We’ve taken a hybrid approach with several of our projects including Lepton, our streaming image compression format.
When thinking about participating in open source the issues exist on a spectrum. There are 100% 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 are proprietary products that are 100% closed source. Most businesses today are somewhere in the middle.
Here are some tips for helping organizations participate in open source while maintaining their IP integrity.
Identify your Motivation
An important aspect in maintaining balance is identifying why you want to support an open source program. For example, is it because you don’t want to re-create the wheel, do you want to help maintain existing open source projects, do you want to use open source to attract and retain talent, do you want to promote your platform, do you want to be well-rounded open source participants, or is there some other reason? These are all legitimate motivators that can help you shape your open source program, identify risk, and chose the appropriate IP strategy.
For us, it’s really all of the above, but sometimes only a subset of the factors apply to any individual open source opportunity. When we considered open sourcing Lepton at least two of the factors surfaced as key motivators: promoting our platform—we really wanted our compression technique to be adopted and incorporated in client applications like web browsers—and promoting the achievements of the engineers who developed the technique.
Pick and Choose
To strike an effective balance between open source and proprietary code, the key is to think strategically about the software, the value it can provide to the organization, and whether the technology should be developed internally. 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 up our engineers to focus on projects that really drive the business.
Contribute 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 few simple 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 through trade secrets or patents?
Blended 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 there is additional value in preserving some of the IP rights. 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.
Lepton is just one example of open sourcing our own projects, but it is one where we had serious discussions about our goals and how to achieve them. We can use the compression technique on our servers—and save storage space—and we could incorporate it into our client applications and compress the content before it is transferred to our servers—and save storage space and synchronization time. Because the compression technique provides such a significant savings it has clear business value and could provide a competitive advantage. So we saw a strong case for maintaining it as proprietary code and protecting through IP protections like patents.
However, our client application isn’t the only way that files end up in a user’s Dropbox account. For example, some users upload content through the web. By open sourcing Lepton, it could be incorporated into web browsers, allowing files to be compressed client side. This provides a better user experience—decreased upload time—and space savings for us. So we also saw a strong case for open sourcing Lepton.
After considering both sides it was clear to us that this was a prime scenario for a hybrid approach: open sourcing Lepton while simultaneously filing for patent protection. Ultimately, that is what we decided to do, and we open sourced it using the Apache 2.0 license. We get our compression technique out to the public, promote adoption, and benefit from insight from the community, but we protect some value for the company.
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 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.
When we open sourced Lepton we could’ve chosen a customized license or added a patent clause to an existing open source license. We opted for a traditional, permissive open source license that includes an explicit patent grant because it satisfied our needs. We want to promote adoption of Lepton, which we believe is achievable using an established permissive license. We also wanted clarity around which patent rights we’re granting (and what rights others are receiving), which the Apache 2.0 license provides.
Due Diligence and Mutual Awareness
Unfortunately, participation in open source isn’t without risk, so 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, what we’ve open sourced, and what responsibilities we bear. Additionally, it’s important that there’s mutual awareness about the company’s open source and IP strategies. True balancing can’t happen without strategy alignment and communication.
Defensive Aggregators
Finally, you can participate in open source and decrease risk by joining defensive aggregators, like LOT Network and Open Innovation Network—an organization designed to protect the linux kernel from patent litigation. In LOT Network, members sign agreements that include licensing terms which immunizes them from patent troll lawsuits, if (and only if) a fellow members’ patents are sold to a troll. Given that over half of companies sued by patent trolls make less than $10M in annual revenue, this type of agreement is especially beneficial to smaller companies in the open source community. And you don’t have to already have your own patents to participate in LOT Network.
Whatever the case and whatever your goals, the first step is to figure out what kind of intellectual property you want to protect. The next step is to develop a system that ensures the vital elements remain under your company’s control and ownership. Open source doesn’t have to mean the end of ownership. If you’re smart about your open source/IP strategy, participating in the open source community can be an invaluable tool for building your own intellectual property more rapidly and securely.
