Hacker News Reader

Comment by einrealist | Hacker News Reader

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.

View on HN

I would add EventstoreDB (now KurrentDB) and NATS to the list of questionable service providers. The former has already relicensed it's service, and the latter had also intended to do so, they just chickened out after seeing the reactions and resistence from their user base. It's really become a business strategy at this point to pull the rug below the users.

I thought NATS was a project under the CNCF, with the trademarks being transferred to the Linux Foundation, which is why they couldn't relicense NATS, and why they can't relicense it in the future.

The beauty of open source is you can always fork the previous version. I don't see how it's anymore of a bait and switch than a vendor raising the price of a product.

> I don't see how it's anymore of a bait and switch than a vendor raising the price of a product.

That's often called bait and switch if a subscription price is hiked significantly.

No relation. This is free, open source, where you can fully use, modify, and continue it as far into the future as you want. A paid model, you lose access if you don't adhere. With this, you're losing nothing except future development time, which you were previously getting for free. These are completely different things.

My naive interoperation of this comment section says there were quite a few people making money on this work, without helping them pay their bills.

The ability to fork something doesn't mean its viable or reasonable for everyone. That's a risk to users in case of both extremes: bait-and-switch tactics (mostly due to commercial motivations) or abandoned projects (see ASF Attic).

> doesn't mean its viable or reasonable for everyone

Related, it's often not viable to give away something for free.

Was Elastic's relicensing a debacle from their perspective? Their share price did drop a bit after the announcement, but the company seems to still be quite healthy. For example, everyone I know who's working on search and RAG products right now is doing it with Elasticsearch. The version published by Elastic NV, not the Open Source fork or any other open source alternative.

And perhaps more to the point, their revenue now is about twice what it was in 2020. That's hardly the situation I would expect to see if the move had destroyed people's trust in the company. If anything it seems like it might have had the opposite effect, at least among the demographic that matters most to Elastic as a company: paying customers.

For users, it was more of a debacle, with Amazon being one of the biggest companies to rely on stable permissive licensing. Users who could not afford commercial licenses or were unable to accept the new license for legal reasons found themselves in limbo. I am sure that Elastic lost (potential) business to OpenSearch (and AWS). By how much is hard to measure. Sure, they were able to retain enough business. It probably attests to good service and product.

And AWS has agreements with services with similar services, eg MongoDB. Maybe elasticsearch asked for too much money, or AWS didn't want to pay out of principle.

It's Postgres specific but there is https://github.com/xataio/pgroll which takes the automation a step further.

Apart from Flyway (Apache), Atlas (Apache) and Sqitch (MIT) still use "Open Source" licenses.

Don't confuse the license with project ownership. Flyway is owned by Red Gate Software and the community edition of Flyway is licensed under Apache 2.0. Apache Atlas is owned by the Apache Software Foundation AND licensed under Apache 2.0.

I'm pretty sure they mean https://atlasgo.io/ and not https://atlas.apache.org/.

Ah, my fault. But that does not change the point I try to make: project ownership is equally important, if you cannot just fork and maintain some open source software yourself. It's something to include in risk calculations.

> 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.

It takes some thinking, but you can just use plain SQL to do the migrations.

That amounts to creating own db migration tool.

Writing idempotent DDL is not that hard and then you don’t have the problem the migration tools solve (tracking state).

Which of course will give you around 10% of what liquibase and flyway do.

everything is always super easy here on HN, liquibase is just SQL you know :)

It takes some thinking, but you can just use rsync to build your own version of Dropbox.

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.

What is their new license blocking you from doing?

The commercial use permissions look murky to me. But I'm not in the legal department.

What's more important is trust. What's to stop them from changing the licence again after evaluating the impact of the first change? Liquibase has collected "anonymous" metrics by default since version 4.30 (do they consider an IP address and timestamp as PII?). As soon as I saw that, I anticipated this scenario. It was not really a surprise. They have a way to analyse the impact. Now, I am reassessing the risks.

Reply on news.ycombinator.com