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?).
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.
"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."
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.
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)
(if the atlasgo team are reading this feel free to reach out too)
For practical adoption, especially in larger orgs, OSI-approved licences are much easier to get through legal review than custom ones.
We could also change to MIT/Apache but we feel PostgreSQL is more appropriate given our intentions to upstream the code
That's just not true. Your license[0] adds a clause to the Postgresql license[1]. This makes it a different license, which by extension also means it isn't OSI approved.
It's the same with the BSD licenses[2]: the 4-clause one is OSI-approved, whereas the 3-clause one is not. Turns out that one additional "all advertising must display the following acknowledgement" clause was rather important - and so is your lawsuit clause.
[0]: https://github.com/orioledb/orioledb?tab=License-1-ov-file
[1]: https://github.com/postgres/postgres?tab=License-1-ov-file
[2]: https://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_...
I hope you can look at the Apache 2 patent grant as a better clause- or even adopt something like Google's Additional IP License found here- https://www.webmproject.org/license/additional/, which doesn't modify the open source license but instead adds an additional grant as a separate license.
Supabase is doing great work, thank you!
https://engineering.fb.com/2017/09/22/web/relicensing-react-...
IANAL nor a patent judge, but this is my understanding after watching the space for some years.
How does it compare with Neon DB?
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.
Of course, the flip side of the coin is that if you do an UPDATE of a row in the presence of a secondary index, and the UPDATE doesn't touch the key, then you don't need to update the index(es) at all. So it really depends on how much you update rows versus how often you index-scan them IME.
[1] TPC-H doesn't have difficult enough queries to really stress the planner, so it mattered comparatively less there than in other OLAP work.
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.”
Our goal now is to ensure that it’s as F/OSS as possible given the pre-existing conditions
Just to add: if anyone wants to contribute (beyond code) benchmarking and stress-testing is very helpful for us
https://www.orioledb.com/docs#patch-set
The actual storage engine is written as an extension - these patches are mostly to improve the TAM API. If these are accepted by the community then it should be simpler for anyone to write their own Storage extensions.
I think (correctly) it will take a lot longer to upstream the extension - the PG community should take a “default no” attitude with big changes like this. Over time we will prove its worthiness (hopefully beyond just supabase - it would be good to collaborate with other Postgres providers)
Would be really nice with a pgdg package, as this is definitely the kind of thing I would want to test in a separate cluster :-)
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...
RDS support when
Ahead in production. Did China research/innovate/develop those industries, or were they 'just' fast followers? (Early in its history the US used the same 'tactics' relative to the UK and other European countries.)
This is an unfortunate limitation to be aware of when evaluating
https://www.orioledb.com/docs/usage/getting-started#current-...
"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.
hardwaresofton•3h ago