On 7/5/07, Carl Worth <[EMAIL PROTECTED]> wrote: > Thanks, John, for sharing this essay. Please allow me to respond to a > few points:
Hey Carl -- thanks for the response. You have definitely made me reconsider some of my arguments, though my conclusion mostly remains intact. At the end of the day, it is a fact that almost all of the significant software for scientific computing in python is BSD compatible and GPL averse. This in part stems from the position of enthought, who make very substantial contributions to scientific computing in python (scipy, chaco, traits, envisage, tvtk, the annual conference...) and it is my understanding that they do need to release closed source applications built on top of their open source libraries. In the past I have had similar ambitions, and one day may again, so I too am GPL averse. I have no objection to proprietary, closed source software in the commercial domain as many in the free software world do, with the notable exception that I think scientific computing should be done with open source software. I wrote mpl as part of a suite of tools to replace proprietary EEG software (dongle and all) because work done with that software is only reproducible if you have the 50 thousand dollar dongle. There is a particular ideology with the free software foundation that all software must be free that many in the scientific computing community in python do not support. In this community, I think most people prefer open source software because they like to build their own tools, see what is going on under the hood, and fix it if it is broken. There is also the compelling argument, in principle though not in practice, that open algorithms and code is required by peer review. And as coding science geeks who might actually do something one day that will also pay off in dollar terms, I think many of us want to leave open the possibility of building a proprietary product built on these tools, and the GPL is somewhat incompatible with these ambitions. > 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"). Well, we certainly have had some success with it and we have had people respond, "you're right, I just picked it because it was the only thing I'd heard of". The target audience here is a grad student releasing some technical suite of algorithms that they happen to be world experts in -- they are more scientists than coders -- and are not nearly as deep into this world as we are. This is their first significant coding project and they want to share their algorithms, and often they release it as GPL. We pounce on them and say, "What about BSD, so it will play more nicely with scipy and friends?". And by and large that is successful. This is not a pitch aimed at mature projects with multiple contributors, where you are certainly right, getting a switch would be almost impossible. > 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? I think LGPL is a perfectly good license which satisfies most of my objections. 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. 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. 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. When I get some time, I'll update my essay, which was really just an email posted on the scipy site but is now an essay <wink>, and incorporate some of your other very good arguments as well. Thanks, JDH ------------------------------------------------------------------------- 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
