Hi Nicolas,
On Mon, Jan 25, 2010 at 2:46 AM, Nicolas Rougier
<Nic...@lo...> wrote:
>
>
> Hello,
>
> This is an update about glumpy, a fast-OpenGL based numpy visualization.
> I modified the code such that the only dependencies are PyOpenGL and
> IPython (for interactive sessions). You will also need matplotlib and
> scipy for some demos.
>
> Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
> No installation required, you can run all demos inplace.
>
> Homepage: http://code.google.com/p/glumpy/
This is great, and it would be very cool to have it updated to the new
code we're now landing in ipython with a much cleaner internal API
(finally :) Have you had a chance to look at the code in my trunk-dev
branch?
https://code.launchpad.net/~fdo.perez/ipython/trunk-dev
Brian finished a large review of it and we just had a chance to go
over his feedback directly, so there's now one more round of reviews
to do (once he applies the changes from our discussion) and this
should become trunk very soon. The apis are much cleaner, this is the
big cleanup I told you about last year, and now we're getting to the
point where having multiple ipython frontends is a very realistic
prospect.
Unfortunately we won't be able to use your code directly in IPython as
it stands, since the GPL provisions in it would require us to GPL all
of IPython to make use of any of it directly in IPython. Your code
uses iptyhon, numpy, matplotlib and scipy (in some demos), which
amounts to hundreds of thousands of lines of code; here are the
sloccount outputs from their respective trunks:
IPython
Totals grouped by language (dominant language first):
python: 47357 (99.24%)
lisp: 262 (0.55%)
sh: 62 (0.13%)
objc: 37 (0.08%)
Numpy
Totals grouped by language (dominant language first):
ansic: 152950 (67.19%)
python: 73188 (32.15%)
cpp: 828 (0.36%)
fortran: 298 (0.13%)
sh: 156 (0.07%)
pascal: 120 (0.05%)
f90: 97 (0.04%)
Matplotlib
Totals grouped by language (dominant language first):
python: 83290 (52.64%)
cpp: 68212 (43.11%)
objc: 4517 (2.85%)
ansic: 2149 (1.36%)
sh: 69 (0.04%)
Scipy
Totals grouped by language (dominant language first):
cpp: 220149 (48.35%)
fortran: 87240 (19.16%)
python: 79164 (17.38%)
ansic: 68746 (15.10%)
sh: 61 (0.01%)
Glumpy:
Totals grouped by language (dominant language first):
python: 3751 (100.00%)
We're looking at ~300.000 lines of python alone in these tools. It's
unfortunately not realistic for us to consider GPL-ing them in order
to incorporate glumpy into the core set; it would be fantastic if you
were willing to consider licensing your code under a license that is
compatible with the body of work you are building on top of.
You are obviously free to choose your license as you see fit, and end
users (myself included) will be always able to use glumpy along with
ipython, numpy, matplotlib and scipy. So *users* get all of the
benefit of your contribution, and for that I am the first to be
delighted and grateful that you've put your code out there.
But as it stands, your code builds on close to half a million lines of
other code which can not benefit back from your contributions. If you
consider licensing glumpy to be compatible with ipython, numpy and
matplotlib, it would be possible to incorporate your ideas back into
those projects: perhaps in some places the right solution would be to
fix our own designs to better provide what glumpy needs, in other
cases we may find fixes you've made fit better upstream, etc.
But this kind of collaboration will not be possible as long as glumpy
can benefit from our tools but our codes are not allowed to benefit
from glumpy (without changing licenses, which isn't going to happen).
I hope you consider this from our perspective and in the most friendly
and open manner: I completely respect your right to license your own
code as you see fit (I've seen people put out GPL 'projects' that
effectively consist of 3 lines that import IPython and make a function
call, and that's OK too, and allowed by the license I chose to use).
The only reason I ask you is because I think your tool is very
interesting, and it would ultimately lead to a much more productive
relationship with ipython, numpy and matplotlib if it could be a
collaboration instead of a one-way benefit.
Best regards,
Fernando.