OrioleDB Patent: now freely available to the Postgres community

The MS-PL has the fairly standard reactive patent shield that only activates for patent-related litigation for the specific software under the license and is kind of similar to the language in Apache 2.0, MPLv2, and GPLv3.

But they have now switched to Apache 2.0, so crisis averted.

Use as a shield would mean limiting it to patent litigation against a user of the software.

It also only covers litigation against Supabase - it does not provide a shield against litigation against OrioleDB users.

On violation the Apache 2.0 license terminates the patent license. I might be mistaken, but that reads an awful lot like you're still allowed to use the software provided you do so in a way which doesn't violate the patent.

On the other hand, the OrioleDB license seems to terminate the entire license - so the way I read this it would include parts of the software which aren't covered under the patent itself.

For practical adoption, especially in larger orgs, OSI-approved licences are much easier to get through legal review than custom ones.

https://engineering.fb.com/2017/09/22/web/relicensing-react-...

For example, if Supabase failed to pay a vendor that happened to use OrioleDB they wouldn't be able to sue you for damages without compromising their stack. That's uncool.

My take-away from the Facebook/React license issue was that the community agrees this violates the spirit of FOSS and invalidates claiming to be open source (at least OSI-approved), with many taking offense to the punitive nature of the clause.

Granted Facebook was in a position to see litigation over a lot more reasons.

https://github.com/orioledb/orioledb/pull/558

It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed. I'll amend the blog to make that clearer.

https://opensource.org/license/ms-pl-html

Microsoft used it a ton, until they eventually just made everything open-source fall under the MIT license.

Some people will still be angry about it (I got a downvote for just mentioning it elsewhere on this thread) but as the person who built your software, you have every right to license your software as you deem necessary. There is a cost to what you've built and you have no true obligation to give everything for free.

On that note, as far as I can remember the MS-PL is OSI approved already.

GPLv3 has text about this in (s)11, MPLv2 has (s)2.3, and Apache-2.0 has s(3). GPLv2 doesn't have an explicit patent grant (and while some folks have argued that it has an implicit one that is just as good, I think the general consensus is that GPLv2 is not immune to patent trolls). All of them still allow you to make modifications but they do not guarantee that some other patents will not be infringed by your modifications and open you up to patent lawsuits (even from the same entity).

Assuming a lawyer wrote this, this is probably part of the reason for it. But it does feel a little sloppy, a separate patent license with clear terms would probably be more preferable.

https://news.ycombinator.com/item?id=45196771

The closest that comes to mind is "Free Nestlé bottled water".

I am "owner" of a bunch of patents, too, and some have actually been proven their test of time by after years having been re-invented (better: "parallel-invented later in time") elsewhere in the open source world.

But in my value system one does not do press releases saying "HELLO! We have decided not to do something evil!".

They could have done the very same thing done quietly to make clear there is no hidden agenda.

"Look, we hold this trivial patent on the open source ecosystem. No no no, all will be fine. No, no, we will not pick up the phone should Broadcom call us one day."

Yay. \o/

In term of other workloads it might not be great for, all my testing has shown a great improvement in every workload I have thrown at it.

and many extensions (e.g. postgis) already work fine with OrioleDB storage.

Any time you have to check constraints manually, you can't just do it before the write, or after the write, because two REPEATABLE READ write transactions will not see each other's INSERT.

You need something like a lock, a two-phase commit, or SERIALIZABLE isolation for writes. Advisory locks have sharp edges, and 2PC is not so simple either, there is a lot that can go wrong.

In the case of SERIALIZABLE you do need to retry in case of conflict, but usually the serialization anomalies can be limited to a reasonably fine level. And an explicit retry feels safer than risking a livelock situation when there is contention.

I use MySQL, not Postgres, for this application (for better or for worse), and I can absolutely generate a bad state if I drop MySQL to a level below SERIALIZABLE — I’ve tried it. (Yes, I could probably avoid this with SELECT FOR UPDATE, but I don’t trust MySQL enough and I get adequate performance with SERIALIZABLE.)

To make SERIALIZABLE work well, I wrap all the transactions in retry loops, and I deal with MySQL’s obnoxious reporting of which errors are worthy of retries.

(Aside from bad committed states, I’ve also seen MySQL return results from a single straightforward query that cannot correspond to any state of the table. It was something like selecting MIN, MAX and COUNT(*) from a table and getting min and max differing and count = 1. It’s been a while — I could be remembering wrong.)

I think that "under review" claim is doing some very heavy lifting, especially when it relates to their changes to index tuple lifecycle management. The patches that have been submitted are unlikely to get committed in full anytime soon, even after substantial changes to the patches' designs.

PostgreSQL just has not been designed for what OrioleDB is doing, and forcing OrioleDB's designs into PostgreSQL upstream would a lot of (very) sharp edges that the community can't properly test without at least a baseline implementation - which critically hasn't been submitted to upstream. Examples of these sharp edges are varsized TIDs, MVCC-owning indexes, and table AM signalled index inserts.

There are certainly ideas in OrioleDB's designs that PostgreSQL can benefit from (retail index tuple deletion! self-clustering tables!), but these will need careful consideration in how this can be brought into the project without duplicating implementations at nearly every level. A wholesale graft of a downstream fork and then hoping it'll work out well enough is just not how the PostgreSQL project works.

1. With PostgreSQL heap, you need to access the heap page itself. And it's not for free. It goes all through the buffer manager and other related components.

2. In OrioleDB, we have a lightweight protocol to read from pages. In-memory pages are connected using direct links (https://www.orioledb.com/docs/architecture/overview#dual-poi...), and pages are read lock-less (https://www.orioledb.com/docs/architecture/overview#page-str...). Additionally, tree navigation for simple data types skips both copying and tuple deforming (https://www.orioledb.com/blog/orioledb-fastpath-search).

According to all of the above, I believe OrioleDB still wins in the case of secondary key lookup. I think this is indirectly confirmed by the results of the TPC-C benchmark, which contains quite a lot of log of secondary key lookups. However, this subject is worth dedicated benchmarking in the future.

Wait when you need to manage a bunch of servers yourself. Unfortunately, the solutions available are complex, and not something where you can simply points something to a server, or VPS, and have a quick total controlled kernel level solution. K8, sure, but even that is not on the same level. And when you then need to manage DB's, your often placing those outside K8. Most scalable solutions like CRDB (10m pay, required yearly "free" license approval), Yugabyte(half broken), TiDB ... have their own issues and again, do not tie into a complete managed cloud experience.