Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-07-26 16:42:24 -0400, Tom Lane wrote: > > Andres Freund <and...@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
signature.asc
Description: PGP signature
