Re: contrib and licensing

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?