Huh, did not realise Liquibase changed their license. Seems a bit weird when basically every web framework has an alternative in house, and there's Alembic and Flyway as framework-generic alternatives.
Not to mention their pro features keep breaking syntax of the community version, obviously with 0 transparency.
Now, of course they should get paid for the work they do, but these sort of "we were FOSS and surprise we're not anymore" are becoming commonplace and are always done hoping no one notices.
I don't like any of these licenses, but if I was playing devil's advocate here, "open source" as a term on its own surely just implies the source code is publicly available? Which it is.
Some people just don't find the distinction between "open source" and "source available" to be meaningful, or at least don't find it meaningful enough to warrant the outsized level of attention it gets. I can't speak for anyone else, but at least to me, "open" is pretty much synonymous with "available" in the way it's used in the term "open source", and despite this debate going on for years now I've yet to see an argument for why it makes sense for those terms to mean different things that doesn't essentially boil down to "because that's what OSI says". I don't find the argument that I should have to agree with the definitions from one specific organization for extremely generic-sounding terms to be particularly compelling, and if anything, the backlash anyone gets from conflating the terms purely based on those definitions as if they're the only morally correct ones just makes me even less inclined to buy into them. It's basically an attempt to trademark via astroturfing.
If we want to be very picky it is "open source" not "Open Source".
The capitalised term indicates it's a license approved by the Open Source Initiative, which is commonly used as the basis of "actual open source"
(I do agree that this gets a little murky, especially with folks who don't understand the nuance, which is a large percentage of folks talking about this)
I do agree that not calling something even "open source" if it's under a license like the FSL is best
So Liquibase made an open-source project, used Apache instead of strong copyleft (e.g GNU AGPL), and then expected others to not do the thing Liquibase chose to allow them: make closed-source derivatives.
Should probably be called "open source with a two year delay", or "open source in two years".
Or "open source when obsolete" because that's what it is, fundamentally. Of course, it sells less and makes it way more obvious what these delayed open source licenses are at their core: "we'd like to make people believe we respect their freedom, but are not actually convinced with giving them that".
Apparently this also poses a problem for OSS projects such as Keycloak since they can't use non-OSS licenses according to the CNCF [1].
I wonder if a project which uses Liquibase can be included in Debian, Fedora, etc.? Since these projects also have requirements on OSS licenses for the software they distribute.
Big tech companies (the money behind the Open Source Initiative) have done a few things.
1. They co-opted the free software movement and made it more business friendly.
2. They convinced people that Open Source is pure and software that isn’t Open Source is unclean.
3. They convinced a bunch of developers that their definition of Open Source that was specifically crafted to protect business interests is canon.
4. They convinced a well meaning subset of those developers to police the other devs and pressure them to release their software under big tech approved licenses.
I have just created a task to find an alternative in case 4.x cannot be used anymore.
I have nothing against someone trying to monetise useful software. However, switching from an open-source software (OSS) licence is essentially a bait-and-switch tactic. This immediately destroys trust. It also destroys the part of the user base that is difficult to monetise but still has the potential to be monetised. I was hoping that the Elastic and TerraForm debacles had taught people a lesson.
Flyway is also questionable at this point. If Liquibase is switching, what's to stop Flyway?
Unless a fork is happening, I'm considering creating my own migration library tailored to our actual needs and usage. It should not be so hard. Liquibase was more of a convenience.
If you use Python a bit, Alembic is a nice one - it's simple and Python is available nearly everywhere.
Alternatively if Liquibase is FSL it will technically be Apache in 2 years I think (not exactly sure how that works) but you could just go to the last non-FSL release and use that for 2 years.
I'm not exactly sure why people would need the most up to datest version of liquibase which just runs schema changes anyway. I used version 2 a bunch of years ago and it was just fine.
After reviewing the available options over a year ago, I decided to implement our own migration tool using https://dbup.readthedocs.io/en/latest/ (we have a pre-existing, sizable .NET codebase). It's worked perfectly for our needs.
> I'm considering creating my own migration library tailored to our actual needs and usage. It should not be so hard.
Indeed. Go has like 5 options for SQL DDL migrations now. On python side there's alembic and bunch of homegrown stuff in various frameworks.
I think much of the complexity in liquibase comes from supporting various databases.
One thing to remember: mark a new version before each step that can fail, even if the steps themselves are together in the same file.
This is a problem I ran too much into with alembic in which each file is a single unit - a statement in the middle of the script fails and there's no simple way to roll back (unless your DB supports transactional DDL). So the pattern I have settled is to have only one simple change in one file. Liquibase of course doesn't suffer this because it has unique IDs per statement.
This is a shame. We use Liquibase on my project and I have a few bugfixes / functional gaps that I was planning to contribute back but I doubt my large enterprise client would sanction contributions to a commercial codebase.
I agree that this isn't technically "open source", but the FSL blocks competing use. Is anyone here actually blocked from using Liquibase because of their switch to the FSL?
I use liquibase at work because there was a large marketing campaign saying this was the standard for db schema versioning in the java world. Now that I look at flyway, it seems to be a tiny bit better...
I had mixed results with liquibase, if you don't use the xml changeSets you are in for a ride and its not that easy to do a simple diff on two databases. It kinda works but feels iffy...
During my frustrations I read blogposts saying you can implement schema version changes easily by yourself and I kind of see it... You have to do the thinking by yourself anyway when you declare changeSets?
41 comments
[ 3.6 ms ] story [ 62.5 ms ] threadPaying a license and playing by the rules of a myriad licenses is a chore even for those who can afford it.
Now, of course they should get paid for the work they do, but these sort of "we were FOSS and surprise we're not anymore" are becoming commonplace and are always done hoping no one notices.
Either just reading the "base" part and plugging some unrelated service, or claiming source available is the same as open source
"Is FSL an open source license?
No."
https://www.liquibase.com/blog/liquibase-community-for-the-f...
The capitalised term indicates it's a license approved by the Open Source Initiative, which is commonly used as the basis of "actual open source"
(I do agree that this gets a little murky, especially with folks who don't understand the nuance, which is a large percentage of folks talking about this)
I do agree that not calling something even "open source" if it's under a license like the FSL is best
Liquibase has only itself to blame.
Or "open source when obsolete" because that's what it is, fundamentally. Of course, it sells less and makes it way more obvious what these delayed open source licenses are at their core: "we'd like to make people believe we respect their freedom, but are not actually convinced with giving them that".
I wonder if a project which uses Liquibase can be included in Debian, Fedora, etc.? Since these projects also have requirements on OSS licenses for the software they distribute.
[1] https://github.com/keycloak/keycloak/issues/43391
1. They co-opted the free software movement and made it more business friendly.
2. They convinced people that Open Source is pure and software that isn’t Open Source is unclean.
3. They convinced a bunch of developers that their definition of Open Source that was specifically crafted to protect business interests is canon.
4. They convinced a well meaning subset of those developers to police the other devs and pressure them to release their software under big tech approved licenses.
I have nothing against someone trying to monetise useful software. However, switching from an open-source software (OSS) licence is essentially a bait-and-switch tactic. This immediately destroys trust. It also destroys the part of the user base that is difficult to monetise but still has the potential to be monetised. I was hoping that the Elastic and TerraForm debacles had taught people a lesson.
Flyway is also questionable at this point. If Liquibase is switching, what's to stop Flyway?
Unless a fork is happening, I'm considering creating my own migration library tailored to our actual needs and usage. It should not be so hard. Liquibase was more of a convenience.
Alternatively if Liquibase is FSL it will technically be Apache in 2 years I think (not exactly sure how that works) but you could just go to the last non-FSL release and use that for 2 years.
I'm not exactly sure why people would need the most up to datest version of liquibase which just runs schema changes anyway. I used version 2 a bunch of years ago and it was just fine.
Indeed. Go has like 5 options for SQL DDL migrations now. On python side there's alembic and bunch of homegrown stuff in various frameworks.
I think much of the complexity in liquibase comes from supporting various databases.
One thing to remember: mark a new version before each step that can fail, even if the steps themselves are together in the same file.
This is a problem I ran too much into with alembic in which each file is a single unit - a statement in the middle of the script fails and there's no simple way to roll back (unless your DB supports transactional DDL). So the pattern I have settled is to have only one simple change in one file. Liquibase of course doesn't suffer this because it has unique IDs per statement.
During my frustrations I read blogposts saying you can implement schema version changes easily by yourself and I kind of see it... You have to do the thinking by yourself anyway when you declare changeSets?