Re: How can we submit code patches that implement our (pending) patents? - Mailing list pgsql-hackers

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