Open Source Semantic Layer: What Each Project Actually Opens

The open-source semantic layers are dbt's MetricFlow, Cube Core, Malloy, Lightdash and Boring Semantic Layer, plus two open specs, Apache Ossie and AtScale's SML. They open different parts: a file format, an engine that turns metrics into SQL, an API, an app. The API your BI tools and agents call is either a server you run yourself or a paid platform.

The open part that matters is the file your metrics live in. Pick the format your team will write, keep one copy of it in your own repo, and use tools that read it as it is.

Which semantic layers are open source?

Project	License	What's open
dbt MetricFlow	Apache 2.0	The metric YAML and the engine that compiles it to SQL
Cube Core	Apache 2.0 (some packages MIT)	A data model, the engine, and SQL, REST and GraphQL APIs, with no UI
Malloy	MIT	A modeling language and its compiler
Lightdash	MIT, except its ee folder	A BI app that reads metrics from dbt YAML
Boring Semantic Layer	MIT	A Python library on Ibis, with optional MCP and HTTP servers
Apache Ossie	Apache 2.0	A spec for metric files, an SDK and converters, with no engine
AtScale SML	Apache 2.0	A modeling language, an SDK and converters; AtScale's engine is commercial

Filter for projects that ship an API and the list gets short: only Cube Core, Boring Semantic Layer and Lightdash ship one for other tools in the same repo. One more name you'll see on older lists, dbt-semantic-interfaces, is deprecated: its code now lives inside MetricFlow.

Is the dbt Semantic Layer open source?

Part of it. MetricFlow, the engine, is Apache 2.0 from version 0.209.0 on. Before that it was AGPL up to 0.140.0 and BSL from 0.150.0 to 0.208.2. dbt's own FAQ still calls it "source-available", so trust the license file.

The APIs aren't open. The JDBC and GraphQL APIs that BI tools and agents use are on the paid dbt platform (Starter, Enterprise and Enterprise+). Without a plan, dbt's FAQ says you can query metrics "locally using the command line. However, they won't be able to use the APIs or available integrations to access metrics dynamically."

What is Apache Ossie?

Apache Ossie is the new name of the Open Semantic Interchange, the vendor-neutral metric format Snowflake launched in 2025 with dbt Labs, Cube and others. It joined the Apache Incubator in 2026. It's a JSON and YAML spec any tool can read and write, plus converters, and it isn't at 1.0 yet. A dbt Core 1.12 build already writes an Ossie file next to semantic_manifest.json. In our Snowflake semantic layer guide, we ran a dbt project through Ossie's converters into Snowflake.

Do open formats make metrics portable between tools?

Not on their own. We put four MetricFlow metrics through AtScale's open-source dbt-to-SML converter (sml-converters, the commit from August 20, 2025):

• revenue, a sum with refunds filtered out, was skipped. The log said "Skipping metric 'revenue'" and no file came out.
• cumulative_revenue, a running total, came out as a sum that resets every week. Nothing warned us. When we added a trailing-month and a month-to-date version, both came out as that same weekly sum.
• completion_rate (a ratio) and avg_order_value (derived) converted correctly.

The same dbt build warned that the running total's window "cannot be represented" in its Ossie file. So the two metrics with the most business logic in them are the two that didn't survive. In our MetricFlow and Ossie test, 9 of 16 metrics came through intact, and the ones that broke were the filtered, cumulative, time-offset and conversion ones.

If you convert anyway, check two things. Count the metrics going in and the files coming out. Then compare every cumulative metric against MetricFlow over the same weeks. A missing metric is easy to spot. A wrong one isn't.

Which open-source semantic layer should a dbt team use?

The one you already have. MetricFlow YAML is Apache 2.0, it sits in your dbt project next to the models it describes, and it goes through pull requests like the rest of dbt. That's your one copy.

Then pick tools by how they read that file:

• Cube Core has its own data model, so your metrics get written again as Cube measures. Our Querio vs Cube page shows what its dbt import carries over.
• Lightdash needs dbt and its own YAML conventions.
• Malloy and Boring Semantic Layer are their own languages, so they mean a second copy too.

Querio reads MetricFlow as it is. It loads semantic_manifest.json, so when someone asks for revenue, the answer uses the metric your team wrote in dbt, and there's no second copy to keep in step. Without dbt, metrics you write in Querio are saved to your repo in MetricFlow format. Agents are covered too: Claude, ChatGPT or your own agent can ask Querio's MCP server for a metric by name on every plan, Free included, and the query runs as the person signed in.

Moving off an older BI tool first? unshackle, our open-source migration CLI, writes those metrics as Ossie models and MetricFlow YAML, and marks what it can't translate.