OrioleDB Patent: now freely available to the Postgres community
supabase.com408 points by tosh 3 days ago
408 points by tosh 3 days ago
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?).
(Supabase ceo)
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)
fixed - sorry about the confusion.
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.
Kudos to your legal team for working with you to provide a quick response. Licensing grants are momentous decisions it exceeds my expectations for you to act within the span of hours.
This change looks much better, thanks!
> "It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed."
It’s worth double-checking the relicensing angle. Imho: you can only relicense your own code. Any 3rd party contribution stays under apache 2.0 unless the author explicitly agrees.
So a full switch to postgresql license is only possible if every contributor signs off. That usually means having a Contributor License Agreement (CLA) in place up front.
And ethically, contributors should already know their work might be relicensed under "postgresql terms" later - otherwise it's a surprise change for the community.
ps: if the plan is serious, do the legal homework early and gather consents now, so upstreaming to postgresql doesn’t fail later because a few open-source contributors (who aren’t supabase/orioledb employees) are unreachable.)
IANAL, but I don't think that is completely necessary for Apache 2.0. It isn't a copyleft license, so it's fine for derivative works (such as merging it into postgres) to use a different license. It would however create a bit of a hassle, since postgres would need to include the Apache license as well and make a note of the fact that the original code was also licensed under Apache 2.0.
> since postgres would need to include the Apache license
imho: given that postgres has many corporate forks and contributors from different companies, mixing apache 2.0 and postgresql licenses isn’t ideal - it complicates the legal picture and can even block upstream acceptance.
And if supabase's goal is really this [1], then it makes sense to think through the legal side now and start consulting with the upstream Postgres community early.
[1] https://supabase.com/blog/orioledb-patent-free#aligned-with-...
"We believe the right long-term home for OrioleDB is inside Postgres itself. Our north star is to upstream what’s necessary so that OrioleDB can eventually be part of the Postgres source tree, developed and maintained in the open alongside the rest of Postgres."
Clarification:
As I see it, postgresql already includes a small amount of Apache 2.0 licensed code.
So it’s not as big an issue as I originally thought.
https://github.com/search?q=repo%3Apostgres%2Fpostgres%20apa...
example:
https://github.com/postgres/postgres/blob/88824e68611a88a4ef...
Great, thanks for this - we’ll make sure we have something in place
You could put it under a "PostgreSQL OR Apache-2.0 at your option" dual-license, so all contributors give you their code under both licenses, instead of needing to re-license later. The Rust project does this (MIT OR Apache-2.0) to get the patents clause from Apache while retaining compatibility with MIT and GPL.
If you do this, you need to have a very explicit policy for contributors to say they are contributing under both licenses, though this is something you need to have anyway if you are licensing under Apache 2.0 (a contributor could theoretically claim retroactively that their contributions were all MIT licensed and that they never gave you or any of your users a patent grant). (Most Rust projects do this.)
For other patent-shield licenses such a combination also removes most of the protections of the patent shield (a patent troll user can use the software under MIT and then sue for patent infrigement). However, the Apache 2.0 patent shield is comparatively weak (when compared to GPLv3 and MPLv2) because it only revokes the patent license rather than the entire license and so it actually acts like a permissive license even after you initiate patent litigation. This makes the above problem even worse -- if you don't actually have any patents in the software then a patent troll can contribute code under MIT then sue all of your users without losing access to the software even under just Apache 2.0 (I don't know if this has ever happened but it seems like a possibility).
IMHO, most people should really should just use MPLv2 if they want GPLv2 compatibility and patent grants. MPLv2 even includes a "you accept that your contributions to this project are under MPLv2" clause, avoiding the first problem entirely. It would be nice if there were an Apache 3.0 that had a stronger patent shield but still remained a permissive license (MPLv2 is a weak file-based copyleft), but I'm more of a copyleft guy so whatever.
> However, the Apache 2.0 patent shield is comparatively weak (when compared to GPLv3 and MPLv2) because it only revokes the patent license rather than the entire license and so it actually acts like a permissive license even after you initiate patent litigation.
Isn't the idea that you could then sue the suer for infringing your patent?
Sure, if you have a patent. If you don't and the patent shield is intended more as pre-emptive protection then MPLv2 or GPLv3 are better.