On Thu, 5 Jul 2007 14:46:13 -0500, "John Hunter" wrote: > 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
pgpMpzIIXaA9C.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
