The postscript backend as it stands is in good shape, and is full
featured (Darren can tell you how much work he has put into supporting
and enhancing the latex support). The last major issue with it is the
font size issue, and with your help a solution is on the horizon. So
it is definitely a good use of time to fix this last bit. It doesn't
sound like your "option 2" is a ton of work, but correct me if I'm
wrong.
For what it's worth, I think I'd be inclined to agree with you
there. If your existing code is working just fine, then switching to
cairo is just more work. But if you do start having to do any serious
maintenance, then you might want to reconsider.
http://www.scipy.org/License_Compatibility
Thanks, John, for sharing this essay. Please allow me to respond to a
few points:
In my experience, the benefits of collaborating with the
private sector are real, whereas the fear that some private
company will "steal" your product and sell it in a proprietary
application leaving you with nothing is not.
In my experience, there is real harm that can come when proprietary
modifications to a license made available under a permissive license
are not contributed back. An extremely clear case is that of the X
Window System which went through a period of several independent
software vendors trying to out-compete each other on their own
proprietary modifications to the system, (resulting in the near death
of the system altogether).
I've had some discussions with Jim Gettys about that process and how
the MIT license for X has played out over the years. You argue that a
project most needs the extra users provided by a permissive license
during its formative years until it reaches critical mass and the
network effects kick in. Jim actually argues the point differently and
says that the extra protections of the GPL are most necessary during
the formative period, but not at all needed once the project reaches
critical mass. So I've heard him express that he wishes there were a
way to allow a project to grow under the GPL and then change to
something like the MIT license once it reaches critical
mass.
There is a lot of GPL code in the world, and it is a constant
reality in the development of matplotlib that when we want to
reuse some algorithm, we have to go on a hunt for a non-GPL
version.
So that's a cost that you need to weigh against the decision to not be
able to accept any GPL code into your project. But I think the fact
that there _is_ a lot of GPL code in the world is a strong argument
against your original thesis that a license more permissible than the
GPL is necessary to bootstrap a free software project to critical
mass. There _is_ a lot of GPL code, which means there _are_ a lot of
users of that code, and a lot of those users are businesses that don't
have a problem using, (and modifying, and contributing back to), GPL
code.
There are two unpalatable options. 1) Go with GPL and lose the
mind-share of the private sector 2) Forgo GPL code and retain
the contribution of the private sector.
You've chosen (2) along with a decision to try to campaign authors of
GPL code to relicense their code as BSD/MIT (ish) whenever you want to
use it. I would guess you'll find that quite difficult in many cases,
(I don't agree that the GPL is most often chosen without intention
just because it is "famous").
I think an easier route to take path (2) is to use the LGPL for your
library, and then only have to convince authors to re-license the
subset of their GPL application code as LGPL that you're actually
interested in incorporating into your library. I would predict that
you will be more successful at that more often than convincing people
to relicense GPL to BSD/MIT (ish).
You only bring the LGPL up at the end of your essay as almost an
afterthought and dismiss it with a very vague, "but many companies are
still loath to use it out of legal concerns". Do you have actual
evidence to point to for that?
It would be simpler if there were direct experiments we could run to
measure some of these things, but there aren't, (and conditions do
continue to change). My experience with the cairo project suggests
that we've been able to achieve a very successful library
implementation, (with plenty of "corporate" contribution), with an
LGPL (and MPL) license.
This is a very tough decision because their is a lot of very
high quality software that is GPL and we need to use it;
Network effects are strong---when they're good, don't fight them. 
And I've even been annoyed enough with having to get code relicensed
from GPL to LGPL+MPL for use in cairo that I'm thinking the next
library I invent might be simply GPL from the beginning.
Which brings me to my final point. I think it's very interesting (and
worthwhile) to debate license decisions like this. But at the end of
the day, when a project chooses a free software license, and that
project becomes at all "established" it's probably rarely a good idea
to change that license. I just don't think that it's right to engage a
community with one set of ground rules, and then to go and change
those rules out from under the community.
So, even if the current license from matplotlib would allow you to
easily change from it to the LGPL (which I think it does), I wouldn't
make any argument that you should think of changing the project
license.
don't think it is supported in cairo. So I am not sure where these
rasters are coming from, unless cairo is converting all text to
rasters.
Definitely not converting all text to raster, (unless someone's using
an ancient version of cairo).
-Carl
···
On Thu, 5 Jul 2007 14:46:13 -0500, "John Hunter" wrote:
