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




Re: How can we submit code patches that implement our (pending) patents?

From
Craig Ringer
Date:
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.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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




Re: How can we submit code patches that implement our (pending) patents?

From
Dave Cramer
Date:

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.

Re: How can we submit code patches that implement our (pending)patents?

From
David Fetter
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
David Fetter
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
David Fetter
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
David Fetter
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Alvaro Herrera
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Markus Wanner
Date:
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



Re: How can we submit code patches that implement our (pending) patents?

From
Craig Ringer
Date:
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?

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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




Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
David Fetter
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Markus Wanner
Date:
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
"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

Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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





Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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





Re: How can we submit code patches that implement our (pending) patents?

From
Craig Ringer
Date:
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. 

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending) patents?

From
Chris Travers
Date:


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

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com 
Saarbrücker Straße 37a, 10405 Berlin

Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending) patents?

From
Andres Freund
Date:

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.


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Chapman Flack
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
David Fetter
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Chapman Flack
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
David Fetter
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
--


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
--


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Bruce Momjian
Date:
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 +


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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.   *****



Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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





Re: How can we submit code patches that implement our (pending) patents?

From
Pavel Stehule
Date:


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.

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.

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

Re: How can we submit code patches that implement our (pending)patents?

From
Alvaro Herrera
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Tomas Vondra
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Chapman Flack
Date:
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

Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending) patents?

From
Isaac Morland
Date:


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. 

Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
jonasmehler46
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Chapman Flack
Date:
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:
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
--

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

 

Re: How can we submit code patches that implement our (pending)patents?

From
David Fetter
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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.


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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.


Re: How can we submit code patches that implement our (pending)patents?

From
Chapman Flack
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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

Re: How can we submit code patches that implement our (pending) patents?

From
Chris Travers
Date:


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

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com 
Saarbrücker Straße 37a, 10405 Berlin

Re: How can we submit code patches that implement our (pending) patents?

From
Chris Travers
Date:


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

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com 
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Stephen Frost
Date:
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

Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending) patents?

From
Robert Haas
Date:
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


Re: How can we submit code patches that implement our (pending) patents?

From
Robert Haas
Date:
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


Re: How can we submit code patches that implement our (pending) patents?

From
Robert Haas
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Nico Williams
Date:
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
-- 


Re: How can we submit code patches that implement our (pending)patents?

From
Chapman Flack
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Andres Freund
Date:
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


Re: How can we submit code patches that implement our (pending)patents?

From
Chapman Flack
Date:
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


Re: How can we submit code patches that implement our (pending) patents?

From
Chris Travers
Date:


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