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.
In this case, they do have a patent.
Sure, that is the point of the original point of the article after all. I was speaking about the problem in general (I suspect most Rust projects--if not most projects in general--with this setup do not have patents).
It also requires actively persuing a patent case which may result in the patent being rendered invalid, while a termination clause for the whole license just requires a far more clear-cut copyright infringement claim (possibly achievable purely through the DMCA system, out of court). But I'm not a lawyer, maybe counter-suits are more common in such situations and so either approach is just as good in practice.
I always use the easy license for this stuff: Unlicense lol
Great, but Unlicense doesn't grant patent rights so you have the exact same problem as MIT (actually it's even worse because Unlicense explicitly states that it is only concerned with copyrights multiple times).
Thanks for the quick fix.
Facebook famously dropped Patents from their BSD + Patents for React and a bunch of other projects, and went MIT unencumbered.
https://engineering.fb.com/2017/09/22/web/relicensing-react-...
The whole patents kerfuffle with Facebook was about a larger issue with their patent grant. Critically the issue was that it practically stopped you from suing Facebook for any patent issues (not just those granted for React, which would be more like the standard reactive termination clause), including counter-suits. Here is the key text from their patent license:
And so that was a fairly justified reaction IMHO. Funnily enough, it seems that the license written by Supabase has the same issue -- I suspect this might just be the "default approach" for patent lawyers.However, MIT has _no_ patent protections and is strictly worse than almost any license with some patent protections for users included. The modern landscape of software patent trolls is far less insane than it was in the 90s but I would really think twice about using something that is likely patented under a license other than Apache-2.0, MPLv2, or GPLv3.
Google has a strong patent shield situation with AV1. Despite burning interest from patent trolls, no one is going after AOMedia members directly.
Agree with this—the A/V media system has some of the most active patent trolls around. https://aomedia.org/license/patent-license/
The relevant patent license is the following:
> 1.3. Defensive Termination. If any Licensee, its Affiliates, or its agents initiates patent litigation or files, maintains, or voluntarily participates in a lawsuit against another entity or any person asserting that any Implementation infringes Necessary Claims, any patent licenses granted under this License directly to the Licensee are immediately terminated as of the date of the initiation of action unless 1) that suit was in response to a corresponding suit regarding an Implementation first brought against an initiating entity, or 2) that suit was brought to enforce the terms of this License (including intervention in a third-party action by a Licensee).
The existing Postgres license already has an "as is" disclaimer, so adding this clause means you want to _punitively_ punish companies that sue you for reasons outside of this software. The interpretation then is you want to punish users of your software that find themselves in a (potentially legitimate) situation to sue you over unrelated matters.
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.
Appreciate the intent!
For practical adoption, especially in larger orgs, OSI-approved licences are much easier to get through legal review than custom ones.
The current license is PostgreSQL (which is OSI approved)
We could also change to MIT/Apache but we feel PostgreSQL is more appropriate given our intentions to upstream the code
> The current license is PostgreSQL
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_...
sorry about the confusion - I wasn't as involved in this process as I should have been. My fault. This is now fixed:
https://github.com/orioledb/orioledb/pull/558
The code 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
Thanks for the fix!
From the phrasing it already seemed your heart was in the right place, but I understand that it can get tricky once people get involved who aren't as familiar with the details of open source licensing.
Getting legal to sign off on a different license this quickly is impressive!
(er, surely it's the other way around? the 3-clause one is OSI approved and the 4-clause one is not)
Anyway, I'm not sure this is true. Having a separate software license + secondary patent grant license is very very common in open source projects where patent trolls are common. See e.g. https://aomedia.org/about/legal/
I would just put them in separate files and then you're good to go.
I like how well-thought-out the licence revocation clause of the AOMedia patent licence is. It takes effect when a licensee sues over an implementation specifically over the relevant patent claims--so lawsuits unrelated to these patent claims are allowed (so if you infringe on other patents but also implement the licensed patent in the same implementation, the rights holder of the other patents can sue you over those claims without losing their licence)--and there is also a carve-out for counterclaims, and lawsuits to enforce this licence.
But I am not sure if the first exemption is necessarily a good thing. The Apache License, Version 2.0 is broader in what may be grounds for patent licence termination. So it is a better deterrent against patent trolls (even if that means some legitimate patent claims are also discouraged).
Cypher in a sibling comment makes a good argument that this was the same logic (patent termination for legitimate, non-licensed patent claims) that got Facebook in trouble: https://news.ycombinator.com/item?id=45199687
I re-read the text again and it's even worse than the Facebook one -- the entire license terminates in reaction to any litigation, not just patent litigation. Hypothetically, a former employee suing Supabase for violation of workers' rights would not be allowed to use the software anymore.
But they have switched to Apache 2.0 now, so crisis averted.
> (er, surely it's the other way around? the 3-clause one is OSI approved and the 4-clause one is not)
Whoops, I did indeed type that a bit too quickly.
> Having a separate software license + secondary patent grant license is very very common
Perhaps, but those are separate. In this instance it was one and the same license, with any violation of the patent part terminating the whole license - including the non-patented software parts.
Additionally, the AOMedia patent license seems to be a bit different: the OrioleDB one said it would terminate when you sued Supabase (and to make it worse: sue them for any reason), but the AOMedia one says it'll terminate if you sue anyone over the licensed patents.
In other words: the OrioleDB one protected only Supabase, the AOMedia one protects the entire community. When it comes to being compatible with open source licenses, details like that become crucial.
The PostgreSQL license does not have a termination clause, you added that. I see that you are trying to use the PostgreSQL license as the basis and simply add the patent clause onto it, but it fundamentally changes the 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!
Can you acquire atlasgo too, or is that still on the secret roadmap?
we will have something to announce in this space within a few months
(if the atlasgo team are reading this feel free to reach out too)
This is highly unprofessional.
Have them look at, and consider just adopting the MS-PL?
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.
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."
https://opensource.org/license/apache-2-0
It also seems a lot less strict on what is being terminated.
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.
MPLv2 has a stronger version of this (I also personally prefer it in general to Apache-2.0 if you can't stomach GPLv3).
https://news.ycombinator.com/item?id=45200014
A shield for Supabase, not for us
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.
A common issue with open source patent licenses is that they cannot grant blanket patent rights from contributors without some limitation around modifications, as it would allow someone to trivially render all of contributors' patents invalid (they just have to write a patch for the software that implements a patent you hold).
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.
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.
The difference is that the license is terminated by ANY litigation against Supabase - e.g. if you sue them for breach of contract completely unrelated to the software.
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.
Or litigation from a future license violation
Sounds like the MS-PL which Microsoft used to use but switched to MIT. MS-PL is basically MIT but cover your butt against patent litigation.
You need to read the text more carefully -- the license terminates for any litigation against Supabase at all. Hypothetically, a former employee of Supabase suing them for some employee rights violation would no longer be allowed to use the software, which is not the case for any other OSI-approved license with patent shields.
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.