Re: contrib and licensing - Mailing list pgsql-hackers

Tom Lane wrote:
> pgsql@mohawksoft.com writes:
> > If I find a wiz-bang library that allows me to do something cool very
> > easily, and I write a some code that would be good for postgresql's contrib,
> > are you saying that it would not be usable because of the requirement of the
> > library that is not included on standard system installations?
> 
> The issue here is whether PG's contrib directory is the most appropriate
> distribution mechanism for such code.  There are at least two other
> paths for distribution of PG add-ons: you can make a gborg project, or
> you can distribute the add-on along with the wiz-bang library it depends
> on (assuming you can interest the developers of libwizbang, which in
> this case is presumably not a problem).  In either of those cases
> there's no problem at all with LGPL or GPL license terms.
> 
> We have taken a policy decision to keep the PG core distribution
> (including contrib) straight BSD license --- and in my mind that
> definitely includes not depending on any outside functionality that is
> both (a) essential and (b) not available anywhere as BSD-license code.
> It should be possible to build a PG installation that is pure BSD.
> Whether people actually choose to do so is not the point.

But if both of these paragraphs are simultaneously true, then why put
*anything* in contrib?  Why not, instead, put everything that is
currently in contrib (and is BSD licensed) either on gborg, or in the
main source tree itself?  If it's code that we eventually intend to
include in the main source tree but which isn't mature enough yet,
then it's probably more appropriate to add a config switch to
enable/disable compilation of that bit of code, rather than putting it
into a "contrib" directory.  But aside from such code, anyone who
wants to create a binary distribution can grab the source for
interesting packages from gborg.  Debian does this, for instance.
Nothing prevents us from putting the source tarballs for the most
important gborg projects on the main ftp site, either.

The theory behind putting things in contrib is that they will be
useful to a great many people who run PG, but how useful something may
be to the population at large is for the most part independent of the
licensing of that something (at least, when you restrict yourself to
GPL, LGPL, BSD, MIT, etc., licenses) -- Gnome, for instance, is very
useful to a great many people, yet it is licensed under the GPL.  The
argument of whether or not something belongs in contrib is therefore
independent of these licenses.

If you're concerned about the distribution problems someone may run
into when building and distributing binary versions of the code,
there's an easy solution to that: don't build anything in contrib by
default!  Force the person building the code to make the decision
whether or not to build the stuff in contrib, and inform him that
licensing issues may be involved.  People who are building binary
distributions of PG for wide dissemination are already very much aware
of the licensing issues involved in building any piece of software,
especially one which comes with a bunch of "extras", so for them
dealing with the licensing issues is simply not an issue.  For almost
everyone else, the licensing issues are not an issue at all because
they don't intend to distribute the binaries to the rest of the world,
only within their group or company -- something that, if I'm not
mistaken, doesn't require them to adhere to the "viral" part of the
license (since they're acting as an agent of the group or company, and
the license applies to that group or company as a whole).

I can understand the desire to keep the licensing of the PG package
"clean", but if your concern is that great then perhaps you should go
a little further and keep the *code* of the PG package "clean" as
well, and remove contrib entirely (there is nothing at all that would
prevent us from packaging up contrib as a separate tarball if we want
to distribute its contents far and wide).  There is some merit to
that: it would force us to finally decide what really belongs in the
main source tree (I'd argue that items such as the auto vacuum daemon
belong there because it's functionality that should have been there
from the beginning), rather than deferring the decision by putting it
in contrib.

Otherwise, perhaps you're more concerned about the licensing issues in
contrib than you need to be?


-- 
Kevin Brown                          kevin@sysexperts.com