# 13. The FSL license change

[← 12. The OSS license service](12-the-oss-license-service.md) · [Index](../README.md) · Next: [14. Running both at once →](14-running-both-at-once.md)

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](https://www.liquibase.com/liquibase-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](https://www.liquibase.com/blog/liquibase-community-for-the-future-fsl)
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**.

<svg viewBox="0 0 700 130" xmlns="http://www.w3.org/2000/svg" font-family="monospace" font-size="13">
  <rect x="20" y="20" width="200" height="50" rx="6" fill="#fef9c3" stroke="#ca8a04"/>
  <text x="120" y="42" text-anchor="middle">Liquibase 5.0.3</text>
  <text x="120" y="58" text-anchor="middle" font-size="11">released under FSL-1.1-ALv2</text>
  <path d="M220 45 L280 45" stroke="#334155" stroke-width="2" marker-end="url(#a6)"/>
  <rect x="280" y="20" width="240" height="50" rx="6" fill="#dcfce7" stroke="#16a34a"/>
  <text x="400" y="42" text-anchor="middle">2 years later</text>
  <text x="400" y="58" text-anchor="middle" font-size="11">reverts to Apache 2.0, automatically</text>
  <text x="20" y="105" font-size="12" fill="#475569">Every future release restarts its own two-year clock — the version you pull today</text>
  <text x="20" y="120" font-size="12" fill="#475569">is FSL for those two years even after a later release has already converted.</text>
  <defs><marker id="a6" markerWidth="8" markerHeight="8" refX="6" refY="4" orient="auto"><path d="M0,0 L8,4 L0,8 z" fill="#334155"/></marker></defs>
</svg>

This is not a hypothetical concern for the projects that depend on Liquibase. The
[Apache Software Foundation's own Legal committee opened LEGAL-721](https://issues.apache.org/jira/browse/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](https://github.com/keycloak/keycloak/issues/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](https://fsl.software/) (`rel="nofollow"`) — the license itself, including the exact terms of the two-year Apache 2.0 conversion.
- [Liquibase GitHub issue #7382](https://github.com/liquibase/liquibase/issues/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](https://github.com/liquibase/liquibase/issues/7375) (`rel="nofollow"`) — whether the last Apache-2.0 major version continues to receive fixes, directly relevant to the "fork 4.x" option above.