Open-Source AI Data Platforms: Licensing, Governance, and Open Core

Teams choose open-source data and AI platforms for four reasons: cost, control, portability, and the ability to read the code. The label on its own does not tell you whether a platform delivers any of them.

Two projects can both be described as open source and give you very different rights. One permits commercial use with almost no conditions. Another restricts offering the software as a service, which matters if your product is a service. A third publishes the core and holds back the features that production requires.

This guide covers what to check: the license, who governs the project, where the open core boundary sits, and what self-hosting actually costs. It covers those questions rather than ranking projects. For engine selection, see the best query engines for real-time AI analytics. For platform capability criteria, see what to look for in a unified data and AI platform.

Four Questions the Label Does Not Answer

1. Which license, and what does it permit? The differences decide whether you can build a product on it.
2. Who governs the project? This predicts whether the license can change later.
3. Where does the open core boundary sit? The free tier is only useful if production can run on it.
4. What does self-hosting cost? The license fee is zero. The total is not.

License Types and What Each Permits

Permissive licenses

Apache 2.0, MIT, and BSD permit use, modification, and redistribution with few conditions. Apache 2.0 also grants patent rights explicitly, which legal teams usually prefer.

These impose no restriction on offering the software as a service. If your product is a hosted product, this category carries the least risk.

Copyleft licenses

GPL and AGPL permit the same use and require derivative works to carry the same license. AGPL extends that requirement to software offered over a network.

AGPL is approved by the Open Source Initiative and is genuinely open source. It still needs legal review when the software sits inside a commercial product, because the reciprocal obligation can reach further than teams expect.

Source-available licenses

The Business Source License (BSL), the Server Side Public License (SSPL), and the Elastic License publish source code with commercial restrictions. They typically forbid offering the software as a competing managed service.

These are not open-source licenses under the Open Source Initiative definition, although vendors often market them alongside genuinely open projects. BSL commonly converts to an open license after a set period, usually a few years per release.

Licenses change. Verify the current license on the project repository before making a decision on it.

Governance: Foundation or Single Vendor

The license tells you the terms today. Governance tells you how likely they are to hold.

Foundation-governed projects are held by a neutral body such as the Apache Software Foundation or the Linux Foundation. Apache DataFusion, Apache Arrow, Apache Iceberg, Delta Lake, and Vortex sit here. Foundation stewardship can distribute decision-making, but it does not by itself determine copyright ownership or make relicensing impossible. Check each project's charter and contribution terms.

Single-vendor projects are controlled by one company that owns or aggregates the copyright, often through a contributor license agreement. That company can relicense future versions.

This is not theoretical. Several widely adopted infrastructure projects have moved from permissive licenses to source-available ones after building large user bases. Each time, downstream users faced the same choice: accept the new terms, pay for a commercial license, or move to a fork.

Single-vendor governance is not disqualifying. Many excellent projects work this way. It is a risk to price rather than a reason to refuse.

Signals worth checking

• Does a foundation hold the copyright, or does one company?
• Does contributing require a license agreement, and what rights does it grant?
• How concentrated are the contributors? A project where one company writes most commits behaves like a single-vendor project whatever its license says.
• Has the project relicensed before?

Open Core: Where the Line Sits

Most commercial open-source platforms publish a core and sell additions. The question is which side of the line the features you need fall on.

Some capabilities are commonly held back:

• Single sign-on and directory integration
• Role-based access control and row-level policy
• Audit logging
• High availability, clustering, and failover
• Managed operations and support commitments

None of that is unreasonable. A company needs revenue. The problem arises when the free tier is a demonstration rather than a product, and the requirement only becomes visible during a security review.

The test: list the capabilities your production deployment requires, including the compliance ones. Check each against the open-source edition specifically, not the documentation site as a whole. Documentation often describes the commercial edition without marking which parts need a license.

What Self-Hosting Actually Costs

The license fee is zero. Four costs replace it.

Operations. Someone runs upgrades, capacity planning, and incident response. For a distributed system this is a meaningful fraction of an engineer.

Expertise. Tuning an unfamiliar engine takes time before it takes effect. Budget the learning period.

Integration. Authentication, secrets, monitoring, and backup all need wiring into your existing systems. A managed service usually includes these.

Support. Community support is real but has no response commitment. If an outage needs an answer within an hour, that commitment costs money.

Self-hosting is often the correct choice. It is correct for reasons of control and data residency more often than for reasons of cost.

Evaluation Checklist

How to Choose

1. Start from what you are building

If your product is a hosted service, source-available licenses need legal review first. That single question removes several options quickly.

2. Separate the engine from the platform

An open engine inside a proprietary platform gives you portability of skills, not portability of workloads. Check what governs the layer you actually depend on.

3. Weight open formats above open engines

Engines are replaceable if the data is readable. Open table formats such as Iceberg and Delta Lake preserve that option. A proprietary storage format removes it whatever the engine license says.

4. Price the relicensing risk

Estimate the cost of migrating away within two years. That number is what single-vendor governance is asking you to accept.

5. Decide honestly who operates it

Match the choice to the team carrying the pager. A platform that needs a dedicated operator is the wrong choice for a team of four.

Advanced Topics

Forks as an escape hatch

When a project relicenses, the community sometimes forks the last permissive version. OpenSearch, OpenTofu, and Valkey all began this way. A fork is a real option and it is not free: it needs its own maintainers, and ecosystem support splits between the two.

The relevant question is whether a credible fork could exist. A project with contributors across several organizations can be forked successfully. A project written almost entirely by one company usually cannot.

Open formats reduce the cost of being wrong

Storing data in Iceberg, Delta Lake, or Parquet lets another compatible engine read the same stored data. SQL dialects, catalogs, and engine-specific features can still require migration work. Open formats reduce switching cost, but they do not make every choice reversible.

Check this at the layer you actually write to. A platform can read open formats and still store its own working data in a proprietary one. That leaves the acceleration tier locked even when the lake is portable. Ask what a different engine could read tomorrow without a conversion job.

Contributor concentration as a health signal

Look at commits by organization over the last year. Broad distribution indicates a project that survives any single company changing direction. Concentration indicates a project whose future is one company's roadmap, whatever the license permits.

Release cadence and issue response times add to the picture. A project with many contributors and no releases for a year carries a different risk from one shipping monthly. Check whether maintainers outside the primary company can merge changes, because that is what determines whether the project continues if the company stops.

Reading the CLA

A contributor license agreement is what usually makes future relicensing practical, and its presence alone does not settle the question. Some agreements assign copyright to a company. Others leave copyright with the author and grant the company broad rights, which can include relicensing. A project with no agreement can still relicense if every copyright holder agrees, which is feasible when contributors are few.

Read the rights the agreement grants rather than noting that one exists.

Open Source at Spice

Spice is open source under Apache 2.0. The runtime includes federation, acceleration, hybrid search, and AI inference, and it is available at github.com/spiceai/spiceai.

The commercial line sits at operations and enterprise controls. Spice Cloud runs the same runtime as a managed service. Spice.ai Enterprise adds self-hosted deployment with SSO, RBAC, audit logs, and support commitments. The engine is the same in all three, so a deployment can move between them without a rewrite.

Spice is built on foundation-governed projects: Apache DataFusion, Apache Arrow, and Vortex. Spice reads open formats including Parquet, Iceberg, and Delta Lake, and Cayenne stores accelerated data in the open-source Vortex format. Deployment runs locally, at the edge, in your own account, or fully managed, as described in edge-to-cloud deployments.