On Fri, 6 Jul 2007 08:20:59 -0500, "John Hunter" wrote: > On 7/5/07, Carl Worth <[EMAIL PROTECTED]> wrote: > Hey Carl -- thanks for the response.
You're quite welcome. Thank you for receiving it as intended---as an
alternate viewpoint based on my experience.
> I think LGPL is a perfectly good license which satisfies most of my
> objections.
Good. That's the most important point I wanted to get across. It
seemed like an obvious hole in the original essay to me.
> Eric Jones of enthought has said he is reluctant to use
> LGPL code. I get the general sense that he simply doesn't want to
> risk a legal battle with the FSF, which may not be entirely rational,
> but their zealotry on some of these issues may simply scare some of
> the people in the commercial space.
I won't comment on hearsay, but I'd love to have a conversation with
anyone about merits and risks of the LGPL. As for the FSF and
commercial involvement, I think the last 18 months of the GPLv3
drafting process has shown quite conclusively that the FSF has very
effectively engaged some very significant commercial interests.
Here's one point of evidence of that:
GNU-Linux Software License Revision Praised By SIFMA
http://www.sifma.org/news/47167838.shtml
And much more information on a similar theme is available in this
excellent talk recently given by Eben Moglen:
http://www.groklaw.net/article.php?story=20070630094005112
> Perhaps you are right that the
> better answer for the scientific computing community in python is to
> reconsider the LGPL stance in scipy, but until that happens, and it is
> not my decision and I view it as unlikely, the best thing for this
> community is to use a set of compatible licenses in which we can share
> code, and the fact remains that we cannot include any LGPL code in our
> code unless we want our code to be LGPL as well.
I made the caveat earlier that it's often good to not change licensing
once a community has formed around it. Similarly, it's also often good
to go with the same license as the wider community you're trying to be
a part of. So again, you're probably doing the right thing.
But I can also point to my own experience. When I first started what
later would become cairo, (it was called Xr at the time), I had
expected it to be a library that formed part of the X Window
System. So I chose the MIT license that was the basis of that
community's code.
Later though, as cairo matured, and we realized it had much wider
scope than just an X library, I didn't feel constrained to choose the
MIT license for purpose of compatibility with X. So we floated the
idea of changing the license from MIT to to LGPL and that idea was
extremely well-received in the cairo community and ultimately
successful. Here's the thread that started it for interest:
[Cairo] Possible license change: MIT -> LGPL
http://lists.freedesktop.org/archives/cairo/2003-November/000737.html
> Sometimes I just
> want to rip out a small algorithm from a library and insert it into
> mpl, without having to bring in the entire library as a dependency.
> Unless I want my code to be LGPL, I can't do that.
There are some ironies in free software licensing decisions. You can
choose an MIT/BSD license in order to have the widest possible "fan
out", (that is, the number of projects that can take your code), but
that might also limit your "fan in", (the number of projects from
which you can accept code into your project).
So you're suffering from "limited fan-in" I would say due to having
chosen a BSD-ish license but wanting to benefit from other LGPL code.
-Carl
pgplsV8awjdq4.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
