At Zama, we believe in Kerckhoffs’s principle: that security by obscurity cannot exist. The only way to feel confident about a cryptosystem’s security is to have the community try to break it and fail. In practice, this means we need to publish our results and open source our implementation.
As an ambitious startup, we have dedicated vast resources to build our technology, with the expectation that eventually we will become profitable. Profitability is necessary to achieve our vision — to make the internet safe by encrypting everything end-to-end — because it enables us to be independent and free from external influence.
A common belief is that open source and monetization are incompatible. Not only is this incorrect, but it is also dangerous when it comes to cryptography: it makes companies sell proprietary technology that hasn’t been validated by the community. If, instead, companies utilized an open-source approach, they would benefit in many ways:
- Software would be more secure, as fresh eyes would inspect the code and report bugs.
- New features would be contributed by the community, especially those that the company may not have envisioned internally.
- Customers would feel more confident adopting the solution, as the code would be safeguarded against future uncertainty.
- Organic brand awareness would be cultivated through word of mouth amongst developers, the most influential group regarding technology adoption.
- Support would be better, as they could rely on both their team and the community to answer questions.
- A low-touch sales model would be facilitated, with potential customers creating their own proof-of-concept ahead of purchasing the solution. PoCs are a startup’s death kiss and should be avoided at all costs, as they require enormous time and effort and rarely convert into recurring revenue.
A decade ago, open source was thought to be the lesser version of proprietary software. This is no longer true, and many industry giants were built on top of open-source projects: MongoDB, Datastax, Elastic Search, Docker, Mapbox, … These companies share the distinction that their business models combine at least two of the following revenue streams: support, hosting, proprietary features and dual licensing.
Support
The most common and simplest model for open source companies is to offer premium support. When a company adopts an open-source solution, they typically require help integrating it, maintaining it and debugging it. Relying purely on community support won’t be enough, as there is no guarantee that a response will be given promptly, if ever.
Although anyone could sell support for a given open-source solution, the company behind the solution will often be the preferred choice as they are more likely to know the internals and be able to ship custom patches swiftly.
The disadvantage of relying on support alone is the stress it places on human resources, making it hard to scale. It is, however, essential, and thus must be offered eventually.
Hosting
Another good way to monetize is to host the solution for other companies, thereby making it easier to integrate, maintain and debug. Take MongoDB as an example: you can either use MongoDB directly and host it yourself, having to patch it, etc; or you can host your data on Mongo’s SaaS platform, letting them do all the work and paying only for what you use.
The advantage here, of course, is simplicity for both the provider and the customer, but the disadvantage is the need for consumer trust in the host. As an open-source company, it also means SLA guarantees are a necessity, which involves heavier internal processes to guarantee uptime, etc.
Proprietary features
Sometimes keeping some features closed source is acceptable, in particular when it doesn’t prevent the community from using the core solution. Automated backups, integration, hardware acceleration and other options are all more convenient if available, but they aren’t deal-breakers and can be kept closed-source and sold as enterprise features.
Choosing what to open source and what to sell as a premium feature can be tricky, however, and many companies have burnt themselves following this open-core business model. It also doesn’t create as much defensibility, as large companies can easily replicate the enterprise features and sell them as their own.
Dual licensing
The idea behind dual licensing is that some open-source licenses have provisions that make it difficult for proprietary software companies to use the open-source code commercially.
For example, GPL licenses include a copyleft provision, meaning that when a company distributes software that incorporates GPL code, they have to make their own software freely available under GPL as well. There is a debate currently, however, on whether using AGPL in a SaaS product would trigger the copyleft provision. Some claim SaaS isn’t distribution and thus it doesn’t trigger the provision. Others maintain it does. The Free Software Foundation has a good article specifically on this issue. Further, this is the reason that MongoDB and Elastic Search are using a modified GPL license that specifically addresses SaaS usage.
Another example is the BSD3-clear license, which is completely permissive, without copyleft, but doesn’t include a patent license (the original BSD3 license did not mention patents at all, creating an ambiguity that the BSD3-clear version resolves).
These legal constraints create an opportunity for monetization of the open-source software:
- If a company open sources their code under GPL, they can sell the same code with a non-GPL license to companies that don’t want to worry about the GPL copyleft provision. In this case, what is being sold isn’t the software, but rather the peace of mind of not having to deal with GPL.
- If a company open sources their code under BSD3-clear, they can sell additional licenses to use the patents included in the open source code. In this case, it still isn’t the software that is sold, but rather the usage rights of the patented intellectual property it contains.
There are other possible models available as well, such as a dual commercial/non-commercial license. But regardless of which model is used, the idea is always the same: big proprietary companies would much rather pay a license fee than worry about the potential legal risks of using open source code.
At Zama, we have thoughtfully chosen the BSD3-clear dual licensing model. We want to allow anyone to use, fork, extend and distribute our software for free for development, research, prototyping and experimentation purposes.
There are several things that motivated our choice:
- We want to be profitable so that we can remain independent and continue investing in privacy-preserving technologies;
- We want to contribute to science by publishing our work and enabling other researchers to build on top of it;
- We want our code to be auditable so that users don’t have to trust us;
- We want companies to freely experiment and evaluate our solution;
- And we want to use a well-known license family.
All these requirements are nicely addressed by our BSD3-clear license scheme:
- Open research, auditability and experimentation are covered by the BSD3-clear license.
- Profitability is covered by our commercial license, that includes both software and patent usage rights.
- BSD is a widely-used license family with which developers are familiar.
We reviewed, in detail, every other major license, and decided to avoid them for the following reasons:
- We were initially using AGPLv3, but we decided to change because too many of our partners and users were not allowed to run GPL code on their work machines and thus couldn’t experiment freely.
- Apache2 grants explicit patent rights, which means we wouldn’t be able to monetize our IP. Without the ability to monetize our IP, we would effectively be spending millions developing a technology that other companies would profit from, without Zama getting anything in return.
- MIT and BSD2/3 (without the clear clause) are permissive but do not explicitly mention patents, creating a legal ambiguity that can lead to expensive patent infringement lawsuits down the line.
We believe that our users and partners deserve to know the risks they take using our code, which is why we have made things very simple: do whatever you want as long as it’s non-commercial, or purchase a license if you want to use our code for commercial purposes.
Additionally, we have purposefully omitted consulting as a business model, as we don’t consider it to be viable for startups. Consulting is great if you want to be a consulting company, but not when you want to be a product company.
Hopefully by now you are convinced that going open source can be profitable for your company. We need more open source in our industry because too many critical infrastructures rely on opaque code that hasn’t been audited. That creates unnecessary risk for all of us.
It’s time to build big businesses that actually make the internet safer!
- Everything we do at Zama is open source, check out our libraries on Github to get started.
- We are open to collaborating and advancing the FHE space with our partners. If you have specific needs, please email us at: hello@zama.ai.
- Follow us on twitter @randhindi and @zama_fhe.
- Join the Zama team and help us to make the internet encrypted end-to-end.
.png)
.png)