Re: contrib and licensing - Mailing list pgsql-hackers

Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > But if both of these paragraphs are simultaneously true, then why put
> > *anything* in contrib?
> 
> Don't say that too loudly, or Marc may take it upon himself to make it
> happen ;-).

Well, I hope he's not so eager to do so that he does it before this
licensing thing is hammered out.  :-)

I think having contrib is a very good idea, but that's only *because*
it currently allows non-BSD licenses.  Take that away, and I think
you've taken away the entire purpose for contrib (versus simply
including something in the main source tree with a configure switch to
enable/disable it).
> There are a number of reasons to keep things in contrib.  One is that
> the code may be too tightly tied to backend innards to be appropriate to
> maintain separately (the GIST extension modules are a good example, and
> most of the modules that include server-side code are easier to maintain
> with the server than not).  

Shouldn't this stuff (if we decide to make contrib BSD-only) become
part of the main source tree, then, with a configure option to
enable/disable it at compile time?

> Another is that small modules may not have
> enough critical mass to get maintained at all, if they're kicked out to
> live or die on their own.

That's certainly a problem, but only if the modules are also tightly
tied to the backend.  But then, does that mean that anything which is
strongly tied to the backend must be included in contrib, no matter
how unpopular?  Aside from that and licensing, what other criteria
would you use to decide on such inclusion?

> > Otherwise, perhaps you're more concerned about the licensing issues in
> > contrib than you need to be?
> 
> The way I see it, the "only BSD stuff in contrib" rule is designed
> precisely to save us from having to think too hard about licensing
> issues.  I'm not interested in getting into lawyeristic arguments
> about how it's okay to distribute something with a different license
> if only we don't do XYZ with it.

Yeah, but what I'm saying is that *we* don't have to think about this
lawyeristic stuff regardless.  All we have to care about is whether or
not the contrib item in question has a license that allows source
distribution.  The rest of it is a problem for whoever wants to build
binary distributions, and such people *already* know what the issues
are and know that they have to think about them.

The only case where that might not be true is the case of the
individual who is building a binary distribution for use within his
own group.  But such a person is easily covered by simply disabling
compilation of contrib by default.  If he has to go to the trouble of
enabling that explicitly, then he can be warned that the stuff in
contrib might be covered by a different license.  But such a person is
likely to be in a role where he's had to deal with licensing issues
elsewhere, so it's more likely than not that he'll be aware of such
things.  The only thing he needs to be made aware of is that contrib
contains items that fall under different licenses.  That alone isn't,
IMO, justification for removing non-BSD items from contrib.

So in the end, keeping contrib BSD-only doesn't help *us*, it only
helps the people who build binary distributions.  But because they're
already used to dealing with the problem, they don't need our help on
this.

And that means that kicking non-BSD stuff out of contrib doesn't
really help anyone very much, if any...but it does hurt us in that
some potentially very valuable things will no longer be considered for
inclusion in the distribution.  So from here it looks like there's
more (perhaps much more) to be lost by making contrib BSD-only than
there is to be gained.


It would be one thing if we had a lot of people clamoring for removal
of non-BSD stuff from contrib because they'd actually been burned by
licensing issues.  But I haven't seen anything to that effect on this
list, at least, and we've had at least one GPL item in there
(pgcrypto) since late 2000.





-- 
Kevin Brown                          kevin@sysexperts.com