Add db-migrations-flyway-liquibase: Flyway vs Liquibase migrations, rollbacks and baselines on Spring Boot 4.1

Companion code for the Flyway vs Liquibase article: checksum validation, out-of-order
and repeatable migrations, baselining an existing schema, Flyway Community's undo/diff/deploy
stubs, concurrent-startup locking for both tools, Liquibase changeset identity and rollback
(auto-generated vs explicit), a verified Liquibase 5.0.3 filename-caching defect, the new
OSS license service, the FSL license change, and running both tools against one database.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Q6XdRjtsp4862EM44T7i9a

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

@@ -0,0 +1,64 @@
+# 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.