Starting with lakeFS v1.87.0, the lakeFS open source project (the lakeFS Community edition) moves from Apache 2.0 to the Business Source License (BSL). Every release published before that stays under Apache 2.0, permanently. DVC stays under Apache 2.0 as well, with no changes at all.
That’s the short version. Here is the detailed breakdown and the reasoning behind our decision:
Why we’re doing this
When we announced that lakeFS had acquired DVC, we said we wanted to keep the project thriving and keep its community growing. We meant it, and nothing about that has changed. DVC keeps its name, its license, its maintainers, and the same open door it has always had for contributors.
But once the dust settled, we had to be honest with ourselves about something. We now owned two open source data version control projects that were slowly circling the same ground. DVC was built by data scientists for data scientists, and it is excellent at what it does. lakeFS started from the other end, in big data systems and object storage at scale. For years those two worlds barely touched. Today, those boundaries are blurring, and maintaining two separate open source projects with overlapping goals isn’t the best path forward for our community.
So we picked a lane for each.
DVC is the project that carries the permissive, no strings attached open source flag. If you want a lightweight, fully open tool for versioning datasets and models alongside your code, it’s there, it’s Apache 2.0, and we’re committed to its ongoing success.
The lakeFS Community edition is the project that becomes the foundation of our commercial product. Almost all of the engineering work going into lakeFS today targets problems that show up at a certain size: petabyte-scale repositories, thousands of concurrent branches spun up for agents and training jobs, distributed training that has to be reproducible six months later, on-prem deployments, and the RBAC, audit logs, and compliance work that lakeFS Enterprise carries.
That work is expensive, and it is funded entirely by lakeFS Enterprise. Moving lakeFS OSS to BSL is how we make sure the thing that funds the work is actually protected, which in turn is how we keep funding DVC, the Slack community, the docs, and the dozens of integrations people depend on.
What BSL actually means
The Business Source License is what people usually call “source available”. It has become a common choice for infrastructure companies, and HashiCorp, MariaDB, and Materialize all use it today.
Here is what it means in practice:
- The code stays public on GitHub. You can read it, build it, file issues, and send pull requests.
- You can run it. In dev, in staging, in production, internally, at whatever scale you want, as long as you’re running it unmodified.
- You cannot use a modified lakeFS system in production, for any purpose, internal or other.
- You cannot use lakeFS standalone or within a production system that is serving anyone outside of your organization.
- Every release converts to Apache 2.0 on its change date, 4 years after it ships. That part is baked into the license.
What this means if you use the lakeFS Community edition
For the overwhelming majority of you, the answer is nothing. Keep going.
If you run the lakeFS Community edition inside your company to version your data lake, branch for CI, isolate agent runs, or reproduce a training set, you are fine. Patching locally to test a fix or to prepare a pull request is fine too. If you build on top of it, script against the API, run it in your own cloud account or your own data center, you are fine. If you contribute to it, please keep doing that too.
Two things fall outside that. The first is hosting or reselling, meaning wrapping lakeFS and offering it to people outside your organization as a service or product. The second is running a modified lakeFS code in production, meaning forking the project, changing it, and deploying your own build. If either of those describes your plans, talk to us first.
If you’re reading that and genuinely can’t tell which side of the line you’re on, email us at hello@lakefs.io. We would much rather answer the question than have you guess, and we will give you a straight answer quickly.
We’re making lakeFS Enterprise easier to start with
There’s a fair criticism that usually follows announcements like this one, which is that companies change the license and then put the commercial product behind a sales call and a six week procurement cycle.
We’re doing the opposite. Over the next few weeks we’re rolling out a much lower friction way to get started with lakeFS Enterprise, with a smaller entry point in both price and effort. If lakeFS Community was where you started and lakeFS Enterprise always felt like a big jump, that gap is about to get a lot smaller. More on that soon.
Why any of this matters
We started lakeFS because we believed data should be managed like code. That was a slightly odd thing to say in 2020. It isn’t anymore.
Agents are now writing to production datasets. Training runs need to be reproducible long after the data underneath them has moved on. Regulators are asking which version of which dataset produced which model output, and “we think it was the March snapshot” is not an acceptable answer. Every one of those problems is a version control problem, and they’re arriving faster than most teams can build for them.
We plan to be working on these problems for a long time, with both projects healthy, both communities intact, and a business underneath that funds the work properly. Moving lakeFS to BSL is how we’re setting that up.
If you have questions, concerns, or you think we got something wrong, come tell us. We’re in Slack, on GitHub, and in your inbox if you’d rather do it privately. Our community is very important to us and we are always glad to hear from you.
Einat and Oz
