from the blog:
"The patent is intended as a shield, not a sword, to protect Open Source from hostile IP claims."
vs. the current license:
"IF ANY LITIGATION IS INSTITUTED AGAINST SUPABASE, INC. BY A LICENSEE OF THIS SOFTWARE, THEN THE LICENSE GRANTED TO SAID LICENSEE SHALL TERMINATE AS OF THE DATE SUCH LITIGATION IS FILED."
imho: the current wording might discourage state organisations, since even a trivial lawsuit (e.g. a minor tax delay) could terminate the licence - perhaps a narrower patent-focused clause would work better (or an OSI-approved licence?).
I’ll revisit this with legal to try make it clearer.
Our intentions here are clear - if people have examples that we can follow we will do what we can to make this irrevocable (even to the extent of donating the patent if/when the community are ready to bear the cost of the maintainance)
Apache 2.0 has a better patent clause - against hostile IP claims, so tax dispute is not terminate the OrioleDB license:
"If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed."
Does the current license even allow for friendly forks, or redistribution?
It starts off nice with the usual:
> PERMISSION TO USE, COPY, MODIFY, AND DISTRIBUTE THIS SOFTWARE AND ITS DOCUMENTATION FOR ANY PURPOSE, WITHOUT FEE, AND WITHOUT A WRITTEN AGREEMENT IS HEREBY GRANTED
.. but then there's the:
> HEREBY GRANTS A (..) LICENSE TO UNITED STATES PATENT NO. 10,325,030 TO MAKE, HAVE MADE, USE, HAVE USED, OFFER TO SELL, OFFERED TO SELL, SELL, SOLD, IMPORT INTO THE UNITED STATES, IMPORTED INTO THE UNITED STATES, AND OTHERWISE TRANSFER THIS SOFTWARE
.. which to me seems to be missing some kind of "modify" clause? Sure, it seems like you're allowing me to distribute it as-is the way a store like Amazon distributes boxes, but what happens when I start modifying the code and distributing those modifications? Is it still "this software", or has it become a derivative? Is the license I get to that patent even sublicensable? What happens to users of a fork when the forkee sues Supabase: do they also by extension lose their patent license?
The GPLv2, for example, has a clause stating that "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor" which makes it very clear what happens. If you're adding a poison pill to open-source code, you really shouldn't be this sloppy: it should be painfully obvious to every reader what the implications are, or nobody will ever risk using it.
So what? I don't see any conflict between what they said and what the license says. As they stated, it's being used as a shield. If you're suing them, you probably don't deserve a free license to their patented tech.
Had a quick look at the patent, had a quick look at the code. To me it appears that 99,999% of all involved research has been taken from prior research from tons of scientists.
You might have good intentions, but in my value system if you invite others to also enjoy what you have stolen, you still are just a thief.
Polite reminder: Just because you managed to trick the US Patent Office into stamping your patent application does not mean you have invented something. It simply means you have managed to convince a bureaucrat to give you a stamp so you can claim ownership about other researchers' work.
Want to be part of the good guys? Burn the patent, and apologize to the research community you tried to steal from.
> Had a quick look at the patent, had a quick look at the code. To me it appears that 99,999% of all involved research has been taken from prior research from tons of scientists.
How'd you arrive at this conclusion? The stuff in the body of the patent can be expected to be 99.99% of widely known stuff, always.
What counts is that something new is disclosed, and that is what the claims cover.
A description of a patent must be enabling: it must tell someone ordinarily skilled in the art enough to reproduce the claimed invention. Gesticulating at "you could find a bunch of the simpler steps in earlier research papers" is not good enough.
How far attorneys go to make sure a patent description is wildly varying (I remember some of my earlier ones take some time to describe what a CPU and program are...) but it's best to error on the side of caution and describe well known techniques. Otherwise, you might spend time arguing in future litigation about whether the average software engineer in 2015 knew how to do a particular thing.
You're being entirely unfair to Supabase here. Research is important, but there is a reason why the USPTO has developed substantial case law around Reduction to Practice, everything is built on prior work, so to say there is nothing novel about actually building displayed working system from parts is factually inaccurate.
This comment makes no sense. They're actively open sourcing the patent and trying to get it upstream into Postgres. They purchased another company to get this patent, and they're spending a lot of money on lawyers to figure out how to release it to the community.
Call out shady shit when companies do shady things, but the sentiment behind this comment seems to be looking for reasons to bee outraged instead of at what's actually being done.
If companies get evicerated every time they try to engage with the community they'll stop engaging. We should be celebrating when they do something positive, even if there are a few critiques (e.g. the license change call out is a good one). Instead, half the comments seem like they're quick reactions meant to stoke outage.
Please have some perspective - this action is a win for the community.
> To reinforce the IP compatibility, Supabase is making available a non-exclusive license of U.S. Patent (“Durable multiversion B+-tree”) to all OrioleDB users, including proprietary forks, in accordance with the OrioleDB license.
It seems that they have changed their mind to make it even more permissive.
They just relicensed the OrioleDB project under Apache 2.0 an hour ago [0], which contains a patent clause.
Open-sourcing a patent in the database space is rare. Do you think this signals a shift where companies will realize that open ecosystems drive adoption faster than closed IP walls?
I think no-open-source is a no-go. In the "best" case it adds a lot of friction in a sales funnel for premium offerings. You can avoid open source in special cases, mostly without complementary offerings.
According to the docs, it “uses Postgres Table Access Method (TAM) to provide a pluggable storage engine for PostgreSQL. […] Pluggable Storage gives developers the ability to use different storage engines for different tables within the same database. Developers will be able to choose a storage method that is optimized for their specific needs: some tables could be configured for high transactional loads, others for analytics workloads, and still others for archiving.”
I am super bullish on OrioleDB. It really seems like the next logical progression for scaling Postgres for 99% of all databases out there. I have been following their development for a while and running benchmarks to see if their performance claims are legitimate, and so far it has been amazing
Based on the README [0] and discussion [1] it seems like it might especially shine on high-write-volume workflows, with the implementation of anti-bloat measures. Do you have a sense for whether it would shine even further where those rows have large text/JSONB fields that might be TOASTed?
And more generally, curious if you have any sense for what might make up the "1%" of workflows this wouldn't be advisable for? Any downsides to be aware of?
OrioleDB looks interesting but the with the storage changes, the issue will be the compatability with other extensions. pg_search (paradedb), timescale come to mind.
We have seen this issue with YugabyteDB, and their integration off RocksDB as the storage engine for postgresql.
IP owners often play the game of “patent what you can, threaten with the rest.” So you might not be able to strictly patent the way data is laid out, but specific, novel algorithms that update or manipulate that layout and improve what was possible before? Those can be understood as key steps of an “innovative process”—and courts have been willing to uphold process claims, especially when tied to what they understand are genuine technical improvements. Fighting even a marginal patent usually means a long, expensive slog with plenty of downside risk.
IANAL nor a patent judge, but this is my understanding after watching the space for some years.
In general China has historically taken any sort of intellectual property rights and outright theft very differently then the rest of the developed world.
That's just the path for all who do this stuff. America seems culturally to like IP (everyone saying that copyright law is paramount and LLMs should be stopped, etc.) but that's just recent history.
We will eventually add the SERIALIZABLE isolation level to OrioleDB, but right now that's not our highest priority. Let me explain why. At first, SSI (serializable snapshot isolation) in PostgreSQL comes with significant shortcomings, including.
1) Overhead. SSI implies a heavyweight lock on any involved index page or heap tuple (even for reads). The overhead of SSI was initially measured at ~10%, but nowadays, scalability has gone much farther. These many HW-locks could slow down in multiple times a typical workload on a multicore machine.
2) SSI needs the user to be able to repeat any transaction due to serialization failure. Even a read-only transaction needs to be DEFERRABLE or might be aborted due to serialization failure (it might "saw impossible things" and needs a retry).
In contrast, typically it's not hard to resolve the concurrency problems of writing transactions using explicit row-level and advisory locks, while REPEATABLE READ is enough for reporting. Frankly speaking, during my whole career, I didn't see a single case where SERIALIZABLE isolation level was justified.
This is not an open source license and it's untrue to say it's an open source project when it's licensed this way.
"IF ANY LITIGATION IS INSTITUTED AGAINST SUPABASE, INC. BY A LICENSEE OF THIS SOFTWARE, THEN THE LICENSE GRANTED TO SAID LICENSEE SHALL TERMINATE AS OF THE DATE SUCH LITIGATION IS FILED."
This is a poison pill. At best the licensing is naive and blocks even customers of Supabase from using OrioleDB, at worst it's an attempt for Supabase to provide themselves unlimited indemnity through the guise of a community project. It means the moment you sue Supabase for anything. Contract dispute, IP, employment, unrelated tort you lose the license. They could lose your data and if you try do anything about it they can immediately counter sue for a license violation. Using the brand of the postgres license to slip this in is pretty wild.
OrioleDB looks like a promising project and undoubtedly an great contribution from Supabase but it's not open source or really usable by anyone with this license.
Oreole is not a plug-and-play yet.
From their docs ( https://www.orioledb.com/docs )
> OrioleDB currently requires a set of patches to PostgreSQL to enhance the pluggable storage API and other PostgreSQL subsystems. All of these patches have been submitted to the PostgreSQL community and are under review.
You get basically most of the advantages of a B-tree-oriented table, but also most of the disadvantages AFAIK. In particular, any index lookup/scan is going to take twice as long (index blocks don't point to the place on disk, they just contain the primary key and then you need to go lookup _that_ in the actual table).
Legal shield? So once again people have to do manual legal work for something that can be taken for granted in any (L)GPL* software.
We should start counting the times a permissive-licensed software needs this kind of protection, and then wonder what is the difference between all this effort and just going GPL.
You don't need to hang onto hopes and public shaming until someone else does the hard part.
[+] [-] 916c0553e164269|6 months ago|reply
vs. the current license:
( https://github.com/orioledb/orioledb/blob/main/LICENSE )imho: the current wording might discourage state organisations, since even a trivial lawsuit (e.g. a minor tax delay) could terminate the licence - perhaps a narrower patent-focused clause would work better (or an OSI-approved licence?).
[+] [-] kiwicopple|6 months ago|reply
I’ll revisit this with legal to try make it clearer.
Our intentions here are clear - if people have examples that we can follow we will do what we can to make this irrevocable (even to the extent of donating the patent if/when the community are ready to bear the cost of the maintainance)
[+] [-] 916c0553e164269|6 months ago|reply
"If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed."
https://opensource.org/license/apache-2-0
[+] [-] yellow_lead|6 months ago|reply
[+] [-] crote|6 months ago|reply
It starts off nice with the usual:
> PERMISSION TO USE, COPY, MODIFY, AND DISTRIBUTE THIS SOFTWARE AND ITS DOCUMENTATION FOR ANY PURPOSE, WITHOUT FEE, AND WITHOUT A WRITTEN AGREEMENT IS HEREBY GRANTED
.. but then there's the:
> HEREBY GRANTS A (..) LICENSE TO UNITED STATES PATENT NO. 10,325,030 TO MAKE, HAVE MADE, USE, HAVE USED, OFFER TO SELL, OFFERED TO SELL, SELL, SOLD, IMPORT INTO THE UNITED STATES, IMPORTED INTO THE UNITED STATES, AND OTHERWISE TRANSFER THIS SOFTWARE
.. which to me seems to be missing some kind of "modify" clause? Sure, it seems like you're allowing me to distribute it as-is the way a store like Amazon distributes boxes, but what happens when I start modifying the code and distributing those modifications? Is it still "this software", or has it become a derivative? Is the license I get to that patent even sublicensable? What happens to users of a fork when the forkee sues Supabase: do they also by extension lose their patent license?
The GPLv2, for example, has a clause stating that "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor" which makes it very clear what happens. If you're adding a poison pill to open-source code, you really shouldn't be this sloppy: it should be painfully obvious to every reader what the implications are, or nobody will ever risk using it.
[+] [-] Reubend|6 months ago|reply
[+] [-] cwillu|6 months ago|reply
[+] [-] giancarlostoro|6 months ago|reply
[+] [-] Fischgericht|6 months ago|reply
You might have good intentions, but in my value system if you invite others to also enjoy what you have stolen, you still are just a thief.
Polite reminder: Just because you managed to trick the US Patent Office into stamping your patent application does not mean you have invented something. It simply means you have managed to convince a bureaucrat to give you a stamp so you can claim ownership about other researchers' work.
Want to be part of the good guys? Burn the patent, and apologize to the research community you tried to steal from.
[+] [-] mlyle|6 months ago|reply
How'd you arrive at this conclusion? The stuff in the body of the patent can be expected to be 99.99% of widely known stuff, always.
What counts is that something new is disclosed, and that is what the claims cover.
A description of a patent must be enabling: it must tell someone ordinarily skilled in the art enough to reproduce the claimed invention. Gesticulating at "you could find a bunch of the simpler steps in earlier research papers" is not good enough.
How far attorneys go to make sure a patent description is wildly varying (I remember some of my earlier ones take some time to describe what a CPU and program are...) but it's best to error on the side of caution and describe well known techniques. Otherwise, you might spend time arguing in future litigation about whether the average software engineer in 2015 knew how to do a particular thing.
[+] [-] dkhenry|6 months ago|reply
https://en.wikipedia.org/wiki/Reduction_to_practice
[+] [-] pas|6 months ago|reply
that's ... that's what they are doing by making it freely available, no?
this helps anyone who is covered by the patent because they are (a bit better) protected from other patent trolls (and from other IP litigation)
[+] [-] mind-blight|6 months ago|reply
Call out shady shit when companies do shady things, but the sentiment behind this comment seems to be looking for reasons to bee outraged instead of at what's actually being done.
If companies get evicerated every time they try to engage with the community they'll stop engaging. We should be celebrating when they do something positive, even if there are a few critiques (e.g. the license change call out is a good one). Instead, half the comments seem like they're quick reactions meant to stoke outage.
Please have some perspective - this action is a win for the community.
[+] [-] maxloh|6 months ago|reply
It seems that they have changed their mind to make it even more permissive.
They just relicensed the OrioleDB project under Apache 2.0 an hour ago [0], which contains a patent clause.
[0]: https://github.com/orioledb/orioledb/commit/44bab2aa9879feb7...
[+] [-] iam_saurabh|6 months ago|reply
[+] [-] wslh|6 months ago|reply
[+] [-] fuzzy_biscuit|6 months ago|reply
[+] [-] kiwicopple|6 months ago|reply
Our goal now is to ensure that it’s as F/OSS as possible given the pre-existing conditions
[+] [-] pbronez|6 months ago|reply
According to the docs, it “uses Postgres Table Access Method (TAM) to provide a pluggable storage engine for PostgreSQL. […] Pluggable Storage gives developers the ability to use different storage engines for different tables within the same database. Developers will be able to choose a storage method that is optimized for their specific needs: some tables could be configured for high transactional loads, others for analytics workloads, and still others for archiving.”
https://www.orioledb.com/docs
[+] [-] dkhenry|6 months ago|reply
https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
[+] [-] kiwicopple|6 months ago|reply
Just to add: if anyone wants to contribute (beyond code) benchmarking and stress-testing is very helpful for us
[+] [-] btown|6 months ago|reply
And more generally, curious if you have any sense for what might make up the "1%" of workflows this wouldn't be advisable for? Any downsides to be aware of?
[0] https://github.com/orioledb/orioledb?tab=readme-ov-file#orio...
[1] https://news.ycombinator.com/item?id=30462695 (2022)
[+] [-] benjiro|6 months ago|reply
We have seen this issue with YugabyteDB, and their integration off RocksDB as the storage engine for postgresql.
[+] [-] 0xb0565e486|6 months ago|reply
[+] [-] jonathaneunice|6 months ago|reply
IANAL nor a patent judge, but this is my understanding after watching the space for some years.
[+] [-] wokkel|6 months ago|reply
[+] [-] hardwaresofton|6 months ago|reply
[+] [-] gethly|6 months ago|reply
[+] [-] InTheArena|6 months ago|reply
[+] [-] renewiltord|6 months ago|reply
When you're in IP, bang on IP
That's just the path for all who do this stuff. America seems culturally to like IP (everyone saying that copyright law is paramount and LLMs should be stopped, etc.) but that's just recent history.
[+] [-] navigate8310|6 months ago|reply
[+] [-] dangoodmanUT|6 months ago|reply
This is an unfortunate limitation to be aware of when evaluating
https://www.orioledb.com/docs/usage/getting-started#current-...
[+] [-] btown|6 months ago|reply
[+] [-] akorotkov|6 months ago|reply
1) Overhead. SSI implies a heavyweight lock on any involved index page or heap tuple (even for reads). The overhead of SSI was initially measured at ~10%, but nowadays, scalability has gone much farther. These many HW-locks could slow down in multiple times a typical workload on a multicore machine.
2) SSI needs the user to be able to repeat any transaction due to serialization failure. Even a read-only transaction needs to be DEFERRABLE or might be aborted due to serialization failure (it might "saw impossible things" and needs a retry).
In contrast, typically it's not hard to resolve the concurrency problems of writing transactions using explicit row-level and advisory locks, while REPEATABLE READ is enough for reporting. Frankly speaking, during my whole career, I didn't see a single case where SERIALIZABLE isolation level was justified.
[+] [-] thayne|6 months ago|reply
[+] [-] samlambert|6 months ago|reply
"IF ANY LITIGATION IS INSTITUTED AGAINST SUPABASE, INC. BY A LICENSEE OF THIS SOFTWARE, THEN THE LICENSE GRANTED TO SAID LICENSEE SHALL TERMINATE AS OF THE DATE SUCH LITIGATION IS FILED."
This is a poison pill. At best the licensing is naive and blocks even customers of Supabase from using OrioleDB, at worst it's an attempt for Supabase to provide themselves unlimited indemnity through the guise of a community project. It means the moment you sue Supabase for anything. Contract dispute, IP, employment, unrelated tort you lose the license. They could lose your data and if you try do anything about it they can immediately counter sue for a license violation. Using the brand of the postgres license to slip this in is pretty wild.
OrioleDB looks like a promising project and undoubtedly an great contribution from Supabase but it's not open source or really usable by anyone with this license.
[+] [-] boxed|6 months ago|reply
[+] [-] wwizo|6 months ago|reply
[+] [-] Sesse__|6 months ago|reply
[+] [-] victorbjorklund|6 months ago|reply
[+] [-] gallypette|6 months ago|reply
[+] [-] 8cvor6j844qw_d6|6 months ago|reply
How does it compare with Neon DB?
[+] [-] 916c0553e164269|6 months ago|reply
https://www.orioledb.com/blog/orioledb-neon-differences
[+] [-] boxed|6 months ago|reply
[+] [-] LtdJorge|6 months ago|reply
[+] [-] Luker88|6 months ago|reply
We should start counting the times a permissive-licensed software needs this kind of protection, and then wonder what is the difference between all this effort and just going GPL.
You don't need to hang onto hopes and public shaming until someone else does the hard part.
Still, kudos for the grant.
[+] [-] exabrial|6 months ago|reply
[+] [-] exabrial|6 months ago|reply
https://github.com/orioledb/orioledb/commit/44bab2aa9879feb7...
[+] [-] monadoid|6 months ago|reply
[+] [-] awaseem|6 months ago|reply