dbt Core stayed Apache 2.0, and that was the only question

Two announcements landed on the first of June, and the louder one was the less interesting. Fivetran and dbt Labs completed their merger, George Fraser as chief executive, Tristan Handy as president, wrapped in language about trusted data infrastructure for AI agents. The same day, dbt Core v2 shipped with the Fusion engine runtime under Apache 2.0.

A merger is a promise. A license is a fact. We can review the second one today.

what the license actually did

Rewind to the 2025 plan, which was that the Fusion runtime would go out under the Elastic License: source you could read, with restrictions on serving it to others. dbt Labs' own post is direct about the reversal. The runtime it "previously committed to releasing publicly under the ELv2 license" is "now under the Apache 2.0 license as dbt Core". The Fusion binary was separately relicensed to be, in their words, "more permissive than ELv2", to the point that it "can now be provided as a managed service by others".

Two moves in the same direction, and not the direction this decade has trained anyone to expect.

The managed-service clause is the one with commercial consequence. Under ELv2, a competitor could not have sold you a hosted Fusion. Under the terms now in force it can, and whether anyone does is a different question from whether the option exists. Options are what keep renewal conversations honest.

The reason is mechanical rather than moral, which is why we believe it. The engine is Rust, and as the post puts it, "Rust projects can be distributed as binaries without disclosing any proprietary source code". That property is what makes two free distributions possible at once. The generosity is downstream of a compiler.

which distribution are you running

One engine, two packages. dbt Core is the Apache 2.0 code in the dbt-core repository, buildable by anyone. Fusion is the precompiled binary with additional proprietary code, also free, carrying more than the open build gives you, including a built-in SQL linter.

The catch is small, and belongs in writing before your next CI change: some Fusion features "will only work if you've authenticated", with either a free login or a paid dbt platform account. Nothing improper about that. It is still a dependency on a vendor's auth service inside a build step, and those belong on the risk register whether or not they carry a price.

So the checkable question is which binary sits in your image, and what degrades when it cannot reach the login service. Teams that have already ranked their transformation tooling by what hurts will recognise the exercise. It is the same one with an auth call added.

verdict

On the license, worth adopting. The runtime is more open than the version promised in 2025, and a fork stays possible, which is the property that matters when a transformation layer is load bearing.

On the merger, wait, with the usual trigger attached. Two months on, the thing that would make it reviewable is a combined bill, and no combined bill has appeared. When it does, this journal will have something to price. Until then the merger is a letterhead, and the license is the news.