Leil FS Open-Source Commitment, Contribution Policy, and Project Roadmap #841
Replies: 3 comments
-
|
I'm very happy to hear this! Will this apply to other projects like saunafs-monitoring as well? This makes me much more likely to want to contribute as well. |
Beta Was this translation helpful? Give feedback.
-
|
The way how the product will incorporate UI, monitoring included, is currently debated/shaped. No clarity yet on what it might be and how the license shall apply. It is not to say that we have one path preferred over the other, it is to say there is no path defined yet. |
Beta Was this translation helpful? Give feedback.
-
|
I hope that DCO will also apply to saunafs-monitoring, since I may want to make some contributions there as well. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Why this post exists
A contributor recently raised an important question about our contribution process and the long-term intentions behind Leil FS. The concern was direct and fair: if the project is GPLv3, why require a CLA? Is there a plan to change the license or go closed-source?
This is exactly the kind of question we want asked in the open. It deserves a clear, public, permanent answer.
The short version
Leil FS is GPLv3. It will stay GPLv3.
We are adopting DCO (Developer Certificate of Origin), not CLA. No documents to sign. No legal team required.
We will not relicense Leil FS under the current leadership. We will not move it to a proprietary license, a source-available license, or any other model that restricts the freedoms GPLv3 provides. The DCO contribution model structurally protects community contributions beyond any single administration.
Leil FS is already shipping in some Linux distributions and we are investing in making it one of the easiest distributed file system to install, deploy, and contribute to.
The rest of this post explains the reasoning, the history, and where we're going.
On CLA vs DCO: what we decided and why
When we initially discussed requiring a CLA (Contributor License Agreement), the intent was to keep our legal basis clean. But we heard the community's concern, and on reflection, we agree: a CLA sends the wrong signal for a GPLv3 project.
Here's the difference, plainly:
CLA grants the project owner (Leil) rights beyond the existing license - typically the ability to relicense contributions. This is the mechanism that companies like MongoDB, Elastic, Redis, and HashiCorp used before changing their licenses. The open-source community knows this pattern well, and the suspicion it generates is justified.
DCO is what the Linux kernel, Git, and hundreds of major GPLv3/GPLv2 projects use. Each contributor adds a
Signed-off-byline to their commits, certifying they have the right to submit the code under the project's license. It is lightweight, requires no separate legal agreement, and - critically - it means no one, including Leil, can relicense community contributions without individually obtaining permission from every contributor.That last point is not a drawback. It is the point. By adopting DCO, we are making a structural commitment: the GPLv3 license on community contributions is locked in by the contribution mechanism itself, not just by a promise.
Effective immediately, Leil FS contributions require DCO sign-off only. The CLA requirement is dropped.
On the history of this project
Leil FS was previously known as SaunaFS. We renamed it when we unified our products under the Leil brand (Leil FS for the open-source distributed file system, Leil OS for the commercial management layer). The code, the architecture, the contributors, and the license are the same. This was a brand consolidation, not a fork or a rewrite.
SaunaFS itself descends from the MooseFS/LizardFS lineage of GPLv3 distributed file systems. We respect that heritage and have no intention of breaking the license continuity that defines it.
Our commitment to GPLv3
Under the current leadership, Leil FS will remain licensed under GPLv3. For as long as we are at the helm of this company, there will be no relicensing, no move to source-available, and no closed-source pivot. This is not a provisional position - it is a commitment Leil is making publicly, and on the record.
I want to be honest about what we can and cannot promise. We can commit to the decisions made under this administration. We cannot make irrevocable promises on behalf of future leadership that may one day operate this company. No CEO can, and those who claim otherwise are either not being thoughtful or not being truthful.
What I can do is put structural safeguards in place that outlast any individual. That is exactly what the DCO does:
All community contributions remain GPLv3 regardless of corporate ownership changes. The DCO means that no future owner, board, or CEO can relicense your contributions without obtaining your individual permission. That protection is built into the contribution mechanism itself - it does not depend on anyone's goodwill.
Any future acquirer or successor inherits a codebase where the community's GPLv3 contributions are irrevocable. The more the community contributes, the stronger this structural lock becomes.
This post itself serves as a public record of the intent and principles under which contributions were solicited and accepted.
I believe this transparency - here is what we commit to, here is the boundary of that commitment, and here is the structural protection that goes beyond it - is more valuable than a vague, unconditional forever-promise. You now understand both our intent and the mechanism that safeguards your work.
Why open source is our strategy, not our concession
Some companies open-source reluctantly or tactically. For Leil, open source is the core of our go-to-market strategy. Here's why:
The enterprises we serve require it. National HPC centers, research institutions, autonomous vehicle companies, and large-scale media archives increasingly mandate open-source storage infrastructure. Proprietary lock-in is a disqualifier, not a preference. Every customer we are engaged with today either requires or strongly prefers open-source file systems.
Our competitive position depends on it. Leil FS is the foundation of Leil OS - the only production-grade, HDD-native parallel file system with native SMR (Shingled Magnetic Recording) drive support at scale. For this technology to become the industry standard - and for the SMR transition to succeed - it needs to have open, trusted, and broadly adopted foundation. A proprietary Leil FS is a less valuable Leil FS.
Our business model does not require relicensing. Leil's commercial revenue comes from Leil OS (the management and operations layer), enterprise support contracts, and professional services. The open-source file system drives adoption; the commercial products serve enterprises that need operational tooling, SLAs, and supported hardware. This is the proven model - it is how Red Hat, Grafana Labs, and Databricks built multi-billion-dollar businesses on open-source foundations.
Closing the source or changing the license would destroy the trust we are building. It would be strategically irrational.
Distribution and packaging: where we are today
We are committed to making Leil FS easy to install on every major platform. Here is the current status:
Our goal is for any systems administrator or developer to be able to deploy a Leil FS cluster with a single package manager command or a
docker-compose up. If you have ever struggled with building a distributed file system from source, we want Leil FS to be the project where that stops being necessary.Packaging contributions and testing across distributions are among the most valuable contributions the community can make right now.
How to contribute under DCO
Contributing under DCO is straightforward:
Read the DCO text at developercertificate.org It is short and clear.
Add a sign-off to each commit:
This appends a
Signed-off-by: Your Name <your@email.com>line, certifying that you have the right to submit the contribution under GPLv3.If you have already submitted contributions, we will not retroactively require sign-off on past commits.
What we are building
Leil FS is on a path to become a robust, stable, and actively maintained distributed file system that serves as critical infrastructure for organizations managing petabyte- and exabyte-scale data. Concretely, this means:
First-class Linux distribution packages so that installing Leil FS is no harder than installing PostgreSQL or Nginx.
Container-native deployment with official Docker images, Kubernetes CSI drivers, and Helm charts for cloud-native and hybrid environments.
Production-grade HDD and SMR support - extracting maximum capacity and performance from the drives that store the vast majority of the world's data.
Multi-protocol access — POSIX, NFS, SMB, and S3 from a single namespace.
A welcoming contributor community where the barriers to participation are technical, not legal.
We want Leil FS to be the project that people trust with their data and their contributions. That trust starts with clarity about who we are, what we intend, and what structural commitments we are making.
This post is that clarity.
Aleksandr Ragel
CEO, Leil
Questions, concerns, or suggestions are welcome in the comments below or in any of our community channels.
Beta Was this translation helpful? Give feedback.
All reactions