Jan Wieck wrote:
"Marc G. Fournier" wrote:I certainly didn't want to open up this can of worms, that's for sure.
On Wed, 2 Apr 2003, scott.marlowe wrote:
Correct, we've always had libreadline support, as a compile option, butTrue. But not linking to LGPLd libs would be a bit extreme there.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 ...
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 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?
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?