Open Source and Proprietary Code: Why It Doesn’t Have to Be a Trade-Off
Open source software brings clear advantages: faster product development, community-driven code review, and a stronger recruiting pitch for engineers. Yet many companies hesitate, worried that incorporating open source or publishing their own code means surrendering control over valuable intellectual property—or leaving themselves exposed to litigation. Those fears kept some of us at Dropbox cautious when we first formalized our open source program.
The good news is that supporting open source and maintaining a robust IP strategy are not mutually exclusive. You can take advantage of community development while still protecting the parts of your software that give you a competitive edge. The spectrum runs from fully open projects like Python, Rust, or Go, through hybrid products that blend open and proprietary code, to fully closed products. Most companies operate somewhere in the middle. We take a hybrid approach ourselves, as we did with Lepton, our streaming image compression format. These are the considerations that helped us find that balance.
Start with Your Motivations
The first step is understanding why you want an open source program at all. Are you trying to avoid reinventing the wheel? Do you want to maintain existing projects, attract talent, or push adoption of your platform? Every one of these is a legitimate reason, but each implies a different risk profile and calls for a different IP strategy.
When we considered open sourcing Lepton, two motivations stood out. We wanted the compression technique widely adopted—ideally built into client applications like web browsers—and we wanted to highlight the work of the engineers behind it.
Choose What to Open
Not every piece of software deserves the same treatment. Some code becomes more valuable when it incorporates open source components. At Dropbox, we encourage engineers to lean on open source for compilers, build tools, and analytics utilities—the sort of internal tooling that supports our product without defining it. Tapping into a community for those elements helps us find bugs and keep pace with new features, while freeing engineers to focus on projects that directly move the business forward.
Open source is also a two-way street. The community only works when everyone contributes, so we give back by both contributing to existing projects and open sourcing some of our own. Before each release, we ask a few pointed questions: Will this contribution require us to grant licenses to patents in our portfolio? Does open sourcing this project actually achieve our goals? Or would trade secret or patent protection better serve us here?
Consider Blended Protection
Just as companies can be hybrid, so can individual projects. There are cases where publishing code is valuable, but retaining some IP rights is even more valuable. In that scenario, we may open source an implementation and file for a patent at the same time.
Licenses like Apache 2.0 support this layered approach. They grant others a license to use the code for a specific purpose—including a patent license for that use—while the originator keeps control over the rest of what the patent covers.
Lepton illustrates how we weighed both sides. The compression format delivers significant savings in storage and sync time, so it has clear value as proprietary code that could provide a competitive advantage. But not all users upload through our client application—many use the web. If Lepton were open source and adopted by browsers, files could be compressed client-side before reaching our servers, reducing upload time for users and storage costs for us.
Both cases were compelling, which made Lepton a prime candidate for a hybrid strategy. We released it under the Apache 2.0 license and filed for patent protection at the same time.
Customize Your Agreements
Another hybrid option is crafting a custom open source license. If an existing license doesn't address patent rights, you can append a custom patent grant or a defensive termination clause. Termination provisions can be tuned to be stronger or weaker. For example, a broader clause might let you revoke the license if the licensee files any lawsuit at all, even one unrelated to the open source project.
For Lepton, we chose a standard permissive license with an explicit patent grant rather than a customized one. The reasoning was straightforward: we wanted maximum adoption, and we wanted everyone to understand exactly which patent rights were being granted. Apache 2.0 gave us both.
Do Your Diligence and Stay Aligned
Open source carries risk, so participation comes with obligations. All third-party code needs thorough vetting, and you need clear documentation of what's in your products, what you've released, and what you're responsible for. It's equally important that your engineering and legal teams share a mutual understanding of the company's open source and IP strategies. Without that alignment across teams, finding balance is that much harder.
Use Defensive Aggregators
There are also structural ways to reduce litigation risk. Joining a defensive aggregator like LOT Network or Open Invention Network—which protects the Linux kernel from patent suits—can help. In LOT Network, members license their patents so that if another member's patents are sold to a patent troll, all members are immunized from that troll's lawsuits. Given that most companies sued by patent trolls have less than $10 million in annual revenue, such agreements are especially meaningful for smaller participants—and you don't need patents of your own to join.
The takeaway is to decide what IP you must protect, then build a system that keeps those core assets under your control. Open source doesn't forfeit ownership. With a deliberate strategy, contributing to the open source community can be one of the fastest ways to build your own intellectual property—securely and sustainably.
