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

Greetings,

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2018-07-26 16:42:24 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)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