spring-boot-demo/db-migrations-flyway-liquibase/docs/13-the-fsl-license-change.md

13. The FSL license change

← 12. The OSS license service · Index · Next: 14. Running both at once →

This is the one chapter in this module with no test behind it — it's not something you can compile and run, it's a licensing fact worth knowing before you mvn dependency:tree your way into it. It's still verified against primary sources, not paraphrased from a blog post, which is why every claim below is a direct link.

Liquibase Community 5.0, the version bundled in the Spring Boot 4.1 BOM this module depends on (5.0.3), is the first release shipped under the Functional Source License (FSL-1.1-ALv2), effective September 30, 2025 — not the Apache License 2.0 every earlier Liquibase release used, and not an OSI-approved open source license at all. FSL is "source-available": the Liquibase blog post announcing it says plainly that using, modifying and self-hosting Liquibase Community stays free, but a third party can't "take Liquibase Community and commercialize it in a way that competes with Liquibase" — offering it as a managed service, specifically — during a two-year exclusivity window per release. The same post confirms the FSL's built-in expiry: two years after each release, that release's license automatically reverts to Apache 2.0.

This is not a hypothetical concern for the projects that depend on Liquibase. The Apache Software Foundation's own Legal committee opened LEGAL-721 to evaluate whether ASF projects (Apache Fineract, specifically) can keep using FSL-licensed Liquibase 5 at all, given the ASF's policy against bundling non-Apache-compatible licenses. Separately, Keycloak opened issue #43391 covering the same problem from the CNCF's side: the CNCF's own source-available policy — quoted directly in that issue as "CNCF does not permit source available licenses, and an exception is unlikely to be granted" — makes continuing to depend on FSL-licensed Liquibase a real compliance question for a CNCF project. The options that thread lays out are exactly the ones you'd expect: fork the last Apache-2.0-licensed 4.x release and maintain it independently, apply Liquibase only at build time and run the generated DDL through custom tooling at runtime, or switch to a still-fully-open-source alternative — the thread names Flyway specifically, noting that Dependency-Track already made that switch for this reason. No final decision had been recorded in that discussion as of this writing.

What this means for a Spring Boot 4.1 project, concretely

Nothing changes for ordinary use: running spring-boot-starter-liquibase in your own application, including in production, is exactly what the FSL permits. The restriction is aimed at competitors reselling Liquibase itself as a hosted product, not at teams using it to manage their own schema. The two things worth actually tracking are whether your organization's own license-compliance process treats "source-available" the same as "open source" (many do not, by policy, regardless of what the license permits in practice), and whether a security or compliance audit of your dependency tree flags a non-OSI license where it previously saw Apache 2.0.

Going deeper

• FSL-1.1-ALv2 license text (rel="nofollow") — the license itself, including the exact terms of the two-year Apache 2.0 conversion.
• Liquibase GitHub issue #7382 (rel="nofollow") — Liquibase's own tracking issue for updating "open source" language across their codebase and docs to match the new license.
• Liquibase 4.x support policy discussion, issue #7375 (rel="nofollow") — whether the last Apache-2.0 major version continues to receive fixes, directly relevant to the "fork 4.x" option above.