Thread: How can we submit code patches that implement our (pending) patents?
How can we submit code patches that implement our (pending) patents?
From
"Tsunakawa, Takayuki"
Date:
Hello, As I asked at the PGCon developer meeting this year, we'd like to offer our company's patents and patent applicationslicense to the PostgreSQL community free of charge. If I heard correctly at that time, we could continue thisdiscussion during the unconference, but I missed that opportunity (I'm sorry). So, please let me continue the consultationhere. If some other mailing list is appropriate such as pgsql-core, let me know (but I hope open discussionwill lead to better and fair ideas and conclusion.) There are three ideas. Is there any effective idea? (1) Share patents through a patent pool for open source communities. Our company, Fujitsu Limited, is a licensee member of OpenInvention Network (OIN). And PostgreSQL is the protection target of OIN as listed here: http://www.openinventionnetwork.com/joining-oin/linux-system/linux-system-table/?cat_id=14&type=table Google, IBM, Red Hat, Toyota, and other big names are the big sponsors. The basic membership is free. (2) For each patch we submit to the community that implements our patents, include in the mail body something like "3. Grantof Patent License" in Apache License 2.0: Apache License, Version 2.0 https://www.apache.org/licenses/LICENSE-2.0 (3) Put up a page on our company web site that's similar to Red Hat's "Patent Promise", which is restricted to PostgreSQL. FYI, I've consulted SFLC (Software Freedom Law Center) about this matter, and I've just got a reply "We'll be in touch." I'm waiting for the next response. Regards Takayuki Tsunakawa
On 4 July 2018 at 08:27, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
Hello,
As I asked at the PGCon developer meeting this year, we'd like to offer our company's patents and patent applications license to the PostgreSQL community free of charge. If I heard correctly at that time, we could continue this discussion during the unconference, but I missed that opportunity (I'm sorry). So, please let me continue the consultation here. If some other mailing list is appropriate such as pgsql-core, let me know (but I hope open discussion will lead to better and fair ideas and conclusion.)
There are three ideas. Is there any effective idea?
My big hesitation with all those approaches is that they seem to exclude derivative and transformative works.
PostgreSQL is BSD-licensed. Knowingly implementing patented work with a patent grant scoped to PostgreSQL would effectively change that license, require that derivatives identify and remove the patented parts, or require that derivatives license them.
I'm assuming you don't want to offer a grant that lets anyone use them for anything. But if you have a really broad grant to PostgreSQL, all someone would have to do to inherit the grant is re-use some part of PostgreSQL.
I guess there's a middle ground somewhere that protects substantial derivatives and extracts but stops you using some Pg code snippets as a freebie license.
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Craig Ringer [mailto:craig@2ndquadrant.com] > I'm assuming you don't want to offer a grant that lets anyone use them for > anything. But if you have a really broad grant to PostgreSQL, all someone > would have to do to inherit the grant is re-use some part of PostgreSQL. Your assumption is right. No scope is the same as no patent; it won't help to defend PostgreSQL community against rivalcompanies/communities of other DBMSs. Or, I think we can set the scope to what OIN states. Fortunately, anyone canjoin OIN free of charge. > I guess there's a middle ground somewhere that protects substantial > derivatives and extracts but stops you using some Pg code snippets as a > freebie license. Are you assuming that developers want to use PG code snippets for non-PostgreSQL or even non-DBMS software? I believe thataccepting patented code from companies would be practically more useful for PostgreSQL enhancement and growth. PostgreSQLis now a mature software, and it can be more corporate-friendly like other software under Apache License. Regards Takayuki Tsunakawa
On 4 July 2018 at 21:15, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
From: Craig Ringer [mailto:craig@2ndquadrant.com]
> I'm assuming you don't want to offer a grant that lets anyone use them for
> anything. But if you have a really broad grant to PostgreSQL, all someone
> would have to do to inherit the grant is re-use some part of PostgreSQL.
Your assumption is right. No scope is the same as no patent; it won't help to defend PostgreSQL community against rival companies/communities of other DBMSs. Or, I think we can set the scope to what OIN states. Fortunately, anyone can join OIN free of charge.
> I guess there's a middle ground somewhere that protects substantial
> derivatives and extracts but stops you using some Pg code snippets as a
> freebie license.
Are you assuming that developers want to use PG code snippets for non-PostgreSQL or even non-DBMS software? I believe that accepting patented code from companies would be practically more useful for PostgreSQL enhancement and growth. PostgreSQL is now a mature software, and it can be more corporate-friendly like other software under Apache License.
Certainly there is history of people using PG code for non-PostgreSQL or at least commercial derivative work. Greenplum for example.
On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote: > From: Craig Ringer [mailto:craig@2ndquadrant.com] > > I'm assuming you don't want to offer a grant that lets anyone use > > them for anything. But if you have a really broad grant to > > PostgreSQL, all someone would have to do to inherit the grant is > > re-use some part of PostgreSQL. > > Your assumption is right. No scope is the same as no patent; it > won't help to defend PostgreSQL community against rival > companies/communities of other DBMSs. Or, I think we can set the > scope to what OIN states. Fortunately, anyone can join OIN free of > charge. > > > > I guess there's a middle ground somewhere that protects > > substantial derivatives and extracts but stops you using some Pg > > code snippets as a freebie license. > > Are you assuming that developers want to use PG code snippets for > non-PostgreSQL or even non-DBMS software? Our license very specifically permits all types of derivative software. > I believe that accepting patented code from companies would be > practically more useful for PostgreSQL enhancement and growth. > PostgreSQL is now a mature software, and it can be more > corporate-friendly like other software under Apache License. The Apache license is "friendly" to the patent holder, not so much to the aspiring maker of derivative proprietary software. We went with a very liberal license from the outset for what we believed were good reasons, and that's served us well over the decades. If you're proposing a change of this magnitude, it's going to have to be a lot more convincing than, "it would be convenient for my company this year." Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Hi, On 2018-07-07 19:12:58 +0200, David Fetter wrote: > On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote: > > I believe that accepting patented code from companies would be > > practically more useful for PostgreSQL enhancement and growth. > > PostgreSQL is now a mature software, and it can be more > > corporate-friendly like other software under Apache License. > > The Apache license is "friendly" to the patent holder, not so much to > the aspiring maker of derivative proprietary software. I don't think that's a true characterization. There's no meaningful reduction in freedoms to make derivative proprietary software in of apache 2 vs BSD/MIT like licenses. It gives you additional rights. Are you talking about the retaliatory clause? If so, that only cancel the patent license, not the entire license. > We went with a very liberal license from the outset for what we > believed were good reasons, and that's served us well over the > decades. If you're proposing a change of this magnitude, it's going > to have to be a lot more convincing than, "it would be convenient for > my company this year." It's entirely possible to dual license contributions and everything. Why are you making such aggressive statements about a, so far, apparently good faith engagement? Greetings, Andres Freund
On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote: > Hi, > On 2018-07-07 19:12:58 +0200, David Fetter wrote: > > On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote: > > > I believe that accepting patented code from companies would be > > > practically more useful for PostgreSQL enhancement and growth. > > > PostgreSQL is now a mature software, and it can be more > > > corporate-friendly like other software under Apache License. > > > > The Apache license is "friendly" to the patent holder, not so much to > > the aspiring maker of derivative proprietary software. > > I don't think that's a true characterization. There's no meaningful > reduction in freedoms to make derivative proprietary software in of > apache 2 vs BSD/MIT like licenses. It gives you additional rights. Are > you talking about the retaliatory clause? If so, that only cancel the > patent license, not the entire license. There is according to IP attorneys I've spoken to on the matter, and this is frequently reflected in the open source policies companies have. For liberal licenses, which are enumerated and do not include the Apache license, the process is, as a rule, brief and perfunctory. For all other licenses, the process ranges from cumbersome to not worth doing. > > We went with a very liberal license from the outset for what we > > believed were good reasons, and that's served us well over the > > decades. If you're proposing a change of this magnitude, it's > > going to have to be a lot more convincing than, "it would be > > convenient for my company this year." > > It's entirely possible to dual license contributions and everything. > Why are you making such aggressive statements about a, so far, > apparently good faith engagement? We went out of our way to excise code that the PostgreSQL license doesn't cover some years back. I think that was done for good reasons, which obtain to this day. While the introduction of code someone else ultimately owns may seem harmless or even beneficial today, owners change, as do their motivations. When we have nothing of this kind in the project, we expose our future users to none of that risk. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 2018-07-07 19:37:45 +0200, David Fetter wrote: > On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote: > > Hi, > > On 2018-07-07 19:12:58 +0200, David Fetter wrote: > > > On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote: > > > > I believe that accepting patented code from companies would be > > > > practically more useful for PostgreSQL enhancement and growth. > > > > PostgreSQL is now a mature software, and it can be more > > > > corporate-friendly like other software under Apache License. > > > > > > The Apache license is "friendly" to the patent holder, not so much to > > > the aspiring maker of derivative proprietary software. > > > > I don't think that's a true characterization. There's no meaningful > > reduction in freedoms to make derivative proprietary software in of > > apache 2 vs BSD/MIT like licenses. It gives you additional rights. Are > > you talking about the retaliatory clause? If so, that only cancel the > > patent license, not the entire license. > > There is according to IP attorneys I've spoken to on the matter, and > this is frequently reflected in the open source policies companies > have. For liberal licenses, which are enumerated and do not include > the Apache license, the process is, as a rule, brief and perfunctory. > For all other licenses, the process ranges from cumbersome to not > worth doing. You're talking about usage or contribution rules? I have a *very* hard to belief this for the former. Note how vast amounts of recent widely used open source projects are licensed under apache 2.0. For the latter, yes, it can be a bit more complicated: But usually only in the cases where we *want* contributor's companies to make explicit IP policy decisions anyway. > > > We went with a very liberal license from the outset for what we > > > believed were good reasons, and that's served us well over the > > > decades. If you're proposing a change of this magnitude, it's > > > going to have to be a lot more convincing than, "it would be > > > convenient for my company this year." > > > > It's entirely possible to dual license contributions and everything. > > Why are you making such aggressive statements about a, so far, > > apparently good faith engagement? > > We went out of our way to excise code that the PostgreSQL license > doesn't cover some years back. I think that was done for good reasons, > which obtain to this day. While the introduction of code someone else > ultimately owns may seem harmless or even beneficial today, owners > change, as do their motivations. When we have nothing of this kind in > the project, we expose our future users to none of that risk. I explicitly said *dual license*. And we definitely have code that's not just under the PG license, but compatibly licensed (mostly various BSD licenses). We even have a few pices (just build-time) of solely GPL licensed code (e.g. ax_pthread.m4). Greetings, Andres Freund
On Sat, Jul 07, 2018 at 11:05:48AM -0700, Andres Freund wrote: > On 2018-07-07 19:37:45 +0200, David Fetter wrote: > > On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote: > > > Hi, > > > On 2018-07-07 19:12:58 +0200, David Fetter wrote: > > > > On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote: > > > > > I believe that accepting patented code from companies would be > > > > > practically more useful for PostgreSQL enhancement and growth. > > > > > PostgreSQL is now a mature software, and it can be more > > > > > corporate-friendly like other software under Apache License. > > > > > > > > The Apache license is "friendly" to the patent holder, not so much to > > > > the aspiring maker of derivative proprietary software. > > > > > > I don't think that's a true characterization. There's no meaningful > > > reduction in freedoms to make derivative proprietary software in of > > > apache 2 vs BSD/MIT like licenses. It gives you additional rights. Are > > > you talking about the retaliatory clause? If so, that only cancel the > > > patent license, not the entire license. > > > > There is according to IP attorneys I've spoken to on the matter, and > > this is frequently reflected in the open source policies companies > > have. For liberal licenses, which are enumerated and do not include > > the Apache license, the process is, as a rule, brief and perfunctory. > > For all other licenses, the process ranges from cumbersome to not > > worth doing. > > You're talking about usage or contribution rules? Usage rules, where "usage" is defined here to mean something that might be modified. Sadly, these aren't usually published, so there's not a great way to compare them even if you're an IP attorney so inclined. > > > > We went with a very liberal license from the outset for what > > > > we believed were good reasons, and that's served us well over > > > > the decades. If you're proposing a change of this magnitude, > > > > it's going to have to be a lot more convincing than, "it would > > > > be convenient for my company this year." > > > > > > It's entirely possible to dual license contributions and > > > everything. Why are you making such aggressive statements about > > > a, so far, apparently good faith engagement? > > > > We went out of our way to excise code that the PostgreSQL license > > doesn't cover some years back. I think that was done for good > > reasons, which obtain to this day. While the introduction of code > > someone else ultimately owns may seem harmless or even beneficial > > today, owners change, as do their motivations. When we have > > nothing of this kind in the project, we expose our future users to > > none of that risk. > > I explicitly said *dual license*. And we definitely have code > that's not just under the PG license, but compatibly licensed > (mostly various BSD licenses). We even have a few pices (just > build-time) of solely GPL licensed code (e.g. ax_pthread.m4). In none of these cases is someone going to be able to claim proprietary rights to the derived code. As to "dual license," that's another legal thicket in which we've been wise not to involve ourselves. "Dual licensing" is generally used to assert proprietary rights followed immediately by a demand for payment. This is a thing we don't want to do, and it's not a thing we should be enabling others to do as part of our project. If they wish to do that, they're welcome to do it without our imprimatur. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Hi, On 2018-07-07 20:51:56 +0200, David Fetter wrote: > As to "dual license," that's another legal thicket in which we've been > wise not to involve ourselves. "Dual licensing" is generally used to > assert proprietary rights followed immediately by a demand for > payment. This is a thing we don't want to do, and it's not a thing we > should be enabling others to do as part of our project. If they wish > to do that, they're welcome to do it without our imprimatur. This is pure FUD. Obviously potential results of dual licensing depends on the license chosen. None of what you describe has anything to do with potential pieces of dual PG License / Apache 2.0 licensed code in PG, or anything similar. You could at any time choose to only use / redistribute postgres, including derivatives, under the rights either license permits. I think there's fair arguments to be made that we do not want to go fo for dual licensing with apache 2.0. Biggest among them that the current situation is the established practice. But let's have the arguments be real, not FUD. Andres
On Sat, Jul 07, 2018 at 12:01:10PM -0700, Andres Freund wrote: > Hi, > > On 2018-07-07 20:51:56 +0200, David Fetter wrote: > > As to "dual license," that's another legal thicket in which we've been > > wise not to involve ourselves. "Dual licensing" is generally used to > > assert proprietary rights followed immediately by a demand for > > payment. This is a thing we don't want to do, and it's not a thing we > > should be enabling others to do as part of our project. If they wish > > to do that, they're welcome to do it without our imprimatur. > > This is pure FUD. Obviously potential results of dual licensing depends > on the license chosen. None of what you describe has anything to do with > potential pieces of dual PG License / Apache 2.0 licensed code in PG, or > anything similar. You could at any time choose to only use / > redistribute postgres, including derivatives, under the rights either > license permits. > > I think there's fair arguments to be made that we do not want to go fo > for dual licensing with apache 2.0. Biggest among them that the current > situation is the established practice. But let's have the arguments be > real, not FUD. If they have no plans to exercise any proprietary rights, our usual process where people submit things and agree to have us label them with the PGDG copyright and publish them under TPL would be the simplest way to accomplish it. Any deviation from that process requires an explanation, which has not thus far been proffered. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 2018-Jul-07, David Fetter wrote: > If they have no plans to exercise any proprietary rights, our usual > process where people submit things and agree to have us label them > with the PGDG copyright and publish them under TPL would be the > simplest way to accomplish it. Eh, but if the submitting company has patents, would it not be dishonest to publish as PGDG copyright & license with no attached patent grant? Some other company deriving a proprietary fork from Postgres could later be sued by the submitting company, because there is no legal standing for them to use the patented code. TBH I don't understand how can we dual-license the code in a manner that protects those proprietary forks. Can you (Andres) explain what is the idea? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi, On 2018-07-08 11:46:51 -0400, Alvaro Herrera wrote: > On 2018-Jul-07, David Fetter wrote: > > > If they have no plans to exercise any proprietary rights, our usual > > process where people submit things and agree to have us label them > > with the PGDG copyright and publish them under TPL would be the > > simplest way to accomplish it. > > Eh, but if the submitting company has patents, would it not be dishonest > to publish as PGDG copyright & license with no attached patent grant? > Some other company deriving a proprietary fork from Postgres could later > be sued by the submitting company, because there is no legal standing > for them to use the patented code. Yep. And even if the original submitter has good intent, it's not unlikely for companies to go bancrupt and their assets sold off. > TBH I don't understand how can we dual-license the code in a manner that > protects those proprietary forks. Can you (Andres) explain what is the > idea? https://www.apache.org/licenses/LICENSE-2.0 grants roughly the same rights as our license. But 3) additionally grants a patent license. That license is *not* restricted to the code in unmodified form. By requiring future contributions to be both under the pg license and apache 2, downstream users, including proprietary forks, can safely use code contributed in the future, without risk of patent mines. There are arguments made that TPL (and BSD, MIT etc) already includes an implicit patent grant, but while a longstanding theory, it's to my knowledge not legally been tested. IANAL etc. Greetings, Andres Freund
David, On 07/07/2018 09:52 PM, David Fetter wrote: > Any deviation from that process requires an explanation, which has not > thus far been proffered. Takayuki-san is *offering* a patent grant. That's something the TPL clearly doesn't cover. If they would follow the standard procedure, as you seem to propose, they'd have every right to sue not only users of derivatives, but even Postgres users for violation of their patent. You seem to have experience with different licences and dual licensing. What would you recommend Takayuki-san to do? Kind Regards Markus -- Markus Wanner - http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: davecramer@gmail.com [mailto:davecramer@gmail.com] On Behalf Of > Dave Cramer > Certainly there is history of people using PG code for non-PostgreSQL or > at least commercial derivative work. Greenplum for example. Yes, we would be glad if companies in the PostgreSQL community, including Greenplum, could utilize our patents and prosperwith no charge. We just want to use our (future) patents to make PostgreSQL a more wonderful DBMS, and to protectPostgreSQL against patent lawsuits by companies outside PostgreSQL community. Regards Takayuki Tsunakawa
On 9 July 2018 at 15:51, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
From: davecramer@gmail.com [mailto:davecramer@gmail.com] On Behalf Of
> Dave Cramer
> Certainly there is history of people using PG code for non-PostgreSQL or
> at least commercial derivative work. Greenplum for example.
Yes, we would be glad if companies in the PostgreSQL community, including Greenplum, could utilize our patents and prosper with no charge. We just want to use our (future) patents to make PostgreSQL a more wonderful DBMS, and to protect PostgreSQL against patent lawsuits by companies outside PostgreSQL community.
I can't speak for my employer, but to me it seems like a broad patent grant that follows the code and derivatives would be reasonable.
A grant just for "PostgreSQL", not so much.
I'm not sure how much practical protection/benefit that'd offer unless it came with a retaliation clause, though, and how it'd differ from an unrestricted grant of rights for everyone. I mentioned that earlier. If you can take a few snippets of PostgreSQL code and add them to your product to inherit the patent grant, then in practice the patent grant is universal, not specific to PostgreSQL and derivatives. But if you start requiring "substantial" derivatives, etc, it gets messy and complicated.
I'm not sure how grants with retaliation clauses would be received by others here. I lack the expertise to have much of an opinion myself. Is that what you propose?
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: David Fetter [mailto:david@fetter.org] > We went out of our way to excise code that the PostgreSQL license > doesn't cover some years back. I think that was done for good reasons, > which obtain to this day. While the introduction of code someone else > ultimately owns may seem harmless or even beneficial today, owners > change, as do their motivations. When we have nothing of this kind in > the project, we expose our future users to none of that risk. From: Andres Freund [mailto:andres@anarazel.de] > Yep. And even if the original submitter has good intent, it's not > unlikely for companies to go bancrupt and their assets sold off. Thank you for supporting me, Andres. And please don't mind, David. I don't think you are attacking me. I understand yourconcern and that you are also trying to protect PostgreSQL. On the other hand, I think TPL seems less defensive. I read in some report that Apache License and some other open sourcelicenses were created partly due to lack of patent description in BSD and GPLv2. How can we assure you? How about attaching something like the following to relevant patches or on our web site? [Excerpt from Red Hat Patent Promise] Red Hat intends Our Promise to be irrevocable (except as stated herein), and binding and enforceable against Red Hat andassignees of, or successors to, Red Hat’s patents (and any patents directly or indirectly issuing from Red Hat’s patentapplications). As part of Our Promise, if Red Hat sells, exclusively licenses, or otherwise assigns or transfers patentsor patent applications to a party, we will require the party to agree in writing to be bound to Our Promise for thosepatents and for patents directly or indirectly issuing on those patent applications. We will also require the partyto agree in writing to so bind its own assignees, transferees, and exclusive licensees. > > TBH I don't understand how can we dual-license the code in a manner that > > protects those proprietary forks. Can you (Andres) explain what is the > > idea? > > https://www.apache.org/licenses/LICENSE-2.0 grants roughly the same > rights as our license. But 3) additionally grants a patent license. That > license is *not* restricted to the code in unmodified form. By > requiring future contributions to be both under the pg license and > apache 2, downstream users, including proprietary forks, can safely use > code contributed in the future, without risk of patent mines. > > There are arguments made that TPL (and BSD, MIT etc) already includes an > implicit patent grant, but while a longstanding theory, it's to my > knowledge not legally been tested. When we find a reasonable consensus here, I'd like to have our legal department write a patent grant statement, and thenhave it reviewed in this ML. Is the above statement of Red Hat's enough? Regards Takayuki Tsunakawa
On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote: > From: Craig Ringer [mailto:craig@2ndquadrant.com] > > I'm assuming you don't want to offer a grant that lets anyone use them for > > anything. But if you have a really broad grant to PostgreSQL, all someone > > would have to do to inherit the grant is re-use some part of PostgreSQL. > > Your assumption is right. No scope is the same as no patent; it won't help to defend PostgreSQL community against rivalcompanies/communities of other DBMSs. Or, I think we can set the scope to what OIN states. Fortunately, anyone canjoin OIN free of charge. > > > > I guess there's a middle ground somewhere that protects substantial > > derivatives and extracts but stops you using some Pg code snippets as a > > freebie license. > > Are you assuming that developers want to use PG code snippets for > non-PostgreSQL or even non-DBMS software? I believe that accepting > patented code from companies would be practically more useful for > PostgreSQL enhancement and growth. PostgreSQL is now a mature > software, and it can be more corporate-friendly like other software > under Apache License. Suppose I have my own patches, not yet contributed to PG, and that I'm using them in production. Can I use my patched version of PG with your functionality? Suppose I am developing my own PostgreSQL derivative, with my own secret sauce perhaps, and perhaps I'm using it to build a proprietary cloud DB service. Can I use my patched version of PG with your functionality? I suspect your answer to the latter would be "absolutely not". Maybe the first one would be OK if you can somehow distinguish it from the latter? Anyways, as a user of PG and occasinal hacker of PG, I would have to insist on a ./configure way to exclude all functionality not licensed to me for my use cases, and I would have to insist on all such code being very well segregated (I don't want to look at your code!), and I would insist too on any free configuration being highly tested. If I were a core developer I would have to think long and hard about whether I could meet user requirements and still have your code in-tree, and I'm not sure I could do both of those. Nico --
On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote: > It's entirely possible to dual license contributions and everything. Why > are you making such aggressive statements about a, so far, apparently > good faith engagement? One problem is that many contributors would not want to be tainted by knowledge of the patents in question (since that leads to triple damages). How would you protect contributors and core developers from tainting? One possible answer is that you wouldn't. But that might reduce the size of the community, or lead to a fork. Dual licensing does not get you out of these issues. Nico --
On Mon, Jul 09, 2018 at 08:29:08AM +0000, Tsunakawa, Takayuki wrote: > > There are arguments made that TPL (and BSD, MIT etc) already includes an > > implicit patent grant, but while a longstanding theory, it's to my > > knowledge not legally been tested. > > When we find a reasonable consensus here, I'd like to have our legal > department write a patent grant statement, and then have it reviewed > in this ML. Is the above statement of Red Hat's enough? You're acting as a go-between between your legal department and executive directors on the one hand, and the PG community on the other. That's not going to be an efficient conversation unless your legal department understands open source communities and is willing to tailor their patent grants to suit. Also, these are *business* decisions that should be made by your directors, not by your legal department. So really, this should be a discussion between an authorized director at your company and the community, with all discussions with your legal department being internal to your company. Also, your legal department will almost certainly default to the most restrictive patent grants. That will contribute to making this conversation unproductive. My advice is that you relay all of this to your legal department and your executives, and ask them make the most liberal patent grant possible such that the PG community can live with it. Also, I would advise you that patents can be the kiss of death for software technologies. For example, in the world of cryptography, we always look for patent-free alternatives and build them from scratch if need be, leading to the non-use of patented algorithms/protocols in many cases. Your best bet is to make a grant so liberal that the only remaining business use of your patents is defensive against legal attacks on the holder. (IMO software patent lifetimes should be commensurate with the effort it takes to come up with and develop an idea for the field -- five to eight years max, not seventeen or twenty.) Nico --
On Mon, Jul 09, 2018 at 08:29:08AM +0000, Tsunakawa, Takayuki wrote: > From: David Fetter [mailto:david@fetter.org] > > We went out of our way to excise code that the PostgreSQL license > > doesn't cover some years back. I think that was done for good > > reasons, which obtain to this day. While the introduction of code > > someone else ultimately owns may seem harmless or even beneficial > > today, owners change, as do their motivations. When we have > > nothing of this kind in the project, we expose our future users to > > none of that risk. > > From: Andres Freund [mailto:andres@anarazel.de] > > Yep. And even if the original submitter has good intent, it's not > > unlikely for companies to go bancrupt and their assets sold off. > > Thank you for supporting me, Andres. And please don't mind, David. > I don't think you are attacking me. I understand your concern and > that you are also trying to protect PostgreSQL. Thanks for your understanding. > On the other hand, I think TPL seems less defensive. I read in some > report that Apache License and some other open source licenses were > created partly due to lack of patent description in BSD and GPLv2. > > How can we assure you? How about attaching something like the > following to relevant patches or on our web site? > [Excerpt from Red Hat Patent Promise] > Red Hat intends Our Promise to be irrevocable (except as stated > herein), and binding and enforceable against Red Hat and assignees > of, or successors to, Red Hat’s patents (and any patents directly or > indirectly issuing from Red Hat’s patent applications). As part of > Our Promise, if Red Hat sells, exclusively licenses, or otherwise > assigns or transfers patents or patent applications to a party, we > will require the party to agree in writing to be bound to Our > Promise for those patents and for patents directly or indirectly > issuing on those patent applications. We will also require the party > to agree in writing to so bind its own assignees, transferees, and > exclusive licensees. Unfortunately, this does not mean anything until courts have upheld it. Were Red Hat to be taken over by people who didn't see things this way, it is a long way from clear that such a statement would be upheld in every court, which is what would have to happen. I am not any kind of attorney, but I would not believe anyone who said that they knew for certain how every court on (or off) the planet would ever rule on a clause in a...well, is that a contract? A license? An aspirational goal without legal force? To my knowledge, no court anywhere has had an opportunity to rule on it, so I don't know. Let's imagine that Red Hat gets this written agreement from a third party. Let's further imagine that that third party happens to be (or be swayed by) a "non-participating entity" a.k.a. patent troll, experienced in writing agreements with exploitable loopholes in them. What good is Red Hat's promise then? I really appreciate your forthrightness on this, but I frankly do not understand how you can actually make representations that would stand the test of time. Whatever is in it needs to be true, not just this year, but decades hence under potentially hostile legal actions. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Hi, On 2018-07-09 05:47:56 -0500, Nico Williams wrote: > Suppose I have my own patches, not yet contributed to PG, and that I'm > using them in production. Can I use my patched version of PG with your > functionality? Yes. Given the proposal was to license the potentially encumbered code under apache 2.0, it'd be fine. > Suppose I am developing my own PostgreSQL derivative, with my own secret > sauce perhaps, and perhaps I'm using it to build a proprietary cloud DB > service. Can I use my patched version of PG with your functionality? Dito. You couldn't invent *new* uses of the patent, but contributed versions would be fine. The relevant language is in section 3: "where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted" > Anyways, as a user of PG and occasinal hacker of PG, I would have to > insist on a ./configure way to exclude all functionality not licensed to > me for my use cases, and I would have to insist on all such code being > very well segregated (I don't want to look at your code!), and I would > insist too on any free configuration being highly tested. Given the above, I don't see why that'd be needed. Greetings, Andres Freund
David, On 07/09/2018 02:52 PM, David Fetter wrote: > Unfortunately, this does not mean anything until courts have upheld > it. Were Red Hat to be taken over by people who didn't see things > this way, it is a long way from clear that such a statement would be > upheld in every court, which is what would have to happen. I agree that there certainly exist questionable patent grants. But I'm equally sure there are well intended ones as well. For example, I'd expect patent pools (including the Open Invention Network, cited by the OP) to hire non-IANAL personnel who know Legalese well enough to setup valid contracts (between participating companies). > I am not any kind of attorney, but I would not believe anyone who said > that they knew for certain how every court on (or off) the planet > would ever rule on a clause in a...well, is that a contract? A > license? An aspirational goal without legal force? To my knowledge, no > court anywhere has had an opportunity to rule on it, so I don't know. With all my own dislike of the patent system: I think you're setting the bar unreasonably high. There won't ever exist any such guarantee, even (or especially if) we avoid patent grants. Or do you expect our existing code base to be 100% free of any patent violation? > I really appreciate your forthrightness on this, but I frankly do not > understand how you can actually make representations that would stand > the test of time. In all cases of patent violations by OSS I've heard of, the projects replaced the portions of code that were (suspected to be) in violation of the patent and moved on. Or what precedent do you know of that *didn't* stand the test of time? I certainly like the (future) patent holder coming forth to offer a grant a lot better than the one who doesn't (but still holds the patent). I'm missing the appreciation for that former strategy in this thread and fear we're setting a precedent for the latter one, instead. Kind Regards -- Markus Wanner - http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Nico Williams [mailto:nico@cryptonector.com] > On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote: > > It's entirely possible to dual license contributions and everything. Why > > are you making such aggressive statements about a, so far, apparently > > good faith engagement? > > One problem is that many contributors would not want to be tainted by > knowledge of the patents in question (since that leads to triple > damages). > > How would you protect contributors and core developers from tainting? IIUC, you are concerned about the possibility that PG developers would read the patent document (not the PG source code),and unconsciously use the patented algorithm for other software that's not related to PostgreSQL. That would onlybe helped by not reading the patent document... BTW, are you relieved the current PostgreSQL doesn't contain any patentedcode? As far as I know, PostgreSQL development process doesn't have a step to check patent and copyright infringement. > One possible answer is that you wouldn't. But that might reduce the > size of the community, or lead to a fork. Yes, that's one unfortunate future, which I don't want to happen of course. I believe PostgreSQL should accept patent forfurther evolution, because PostgreSQL is now a popular, influential software that many organizations want to join. Regards Takayuki Tsunakawa
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Markus Wanner [mailto:markus.wanner@2ndquadrant.com] > equally sure there are well intended ones as well. For example, I'd > expect patent pools (including the Open Invention Network, cited by the > OP) to hire non-IANAL personnel who know Legalese well enough to setup > valid contracts (between participating companies). I think I'll consult Open Invention Network on this issue, since I haven't received any reply from SFLC. > I certainly like the (future) patent holder coming forth to offer a > grant a lot better than the one who doesn't (but still holds the > patent). I'm missing the appreciation for that former strategy in this > thread and fear we're setting a precedent for the latter one, instead. Me too. Regards Takayuki Tsunakawa
Hi
--
On Tue, Jul 10, 2018 at 9:29 AM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
From: Markus Wanner [mailto:markus.wanner@2ndquadrant.com]
> equally sure there are well intended ones as well. For example, I'd
> expect patent pools (including the Open Invention Network, cited by the
> OP) to hire non-IANAL personnel who know Legalese well enough to setup
> valid contracts (between participating companies).
I think I'll consult Open Invention Network on this issue, since I haven't received any reply from SFLC.
SFLC have acted as the projects counsel in the past, so I'm not surprised they aren't talking to you; you won't be a known contact to them as a PG contributor, and as a Fujitsu employee there would likely be a conflict of interest for them to talk to you.
> I certainly like the (future) patent holder coming forth to offer a
> grant a lot better than the one who doesn't (but still holds the
> patent). I'm missing the appreciation for that former strategy in this
> thread and fear we're setting a precedent for the latter one, instead.
Me too.
Regards
Takayuki Tsunakawa
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
"Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> writes: > From: Nico Williams [mailto:nico@cryptonector.com] >> ... But that might reduce the >> size of the community, or lead to a fork. > Yes, that's one unfortunate future, which I don't want to happen of > course. I believe PostgreSQL should accept patent for further > evolution, because PostgreSQL is now a popular, influential software > that many organizations want to join. The core team has considered this matter, and has concluded that it's time to establish a firm project policy that we will not accept any code that is known to be patent-encumbered. The long-term legal risks and complications involved in doing that seem insurmountable, given the community's amorphous legal nature and the existing Postgres license wording (neither of which are open for negotiation here). Furthermore, Postgres has always been very friendly to creation of closed-source derivatives, but it's hard to see how inclusion of patented code would not cause serious problems for those. The potential benefits of accepting patented code just don't seem to justify trying to navigate these hazards. regards, tom lane
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Dave Page [mailto:dpage@pgadmin.org] > SFLC have acted as the projects counsel in the past, so I'm not surprised > they aren't talking to you; you won't be a known contact to them as a PG > contributor, and as a Fujitsu employee there would likely be a conflict > of interest for them to talk to you. I see. Then I hope for some reply saying so so that I can give up my hope that I might get a good idea from them... Who is a known contact to SFLC in PostgreSQL community? Can we expect response from SFLC if he/she contacts them? Regards Takayuki Tsunakawa
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > The core team has considered this matter, and has concluded that it's > time to establish a firm project policy that we will not accept any code > that is known to be patent-encumbered. The long-term legal risks and > complications involved in doing that seem insurmountable, given the > community's amorphous legal nature and the existing Postgres license > wording (neither of which are open for negotiation here). Furthermore, > Postgres has always been very friendly to creation of closed-source > derivatives, but it's hard to see how inclusion of patented code would > not cause serious problems for those. The potential benefits of > accepting patented code just don't seem to justify trying to navigate > these hazards. That decision is very unfortunate as a corporate employee on one hand, but the firm cleanness looks a bit bright to me asone developer. As a practical matter, when and where are you planning to post the project policy? How would you check and prevent patentedcode? Regards Takayuki Tsunakawa
On Wed, Jul 11, 2018 at 1:34 AM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
-- From: Dave Page [mailto:dpage@pgadmin.org]
> SFLC have acted as the projects counsel in the past, so I'm not surprised
> they aren't talking to you; you won't be a known contact to them as a PG
> contributor, and as a Fujitsu employee there would likely be a conflict
> of interest for them to talk to you.
I see. Then I hope for some reply saying so so that I can give up my hope that I might get a good idea from them...
Who is a known contact to SFLC in PostgreSQL community? Can we expect response from SFLC if he/she contacts them?
I am - however as you've seen from Tom, the core team has already discussed this and come to the conclusion that the risks and downsides to accepting code under patent far outweighs the benefitsm so I won't be contacting them about this.
We do thank you (and Fujitsu) for your efforts though.
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Jul 10, 2018 at 08:20:53AM +0000, Tsunakawa, Takayuki wrote: > From: Nico Williams [mailto:nico@cryptonector.com] > > On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote: > > > It's entirely possible to dual license contributions and everything. Why > > > are you making such aggressive statements about a, so far, apparently > > > good faith engagement? > > > > One problem is that many contributors would not want to be tainted by > > knowledge of the patents in question (since that leads to triple > > damages). > > > > How would you protect contributors and core developers from tainting? > > IIUC, you are concerned about the possibility that PG developers would > read the patent document (not the PG source code), and unconsciously > use the patented algorithm for other software that's not related to > PostgreSQL. That would only be helped by not reading the patent > document... BTW, are you relieved the current PostgreSQL doesn't > contain any patented code? As far as I know, PostgreSQL development > process doesn't have a step to check patent and copyright > infringement. You're proposing to include code that implements patented ideas with a suitable patent grant. I would be free to not read the patent, but what if the code or documents mention the relevant patented algorithms? If I come across something like this in the PG source code: /* The following is covered by patents US#... and so on */ now what? I could choose not to read it. But what if I have to touch that code in order to implement an unrelated feature due to some required refactoring of internal interfaces used by your code? Now I have to read it, and now I'm tainted, or I must choose to abandon my project. That is a heavy burden on the community. The community may want to extract a suitable patent grant to make that burden lighter. > > One possible answer is that you wouldn't. But that might reduce the > > size of the community, or lead to a fork. > > Yes, that's one unfortunate future, which I don't want to happen of > course. I believe PostgreSQL should accept patent for further > evolution, because PostgreSQL is now a popular, influential software > that many organizations want to join. I don't speak for the PG community, nor the core developers. Speaking for myself only, I hope that you can get, and PG accepts only, the widest possible royalty-free patent grant to the community, allowing others to not be constrained in making derivatives of PG. My advice is to write up a patent grant that allows all to use the relevant patents royalty-free with a no-lawsuit covenant. I.e., make only defensive use of your patents. Nico --
On Tue, Jul 10, 2018 at 09:47:09AM -0400, Tom Lane wrote: > The core team has considered this matter, and has concluded that it's > time to establish a firm project policy that we will not accept any code > that is known to be patent-encumbered. The long-term legal risks and > complications involved in doing that seem insurmountable, given the > community's amorphous legal nature and the existing Postgres license > wording (neither of which are open for negotiation here). Furthermore, > Postgres has always been very friendly to creation of closed-source > derivatives, but it's hard to see how inclusion of patented code would > not cause serious problems for those. The potential benefits of > accepting patented code just don't seem to justify trying to navigate > these hazards. +1. You should probably consider accepting code that involves patents that are in the public domain or expired by the time of release, though even that involves some legal costs you might not want to incur. E.g., what if a US patent is in the public domain but a corresponding EU patent is not? A search could be done, naturally, but professional patent searches are not cheap! Nico --
On Wed, Jul 11, 2018 at 01:03:44AM +0000, Tsunakawa, Takayuki wrote: > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > The core team has considered this matter, and has concluded that it's > > time to establish a firm project policy that we will not accept any code > > that is known to be patent-encumbered. The long-term legal risks and > > complications involved in doing that seem insurmountable, given the > > community's amorphous legal nature and the existing Postgres license > > wording (neither of which are open for negotiation here). Furthermore, > > Postgres has always been very friendly to creation of closed-source > > derivatives, but it's hard to see how inclusion of patented code would > > not cause serious problems for those. The potential benefits of > > accepting patented code just don't seem to justify trying to navigate > > these hazards. > > That decision is very unfortunate as a corporate employee on one hand, > but the firm cleanness looks a bit bright to me as one developer. > > As a practical matter, when and where are you planning to post the > project policy? How would you check and prevent patented code? PG may need a contributor agreement. All I can find on that is: https://www.postgresql.org/message-id/flat/54337476.3040605%402ndquadrant.com#9b1968ddc0fadfe225001adc1a821925 Nico --
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Nico Williams [mailto:nico@cryptonector.com] > On Wed, Jul 11, 2018 at 01:03:44AM +0000, Tsunakawa, Takayuki wrote: > > As a practical matter, when and where are you planning to post the > > project policy? How would you check and prevent patented code? > > PG may need a contributor agreement. All I can find on that is: > > https://www.postgresql.org/message-id/flat/54337476.3040605%402ndquadr > ant.com#9b1968ddc0fadfe225001adc1a821925 Yes, I thought we should probably need a CLA, but I was hesitant to mention it... This is somehow off-topic, but a member in our IP department informed me that TPL only states the disclaimer for the Universityof California, not for PGDG or all copyright holders, which is unlike Apache License. Is this intended? https://www.postgresql.org/about/licence/ -------------------------------------------------- IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIALDAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THEUNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIESOF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS,AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. -------------------------------------------------- Regards Takayuki Tsunakawa
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Nico Williams [mailto:nico@cryptonector.com] > You're proposing to include code that implements patented ideas with a > suitable patent grant. I would be free to not read the patent, but what > if the code or documents mention the relevant patented algorithms? > > If I come across something like this in the PG source code: > > /* The following is covered by patents US#... and so on */ I got it. Your concern makes sense. > My advice is to write up a patent grant that allows all to use the > relevant patents royalty-free with a no-lawsuit covenant. I.e., make > only defensive use of your patents. How can one make defensive use of his patent if he allows everyone to use it royalty-free? Can he use his patent for cross-licensingnegotiation if some commercial database vendor accuses his company that PostgreSQL unintentionally infringesthat vendor's patent? Regards Takayuki Tsunakawa
On Thu, Jul 12, 2018 at 12:29:12AM +0000, Tsunakawa, Takayuki wrote: > From: Nico Williams [mailto:nico@cryptonector.com] > > My advice is to write up a patent grant that allows all to use the > > relevant patents royalty-free with a no-lawsuit covenant. I.e., make > > only defensive use of your patents. > > How can one make defensive use of his patent if he allows everyone to > use it royalty-free? Can he use his patent for cross-licensing > negotiation if some commercial database vendor accuses his company > that PostgreSQL unintentionally infringes that vendor's patent? https://en.wikipedia.org/wiki/Defensive_termination
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Nico Williams [mailto:nico@cryptonector.com] > On Thu, Jul 12, 2018 at 12:29:12AM +0000, Tsunakawa, Takayuki wrote: > > How can one make defensive use of his patent if he allows everyone to > > use it royalty-free? Can he use his patent for cross-licensing > > negotiation if some commercial database vendor accuses his company > > that PostgreSQL unintentionally infringes that vendor's patent? > > https://en.wikipedia.org/wiki/Defensive_termination Thank you, his looks reasonable to give everyone the grant. Then, I wonder if the community can accept patented code ifthe patent holder grants this kind of license. Regards Takayuki Tsunakawa
On 12 July 2018 at 09:10, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
From: Nico Williams [mailto:nico@cryptonector.com]
> On Thu, Jul 12, 2018 at 12:29:12AM +0000, Tsunakawa, Takayuki wrote:
> > How can one make defensive use of his patent if he allows everyone to
> > use it royalty-free? Can he use his patent for cross-licensing
> > negotiation if some commercial database vendor accuses his company
> > that PostgreSQL unintentionally infringes that vendor's patent?
>
> https://en.wikipedia.org/wiki/Defensive_termination
Thank you, his looks reasonable to give everyone the grant. Then, I wonder if the community can accept patented code if the patent holder grants this kind of license.
Personally, I'd be in favour, but the core team has spoken here. I'm not privy to the discussion but the outcome seems firm.
On Thu, Jul 12, 2018 at 01:10:33AM +0000, Tsunakawa, Takayuki wrote: > From: Nico Williams [mailto:nico@cryptonector.com] > > On Thu, Jul 12, 2018 at 12:29:12AM +0000, Tsunakawa, Takayuki wrote: > > > How can one make defensive use of his patent if he allows everyone to > > > use it royalty-free? Can he use his patent for cross-licensing > > > negotiation if some commercial database vendor accuses his company > > > that PostgreSQL unintentionally infringes that vendor's patent? > > > > https://en.wikipedia.org/wiki/Defensive_termination > > Thank you, his looks reasonable to give everyone the grant. Then, I > wonder if the community can accept patented code if the patent holder > grants this kind of license. I'm not a core member, but personally I'd be inclined to accept a royalty-free, non-exclusive, non-expiring, transferrable, ..., grant where the only condition is to not sue the patent holder. I don't object to patents in general, but I think patent lifetimes are way too long for software (because they are not commensurate with the costs of developing software), and I understand that often one must obtain patents for *defensive* purposes because there are sharks out there. So I'm inclined to accept patents with defensive but otherwise very wide grants. Nico --
On Thu, Jul 12, 2018 at 09:33:21AM +0800, Craig Ringer wrote: > On 12 July 2018 at 09:10, Tsunakawa, Takayuki < > tsunakawa.takay@jp.fujitsu.com> wrote: > > From: Nico Williams [mailto:nico@cryptonector.com] > > > On Thu, Jul 12, 2018 at 12:29:12AM +0000, Tsunakawa, Takayuki wrote: > > > > How can one make defensive use of his patent if he allows everyone to > > > > use it royalty-free? Can he use his patent for cross-licensing > > > > negotiation if some commercial database vendor accuses his company > > > > that PostgreSQL unintentionally infringes that vendor's patent? > > > > > > https://en.wikipedia.org/wiki/Defensive_termination > > > > Thank you, his looks reasonable to give everyone the grant. Then, I > > wonder if the community can accept patented code if the patent holder > > grants this kind of license. > > Personally, I'd be in favour, but the core team has spoken here. I'm not > privy to the discussion but the outcome seems firm. Has the issue been considered in enough detail? A thorough treatment of the issue would probably mean that PG should have a contributor agreement, or at the very least the license that PG uses should include generous royalty-free patent grants so as to force contributors to make them. Of course, any time you add contributor agreements you add friction to the contribution process, and at least one-time legal costs for the core. Also, what about patents that are placed in the public domain? Surely code implementing those would not be rejected for involving patents... I'm not sure that the widest grant with no-lawsuit defensive clauses should be accepted, but it's not that far from the public domain case. Even here there's legal costs: at least a one-time cost of hiring an IP lawyer to write up patent grant language that the PG community would insist on. It could be well worth it. Nico --
On Sat, Jul 7, 2018 at 9:01 PM Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2018-07-07 20:51:56 +0200, David Fetter wrote:
> As to "dual license," that's another legal thicket in which we've been
> wise not to involve ourselves. "Dual licensing" is generally used to
> assert proprietary rights followed immediately by a demand for
> payment. This is a thing we don't want to do, and it's not a thing we
> should be enabling others to do as part of our project. If they wish
> to do that, they're welcome to do it without our imprimatur.
This is pure FUD. Obviously potential results of dual licensing depends
on the license chosen. None of what you describe has anything to do with
potential pieces of dual PG License / Apache 2.0 licensed code in PG, or
anything similar. You could at any time choose to only use /
redistribute postgres, including derivatives, under the rights either
license permits.
I think there's fair arguments to be made that we do not want to go fo
for dual licensing with apache 2.0. Biggest among them that the current
situation is the established practice. But let's have the arguments be
real, not FUD.
First, generally, dual licensing is used to assert proprietary rights and that's actually the issue here (the scope of the patent-holder's rights) and the fact that it would change the future code use in some not very nice ways. The major exception I know of is the Perl situation where you have this GPL v2/Artistic License release but I am not entirely sure the historical reasons for this.
The problem here is the scope of a patent right is different here and this would effectively mean the Apache License is the real license of the product.
I assume we agree that the PostgreSQL license plus a patent encumbrance would be the same as the scope of the patent license, not the scope of the copyright license.
Andres
Best Regards,
Chris Travers
Database Administrator
Saarbrücker Straße 37a, 10405 Berlin
On Mon, Jul 9, 2018 at 08:29:08AM +0000, Tsunakawa, Takayuki wrote: > Thank you for supporting me, Andres. And please don't mind, David. I > don't think you are attacking me. I understand your concern and that > you are also trying to protect PostgreSQL. > > On the other hand, I think TPL seems less defensive. I read > in some report that Apache License and some other open source > licenses were created partly due to lack of patent description > in BSD and GPLv2. > > How can we assure you? How about attaching something like the > following to relevant patches or on our web site? > > [Excerpt from Red Hat Patent Promise] Red Hat intends Our Promise to > be irrevocable (except as stated herein), and binding and enforceable > against Red Hat and assignees of, or successors to, Red Hat’s > patents (and any patents directly or indirectly issuing from Red > Hat’s patent applications). As part of Our Promise, if Red Hat > sells, exclusively licenses, or otherwise assigns or transfers > patents or patent applications to a party, we will require the party > to agree in writing to be bound to Our Promise for those patents > and for patents directly or indirectly issuing on those patent > applications. We will also require the party to agree in writing to so > bind its own assignees, transferees, and exclusive licensees. Notice this makes no mention of what happens to the patents if the company goes bankrupt. My guess is that in such a situation the company would have no control over who buys the patents or how they are used. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On July 23, 2018 6:25:42 AM PDT, Bruce Momjian <bruce@momjian.us> wrote: >On Mon, Jul 9, 2018 at 08:29:08AM +0000, Tsunakawa, Takayuki wrote: >> Thank you for supporting me, Andres. And please don't mind, David. >I >> don't think you are attacking me. I understand your concern and that >> you are also trying to protect PostgreSQL. >> >> On the other hand, I think TPL seems less defensive. I read >> in some report that Apache License and some other open source >> licenses were created partly due to lack of patent description >> in BSD and GPLv2. >> >> How can we assure you? How about attaching something like the >> following to relevant patches or on our web site? >> >> [Excerpt from Red Hat Patent Promise] Red Hat intends Our Promise to >> be irrevocable (except as stated herein), and binding and enforceable >> against Red Hat and assignees of, or successors to, Red Hat’s >> patents (and any patents directly or indirectly issuing from Red >> Hat’s patent applications). As part of Our Promise, if Red Hat >> sells, exclusively licenses, or otherwise assigns or transfers >> patents or patent applications to a party, we will require the party >> to agree in writing to be bound to Our Promise for those patents >> and for patents directly or indirectly issuing on those patent >> applications. We will also require the party to agree in writing to >so >> bind its own assignees, transferees, and exclusive licensees. > >Notice this makes no mention of what happens to the patents if the >company goes bankrupt. My guess is that in such a situation the >company >would have no control over who buys the patents or how they are used. It explicitly says irrevocable and successors. Why seems squarely aimed at your concern. Bankruptcy wouldn't just invalidatethat. Similarly icenses like Apache 2 grant a perpetual and irrevocable patent grant for the use in the contribution. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Tue, Jul 10, 2018 at 09:47:09AM -0400, Tom Lane wrote: > "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> writes: > > From: Nico Williams [mailto:nico@cryptonector.com] > >> ... But that might reduce the > >> size of the community, or lead to a fork. > > > Yes, that's one unfortunate future, which I don't want to happen of > > course. I believe PostgreSQL should accept patent for further > > evolution, because PostgreSQL is now a popular, influential software > > that many organizations want to join. > > The core team has considered this matter, and has concluded that it's > time to establish a firm project policy that we will not accept any code > that is known to be patent-encumbered. The long-term legal risks and > complications involved in doing that seem insurmountable, given the > community's amorphous legal nature and the existing Postgres license > wording (neither of which are open for negotiation here). Furthermore, > Postgres has always been very friendly to creation of closed-source > derivatives, but it's hard to see how inclusion of patented code would > not cause serious problems for those. The potential benefits of > accepting patented code just don't seem to justify trying to navigate > these hazards. Just to add a summary to this, any patent assignment to Postgres would have to allow free patent use for all code, under _any_ license. This effectively makes the patent useless, except for defensive use, even for the patent owner. I think everyone here agrees on this. The open question is whether it is useful for the PGDG to accept such patents for defensive use. There are practical problems with this (PGDG is not a legal entity) and operational complexity too. The core team's feeling is that it not worth it, but that discussion can be re-litigated on this email list if desired. The discussion would have to relate to such patents in general, not to the specific Fujitsu proposal. If it was determined that such defensive patents were desired, we can then consider the Fujitsu proposal. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian <bruce@momjian.us> wrote: > >On Mon, Jul 9, 2018 at 08:29:08AM +0000, Tsunakawa, Takayuki wrote: > >> Thank you for supporting me, Andres. And please don't mind, David. > >I > >> don't think you are attacking me. I understand your concern and that > >> you are also trying to protect PostgreSQL. > >> > >> On the other hand, I think TPL seems less defensive. I read > >> in some report that Apache License and some other open source > >> licenses were created partly due to lack of patent description > >> in BSD and GPLv2. > >> > >> How can we assure you? How about attaching something like the > >> following to relevant patches or on our web site? > >> > >> [Excerpt from Red Hat Patent Promise] Red Hat intends Our Promise to > >> be irrevocable (except as stated herein), and binding and enforceable > >> against Red Hat and assignees of, or successors to, Red Hat’s > >> patents (and any patents directly or indirectly issuing from Red > >> Hat’s patent applications). As part of Our Promise, if Red Hat > >> sells, exclusively licenses, or otherwise assigns or transfers > >> patents or patent applications to a party, we will require the party > >> to agree in writing to be bound to Our Promise for those patents > >> and for patents directly or indirectly issuing on those patent > >> applications. We will also require the party to agree in writing to > >so > >> bind its own assignees, transferees, and exclusive licensees. > > > >Notice this makes no mention of what happens to the patents if the > >company goes bankrupt. My guess is that in such a situation the > >company > >would have no control over who buys the patents or how they are used. > > It explicitly says irrevocable and successors. Why seems squarely aimed at your concern. Bankruptcy wouldn't just invalidatethat. They can say whatever they want, but if they are bankrupt, what they say doesn't matter much. My guess is that they would have to give their patents to some legal entity that owns them so it is shielded from bankrupcy. > Similarly icenses like Apache 2 grant a perpetual and irrevocable patent grant for the use in the contribution. As far as I know, this is exactly that case that the company is giving irrevocable patent access to an external entity, but only for Apache-licensed code. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Tue, Jul 10, 2018 at 08:20:53AM +0000, Tsunakawa, Takayuki wrote: > > One possible answer is that you wouldn't. But that might reduce the > > size of the community, or lead to a fork. > > Yes, that's one unfortunate future, which I don't want to happen > of course. I believe PostgreSQL should accept patent for further > evolution, because PostgreSQL is now a popular, influential software > that many organizations want to join. Why did you say this last sentence? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jul 23, 2018 at 09:53:26AM -0400, Bruce Momjian wrote: > On Tue, Jul 10, 2018 at 09:47:09AM -0400, Tom Lane wrote: > > The core team has considered this matter, and has concluded that it's > > time to establish a firm project policy that we will not accept any code > > that is known to be patent-encumbered. The long-term legal risks and > > complications involved in doing that seem insurmountable, given the > > community's amorphous legal nature and the existing Postgres license > > wording (neither of which are open for negotiation here). Furthermore, > > Postgres has always been very friendly to creation of closed-source > > derivatives, but it's hard to see how inclusion of patented code would > > not cause serious problems for those. The potential benefits of > > accepting patented code just don't seem to justify trying to navigate > > these hazards. > > Just to add a summary to this, any patent assignment to Postgres would > have to allow free patent use for all code, under _any_ license. This > effectively makes the patent useless, except for defensive use, even for > the patent owner. I think everyone here agrees on this. > > The open question is whether it is useful for the PGDG to accept such > patents for defensive use. There are practical problems with this (PGDG > is not a legal entity) and operational complexity too. The core team's > feeling is that it not worth it, but that discussion can be re-litigated > on this email list if desired. The discussion would have to relate to > such patents in general, not to the specific Fujitsu proposal. If it > was determined that such defensive patents were desired, we can then > consider the Fujitsu proposal. And the larger question is whether a patent free for use by software under any license can be used in a defensive way. If not, it means we have no way forward here. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 2018-07-23 09:56:47 -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian <bruce@momjian.us> wrote: > > >On Mon, Jul 9, 2018 at 08:29:08AM +0000, Tsunakawa, Takayuki wrote: > > >> Thank you for supporting me, Andres. And please don't mind, David. > > >I > > >> don't think you are attacking me. I understand your concern and that > > >> you are also trying to protect PostgreSQL. > > >> > > >> On the other hand, I think TPL seems less defensive. I read > > >> in some report that Apache License and some other open source > > >> licenses were created partly due to lack of patent description > > >> in BSD and GPLv2. > > >> > > >> How can we assure you? How about attaching something like the > > >> following to relevant patches or on our web site? > > >> > > >> [Excerpt from Red Hat Patent Promise] Red Hat intends Our Promise to > > >> be irrevocable (except as stated herein), and binding and enforceable > > >> against Red Hat and assignees of, or successors to, Red Hat’s > > >> patents (and any patents directly or indirectly issuing from Red > > >> Hat’s patent applications). As part of Our Promise, if Red Hat > > >> sells, exclusively licenses, or otherwise assigns or transfers > > >> patents or patent applications to a party, we will require the party > > >> to agree in writing to be bound to Our Promise for those patents > > >> and for patents directly or indirectly issuing on those patent > > >> applications. We will also require the party to agree in writing to > > >so > > >> bind its own assignees, transferees, and exclusive licensees. > > > > > >Notice this makes no mention of what happens to the patents if the > > >company goes bankrupt. My guess is that in such a situation the > > >company > > >would have no control over who buys the patents or how they are used. > > > > It explicitly says irrevocable and successors. Why seems squarely aimed at your concern. Bankruptcy wouldn't just invalidatethat. > > They can say whatever they want, but if they are bankrupt, what they say > doesn't matter much. My guess is that they would have to give their > patents to some legal entity that owns them so it is shielded from > bankrupcy. Huh? Bancruptcy doesn't simply invalidate licenses which successors then can ignore. By that logic a license to use the code, like the PG license, would be just as ineffectual Greetings, Andres Freund
On 07/23/2018 10:01 AM, Bruce Momjian wrote: > And the larger question is whether a patent free for use by software > under any license can be used in a defensive way. If not, it means we > have no way forward here. Isn't 'defensive', in patent-speak, used to mean 'establishing prior art usable to challenge future patent claims by others on the same technique'? Is there any way that conditions of use, or lack of them, on an existing patent, would make it unusable in that context? -Chap
On Mon, Jul 23, 2018 at 10:13:48AM -0400, Chapman Flack wrote: > On 07/23/2018 10:01 AM, Bruce Momjian wrote: > > > And the larger question is whether a patent free for use by software > > under any license can be used in a defensive way. If not, it means we > > have no way forward here. > > Isn't 'defensive', in patent-speak, used to mean 'establishing prior > art usable to challenge future patent claims by others on the same > technique'? > > Is there any way that conditions of use, or lack of them, on an > existing patent, would make it unusable in that context? It doesn't have to be a patent on the same technique; this URL was referenced in the thread: https://en.wikipedia.org/wiki/Defensive_termination -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jul 23, 2018 at 07:08:32AM -0700, Andres Freund wrote: > On 2018-07-23 09:56:47 -0400, Bruce Momjian wrote: > > They can say whatever they want, but if they are bankrupt, what they say > > doesn't matter much. My guess is that they would have to give their > > patents to some legal entity that owns them so it is shielded from > > bankrupcy. > > Huh? Bancruptcy doesn't simply invalidate licenses which successors then > can ignore. By that logic a license to use the code, like the PG > license, would be just as ineffectual You are not thinking this through. It depends if the patent owner retains some un-released/un-shared rights to the patent, e.g. patent can only be used by others in GPL-licensed code. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 2018-07-23 10:27:10 -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 07:08:32AM -0700, Andres Freund wrote: > > On 2018-07-23 09:56:47 -0400, Bruce Momjian wrote: > > > They can say whatever they want, but if they are bankrupt, what they say > > > doesn't matter much. My guess is that they would have to give their > > > patents to some legal entity that owns them so it is shielded from > > > bankrupcy. > > > > Huh? Bancruptcy doesn't simply invalidate licenses which successors then > > can ignore. By that logic a license to use the code, like the PG > > license, would be just as ineffectual > > You are not thinking this through. Err. > It depends if the patent owner retains some un-released/un-shared > rights to the patent, e.g. patent can only be used by others in > GPL-licensed code. Please point me to any sort of reference that bancruptcy simply terminates perpetual irrevocable license agreements; that's simply not the case afaik. Even if the patent rights are liquidated, the new owner would be bound by the terms. Also, as I pointed out above, how would the same not be applicable to the code itself? Greetings, Andres Freund
On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian <bruce@momjian.us> wrote: > >Notice this makes no mention of what happens to the patents if the > >company goes bankrupt. My guess is that in such a situation the > >company > >would have no control over who buys the patents or how they are used. > > It explicitly says irrevocable and successors. Why seems squarely > aimed at your concern. Bankruptcy wouldn't just invalidate that. Until this has been upheld in court, it's just a vague idea. > Similarly icenses like Apache 2 grant a perpetual and irrevocable > patent grant for the use in the contribution. The "upheld in court" business applies here, too. I know it's tempting to look at formal-looking texts and infer that they operate something vaguely like computer code, but that is manifestly not the case. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Mon, Jul 23, 2018 at 07:32:34AM -0700, Andres Freund wrote: > On 2018-07-23 10:27:10 -0400, Bruce Momjian wrote: > > On Mon, Jul 23, 2018 at 07:08:32AM -0700, Andres Freund wrote: > > > On 2018-07-23 09:56:47 -0400, Bruce Momjian wrote: > > > > They can say whatever they want, but if they are bankrupt, what they say > > > > doesn't matter much. My guess is that they would have to give their > > > > patents to some legal entity that owns them so it is shielded from > > > > bankrupcy. > > > > > > Huh? Bancruptcy doesn't simply invalidate licenses which successors then > > > can ignore. By that logic a license to use the code, like the PG > > > license, would be just as ineffectual > > > > You are not thinking this through. > > Err. > > > > It depends if the patent owner retains some un-released/un-shared > > rights to the patent, e.g. patent can only be used by others in > > GPL-licensed code. > > Please point me to any sort of reference that bancruptcy simply > terminates perpetual irrevocable license agreements; that's simply not > the case afaik. Even if the patent rights are liquidated, the new owner > would be bound by the terms. > Also, as I pointed out above, how would the same not be applicable to > the code itself? I am explaining a case where some of the patent rights are given to a group, but some rights are retained by the company. They cannot change the rights given, but can change how the company-controlled rights are used. I am just guessing since I have not heard of any such cases, but I know that companies have limited rights now their assets are sold. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 07/23/2018 10:25 AM, Bruce Momjian wrote: >> Isn't 'defensive', in patent-speak, used to mean 'establishing prior >> art usable to challenge future patent claims by others on the same >> technique'? >> >> Is there any way that conditions of use, or lack of them, on an >> existing patent, would make it unusable in that context? > > It doesn't have to be a patent on the same technique; this URL was > referenced in the thread: > > https://en.wikipedia.org/wiki/Defensive_termination Ah, a very different understanding of defensive use of a patent, and one that I can see would lose force if there could be no conditions on its use. I was thinking more of the use of a filing to establish prior art so somebody else later can't obtain and enforce a patent on the technique that you're already using. Something along the lines of a statutory invention registration[1], which used to be a thing in the US, but now apparently is not, though any filed, published application, granted or abandoned, can serve the same purpose. That, I think, would still work. -Chap [1] https://en.wikipedia.org/wiki/United_States_Statutory_Invention_Registration
On Mon, Jul 23, 2018 at 10:42:11AM -0400, Chapman Flack wrote: > On 07/23/2018 10:25 AM, Bruce Momjian wrote: > > >> Isn't 'defensive', in patent-speak, used to mean 'establishing prior > >> art usable to challenge future patent claims by others on the same > >> technique'? > >> > >> Is there any way that conditions of use, or lack of them, on an > >> existing patent, would make it unusable in that context? > > > > It doesn't have to be a patent on the same technique; this URL was > > referenced in the thread: > > > > https://en.wikipedia.org/wiki/Defensive_termination > > Ah, a very different understanding of defensive use of a patent, > and one that I can see would lose force if there could be no > conditions on its use. > > I was thinking more of the use of a filing to establish prior art > so somebody else later can't obtain and enforce a patent on > the technique that you're already using. Something along the lines > of a statutory invention registration[1], which used to be a thing > in the US, but now apparently is not, though any filed, published > application, granted or abandoned, can serve the same purpose. > > That, I think, would still work. Yes, those preemptive patent approaches work too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Hi, On 2018-07-23 16:32:55 +0200, David Fetter wrote: > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian <bruce@momjian.us> wrote: > > >Notice this makes no mention of what happens to the patents if the > > >company goes bankrupt. My guess is that in such a situation the > > >company > > >would have no control over who buys the patents or how they are used. > > > > It explicitly says irrevocable and successors. Why seems squarely > > aimed at your concern. Bankruptcy wouldn't just invalidate that. > > Until this has been upheld in court, it's just a vague idea. To my knowledge this has long been settled. Which makes a lot of sense, because this is relevant *far* beyond just open source. FWIW, in the US it's explicit law, see https://www.law.cornell.edu/uscode/text/11/365 subclause (n). Anyway, should we decide that this would be a good idea as a policy matter, we'd *OBVIOUSLY* have to check in with lawyers to see whether our understanding is correct. But that doesn't mean we should just assume it's impossible without any sort of actual understanding. You're just muddying the waters. Greetings, Andres Freund
On Mon, Jul 23, 2018 at 07:59:20AM -0700, Andres Freund wrote: > Hi, > > On 2018-07-23 16:32:55 +0200, David Fetter wrote: > > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > > > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian <bruce@momjian.us> wrote: > > > >Notice this makes no mention of what happens to the patents if the > > > >company goes bankrupt. My guess is that in such a situation the > > > >company > > > >would have no control over who buys the patents or how they are used. > > > > > > It explicitly says irrevocable and successors. Why seems squarely > > > aimed at your concern. Bankruptcy wouldn't just invalidate that. > > > > Until this has been upheld in court, it's just a vague idea. > > To my knowledge this has long been settled. Which makes a lot of sense, > because this is relevant *far* beyond just open source. FWIW, in the US > it's explicit law, see https://www.law.cornell.edu/uscode/text/11/365 > subclause (n). Anyway, should we decide that this would be a good idea > as a policy matter, we'd *OBVIOUSLY* have to check in with lawyers to > see whether our understanding is correct. But that doesn't mean we > should just assume it's impossible without any sort of actual > understanding. You are saying that Red Hat's promise is part of the contract when they contributed that code --- I guess that interpretation is possible, but again, I am not sure. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jul 23, 2018 at 07:59:20AM -0700, Andres Freund wrote: > Hi, > > On 2018-07-23 16:32:55 +0200, David Fetter wrote: > > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > > > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian <bruce@momjian.us> wrote: > > > >Notice this makes no mention of what happens to the patents if the > > > >company goes bankrupt. My guess is that in such a situation the > > > >company > > > >would have no control over who buys the patents or how they are used. > > > > > > It explicitly says irrevocable and successors. Why seems squarely > > > aimed at your concern. Bankruptcy wouldn't just invalidate that. > > > > Until this has been upheld in court, it's just a vague idea. > > To my knowledge this has long been settled. Which makes a lot of sense, > because this is relevant *far* beyond just open source. FWIW, in the US > it's explicit law, see https://www.law.cornell.edu/uscode/text/11/365 > subclause (n). Anyway, should we decide that this would be a good idea > as a policy matter, we'd *OBVIOUSLY* have to check in with lawyers to > see whether our understanding is correct. But that doesn't mean we > should just assume it's impossible without any sort of actual > understanding. Yet again, you are assuming contrary to reality that you can simply read and understand how legal code will operate without court cases to back it. In the particular instance you're citing, that's what happens *after* the contract is upheld as legal, which it could well not be. There are lots of ways it might not be, even if you don't count bad will and venue shopping, tactics known to be used ubiquitously by NPEs. We know things about the GPL because courts have upheld provisions in it, not because somebody's idea of the "obvious meaning" of that document held sway. > You're just muddying the waters. Nope. I'm just making sure we understand that when it comes to patent thickets, it's a LOT easier to get in than out. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 2018-07-23 11:06:25 -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 07:59:20AM -0700, Andres Freund wrote: > > Hi, > > > > On 2018-07-23 16:32:55 +0200, David Fetter wrote: > > > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > > > > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian <bruce@momjian.us> wrote: > > > > >Notice this makes no mention of what happens to the patents if the > > > > >company goes bankrupt. My guess is that in such a situation the > > > > >company > > > > >would have no control over who buys the patents or how they are used. > > > > > > > > It explicitly says irrevocable and successors. Why seems squarely > > > > aimed at your concern. Bankruptcy wouldn't just invalidate that. > > > > > > Until this has been upheld in court, it's just a vague idea. > > > > To my knowledge this has long been settled. Which makes a lot of sense, > > because this is relevant *far* beyond just open source. FWIW, in the US > > it's explicit law, see https://www.law.cornell.edu/uscode/text/11/365 > > subclause (n). Anyway, should we decide that this would be a good idea > > as a policy matter, we'd *OBVIOUSLY* have to check in with lawyers to > > see whether our understanding is correct. But that doesn't mean we > > should just assume it's impossible without any sort of actual > > understanding. > > You are saying that Red Hat's promise is part of the contract when they > contributed that code --- I guess that interpretation is possible, but > again, I am not sure. I'm fairly sure that I'm right. But my point isn't that we should "trust Andres implicitly ™" (although that's obviously not a bad starting point ;)). But rather, given that that is a reasonable assumption that such agreements are legally possible, we can decide whether we want to take advantage of such terms *assuming they are legally sound*. Then, if, and only if, we decide that that's interesting from a policy POV, we can verify those assumptions with lawyers. Given we're far from the first project dealing with this, and that companies that have shown themselves to be reasonably trustworthy around open source, like Red Hat, assuming that such agreements are sound seems quite reasonable. I find it fairly hubristic to just assume bad faith, or lack of skill, on part of the drafters of Apache2, GLPv3, RH patent promise, ... that they either didn't think about bancruptcy or didn't care about it. They're certainly better lawyers than any of us here. Greetings, Andres Freund
Hi, On 2018-07-23 17:11:30 +0200, David Fetter wrote: > Yet again, you are assuming contrary to reality that you can simply > read and understand how legal code will operate without court cases to > back it. Oh, FFS. You're implying serious bad faith here (and not just on my part, but also on the drafters of apache2, gplv3 etc). I *explicitly* said that we should check in with lawyers if we decided we want to go forward. You're arguing that we shouldn't even consider anything around patent grants because YOU don't know of caselaw supporting what's proposed. You're very clearly not a lawyer. You're doing precisely what you warn about. > In the particular instance you're citing, that's what happens > *after* the contract is upheld as legal, which it could well not be. In which case we'd likely be screwed anyway, because the right to the code would quite likely not be effective anymore either. A lot of the relevant law treats copyright and patents similarly. Greetings, Andres Freund
On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote: > I'm fairly sure that I'm right. But my point isn't that we should "trust > Andres implicitly ™" (although that's obviously not a bad starting point > ;)). But rather, given that that is a reasonable assumption that such > agreements are legally possible, we can decide whether we want to take > advantage of such terms *assuming they are legally sound*. Then, if, and > only if, we decide that that's interesting from a policy POV, we can > verify those assumptions with lawyers. > > Given we're far from the first project dealing with this, and that > companies that have shown themselves to be reasonably trustworthy around > open source, like Red Hat, assuming that such agreements are sound seems > quite reasonable. Sun Microsystems seemed reasonably trustworthy too. > I find it fairly hubristic to just assume bad faith, or lack of skill, > on part of the drafters of Apache2, GLPv3, RH patent promise, ... that > they either didn't think about bankruptcy or didn't care about > it. They're certainly better lawyers than any of us here. True. It would be nice if we could get an answer about bankruptcy from Red Hat. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote: > > I'm fairly sure that I'm right. But my point isn't that we should "trust > > Andres implicitly ™" (although that's obviously not a bad starting point > > ;)). But rather, given that that is a reasonable assumption that such > > agreements are legally possible, we can decide whether we want to take > > advantage of such terms *assuming they are legally sound*. Then, if, and > > only if, we decide that that's interesting from a policy POV, we can > > verify those assumptions with lawyers. > > > > > Given we're far from the first project dealing with this, and that > > companies that have shown themselves to be reasonably trustworthy around > > open source, like Red Hat, assuming that such agreements are sound seems > > quite reasonable. > > Sun Microsystems seemed reasonably trustworthy too. I realize what you are saying is that at the time Red Hat wrote that, they had good intentions, but they might not be able to control its behavior in a bankruptcy, so didn't mention it. Also, Oracle is suing Google over the Java API: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. which I can't imagine Sun doing, but legally Oracle can now that they own Java via Sun. Of course, Sun might not have realized the problem, and Red Hat might have, but that's also assuming that there aren't other problems that Red Hat doesn't know about. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Hi, On 2018-07-23 11:40:41 -0400, Bruce Momjian wrote: > Sun Microsystems seemed reasonably trustworthy too. I don't really agree with that characterization (they've a long history of weird behaviour around open source, LONG before the Oracle acquisition). But it doesn't really matter, as they've not breached any of their hard obligations, have they? Greetings, Andres Freund
On Mon, Jul 23, 2018 at 09:56:47AM -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > > It explicitly says irrevocable and successors. Why seems squarely > > aimed at your concern. Bankruptcy wouldn't just invalidate that. > > They can say whatever they want, but if they are bankrupt, what they say > doesn't matter much. My guess is that they would have to give their > patents to some legal entity that owns them so it is shielded from > bankrupcy. Can you explain how a new owner could invalidate/revoke previous irrevocable grants? That's not rhetorical. I want to know if that's possible. Perhaps patent law [in some countries] requires contracts as opposed to licenses? Nico --
On Mon, Jul 23, 2018 at 10:13:48AM -0400, Chapman Flack wrote: > On 07/23/2018 10:01 AM, Bruce Momjian wrote: > > > And the larger question is whether a patent free for use by software > > under any license can be used in a defensive way. If not, it means we > > have no way forward here. > > Isn't 'defensive', in patent-speak, used to mean 'establishing prior > art usable to challenge future patent claims by others on the same > technique'? Not prior art. You don't need patents to establish prior art. Just publish your idea and you're done. (The problem with just publishing an idea is that someone might have a patent application regarding a similar idea and might modify their application to cover yours once they see it. Later, when you go claim that you have prior art, there will be a heavy burden of presumption on you. This, of course, encourages you to apply for a patent...) Patents let you have counter-suit options should you get sued for patent infringement -- that's the "defensive" in defensive patents. You need a large portfolio of patents, and this doesn't work against patent trolls. There's also no-lawsuit covenants in grants. You get to use my patent if you don't sue me for using yours, and if you sue me then my grants to you are revoked. Nico --
On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote: > > I'm fairly sure that I'm right. But my point isn't that we should "trust > > Andres implicitly ™" (although that's obviously not a bad starting point > > ;)). But rather, given that that is a reasonable assumption that such > > agreements are legally possible, we can decide whether we want to take > > advantage of such terms *assuming they are legally sound*. Then, if, and > > only if, we decide that that's interesting from a policy POV, we can > > verify those assumptions with lawyers. > > > > > Given we're far from the first project dealing with this, and that > > companies that have shown themselves to be reasonably trustworthy around > > open source, like Red Hat, assuming that such agreements are sound seems > > quite reasonable. > > Sun Microsystems seemed reasonably trustworthy too. Are there patent grants from Sun that Oracle has attempted to renege on? Are there court cases about that? Links? Nico --
On Mon, Jul 23, 2018 at 11:55:01AM -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote: > > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote: > > > I'm fairly sure that I'm right. But my point isn't that we should "trust > > > Andres implicitly ™" (although that's obviously not a bad starting point > > > ;)). But rather, given that that is a reasonable assumption that such > > > agreements are legally possible, we can decide whether we want to take > > > advantage of such terms *assuming they are legally sound*. Then, if, and > > > only if, we decide that that's interesting from a policy POV, we can > > > verify those assumptions with lawyers. > > > > > > > > Given we're far from the first project dealing with this, and that > > > companies that have shown themselves to be reasonably trustworthy around > > > open source, like Red Hat, assuming that such agreements are sound seems > > > quite reasonable. > > > > Sun Microsystems seemed reasonably trustworthy too. > > I realize what you are saying is that at the time Red Hat wrote that, > they had good intentions, but they might not be able to control its > behavior in a bankruptcy, so didn't mention it. Also, Oracle is suing > Google over the Java API: > > https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. > > which I can't imagine Sun doing, but legally Oracle can now that they > own Java via Sun. Of course, Sun might not have realized the problem, > and Red Hat might have, but that's also assuming that there aren't other > problems that Red Hat doesn't know about. That's not about patents though, is it. (I do believe that case is highly contrived. Sun put Java under the GPL, so presumably Google can fork it under those terms. I've not followed that case, so I don't really know what's up with it or why it wasn't just dismissed with prejudice.) Nico --
On Mon, Jul 23, 2018 at 11:27:49AM -0500, Nico Williams wrote: > On Mon, Jul 23, 2018 at 09:56:47AM -0400, Bruce Momjian wrote: > > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote: > > > It explicitly says irrevocable and successors. Why seems squarely > > > aimed at your concern. Bankruptcy wouldn't just invalidate that. > > > > They can say whatever they want, but if they are bankrupt, what they say > > doesn't matter much. My guess is that they would have to give their > > patents to some legal entity that owns them so it is shielded from > > bankruptcy. > > Can you explain how a new owner could invalidate/revoke previous > irrevocable grants? The question is whether the promises Red Hat makes are part of the license for free use of their patents or something they fully control and just promise to do, i.e. is this a promise from the company or embedded in the patent grant. I don't know. But it is a larger question of how such a promise is embedded in the patent grant and _cannot_ be revoked, even if someone else buys the patent in a bankruptcy case and does control that promise. > That's not rhetorical. I want to know if that's possible. > > Perhaps patent law [in some countries] requires contracts as opposed to > licenses? Yes, I really don't know. I have just seen enough "oh, we didn't think of that" to be cautious. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jul 23, 2018 at 11:37:05AM -0500, Nico Williams wrote: > On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote: > > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote: > > > I'm fairly sure that I'm right. But my point isn't that we should "trust > > > Andres implicitly ™" (although that's obviously not a bad starting point > > > ;)). But rather, given that that is a reasonable assumption that such > > > agreements are legally possible, we can decide whether we want to take > > > advantage of such terms *assuming they are legally sound*. Then, if, and > > > only if, we decide that that's interesting from a policy POV, we can > > > verify those assumptions with lawyers. > > > > > > > > Given we're far from the first project dealing with this, and that > > > companies that have shown themselves to be reasonably trustworthy around > > > open source, like Red Hat, assuming that such agreements are sound seems > > > quite reasonable. > > > > Sun Microsystems seemed reasonably trustworthy too. > > Are there patent grants from Sun that Oracle has attempted to renege on? > Are there court cases about that? Links? No, but I bet there are things Oracle is doing that no one at Sun expected to be done, and users who relied on Sun didn't expect to be done. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jul 23, 2018 at 11:38:47AM -0500, Nico Williams wrote: > On Mon, Jul 23, 2018 at 11:55:01AM -0400, Bruce Momjian wrote: > > On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote: > > > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote: > > > > I'm fairly sure that I'm right. But my point isn't that we should "trust > > > > Andres implicitly ™" (although that's obviously not a bad starting point > > > > ;)). But rather, given that that is a reasonable assumption that such > > > > agreements are legally possible, we can decide whether we want to take > > > > advantage of such terms *assuming they are legally sound*. Then, if, and > > > > only if, we decide that that's interesting from a policy POV, we can > > > > verify those assumptions with lawyers. > > > > > > > > > > > Given we're far from the first project dealing with this, and that > > > > companies that have shown themselves to be reasonably trustworthy around > > > > open source, like Red Hat, assuming that such agreements are sound seems > > > > quite reasonable. > > > > > > Sun Microsystems seemed reasonably trustworthy too. > > > > I realize what you are saying is that at the time Red Hat wrote that, > > they had good intentions, but they might not be able to control its > > behavior in a bankruptcy, so didn't mention it. Also, Oracle is suing > > Google over the Java API: > > > > https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. > > > > which I can't imagine Sun doing, but legally Oracle can now that they > > own Java via Sun. Of course, Sun might not have realized the problem, > > and Red Hat might have, but that's also assuming that there aren't other > > problems that Red Hat doesn't know about. > > That's not about patents though, is it. No, it is not. It is just a case of not being able to trust any company's "good will". You only get what the contract says. > (I do believe that case is highly contrived. Sun put Java under the > GPL, so presumably Google can fork it under those terms. I've not > followed that case, so I don't really know what's up with it or why it > wasn't just dismissed with prejudice.) Yes, it is a big case with big ramifications if upheld. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 2018-07-23 13:14:04 -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 11:38:47AM -0500, Nico Williams wrote: > > On Mon, Jul 23, 2018 at 11:55:01AM -0400, Bruce Momjian wrote: > > > On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote: > > > > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote: > > > > > I'm fairly sure that I'm right. But my point isn't that we should "trust > > > > > Andres implicitly ™" (although that's obviously not a bad starting point > > > > > ;)). But rather, given that that is a reasonable assumption that such > > > > > agreements are legally possible, we can decide whether we want to take > > > > > advantage of such terms *assuming they are legally sound*. Then, if, and > > > > > only if, we decide that that's interesting from a policy POV, we can > > > > > verify those assumptions with lawyers. > > > > > > > > > > > > > > Given we're far from the first project dealing with this, and that > > > > > companies that have shown themselves to be reasonably trustworthy around > > > > > open source, like Red Hat, assuming that such agreements are sound seems > > > > > quite reasonable. > > > > > > > > Sun Microsystems seemed reasonably trustworthy too. > > > > > > I realize what you are saying is that at the time Red Hat wrote that, > > > they had good intentions, but they might not be able to control its > > > behavior in a bankruptcy, so didn't mention it. Also, Oracle is suing > > > Google over the Java API: > > > > > > https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. > > > > > > which I can't imagine Sun doing, but legally Oracle can now that they > > > own Java via Sun. Of course, Sun might not have realized the problem, > > > and Red Hat might have, but that's also assuming that there aren't other > > > problems that Red Hat doesn't know about. > > > > That's not about patents though, is it. > > No, it is not. It is just a case of not being able to trust any > company's "good will". You only get what the contract says. > > (I do believe that case is highly contrived. Sun put Java under the > > GPL, so presumably Google can fork it under those terms. I've not > > followed that case, so I don't really know what's up with it or why it > > wasn't just dismissed with prejudice.) > > Yes, it is a big case with big ramifications if upheld. Google didn't originally fork Dalvik from OpenJDK under the GPL though, they re-implemented under a *more* permissive license (and reused Apache Harmony bits). The "fix" google pursued is *precisely* to instead go for an OpenJDK fork, to benefit from GPL protections. But that doesn't help them with retroactive claims about the time when that wasn't true. There was no contract granting patent rights in the relevant case. So I fail to see what this has to do with the topic at hand. Greetings, Andres Freund
On Mon, Jul 23, 2018 at 01:12:19PM -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 11:27:49AM -0500, Nico Williams wrote: > > Perhaps patent law [in some countries] requires contracts as opposed to > > licenses? > > Yes, I really don't know. I have just seen enough "oh, we didn't think > of that" to be cautious. So, is it FUD? The core needs paid-for legal advice, not speculation. I'm quite certain that a software license can make a patent grant to the satisfaction of many open source communities, and almost certainly to the satisfaction of the PG community. But it will take an IP lawyer to review or write such a license. Nico --
On Mon, Jul 23, 2018 at 02:02:40PM -0500, Nico Williams wrote: > On Mon, Jul 23, 2018 at 01:12:19PM -0400, Bruce Momjian wrote: > > On Mon, Jul 23, 2018 at 11:27:49AM -0500, Nico Williams wrote: > > > Perhaps patent law [in some countries] requires contracts as opposed to > > > licenses? > > > > Yes, I really don't know. I have just seen enough "oh, we didn't think > > of that" to be cautious. > > So, is it FUD? The core needs paid-for legal advice, not speculation. > > I'm quite certain that a software license can make a patent grant to the > satisfaction of many open source communities, and almost certainly to > the satisfaction of the PG community. But it will take an IP lawyer to > review or write such a license. And is the payback worth it? Many don't think so. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Mon, Jul 23, 2018 at 01:12:49PM -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 11:37:05AM -0500, Nico Williams wrote: > > On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote: > > > Sun Microsystems seemed reasonably trustworthy too. > > > > Are there patent grants from Sun that Oracle has attempted to renege on? > > Are there court cases about that? Links? > > No, but I bet there are things Oracle is doing that no one at Sun > expected to be done, and users who relied on Sun didn't expect to be > done. There are questions that the PG core needs help with and which IP lawyers are needed to answer. There are also business questions, because sure, even if a patent owner makes an acceptable grant, how fast and cheaply you could get a lawsuit by them dismissed on the basis of that grant is a business consideration. We, the non-lawyer PG community, can give input such as that which I've contributed: - I won't read/modify source code involving patents whose grants are not as wide as X - the PG core needs advice from IP lawyers - patents placed in the public domain surely are safe for PG - there must be patent grant language acceptable to PG Just merely "but they could do something bad!" from us non-lawyers is not very good advice. Already PG incurs the risk that its contributors could act in bad faith. For example, a contributor's employer might sue PG under copyright and/or trade secrecy law claiming the contribution was not authorized (this is why some open source projects require contributor agreements). Nico --
Re: How can we submit code patches that implement our (pending)patents?
From
"Joshua D. Drake"
Date:
On 07/23/2018 12:06 PM, Bruce Momjian wrote: >> So, is it FUD? The core needs paid-for legal advice, not speculation. >> >> I'm quite certain that a software license can make a patent grant to the >> satisfaction of many open source communities, and almost certainly to >> the satisfaction of the PG community. But it will take an IP lawyer to >> review or write such a license. > And is the payback worth it? Many don't think so. Although Nico is correct, I also think we need to consider what the community wants here. Historically, we have always explicitly avoided anything to do with patents to the point where some hackers won't even read white papers on patented methods. I do think there is a definite technological advantage for PostgreSQL if there was a license that core could accept that was patent friendly but frankly, I don't think that core or the community has the desire to work through the cost of doing so. JD -- Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc *** A fault and talent of mine is to tell it exactly how it is. *** PostgreSQL centered full stack support, consulting and development. Advocate: @amplifypostgres || Learn: https://postgresconf.org ***** Unless otherwise stated, opinions are my own. *****
On Mon, Jul 23, 2018 at 03:06:13PM -0400, Bruce Momjian wrote: > On Mon, Jul 23, 2018 at 02:02:40PM -0500, Nico Williams wrote: > > On Mon, Jul 23, 2018 at 01:12:19PM -0400, Bruce Momjian wrote: > > > On Mon, Jul 23, 2018 at 11:27:49AM -0500, Nico Williams wrote: > > > > Perhaps patent law [in some countries] requires contracts as opposed to > > > > licenses? > > > > > > Yes, I really don't know. I have just seen enough "oh, we didn't think > > > of that" to be cautious. > > > > So, is it FUD? The core needs paid-for legal advice, not speculation. > > > > I'm quite certain that a software license can make a patent grant to the > > satisfaction of many open source communities, and almost certainly to > > the satisfaction of the PG community. But it will take an IP lawyer to > > review or write such a license. > > And is the payback worth it? Many don't think so. Wouldn't that be something to decide on a case-by-case basis? Recall, a contributor might have acquired a patent only for the purpose of defensive use, and the patent might involve useful-to-PG ideas. Moreover, if PG re-invents those ideas later it then risks exposure to lawsuit anyways. Arguably, accepting suitably-wide patent grants serves to protect PG from this risk! Is that FUD from me, or good advice? You'll need a lawyer to decide. The important thing is the legal language of the grant. This is why PG needs legal advice. Nico --
On Mon, Jul 23, 2018 at 12:12:03PM -0700, Joshua D. Drake wrote: > On 07/23/2018 12:06 PM, Bruce Momjian wrote: > >>So, is it FUD? The core needs paid-for legal advice, not speculation. > >> > >>I'm quite certain that a software license can make a patent grant to the > >>satisfaction of many open source communities, and almost certainly to > >>the satisfaction of the PG community. But it will take an IP lawyer to > >>review or write such a license. > >And is the payback worth it? Many don't think so. > > Although Nico is correct, I also think we need to consider what the > community wants here. Historically, we have always explicitly avoided > anything to do with patents to the point where some hackers won't even read > white papers on patented methods. I do think there is a definite > technological advantage for PostgreSQL if there was a license that core > could accept that was patent friendly but frankly, I don't think that core > or the community has the desire to work through the cost of doing so. Absolutely. I myself don't want to be tainted when reading PG source code (or even docs). I believe PG needs to demand at least royalty-free, world-wide, non-exclusive, transferrable license, either irrevocable (i.e., without further conditions) or with a no-lawsuit covenant (i.e., revocable when the patent owner gets sued by the patent user). Such terms would be acceptable to me as a third-party contributor. Other contributors might have a different take. An IP lawyer could tighten that up and turn it into legalese. There might exist a license with suitable patent grant clauses that PG could adopt for new contributions. (Not GPLv3, of course, since that one is viral, but still, it has patent grant language that could be adapted for PG.) I myself would not welcome patent grants that apply only to PG itself and not to forks of it. I would also not welcome grants that apply only to PG and forks of it, but not new non-PG implementations of the same patent (whether open source or not) -- i.e., don't taint me. I suspect most other contributors too would not want to be tainted, so I think that's probably the most critical requirement, and that does drive towards the minimum grant breadth described above. Some contributors may also oppose no-lawsuit covenants, but I believe PG will benefit much more from allowing them than from disallowing them. At any rate, PG absolutely should accept code involving patents that are placed in the public domain provided that the owner places all relevant patents (in the U.S., in the EU, and so on -- wherever they have them) in the public domain. Yes, I'm aware that Germany does not recognize the idea of "public domain". This too requires legal advice, which my advice isn't. Nico --
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Bruce Momjian [mailto:bruce@momjian.us] > On Tue, Jul 10, 2018 at 08:20:53AM +0000, Tsunakawa, Takayuki wrote: > > Yes, that's one unfortunate future, which I don't want to happen > > of course. I believe PostgreSQL should accept patent for further > > evolution, because PostgreSQL is now a popular, influential software > > that many organizations want to join. > > Why did you say this last sentence? That's a simple story (but might still be a pipedream now.) PostgreSQL may become popular enough to be considered a publicproperty like Linux, OpenStack and Hadoop. Then more companies may want to join its development. For example, Greenplummay want to contribute its clever planner code to better align with the latest version of PostgreSQL, IBM may wantto give its Netezza-specific code to reduce maintenance burdon, and AWS/Microsoft/Google may want to contribute somebasic scalability and HA technology so that they can focus on more advanced features with less rebase burdon. I thinkPostgreSQL community can be ready to open its door a bit more to embrace big companies with many patents. Regards Takayuki Tsunakawa
2018-07-24 8:13 GMT+02:00 Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>:
From: Bruce Momjian [mailto:bruce@momjian.us]
> On Tue, Jul 10, 2018 at 08:20:53AM +0000, Tsunakawa, Takayuki wrote:
> > Yes, that's one unfortunate future, which I don't want to happen
> > of course. I believe PostgreSQL should accept patent for further
> > evolution, because PostgreSQL is now a popular, influential software
> > that many organizations want to join.
>
> Why did you say this last sentence?
That's a simple story (but might still be a pipedream now.) PostgreSQL may become popular enough to be considered a public property like Linux, OpenStack and Hadoop. Then more companies may want to join its development. For example, Greenplum may want to contribute its clever planner code to better align with the latest version of PostgreSQL, IBM may want to give its Netezza-specific code to reduce maintenance burdon, and AWS/Microsoft/Google may want to contribute some basic scalability and HA technology so that they can focus on more advanced features with less rebase burdon. I think PostgreSQL community can be ready to open its door a bit more to embrace big companies with many patents.
This back door can be really dangerous for companies that support PostgreSQL now like EDB, PostgreSQL Pro, 2nd quadrant and maybe other.
The popularity of PostgreSQL is not argument against patent trolls and patent lawyer.
Regards
Pavel
Regards
Takayuki Tsunakawa
On Mon, Jul 23, 2018 at 8:12 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
-- On 07/23/2018 12:06 PM, Bruce Momjian wrote:So, is it FUD? The core needs paid-for legal advice, not speculation.And is the payback worth it? Many don't think so.
I'm quite certain that a software license can make a patent grant to the
satisfaction of many open source communities, and almost certainly to
the satisfaction of the PG community. But it will take an IP lawyer to
review or write such a license.
Although Nico is correct, I also think we need to consider what the community wants here. Historically, we have always explicitly avoided anything to do with patents to the point where some hackers won't even read white papers on patented methods. I do think there is a definite technological advantage for PostgreSQL if there was a license that core could accept that was patent friendly but frankly, I don't think that core or the community has the desire to work through the cost of doing so.
Exactly. There would be a ton of work to do, lawyers to involve (which inevitably means lots of fun work for me :-) ), uncertainty for forks, likely changes to a licence many of us hold dear, various potential risks to the project, both in the short and long term - and in return for what? One or more patches that we currently know nothing about, have no idea of the benefit of, that if posted now would likely not get any eyes on them at all precisely because they're covered by a patent.
tldr; it's a crap ton of work, risk and uncertainty for what might well be zero benefit at the moment.
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 2018-Jul-24, Dave Page wrote: > tldr; it's a crap ton of work, risk and uncertainty for what might well be > zero benefit at the moment. Probably easiest way forward is to state the requirement and have someone untainted by the patent come up with a clean-room re-implementation. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 07/24/2018 05:20 PM, Alvaro Herrera wrote: > On 2018-Jul-24, Dave Page wrote: > >> tldr; it's a crap ton of work, risk and uncertainty for what might well be >> zero benefit at the moment. > > Probably easiest way forward is to state the requirement and have > someone untainted by the patent come up with a clean-room > re-implementation. > Clean room design addresses copyright-related issues, not patents. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 07/24/2018 11:20 AM, Alvaro Herrera wrote: > Probably easiest way forward is to state the requirement and have > someone untainted by the patent come up with a clean-room > re-implementation. That sounds like an approach based on copyright considerations. A patent, on the other hand, will apply if you happen to arrive at an implementation technique that's arguably covered by its claims, no matter how independently you may have arrived at it. Under those circumstances, I'm not certain how useful 'untaintedness' even is. It may be more useful for someone who *is* familiar with the patent to confirm that the re-implementation does in fact accomplish the requirement in a different way. -Chap
On Tue, Jul 24, 2018 at 4:26 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
On 07/24/2018 05:20 PM, Alvaro Herrera wrote:On 2018-Jul-24, Dave Page wrote:tldr; it's a crap ton of work, risk and uncertainty for what might well be
zero benefit at the moment.
Probably easiest way forward is to state the requirement and have
someone untainted by the patent come up with a clean-room
re-implementation.
Clean room design addresses copyright-related issues, not patents.
Correct. It's important folks realise that!
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Jul 24, 2018 at 04:28:51PM +0100, Dave Page wrote: > On Tue, Jul 24, 2018 at 4:26 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> > wrote: > > Clean room design addresses copyright-related issues, not patents. > > Correct. It's important folks realise that! Indeed. It's also important to know, when reading PG source code or docs, that there are no descriptions of patented algorithms nor references to unexpired patents in PG code / docs, unless those have the widest possible grant (as described before and below), are in the public domain, or are expired. Updating the PG license to make such patent grants (thus committing contributors to making them too) would be the best and simplest way to gain the reader's confidence that PG is not tainting them. Note that it's OK to *accidentally* implement patented algorithms as long as the author of the contribution didn't know about. There's no trebble damages in that case, and no tainting of others, plus, contributors and code reviewers/committers can't be expected to do patent searches for each contribution. IMO PG should have: - a license that grants patent rights as described before (royalty-free, non-exclusive, transferrable, irrevocable or revocable only where a relevant patent holder is sued, and then revocable only for the user doing the suing) - an employer contributor agreement whereby an individual contributor's employer's director agrees to allow PG-relevent contributions (by the contributor) to PG under the PG license (including patent grant text), and committing the contributor to disclose all non-expired patents embodied in the contribution - an individual contributor agreement whereby an individual contributor commits to following the PG code of conduct (which should include text about patents and copyrights), to make only PG-relevant contributions that the individual's employer (if they have one) permits, and to place the contributions under the PG license (including patent grant text), and so on Nico --
On 24 July 2018 at 18:17, Nico Williams <nico@cryptonector.com> wrote:
Note that it's OK to *accidentally* implement patented algorithms as
long as the author of the contribution didn't know about. There's no
trebble damages in that case, and no tainting of others, plus,
contributors and code reviewers/committers can't be expected to do
patent searches for each contribution.
Non-lawyer here, but "OK" is not a description I would apply to implementing a patented algorithm. You might be thinking of copyright. Of course it is true that people can't reasonably be expected to do patent searches, as you describe, but the patent system as applied to software is not well-known among knowledgeable people for being reasonable.
On Tue, Jul 24, 2018 at 06:29:37PM -0400, Isaac Morland wrote: > On 24 July 2018 at 18:17, Nico Williams <nico@cryptonector.com> wrote: > > Note that it's OK to *accidentally* implement patented algorithms as > > long as the author of the contribution didn't know about. There's no > > trebble damages in that case, and no tainting of others, plus, > > contributors and code reviewers/committers can't be expected to do > > patent searches for each contribution. > > Non-lawyer here, but "OK" is not a description I would apply to > implementing a patented algorithm. You might be thinking of copyright. Of > course it is true that people can't reasonably be expected to do patent > searches, as you describe, but the patent system as applied to software is > not well-known among knowledgeable people for being reasonable. Wrong. With patents the important thing is not to know about them when you implement -- if you come up with the same idea by accident (which, of course, is obviously entirely possible) then you are not subject to trebble damages. But if you knowingly copy the invention without a license then you are subject to trebble damages. A lot of patented ideas are fairly obvious. That always seems true after the fact, naturally, but many are fairly obvious even before knowing about them. It's clearly possible that you'll infringe by accident -- that's OK by comparison to infringing on purpose. Nico --
On 2018-Jul-07, David Fetter composed: > If they have no plans to practice any exclusive rights, our standard thing > process where individuals submit things and consent to have us name them > with the PGDG copyright and distribute them under TPL would be the > most straightforward approach to achieve it. Eh, however in the event that the submitting organization has licenses, would it not be untrustworthy to distribute as PGDG copyright and permit with no joined patent give? Some other organization getting a restrictive fork from Postgres could later be sued by the submitting organization, on the grounds that there is no legitimate standing for them to utilize the licensed code. TBH I don't see in what capacity would we be able to double permit the code in a way that secures those restrictive forks. Can you (Andres) clarify what is the thought? Regards: Kamagra <https://www.potenz4all.com/> ----- Kamagra -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On 07/25/18 01:56, Nico Williams wrote: > Wrong. With patents the important thing is not to know about them when > you implement -- if you come up with the same idea by accident (which, > of course, is obviously entirely possible) then you are not subject to > trebble damages. Even if the damages are not trebled, can 1✕ the damages be more than you would like to shell out? Not to mention the hassle of getting any infringing uses to cease? Also, is this distinction universally applied across jurisdictions? -Chap
Re: How can we submit code patches that implement our (pending) patents?
From
Benjamin Scherrey
Date:
On Wed, Jul 25, 2018 at 12:56 PM, Nico Williams <nico@cryptonector.com> wrote:
Wrong. With patents the important thing is not to know about them whenOn Tue, Jul 24, 2018 at 06:29:37PM -0400, Isaac Morland wrote:
> On 24 July 2018 at 18:17, Nico Williams <nico@cryptonector.com> wrote:
> > Note that it's OK to *accidentally* implement patented algorithms as
> > long as the author of the contribution didn't know about. There's no
> > trebble damages in that case, and no tainting of others, plus,
> > contributors and code reviewers/committers can't be expected to do
> > patent searches for each contribution.
>
> Non-lawyer here, but "OK" is not a description I would apply to
> implementing a patented algorithm. You might be thinking of copyright. Of
> course it is true that people can't reasonably be expected to do patent
> searches, as you describe, but the patent system as applied to software is
> not well-known among knowledgeable people for being reasonable.
you implement -- if you come up with the same idea by accident (which,
of course, is obviously entirely possible) then you are not subject to
trebble damages. But if you knowingly copy the invention without a
license then you are subject to trebble damages.
A lot of patented ideas are fairly obvious. That always seems true
after the fact, naturally, but many are fairly obvious even before
knowing about them. It's clearly possible that you'll infringe by
accident -- that's OK by comparison to infringing on purpose.
Nico
--
If you violate a patent, knowingly or otherwise, you are subject to penalties (perhaps not treble but still penalties) and will have to remove the offending code unless a deal is reached with the patent holder.
It is critical that Postgres require that all contributors do not enforce patents against Postgres - full stop. That's the IP agreement that should be in place.
-- Ben Scherrey
On Tue, Jul 24, 2018 at 06:13:37AM +0000, Tsunakawa, Takayuki wrote: > From: Bruce Momjian [mailto:bruce@momjian.us] > > On Tue, Jul 10, 2018 at 08:20:53AM +0000, Tsunakawa, Takayuki wrote: > > > Yes, that's one unfortunate future, which I don't want to happen > > > of course. I believe PostgreSQL should accept patent for further > > > evolution, because PostgreSQL is now a popular, influential software > > > that many organizations want to join. > > > > Why did you say this last sentence? > > That's a simple story (but might still be a pipedream now.) > PostgreSQL may become popular enough to be considered a public > property like Linux, OpenStack and Hadoop. I disagree with your characterization of this as a future possibility. It's a current reality, and it got to be that way by a process I describe below. > Then more companies may want to join its development. For example, > Greenplum may want to contribute its clever planner code to better > align with the latest version of PostgreSQL, IBM may want to give > its Netezza-specific code to reduce maintenance burdon, and > AWS/Microsoft/Google may want to contribute some basic scalability > and HA technology so that they can focus on more advanced features > with less rebase burdon. I think PostgreSQL community can be ready > to open its door a bit more to embrace big companies with many > patents. What made PostgreSQL attractive to those companies in the first place was a known lack of need to have Extensive Conversations with Legal™ about licensing and other financial/IP matters. This in turn was guaranteed by our license, which is totally pervasive in its grants, and by our refusal, as a policy, to include anything that might compromise those pervasive grants. We have specifically excluded, and in at least one case removed, patented things in order to maintain this property. Your proposal is aimed at a problem which doesn't exist, and it is asking us to make a titanic shift in our project policy in exchange for benefits which are at best ephemeral, even according to you. Please let this go. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Wed, Jul 25, 2018 at 03:06:22AM -0400, Chapman Flack wrote: > On 07/25/18 01:56, Nico Williams wrote: > > > Wrong. With patents the important thing is not to know about them when > > you implement -- if you come up with the same idea by accident (which, > > of course, is obviously entirely possible) then you are not subject to > > trebble damages. > > Even if the damages are not trebled, can 1✕ the damages be more than you > would like to shell out? Not to mention the hassle of getting any infringing > uses to cease? You get a chance to stop infringing. Also, how could you avoid accidentally re-inventing patented algorithms if not by doing a costly patent search every time you open $EDITOR?? > Also, is this distinction universally applied across jurisdictions? It doesn't matter. The point is that no one does a patent search every time they design an algorithm -- not unless they mean to patent it. So you can't avoid accidentally re-inventing patented algorithms.
On Wed, Jul 25, 2018 at 02:48:01PM +0700, Benjamin Scherrey wrote: > If you violate a patent, knowingly or otherwise, you are subject to > penalties (perhaps not treble but still penalties) and will have to remove > the offending code unless a deal is reached with the patent holder. Unless you do a patent search every time you design something, you can't avoid the risk of accidentally infringing. > It is critical that Postgres require that all contributors do not enforce > patents against Postgres - full stop. That's the IP agreement that should > be in place. My take is that the PG license should make royalty-free, non-exclusive, transferrable, worldwide patent grants that are either irrevocable or revocable only againts those who sue the owner. This together with a contributor agreement would stop contributions by patent trolls, but it still wouldn't prevent accidental re-inventions. I don't understand why it's not obvious that one can unknowingly and accidentally re-invent someone else's idea.
On 07/25/2018 11:25 AM, Nico Williams wrote: > I don't understand why it's not obvious that one can unknowingly and > accidentally re-invent someone else's idea. It's perfectly obvious. It's the chief reason the whole topic of software patents has been deeply controversial for so long. You seem to be using it as part of a proof by contradiction: One can unknowingly and accidentally reinvent a patented idea. If that were not tidily excused in practice, software patents would be deeply problematic. ---------------------------------------------- Therefore, it must be the case that unknowing and accidental reinvention is tidily excused in practice. I don't think it works. -Chap
On 2018-07-25 11:45:58 -0400, Chapman Flack wrote: > On 07/25/2018 11:25 AM, Nico Williams wrote: > > > I don't understand why it's not obvious that one can unknowingly and > > accidentally re-invent someone else's idea. > > It's perfectly obvious. It's the chief reason the whole topic > of software patents has been deeply controversial for so long. > > You seem to be using it as part of a proof by contradiction: > > > One can unknowingly and accidentally reinvent > a patented idea. > > If that were not tidily excused in practice, > software patents would be deeply problematic. > ---------------------------------------------- > > Therefore, it must be the case that unknowing and > accidental reinvention is tidily excused in practice. This seems like a discussion more suited to be over a beer, or some other medium, not the PG lists. Greetings, Andres Freund
On Wed, Jul 25, 2018 at 11:45:58AM -0400, Chapman Flack wrote: > On 07/25/2018 11:25 AM, Nico Williams wrote: > > > I don't understand why it's not obvious that one can unknowingly and > > accidentally re-invent someone else's idea. > > It's perfectly obvious. It's the chief reason the whole topic > of software patents has been deeply controversial for so long. Thanks. > You seem to be using it as part of a proof by contradiction: wat > One can unknowingly and accidentally reinvent > a patented idea. > > If that were not tidily excused in practice, > software patents would be deeply problematic. > ---------------------------------------------- > > Therefore, it must be the case that unknowing and > accidental reinvention is tidily excused in practice. > > I don't think it works. I didn't say it's excused. The damages that can be awarded are just three times less. In practice it is common to settle for no longer infringing. What are you proposing anyways? That every commit come with a patent search? Nico --
Re: How can we submit code patches that implement our (pending) patents?
From
Oleksandr Shulgin
Date:
On Wed, Jul 25, 2018 at 8:35 PM Nico Williams <nico@cryptonector.com> wrote:
What are you proposing anyways? That every commit come with a patent
search?
I would propose that everyone wasting their time and effort to discuss this issue here, would rather spend that time working towards putting an end to software patents instead.
That would be a much better use of the time, IMHO.
Just my 2c,
Alex
On Thu, Jul 26, 2018 at 9:33 AM Oleksandr Shulgin <oleksandr.shulgin@zalando.de> wrote:
On Wed, Jul 25, 2018 at 8:35 PM Nico Williams <nico@cryptonector.com> wrote:
What are you proposing anyways? That every commit come with a patent
search?I would propose that everyone wasting their time and effort to discuss this issue here, would rather spend that time working towards putting an end to software patents instead.That would be a much better use of the time, IMHO.
What about adding an extra line to the license that indicates that the copyright owners also give all patent licenses which are both in their power to grant and also needed for exercise of the copyright license and require that new code contributions use this license with the extra clause.
Now, no patent owner is likely to accept those terms, but then we can save our breath for later discussion.
Strictly speaking I also don't think ti is the same thing as a global public license for the patent, since it would only apply to cases where there was a copyright license tied to the PostgreSQL source code contributed by the patent holder. So you still have taint problems but probably not to the same extent.
Best Regards,
Chris Travers
Database Administrator
Saarbrücker Straße 37a, 10405 Berlin
On Wed, Jul 4, 2018 at 2:28 AM Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
Hello,
As I asked at the PGCon developer meeting this year, we'd like to offer our company's patents and patent applications license to the PostgreSQL community free of charge. If I heard correctly at that time, we could continue this discussion during the unconference, but I missed that opportunity (I'm sorry). So, please let me continue the consultation here. If some other mailing list is appropriate such as pgsql-core, let me know (but I hope open discussion will lead to better and fair ideas and conclusion.)
There are three ideas. Is there any effective idea?
(1)
Share patents through a patent pool for open source communities. Our company, Fujitsu Limited, is a licensee member of Open Invention Network (OIN). And PostgreSQL is the protection target of OIN as listed here:
http://www.openinventionnetwork.com/joining-oin/linux-system/linux-system-table/?cat_id=14&type=table
Google, IBM, Red Hat, Toyota, and other big names are the big sponsors. The basic membership is free.
(2)
For each patch we submit to the community that implements our patents, include in the mail body something like "3. Grant of Patent License" in Apache License 2.0:
Apache License, Version 2.0
https://www.apache.org/licenses/LICENSE-2.0
(3)
Put up a page on our company web site that's similar to Red Hat's "Patent Promise", which is restricted to PostgreSQL.
FYI, I've consulted SFLC (Software Freedom Law Center) about this matter, and I've just got a reply "We'll be in touch." I'm waiting for the next response.
Some fresh thoughts on the top-level matter.
I think the general concern of everyone here is that the PostgreSQL copyright license is a very broad license. It allows people to take the code, build new products possibly unrelated, using the code, and then commercialize them. While a patent license that grants everything needed to make full use of the copyright license is not quite the same as just handing the patents over to the public domain, it seems likely that this is close enough to be indistinguishable from the perspective of your business.
For example a competitor of yours could copy the relevant pieces of the PostgreSQL code, refactor this into a library, and then use it as a derivative work and this would be entirely within the copyright license. They could then license that library out, and you could not use your patents or copyrights to stop them. As such, a patent license would probably be very similar from a business perspective to a global public grant even though the two strike me as something which might not offer protection in the case of a clean-room implementation.
I certainly wouldn't be opposed to accepting patents where a license was granted to the PostgreSQL Global Developer Group and the community as a whole to make full use of the patents in any way covered by the copyright license of PostgreSQL (i.e where any use that involves utilizing the copyright license for PostgreSQL extends to the patents in question). But I am not sure that a business case would be able to be made for releasing any patents under such a license since it means that for anyone else, using the patents even in commercial software becomes trivial and enforcement would become very difficult indeed.
Best Regards,
Chris Travers
Database Administrator
Saarbrücker Straße 37a, 10405 Berlin
Chris Travers <chris.travers@adjust.com> writes: > What about adding an extra line to the license that indicates that the > copyright owners also give all patent licenses which are both in their > power to grant and also needed for exercise of the copyright license and > require that new code contributions use this license with the extra clause. There's been an awful lot of discussion in this thread that supposes that we can change the Postgres license. Let me just point out very clearly that no such thing is going to happen. There will be no changes, no additions, no alternate licenses, period. To change the license, we'd need the agreement of all current and past contributors, which is a completely impractical thing even if there were fairly wide consensus that a particular change is a good idea. Which there isn't. Anyone who's not completely bored by this topic already would do well to visit the list archives and read the last major discussion of changing the license, which was in 2001 if memory serves. We decided it was an impractical idea then, and it's only gotten more so with the passage of time. regards, tom lane
On 2018-07-26 09:51:54 -0400, Tom Lane wrote: > Chris Travers <chris.travers@adjust.com> writes: > > What about adding an extra line to the license that indicates that the > > copyright owners also give all patent licenses which are both in their > > power to grant and also needed for exercise of the copyright license and > > require that new code contributions use this license with the extra clause. > > There's been an awful lot of discussion in this thread that supposes that > we can change the Postgres license. Let me just point out very clearly > that no such thing is going to happen. There will be no changes, no > additions, no alternate licenses, period. To change the license, we'd > need the agreement of all current and past contributors, which is a > completely impractical thing even if there were fairly wide consensus > that a particular change is a good idea. Which there isn't. That's obviously not going to happen. But there is the less crazy alternative of dual licensing new contributions going forward, with a licence that's TPL compatible. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes: > On 2018-07-26 09:51:54 -0400, Tom Lane wrote: >> There's been an awful lot of discussion in this thread that supposes that >> we can change the Postgres license. Let me just point out very clearly >> that no such thing is going to happen. There will be no changes, no >> additions, no alternate licenses, period. To change the license, we'd >> need the agreement of all current and past contributors, which is a >> completely impractical thing even if there were fairly wide consensus >> that a particular change is a good idea. Which there isn't. > That's obviously not going to happen. But there is the less crazy > alternative of dual licensing new contributions going forward, with a > licence that's TPL compatible. No, we can't do that. Past contributions were made with the expectation that they'd be distributed under the existing license, full stop. Relicensing other people's work without their permission is definitely lawsuit bait. (Of course, most people might be fine with it, but it only takes one.) I think what you're suggesting is some legalese along the lines of "parts of this are under license X and other parts are under license Y", but nobody's going to want to deal with that. As David or someone mentioned upthread, not having to have a discussion with your corporate legal department is one of the big attractions of Postgres. Furthermore, there would be an awfully strong argument to be made that the net effect of such a thing would be that the whole of Postgres is effectively now under the double license --- because who could make use of only the old-license part, especially after a few years of mixing? So anyone who wasn't happy about their work being relicensed would still have solid grounds to sue. It's barely possible that we could get current and new contributors to sign some kind of CLA containing anti-patent terms, but I don't think there's any hope of amending the distribution license. regards, tom lane
On 2018-07-26 16:42:24 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2018-07-26 09:51:54 -0400, Tom Lane wrote: > >> There's been an awful lot of discussion in this thread that supposes that > >> we can change the Postgres license. Let me just point out very clearly > >> that no such thing is going to happen. There will be no changes, no > >> additions, no alternate licenses, period. To change the license, we'd > >> need the agreement of all current and past contributors, which is a > >> completely impractical thing even if there were fairly wide consensus > >> that a particular change is a good idea. Which there isn't. > > > That's obviously not going to happen. But there is the less crazy > > alternative of dual licensing new contributions going forward, with a > > licence that's TPL compatible. > > No, we can't do that. Past contributions were made with the expectation > that they'd be distributed under the existing license, full stop. > Relicensing other people's work without their permission is definitely > lawsuit bait. (Of course, most people might be fine with it, but it > only takes one.) I *explicitly* said "dual licensing new contributions going forward", note the words "new" and "forward". There's plenty reasons to not want that, but it definitely doesn't amount to relicensing or anything in that vein. Not that the PG license actually blocks much of that. > I think what you're suggesting is some legalese along the lines of > "parts of this are under license X and other parts are under license Y", > but nobody's going to want to deal with that. As David or someone > mentioned upthread, not having to have a discussion with your corporate > legal department is one of the big attractions of Postgres. Furthermore, > there would be an awfully strong argument to be made that the net effect > of such a thing would be that the whole of Postgres is effectively now > under the double license --- because who could make use of only the > old-license part, especially after a few years of mixing? So anyone who > wasn't happy about their work being relicensed would still have solid > grounds to sue. Where would that ground come from if the license is BSD / TPL compatible? Unless we somehow stopped keeping the file headers intact, there'd be absolutely nothing in the TPL that'd not still be correct? Have these people sued the forks of PG? No. Again, the idea here wasn't to have some crazy license, but to dual license new contributions under something like Apache 2 & TPL. The only meaningful difference is that Apache 2 has an explicit (rather than the theorized implicit grant in BSD / TPL) patent grant for the contribution. Greetings, Andres Freund
Greetings, * Andres Freund (andres@anarazel.de) wrote: > On 2018-07-26 16:42:24 -0400, Tom Lane wrote: > > Andres Freund <andres@anarazel.de> writes: > > > On 2018-07-26 09:51:54 -0400, Tom Lane wrote: > > >> There's been an awful lot of discussion in this thread that supposes that > > >> we can change the Postgres license. Let me just point out very clearly > > >> that no such thing is going to happen. There will be no changes, no > > >> additions, no alternate licenses, period. To change the license, we'd > > >> need the agreement of all current and past contributors, which is a > > >> completely impractical thing even if there were fairly wide consensus > > >> that a particular change is a good idea. Which there isn't. > > > > > That's obviously not going to happen. But there is the less crazy > > > alternative of dual licensing new contributions going forward, with a > > > licence that's TPL compatible. > > > > No, we can't do that. Past contributions were made with the expectation > > that they'd be distributed under the existing license, full stop. > > Relicensing other people's work without their permission is definitely > > lawsuit bait. (Of course, most people might be fine with it, but it > > only takes one.) > > I *explicitly* said "dual licensing new contributions going forward", > note the words "new" and "forward". There's plenty reasons to not want > that, but it definitely doesn't amount to relicensing or anything in > that vein. Not that the PG license actually blocks much of that. Indeed. > > I think what you're suggesting is some legalese along the lines of > > "parts of this are under license X and other parts are under license Y", > > but nobody's going to want to deal with that. As David or someone > > mentioned upthread, not having to have a discussion with your corporate > > legal department is one of the big attractions of Postgres. Furthermore, > > there would be an awfully strong argument to be made that the net effect > > of such a thing would be that the whole of Postgres is effectively now > > under the double license --- because who could make use of only the > > old-license part, especially after a few years of mixing? So anyone who > > wasn't happy about their work being relicensed would still have solid > > grounds to sue. > > Where would that ground come from if the license is BSD / TPL > compatible? Unless we somehow stopped keeping the file headers intact, > there'd be absolutely nothing in the TPL that'd not still be correct? > Have these people sued the forks of PG? No. This is a killer point here- clearly the people who have been contributing to PG aren't going to complain about their contributions being released as part of some other work which has a different license or they'd have gone after the many, many, many closed-source and proprietary and commercial forks of PG. Not only that, but I'd be quite happy to bet serious dollars that at least some of the companies who have forked PG into commerical closed-source products have talked to their lawyers about if they need to be worried about some contributor complaining or trying to sue them, and have concluded that it's not enough of an issue to worry about. > Again, the idea here wasn't to have some crazy license, but to dual > license new contributions under something like Apache 2 & TPL. The only > meaningful difference is that Apache 2 has an explicit (rather than the > theorized implicit grant in BSD / TPL) patent grant for the > contribution. I have to say that I do like the idea of the explicit patent grant which is included in the Apache 2 license. I'm a bit concerned about how it's just a heck of a lot more text for some, but I doubt there's a simpler way to get there with a license that's been actually reviewed by modern lawyers and which covers what we'd like. When it comes to RedHat's promise, there's a distinction that I believe is being missed in this thread so far. Bruce is absolutely right when he says that RedHat's promise is no guarantee that a successor in interest will keep the promise. We aren't talking about trusting RedHat's promise here though, at least, not by itself. RedHat's promise is about *RedHat's* patents, of which they have quite a few, but none of which are currently being proposed for inclusion in PG. What we're currently discussing is the case where $COMPANY wants to contribute code to PG which implements an algorithm on which $COMPANY has both the copyright to the new code and a patent on the algorithm. As $COMPANY has both the copyright and the patent, they're free to license both. Under the Apache 2 license, they would be explicitly granting use of the copyright'd code and the patent. Currently, we don't let them grant both- they can only grant use of the copyright'd code by placing it under TPL, leaving the patent side of things nebulous and full of FUD. I do think we'd do well to remove the FUD around patented technology by allowing companies to explicitly grant patent usage in the same way that the code is explicitly licensed to address copyright. Dual-licensing new contributions seems like it would do that nicely, though I would think some kind of distinction should be made in terms of our process should we decide to make that change, so that it's abundently clear when we institute that and minimize any confusion over if a certain patch has been submitted under TPL or under TPL + Apache 2. The RedHat Promise would come into play were a third party to implement a RedHat patented algorithm where the third party then holds the copyright but RedHat owns the patent. In that case, RedHat has promised to not sue as long as the patent is used in FOSS (more-or-less), but we have no guarantee of that should RedHat end up bankrupt. In such a case, should it arise, where a third party submits code which implements a RedHat patented algorithm, perhaps we could simply ask RedHat to distribute the code itself under the Apache 2 license, thereby binding RedHat and successors to the terms of that license and thus removing any dependency on the Promise. Thanks! Stephen
Attachment
On Thu, Jul 26, 2018 at 04:42:24PM -0400, Tom Lane wrote: > It's barely possible that we could get current and new contributors to > sign some kind of CLA containing anti-patent terms, but I don't think > there's any hope of amending the distribution license. Leaving aside whether you could change the license, or apply a new license only to new contributions (that might be hard unless you're making the history part of the product), ... ...if a CLA is too difficult too, then perhaps demand disclosure by authors of any knowledge they might have of patents that their contribution implements. Nico --
On Thu, Jul 26, 2018 at 11:00 PM, Stephen Frost <sfrost@snowman.net> wrote: > This is a killer point here- clearly the people who have been > contributing to PG aren't going to complain about their contributions > being released as part of some other work which has a different license > or they'd have gone after the many, many, many closed-source and > proprietary and commercial forks of PG. Yes. Tom's argument doesn't work at all, for this reason among others. Other projects have done things like this, I'm pretty sure, so we could, too. > I have to say that I do like the idea of the explicit patent grant which > is included in the Apache 2 license. I'm a bit concerned about how it's > just a heck of a lot more text for some, but I doubt there's a simpler > way to get there with a license that's been actually reviewed by modern > lawyers and which covers what we'd like. I agree. The argument that is being made by Tom, Bruce, Dave, and David Fetter -- not to conflate them all, but they seem to be broadly on the same wavelength -- is that we should just reject contributions if the contributor says that there is a patent on anything in that contribution, or if we find out that this is the case. Then, they allege, we will have no problem with patents. I am not a lawyer, but I don't think it works that way. Even if PostgreSQL never accepts a contribution that is known to be covered by a patent, somebody can still find something in there that they think is covered by some patent they own and start suing people. The point of the Apache 2 license (and similar ones) is to make that sort of thing less likely to happen and less likely to be successful. It is not bullet-proof, of course, but it is intended to help. Saying "as long as we don't handle any patents we won't have any trouble with patents" is roughly as credible as the same sentence would be if you replaced "patents" with "nuclear weapons" or "knives" or "guns" or "toxic waste". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Jul 25, 2018 at 10:53 AM, David Fetter <david@fetter.org> wrote: > What made PostgreSQL attractive to those companies in the first place > was a known lack of need to have Extensive Conversations with Legal™ > about licensing and other financial/IP matters. If you think that the lack of a CLA and a patent grant never causes extensive conversations with legal, I am quite certain that you are incorrect. I know of multiple instances where this has been a concern. Other open source projects even more prominent and successful than PostgreSQL have done these things. You (and some others) seem confident that we know better, an attitude that I just don't understand. It's not as if we have some blue ribbon panel coming up with best practices which we then implement. We're just doing the same thing that we have been doing for 20+ years because that's the way we've always done it. It's probably not a bad process, because it's gotten us this far and this is a pretty cool place to be, but processes can involve and get better, just as the code itself has done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Jul 26, 2018 at 11:00 PM, Stephen Frost <sfrost@snowman.net> wrote: >> This is a killer point here- clearly the people who have been >> contributing to PG aren't going to complain about their contributions >> being released as part of some other work which has a different license >> or they'd have gone after the many, many, many closed-source and >> proprietary and commercial forks of PG. > Yes. Tom's argument doesn't work at all, for this reason among > others. Other projects have done things like this, I'm pretty sure, > so we could, too. No, it doesn't follow. Anyone who's contributed code to PG in the last twenty years has known, if they were paying any attention, that it'd also end up in proprietary forks. The ground rules for the community are that we don't care about that; somebody who did care would probably look for a GPL-licensed project to contribute to. However, that does *not* mean that adding patent-related qualifiers to the license is going to be OK with everybody. An easy counterexample is that we get code from some of those selfsame companies with private forks, which then feeds back into their forks (EDB, for instance). What if the license change interferes with their own IP situation? > I agree. The argument that is being made by Tom, Bruce, Dave, and > David Fetter -- not to conflate them all, but they seem to be broadly > on the same wavelength -- is that we should just reject contributions > if the contributor says that there is a patent on anything in that > contribution, or if we find out that this is the case. Then, they > allege, we will have no problem with patents. I am not a lawyer, but > I don't think it works that way. You're just attacking a straw man. Nobody is claiming that that would give us entire safety. We *are* saying that not doing that would expose us to more legal risk than if we do do it (ie refuse any known-patent- encumbered code). In any case we will always have to be prepared to remove patent-covered code when someone brings it to our notice. The latter is a fact of life that no amount of license-tweaking or contributor-agreement-making is going to alter. But what we can do, to reduce the risk of future trouble, is avoid planting already-known patent time bombs in our code. That prevents issues if the patent owner (or a successor) has a change of heart; and I think also that having a clear no-patents policy will help establish lack of intent to infringe if things ever get sticky with an accidental infringement. regards, tom lane
On Fri, Jul 27, 2018 at 10:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > However, that does *not* mean that adding patent-related qualifiers to the > license is going to be OK with everybody. An easy counterexample is that > we get code from some of those selfsame companies with private forks, > which then feeds back into their forks (EDB, for instance). What if the > license change interferes with their own IP situation? Maybe I'm missing something, but if it interferes with their IP situation, that must mean that their IP situation involves potentially wanting to sue users of PostgreSQL or derivate works for patent infringement. If that is the case, interfering with that situation is a feature, not a bug. In other words, if we say to various companies "hey, you can't contribute to PostgreSQL any more unless you are willing to have your contributions include the right to any patents they implicate" and one of those companies says "well, in that case we're not going to contribute any more," we have got to really wonder about the motivations of that company. > You're just attacking a straw man. I can't agree with that statement. > Nobody is claiming that that would > give us entire safety. We *are* saying that not doing that would expose > us to more legal risk than if we do do it (ie refuse any known-patent- > encumbered code). In any case we will always have to be prepared to > remove patent-covered code when someone brings it to our notice. > The latter is a fact of life that no amount of license-tweaking or > contributor-agreement-making is going to alter. I agree with all this. > But what we can do, > to reduce the risk of future trouble, is avoid planting already-known > patent time bombs in our code. That prevents issues if the patent owner > (or a successor) has a change of heart; No, that's exactly backwards. Right now, you are relying on people not having a change of heart; if you made them promise to license any patents they have, you would be relying on the law. Today, if an employee of company A contributes a patch to PostgreSQL which happens to include patented technology, and they happen not to mention it because their present management has no intention of asserting that patent against PostgreSQL, or because they just want to get the patch accepted for whatever reasons, they can later decide that they'd like to assert that patent after all. If they have agreed to a license that includes an explicit patent grant, then they can't just change their mind. There's a lot of speculation on this thread which suggests that there may be situations such as bankruptcy in which companies can go back on their contracts and/or promises; regardless of whether that is the case, it must be far easier for a company to reverse course when it hasn't contracted or promised anything to begin with. > and I think also that having a > clear no-patents policy will help establish lack of intent to infringe > if things ever get sticky with an accidental infringement. We don't have a clear contribution policy of any kind, about patents or anything else. The entire policy around contributions consists of a corpus of remarks you've made on the mailing list and *maybe* a wiki page someplace. (I couldn't find one in a quick search, though.) There's nothing that anybody needs to agree to in order to contribute, and there are no checks that anyone is aware of, let alone intending to adhere to, any particular set of rules. If we actually did have a clear policy, though, I agree that it might help. On the other hand, how much difference is there between a policy that says "we don't want code that is known to be covered by patents of any kind" and a similar policy that says "...unless a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable patent license allowing use for any purpose is conveyed along with the code"? If you operate under the theory that someone can revoke a license that has "irrevocable" in the legal language, then there's a big difference, but I don't think that's how the law works. My understanding, rather, is that once a technique is patented by company or individual A, it cannot later be patented by somebody else. So if you know who the patent-holder is, and you know they've given a license, you're actually safer than if there is no patent at all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Jul 27, 2018 at 09:30:45AM -0400, Robert Haas wrote: > If you think that the lack of a CLA and a patent grant never causes > extensive conversations with legal, I am quite certain that you are > incorrect. I know of multiple instances where this has been a > concern. > > Other open source projects even more prominent and successful than > PostgreSQL have done these things. [...] FWIW, some have done it poorly. I had trouble getting an employer to sign the Oracle contributor agreement, for example, because the OCA did not allow the employer to specify who could make the contribution (only who the director is who signs the OCA) and also did not allow the employer to narrow the scope of contributions to those relevant to the OpenJDK. I also recommend adding to the PG code of conduct text requiring disclosure of relevant patent rights that the contributor knows about. Nico --
Even assuming you can't change the PG license, you could still: - require disclosure in contributions - require a wide grant in contributions - document all such grants separately from the copyright license Putting the grants in the license is convenient, but it's not required to include patent language in order to get the desired effect. The license is just a copyright license -- it could stay just that. You could also require a CLA in the case where disclosure is made, or even in all cases. But a CLA for all cases would be a bit too burdensome. Nico --
Hi, On 2018-07-27 11:15:00 -0500, Nico Williams wrote: > Even assuming you can't change the PG license, you could still: > > - require disclosure in contributions That really has no upsides, except poison the area. Either we reject the patch and people doing so can reasonably be expected to know about the patents, making further contributions by them worse. Or we accept the patch, and the listed patents make the commercial offerings harder, further development more dubious, readers can reasonably be concerned about being considered do know about the patents in independent projects. Greetings, Andres Freund
On Fri, Jul 27, 2018 at 10:01:40AM -0700, Andres Freund wrote: > On 2018-07-27 11:15:00 -0500, Nico Williams wrote: > > Even assuming you can't change the PG license, you could still: > > > > - require disclosure in contributions > > That really has no upsides, except poison the area. [...] Sure it does: a) it allows PG to reject such contributions unless they come with suitable grants, and b) it gives PG users a legal defense should they ever be sued for infringement on a patent that was not disclosed to PG at the time of the contribution. (b) is a big deal. Nico --
On 07/27/2018 01:01 PM, Andres Freund wrote: > the patch and people doing so can reasonably be expected to know about > the patents, making further contributions by them worse. I'm not sure this line of thinking, which seems rooted in notions of tainted or cleanroom development from the copyright world, has the same force wrt patents. Sometimes a good understanding of a patented technique, including just what aspects of it are claimed or not in the patent's claims section, will be just what you need in order to be confident that an alternative approach you've devised really is different in the ways that matter. I don't think it automatically casts a cloud on the work as it would in the copyright case. -Chap
On 2018-07-27 13:33:28 -0400, Chapman Flack wrote: > On 07/27/2018 01:01 PM, Andres Freund wrote: > > > the patch and people doing so can reasonably be expected to know about > > the patents, making further contributions by them worse. > > I'm not sure this line of thinking, which seems rooted in notions of > tainted or cleanroom development from the copyright world, has the > same force wrt patents. Yes, violations made with knowledge triples damages in the US. > Sometimes a good understanding of a patented technique, including > just what aspects of it are claimed or not in the patent's claims > section, will be just what you need in order to be confident that > an alternative approach you've devised really is different in the > ways that matter. I don't think it automatically casts a cloud on > the work as it would in the copyright case. There's no way we can do that without extensive lawyerly input in each case. Greetings, Andres Freund
On 07/27/2018 01:42 PM, Andres Freund wrote: > On 2018-07-27 13:33:28 -0400, Chapman Flack wrote: >> On 07/27/2018 01:01 PM, Andres Freund wrote: >> >>> the patch and people doing so can reasonably be expected to know about >>> the patents, making further contributions by them worse. >> >> I'm not sure this line of thinking, which seems rooted in notions of >> tainted or cleanroom development from the copyright world, has the >> same force wrt patents. > > Yes, violations made with knowledge triples damages in the US. Nobody suggested violating with knowledge. The point is to use the knowledge to /not/ violate. In the domain of copyright, that's nonsensical of course. In the domain of patent, it isn't, and can be smarter than forging ahead blindly in the hope that you're just happening to skirt the claims of a patent you'd rather not know about. -Chap
On Fri, Jul 27, 2018, 19:01 Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2018-07-27 11:15:00 -0500, Nico Williams wrote:
> Even assuming you can't change the PG license, you could still:
>
> - require disclosure in contributions
That really has no upsides, except poison the area. Either we reject
the patch and people doing so can reasonably be expected to know about
the patents, making further contributions by them worse. Or we accept
the patch, and the listed patents make the commercial offerings harder,
further development more dubious, readers can reasonably be concerned
about being considered do know about the patents in independent
projects.
What about just requiring a patent license that grants all rights necessary to fully enjoy the copyright license? That avoids the need to change the license fomally. And it would just clarify that we expect that patents do NOT change the license. Not that I expect there would be takers....
Greetings,
Andres Freund
RE: How can we submit code patches that implement our (pending)patents?
From
"Tsunakawa, Takayuki"
Date:
From: Chris Travers [mailto:chris.travers@adjust.com] > For example a competitor of yours could copy the relevant pieces of the > PostgreSQL code, refactor this into a library, and then use it as a > derivative work and this would be entirely within the copyright license. > They could then license that library out, and you could not use your patents > or copyrights to stop them. As such, a patent license would probably be > very similar from a business perspective to a global public grant even though > the two strike me as something which might not offer protection in the case > of a clean-room implementation. > > I certainly wouldn't be opposed to accepting patents where a license was > granted to the PostgreSQL Global Developer Group and the community as a > whole to make full use of the patents in any way covered by the copyright > license of PostgreSQL (i.e where any use that involves utilizing the > copyright license for PostgreSQL extends to the patents in question). But > I am not sure that a business case would be able to be made for releasing > any patents under such a license since it means that for anyone else, using > the patents even in commercial software becomes trivial and enforcement > would become very difficult indeed. It looks like you are right in that we can't restrict the use of patents in PostgreSQL code to PostgreSQL-based software... Re-reading Apache License 2.0, it doesn't have any restriction either. But, like Apache License, I think thepatents can be useful to prevent litigation. Regards Takayuki Tsunakawa