Re: contrib and licensing

On Tue, 2003-04-01 at 16:31, mlw wrote:
> I know nothing in contrib should be GPL, I have no problem with that.
> The question is the requirement of a GPL library to build a contrib project.
>
> My SOAP/XML function will probably require my LGPL library as there is a
> lot of code I have written that I would need to implement it.
>
> Is there any sort of philosophical problem with that?

There is a big difference between an LGPL'd library and a GPL'd library.

The latter may have problems as I believe your code should be GPL'd, but
the former should be fine.

--
Rod Taylor <rbt(at)rbt(dot)ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.

My SOAP/XML function will probably require my LGPL library as there is a
lot of code I have written that I would need to implement it.

Is there any sort of philosophical problem with that?

mlw <pgsql(at)mohawksoft(dot)com> writes:
> I know nothing in contrib should be GPL, I have no problem with that.
> The question is the requirement of a GPL library to build a contrib project.

> My SOAP/XML function will probably require my LGPL library as there is a
> lot of code I have written that I would need to implement it.

If it won't work without your library then there's not much point in
putting it into contrib. Might as well just put it in your library
and distribute same as you have been doing.

regards, tom lane

Tom Lane wrote:

>mlw <pgsql(at)mohawksoft(dot)com> writes:
>
>
>>I know nothing in contrib should be GPL, I have no problem with that.
>>The question is the requirement of a GPL library to build a contrib project.
>>
>>
>
>
>
>>My SOAP/XML function will probably require my LGPL library as there is a
>>lot of code I have written that I would need to implement it.
>>
>>
>
>If it won't work without your library then there's not much point in
>putting it into contrib. Might as well just put it in your library
>and distribute same as you have been doing.
>
>
I'm a little put off by this attitude, are you saying there are no LGPL
dependencies in PostgreSQL or /contrib?

If that is a real objective, I'm surprised.

On Wed, 2 Apr 2003, mlw wrote:

>
>
> Tom Lane wrote:
>
> >mlw <pgsql(at)mohawksoft(dot)com> writes:
> >
> >
> >>I know nothing in contrib should be GPL, I have no problem with that.
> >>The question is the requirement of a GPL library to build a contrib project.
> >>
> >>
> >
> >
> >
> >>My SOAP/XML function will probably require my LGPL library as there is a
> >>lot of code I have written that I would need to implement it.
> >>
> >>
> >
> >If it won't work without your library then there's not much point in
> >putting it into contrib. Might as well just put it in your library
> >and distribute same as you have been doing.
> >
> >
> I'm a little put off by this attitude, are you saying there are no LGPL
> dependencies in PostgreSQL or /contrib?
>
> If that is a real objective, I'm surprised.

I think it's more that if the lib is commonly included in most
environments, like say readline is, then someone will have to download the
lib seperately anyway, so you might as well have the soap functions be
there at the same place.

If your LGPL lib and / or an analog in BSD land are common, then including
it in contrib would make perfect sense.

On Wed, 2 Apr 2003, mlw wrote:

>
>
> Tom Lane wrote:
>
> >mlw <pgsql(at)mohawksoft(dot)com> writes:
> >
> >
> >>I know nothing in contrib should be GPL, I have no problem with that.
> >>The question is the requirement of a GPL library to build a contrib project.
> >>
> >>
> >
> >
> >
> >>My SOAP/XML function will probably require my LGPL library as there is a
> >>lot of code I have written that I would need to implement it.
> >>
> >>
> >
> >If it won't work without your library then there's not much point in
> >putting it into contrib. Might as well just put it in your library
> >and distribute same as you have been doing.
> >
> >
> I'm a little put off by this attitude, are you saying there are no LGPL
> dependencies in PostgreSQL or /contrib?

In fact, yes ... or, at least, if there are any left in /contrib, its only
because we haven't moved them to gborg yet ...

> If that is a real objective, I'm surprised.

The base source tree has always been as BSD pure as we can make it ... its
never been kept a secret ...

On Wed, 2 Apr 2003, Marc G. Fournier wrote:

> On Wed, 2 Apr 2003, mlw wrote:
>
> >
> >
> > Tom Lane wrote:
> >
> > >mlw <pgsql(at)mohawksoft(dot)com> writes:
> > >
> > >
> > >>I know nothing in contrib should be GPL, I have no problem with that.
> > >>The question is the requirement of a GPL library to build a contrib project.
> > >>
> > >>
> > >
> > >
> > >
> > >>My SOAP/XML function will probably require my LGPL library as there is a
> > >>lot of code I have written that I would need to implement it.
> > >>
> > >>
> > >
> > >If it won't work without your library then there's not much point in
> > >putting it into contrib. Might as well just put it in your library
> > >and distribute same as you have been doing.
> > >
> > >
> > I'm a little put off by this attitude, are you saying there are no LGPL
> > dependencies in PostgreSQL or /contrib?
>
> In fact, yes ... or, at least, if there are any left in /contrib, its only
> because we haven't moved them to gborg yet ...

a program in /contrib linking to an LGPL lib has never been an issue.
Linking to LGPL libs doesn't encumber the software linking to it.

> > If that is a real objective, I'm surprised.
>
> The base source tree has always been as BSD pure as we can make it ... its
> never been kept a secret ...

True. But not linking to LGPLd libs would be a bit extreme there.

On Wed, 2 Apr 2003, scott.marlowe wrote:

> > > If that is a real objective, I'm surprised.
> >
> > The base source tree has always been as BSD pure as we can make it ... its
> > never been kept a secret ...
>
> True. But not linking to LGPLd libs would be a bit extreme there.

Correct, we've always had libreadline support, as a compile option, but
libreadline is not part of the distribution, only the hooks to it are ...
and, just recently, libedit(?) support was added as well, so that a
non-GPL licensed alternative is available for those wishing to distribute
the software ...

mlw writes:

> I'm a little put off by this attitude, are you saying there are no LGPL
> dependencies in PostgreSQL or /contrib?

No, the point is, why put it in contrib when someone who wants to use it
has to download your library anyway. Then you might as well distribute
the module next to that library.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Wed, 2003-04-02 at 18:00, Marc G. Fournier wrote:
> On Wed, 2 Apr 2003, scott.marlowe wrote:
> > True. But not linking to LGPLd libs would be a bit extreme there.
>
> Correct, we've always had libreadline support, as a compile option

Why is that relevant? libreadline is GPL'd, not LGPL'd.

Cheers,

Neil

mlw <pgsql(at)mohawksoft(dot)com> writes:
> Tom Lane wrote:
>> If it won't work without your library then there's not much point in
>> putting it into contrib. Might as well just put it in your library
>> and distribute same as you have been doing.
>>
> I'm a little put off by this attitude, are you saying there are no LGPL
> dependencies in PostgreSQL or /contrib?

> If that is a real objective, I'm surprised.

The intention is that the entire distribution, including contrib, be under
straight BSD license. This is a real objective --- we're not there yet,
mainly because it's not being pursued vigorously with regard to the
contrib modules already in place, but we think it is a valuable way of
minimizing confusion.

We have no problem at all with offering gborg project space to LGPL or
GPL-licensed code; it's just that we don't want it in the core
distribution, so that people don't have to hunt-and-peck through the
distro to see which parts are under which license.

Although you indicated willingness to provide the SOAP code per se as
BSD license, it seems to me that this is rather pointless if it can't
be used without an LGPL'd associated library. Someone who wanted a
pure-BSD setup would still be unable to use the code. The SOAP code
plus underlying library would be a more sensible distribution unit,
and as such you might as well make it all LGPL.

Of course, if you wanted to make it all BSD and put the whole mess in
contrib, we'd be open to that idea ...

regards, tom lane

"Marc G. Fournier" wrote:
>
> On Wed, 2 Apr 2003, scott.marlowe wrote:
>
> > > > If that is a real objective, I'm surprised.
> > >
> > > The base source tree has always been as BSD pure as we can make it ... its
> > > never been kept a secret ...
> >
> > True. But not linking to LGPLd libs would be a bit extreme there.
>
> Correct, we've always had libreadline support, as a compile option, but
> libreadline is not part of the distribution, only the hooks to it are ...
> and, just recently, libedit(?) support was added as well, so that a
> non-GPL licensed alternative is available for those wishing to distribute
> the software ...

GPL vs. LGPL vs. BSD vs. MyFu**inLicense the next round ... man is this
annoying. I think with this new incarnation of the License war it's a
good time to give a real example what dragging our attention to
licensing leads to. Libedit might not be as good ... so be it. Who cares
about people who choose their database system by the color of the splash
screen? We have a pure BSD alternative that we could even ship with our
distro, time to retire the libreadline hooks.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Jan Wieck wrote:

>"Marc G. Fournier" wrote:
>
>
>>On Wed, 2 Apr 2003, scott.marlowe wrote:
>>
>>
>>
>>>>>If that is a real objective, I'm surprised.
>>>>>
>>>>>
>>>>The base source tree has always been as BSD pure as we can make it ... its
>>>>never been kept a secret ...
>>>>
>>>>
>>>True. But not linking to LGPLd libs would be a bit extreme there.
>>>
>>>
>>Correct, we've always had libreadline support, as a compile option, but
>>libreadline is not part of the distribution, only the hooks to it are ...
>>and, just recently, libedit(?) support was added as well, so that a
>>non-GPL licensed alternative is available for those wishing to distribute
>>the software ...
>>
>>
>
>GPL vs. LGPL vs. BSD vs. MyFu**inLicense the next round ... man is this
>annoying. I think with this new incarnation of the License war it's a
>good time to give a real example what dragging our attention to
>licensing leads to. Libedit might not be as good ... so be it. Who cares
>about people who choose their database system by the color of the splash
>screen? We have a pure BSD alternative that we could even ship with our
>distro, time to retire the libreadline hooks.
>
>
I certainly didn't want to open up this can of worms, that's for sure.

I have an amount of code that is LGPL, I would rather use it than write
the bits again or try to extract them from the whole. The actual
extension would be BSD, but it would need to link with my library. I
made the library LGPL (from GPL) for the PHP group who have similar
restrictions.

Thus this discussion.

I don't know what the answer is, but to say "NO LGPL" seems a bit
extream, especially if you already have such dependencies. Then if you
conclude you do allow LGPL libraries, but then only allow some
libraries, not all, then what is the criteria for choosing which
libraries get blessed. Is it purely "popularity?"

Do you guys really think that a contrib function should not be allowed
to require code which may not be on a common UNIX/BSD/Linux box?

mlw wrote:
>
> Jan Wieck wrote:
> >[...]
> >screen? We have a pure BSD alternative that we could even ship with our
> >distro, time to retire the libreadline hooks.
> >
> >
> I certainly didn't want to open up this can of worms, that's for sure.
>
> I have an amount of code that is LGPL, I would rather use it than write
> the bits again or try to extract them from the whole. The actual
> extension would be BSD, but it would need to link with my library. I
> made the library LGPL (from GPL) for the PHP group who have similar
> restrictions.
>
> Thus this discussion.

If it is "your" library as you've said multiple times now, there is
nothing that can stop you from relicensing it. Give me one good reason
why you have to keep your library under the LGPL, or better why it
cannot be relicensed under BSD.

> I don't know what the answer is, but to say "NO LGPL" seems a bit
> extream, especially if you already have such dependencies. Then if you
> conclude you do allow LGPL libraries, but then only allow some
> libraries, not all, then what is the criteria for choosing which
> libraries get blessed. Is it purely "popularity?"

Not more extreme than "I am the only true license, you shall not have
any other licenses beside me", which is my personal interpretation of
the entire FSF attempt.

> Do you guys really think that a contrib function should not be allowed
> to require code which may not be on a common UNIX/BSD/Linux box?

Your library does appear in what Unix distributions? And in which of
them is it installed by default like the libreadline? Yes, that
certainly has to do with popularity.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

> mlw wrote:
>>
>> Jan Wieck wrote:
>> >[...]
>> >screen? We have a pure BSD alternative that we could even ship with
>> >our distro, time to retire the libreadline hooks.
>> >
>> >
>> I certainly didn't want to open up this can of worms, that's for sure.
>>
>> I have an amount of code that is LGPL, I would rather use it than
>> write the bits again or try to extract them from the whole. The
>> actual extension would be BSD, but it would need to link with my
>> library. I made the library LGPL (from GPL) for the PHP group who have
>> similar restrictions.
>>
>> Thus this discussion.
>
> If it is "your" library as you've said multiple times now, there is
> nothing that can stop you from relicensing it. Give me one good reason
> why you have to keep your library under the LGPL, or better why it
> cannot be relicensed under BSD.

I do not want to get in to a "my license theology is better or more correct
than yours" discussion. Can we not do that? I have chosen to make the
library open source and LGPL. Respect that. I respect that the PG group
wants BSD, and everything that I would contribute to PG will be BSD.

This issue is the requirement of a third party LGPL library. Ignore for the
moment that it is mine.

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?

>
>> I don't know what the answer is, but to say "NO LGPL" seems a bit
>> extream, especially if you already have such dependencies. Then if you
>> conclude you do allow LGPL libraries, but then only allow some
>> libraries, not all, then what is the criteria for choosing which
>> libraries get blessed. Is it purely "popularity?"
>
> Not more extreme than "I am the only true license, you shall not have
> any other licenses beside me", which is my personal interpretation of
> the entire FSF attempt.

Let's not bring this into an argument about BSD vs [L]GPL, it isn't about that.

>
>> Do you guys really think that a contrib function should not be allowed
>> to require code which may not be on a common UNIX/BSD/Linux box?
>
> Your library does appear in what Unix distributions? And in which of
> them is it installed by default like the libreadline? Yes, that
> certainly has to do with popularity.

Did the tools required to build PostgreSQL *always* come standard on systems?
Could I currently build all the contrib directories on a RH 6.2 system
without any extra libraries?

The issue is:
Is the requirement of an LGPL library that is more than likely not already
on your system a disqualification for a contrib function?

This is NOT a BSD vs [L]GPL argument, so lets not make it one. The actual
code for the function *will* be BSD or any license you want.

pgsql(at)mohawksoft(dot)com wrote:
> The issue is:
> Is the requirement of an LGPL library that is more than likely not already
> on your system a disqualification for a contrib function?

Yes.

Because the requirement of something that is more likely not found on
"usual" installations TOGETHER WITH that it cannot be included per se in
a (not necessarily our) PostgreSQL distribution IMNSVHO disqualifies
from being added to the official PostgreSQL release.

As Tom pointed out, we aren't there yet with the cleanup. But we
certainly don't want to add more candidates of that category to contrib.

Everything that falls out of contrib can be added to gborg.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

pgsql(at)mohawksoft(dot)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.

regards, tom lane

> pgsql(at)mohawksoft(dot)com writes:
> 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.

OK, that is more or less the answer to the question I originally posed.

Thanks.

On Thu, 3 Apr 2003 pgsql(at)mohawksoft(dot)com wrote:

> 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?

My two-bits here, but we're trying to *move* things out of contrib to
gborg, like we have for most of the language interfaces ... why is/should
this be any different? I don't care what licence it falls under, new
contrib's should be going into gborg, not into the distribution itself ...

Tom Lane wrote:
> pgsql(at)mohawksoft(dot)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(at)sysexperts(dot)com

Kevin Brown <kevin(at)sysexperts(dot)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 ;-).

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). 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.

> 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.

regards, tom lane

Tom Lane wrote:
> Kevin Brown <kevin(at)sysexperts(dot)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(at)sysexperts(dot)com

Kevin Brown wrote:

> 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.

Well, professional distributers are used to deal with licensing issues. What
about all those nice guys who just build unofficial RPM's of software for
their favorite plattform, so other's don't have to? Now they whould have a
problem with including contrib stuff.

Just a thought.

Regards,
Michael Paesold

Kevin Brown kirjutas E, 07.04.2003 kell 04:39:
>
> 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.

The current move-everything-possible-out-of-contrib seems to be
motivated by "less is more" philosophy, i.e. the standard tarball / cvs
update is considered too big.

Licensing is used as additional guideline, partly because of fear of
some licenses being viral.

>
>
> 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.

If licensing is a non-issue then it is be easy to change the license ;)

> > 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.

I guess this is also being moved to gborg.

-------------
Hannu