Open-source software has played a critical role in the development of computing and enabled the growth of free digital societies. Since Protocol Labs was created, open-source technology has been at our core. We’re implementing a new intellectual property strategy to formalize our commitment to open-source development, give our employees more visibility and input into how their work is made available, and collaborate more freely with our friends at other institutions.
Our intellectual property strategy is based on three core principles:
All Protocol Labs software should default to being freely available forever.
The people who build things should have input into how those things are used.
If we believe permissive open-source licensing is untenable for a particular technology, we should be able to carve out specific pieces of intellectual property, but only after a thoughtful, open process.
We translate these principles into the following commitments so the communities we work with can confidently build on the knowledge we contribute. We’re implementing our core principles with the following strategy, which we refer to as the Permissive Licensing Stack:
We are publicly announcing our patent non-aggression pledge. If we receive patents related to our software, we will not be the aggressor in a patent suit.
When we apply for patents, we’ll give every inventor the ability to unilaterally grant licenses preventing us from using the patents to initiate an infringement suit.
We’re adopting the MIT/Apache-2 dual license as a strong default governing the copyrights and patents for our software projects.
If we want to apply a different license to a new project or to future contributions to an existing project, we’ll solicit feedback from the project team and the company’s employees. If there’s disagreement, we’ll conduct a meaningful internal hearing to determine whether the alternative license is the best way to advance our mission.
Software is one of the most important things Protocol Labs creates. Under U.S. law, the person who writes a chunk of code automatically acquires a copyright in it, meaning they generally have a right to decide how (or if) other people can use it. If the person is working for a company, they may sign an agreement assigning automatic ownership of the copyright to the company instead. Third-party contributions to open-source projects (generally) adopt the license chosen by the projects’ maintainers automatically.
Copyright owners can choose licenses for their work that dictate the terms under which others may use them. These range from extremely open (like the MIT license, which allows unlimited use, reproduction, and modification in any context) to “copyleft” licenses (like the GNU General Public License, or GPL, which allows free use under the condition that any derived work is also made publicly available) to proprietary or closed-source licenses (like most commercial software). The choice of license dramatically affects whether software can be used in various contexts. For example, some projects are unable to pay for proprietary licenses, while others might be unwilling to use copyleft code because they care a lot about keeping their code private.
Most existing Protocol Labs projects use the MIT license, and we’ve also proposed similar licensing for upcoming projects. While preparing this strategy, we spent several months comparing approaches to handling open-source software and open patents. We ultimately decided that the MIT/Apache-2 dual license is the right choice for our projects. This approach means that all contributions are available under the most permissive commonly-used licenses, and dependent projects can pick the license that best suits them. It also means that contributors explicitly license any required patents alongside each contribution, which minimizes the risk of infringement claims against our organization and our users.
Now, we’re formalizing Protocol Labs’ commitment to open-source software through the following Default Open Pledge. This approach advances Protocol Labs’ open-source culture and pushes us strongly toward open behavior, but still gives us flexibility to handle edge cases.
This organization (Protocol Labs) chooses an open license, the MIT and Apache-2 dual license, as the default license for its software projects.
All new software we create will be provided under the above license by default.
When one of our projects builds on another open-source project, we might be required to apply that project’s underlying license to our work. If practical, we will dual-license our work under both that project’s license and the default license so future users can choose the license that best suits them.
If a team wants to apply a different license to any project (such as a GPL or proprietary license), it will notify the contributors to that project and give them a chance to discuss the proposed change. If the contributors agree, they’ll write a short explanation of why the change meets the following License Criteria and submit it to our team:
Does the alternative license meaningfully advance our mission?
Would it be excessively difficult to achieve the same goal in a more open and permissive way?
If, after a week of discussion, any contributor or at least 20% of our organization disagrees with the licensing decision, we’ll conduct a fair and open internal hearing to consider the License Criteria and decide the best path forward.
Protocol Labs encourages other companies to implement their own versions of the Default Open Pledge. While Protocol Labs has chosen the MIT/Apache-2 dual license for our projects, other companies can choose any source license and develop dispute resolution procedures that make sense for their circumstances while still fulfilling the spirit of the Default Open Pledge.
Protocol Labs applied for its first U.S. patents in 2018 for purely defensive use. Although we don’t generally believe in software patents and strongly support open-source software, patents exist and we need to protect ourselves, our miners, and our users from patent litigation. Few open-source companies want to apply for patents, but many of those that are deeply committed to open-source software end up applying for patents, and we recognize the importance of doing so to protect our users.
A patent is a government-granted right to prevent other people from using an invention. Patents protect an invention itself, while copyrights protect a specific expression of the underlying idea (for example, the code of a specific implementation). You get a patent (effectively, a time-limited monopoly on an invention) in exchange for publicly disclosing your invention to the public.
Our view is that using software patents offensively slows the spread of knowledge and is almost always more harmful than beneficial. To that end, Protocol Labs is taking two actions:
Adopting a streamlined version of Blockstream’s patent non-aggression pledge.
Adopting the Modified Innovator’s Patent Agreement, introduced by Twitter and refined by Blockstream, to remove a loophole that made offensive suits easier.
The non-aggression pledge is straightforward: We promise not to use any of our patents offensively. You can read our non-aggression pledge here. The Modified Innovator’s Patent Agreement further discourages the offensive use of our patents by giving each inventor the right to grant free licenses. Put differently, it requires all of the inventors to consent to any offensive lawsuit. This protection would follow our patents even if we lost control of them.
Taken together, these two actions are meant to send a clear signal that others can safely use our patents and to provide a legal mechanism that will serve as further comfort. Protocol Labs will still be able to use the patents to defend lawsuits against ourselves, our customers, or other companies relying on our patents. To increase openness, we’ll also commit to announcing internally if we ever need to enforce a patent, unless we’re legally unable to do so.
Protocol Labs is building software that we hope will be used for decades or centuries. We’re confident that an MIT/Apache-2 dual license is the right approach for our software today, but we have no way of knowing whether a better choice for open software will arise in a few decades.
The people who contribute to the Protocol Labs ecosystem—both internally and in our wider open source communities—are important stakeholders in this policy. If we ever decide to change our IP strategy, we promise to involve those stakeholders and seek widely beneficial consensus to the greatest extent possible.
But please note: Whatever changes might happen in the far future, as a matter of law, a copyright holder can’t “take back” a permissive license—they can only adopt a new license for future work. The Innovator’s Patent Agreement likewise gives individual inventors the ability to protect users regardless of future changes. If you’re contributing to the open-source technology Protocol Labs is creating, you can do so with confidence that our code will remain open source.
We believe open-source values are critical to free societies, especially in the digital age. As our digital and analog lives depend more and more on software, freedom requires more and more open-source – open-source values and open-source code. Open-source software allows everyone to contribute, make changes to suit their needs, or pivot entirely to build something better. These traits lead to software that’s fundamentally better and more dependable, because we have the freedom of choice, and the freedom to improve it, together. “In real open-source, you have the right to control your own destiny.”
There are many giants in the open-source space, and we are extremely grateful for the leadership and innovation they have provided over many years. Our IP strategy was particularly influenced by Mozilla and Google’s approaches to open-source governance, the Rust project’s work on choice of license, and Twitter and Blockstream’s thoughtful treatment of defensive patents. We thank them – and countless others – for their contributions.
Now, Protocol Labs is picking up the torch and pushing for an even more strongly open-source world. We invite our colleagues at other companies and organizations to join us and follow this path forward.
In the coming months, we plan to open-source the legal documents we’re using to implement the Permissive Licensing Stack we’ve described. In the meantime, the fundamental approach is to:
License your projects under an MIT/Apache-2 license (or the open-source license you prefer) by default.
Implement meaningful, open procedures to consider feedback from creators and contributors before you apply a different license or change your approach to open intellectual property.
Announce a patent non-aggression pledge.
Modify your standard employee intellectual property agreements to implement the Innovator’s Patent Agreement with each inventor of any patents you file.
This approach to intellectual property is, of course, provided for anyone to freely use or modify – and we hope you will. In the spirit of open-source software, we have no doubt that others will dramatically improve on this policy. We look forward to learning about and incorporating many of your improvements.