sympy and a derived work
Hi, I was recently at a Sage workshop, some of my notes here: http://ondrejcertik.blogspot.com/2007/11/sage-days-6.html and there we also discussed sympy and ginac and licensing issues and we came to the conclusion, that just by copying a C++ code to Python (by hand) is a derived work. That's what I did at the beginning - I used the same class structure and copied some of the algorithms from ginac. Ginac is GPL and sympy used to be too, so far so good. But then, we decided to use BSD, because it's more free and we think it's just better for sympy. However, we now changed almost everything in sympy, just the class structure stayed - but I mean - it's just a class structure (even that is not 100% the same, we don't use ex for example). So I wanted to clarify with you, if it's ok, if we use BSD for sympy. Thanks, Ondrej
Hello! On Tue, Jan 01, 2008 at 02:24:33PM +0100, Ondrej Certik wrote:
and there we also discussed sympy and ginac and licensing issues and we came to the conclusion, that just by copying a C++ code to Python (by hand) is a derived work.
Disclaimer: IANAL, you should consult a lawyer to get a definitive answer. AFAIK, looking at the code and re-implementing the algorithm counts as a reverse engineering (GPL does NOT forbid it), and it does not make your code a derived work. Moreover, the algorithms in question are described in virtually any textbook on the symbolic computations. So, I think it is OK to use whatever license you like. That said, I don't think BSD one is a good choice (it will certainly distract some potential contributors), but that's a matter of my personal preferences.
we decided to use BSD, because it's more free ^^^^^^^^^^^^^^^^^^^^^^ Could you please refrain from claims like this? Pretty *please*.
Best regards, Alexei -- All science is either physics or stamp collecting.
On Jan 1, 2008 5:44 PM, Alexei Sheplyakov <varg@theor.jinr.ru> wrote:
Hello!
On Tue, Jan 01, 2008 at 02:24:33PM +0100, Ondrej Certik wrote:
and there we also discussed sympy and ginac and licensing issues and we came to the conclusion, that just by copying a C++ code to Python (by hand) is a derived work.
Disclaimer: IANAL, you should consult a lawyer to get a definitive answer.
AFAIK, looking at the code and re-implementing the algorithm counts as a reverse engineering (GPL does NOT forbid it), and it does not make your code a derived work. Moreover, the algorithms in question are described in virtually any textbook on the symbolic computations. So, I think it is OK
We discussed that pretty thoroughly at the Sage workshop - and I think when you look at a code and translate it line to line to another language, it's a derived work. But anyway, I just wanted a confirmation, that you are ok with this. (I think now, SymPy is not derived work anymore, but it used to be).
to use whatever license you like. That said, I don't think BSD one is a good choice (it will certainly distract some potential contributors), but that's a matter of my personal preferences.
It will distract some but bring some other ones. For example if you look into the sympy mailinglist, you will see that some people find ginac to restrictive, that it's GPL. On the other hand, I also don't like, that Mathematica, a non-free program, is using GMP, while giving nothing back.
we decided to use BSD, because it's more free ^^^^^^^^^^^^^^^^^^^^^^ Could you please refrain from claims like this? Pretty *please*.
Sorry about that, I should have written: we decided to use BSD, because we arrived at a consenus, that BSD is more free (but other people may think otherwise). Is that ok? :) Ondrej
On Tue, Jan 01, 2008 at 07:29:23PM +0100, Ondrej Certik wrote:
But anyway, I just wanted a confirmation, that you are ok with this.
_I_ am OK with this. Let's see what other developers and contributors think.
That said, I don't think BSD one is a good choice (it will certainly distract some potential contributors), but that's a matter of my personal preferences.
It will distract some but bring some other ones. For example if you look into the sympy mailinglist, you will see that some people find ginac to restrictive, that it's GPL.
GPL forbids one to take away the freedom. Some people happen to dislike that, but I like this "restriction" *very* much.
On the other hand, I also don't like, that Mathematica, a non-free program, is using GMP, while giving nothing back.
So release your code under a (more) restrictive license. :)
we decided to use BSD, because it's more free ^^^^^^^^^^^^^^^^^^^^^^ Could you please refrain from claims like this? Pretty *please*.
Sorry about that, I should have written:
we decided to use BSD, because we arrived at a consenus, that BSD is more free (but other people may think otherwise).
Is that ok? :)
Almost, although "we decied to use BSD" would be even better, as it's more informative and does not provoke yet another "BSD versus GPL" flamewar :) Best regards, Alexei -- All science is either physics or stamp collecting.
GPL forbids one to take away the freedom. Some people happen to dislike that, but I like this "restriction" *very* much.
I used to think the same. But I changed my mind, especially with the GPL2 vs 3 incompatibility. GPL is probably better for endusers of a program, but as to freedom for developers, BSD (I am talking about the modified BSD) is imho more free, because you can use BSD code in ginac or in any other opensource (and even closed-source) code. There are codes that are GPL 2 only and there are codes that are GPL 3 only and you cannot mix them. You can however mix a BSD code in both of them. Ginac solves this issue by being GPL 2, or at your option, any later version. But that's something that I don't like at all - putting the software under the license, that the user can optionally choose (from any license that FSF, produces, even if I didn't agree with some new license of FSF). I like clear terms. Like GPL 2. Or GPL 3. or BSD. It's a serious problem, for project like Sage (sagemath.org), that combines a lot of opensource codes, some GPL2, some GPL3, and Sage cannot legally combine them, so FSF basically works against Sage, instead of for Sage. And that's bad. Read this: http://groups.google.com/group/sage-devel/browse_thread/thread/3ab61a6dbaa2f...
On the other hand, I also don't like, that Mathematica, a non-free program, is using GMP, while giving nothing back.
So release your code under a (more) restrictive license. :)
we decided to use BSD, because it's more free ^^^^^^^^^^^^^^^^^^^^^^ Could you please refrain from claims like this? Pretty *please*.
Sorry about that, I should have written:
we decided to use BSD, because we arrived at a consenus, that BSD is more free (but other people may think otherwise).
Is that ok? :)
Almost, although "we decied to use BSD" would be even better, as it's more informative and does not provoke yet another "BSD versus GPL" flamewar :)
I know that you are afraid of having a flamewar, and thus you try not to touch this issue. :) But I am not afraid - flamewar happens if one cannot discuss. But we are just stating each other's opinions, and that's not a flamewar. http://en.wikipedia.org/wiki/Flame_war I think things and especially things like this should be discussed. Rationally. Ondrej
On Tue, Jan 01, 2008 at 09:29:25PM +0100, Ondrej Certik wrote:
I know that you are afraid of having a flamewar and thus you try not to touch this issue. :) But I am not afraid - flamewar happens if one cannot discuss.
In mathematics different axiomatics give rise to (completely) different theorems (cf. Euclidean geometry versus Lobachevskian one). Arguing how to prove some theorem within particular axiomatics is a discussion. Arguing which axiomatics is "better" is a flamewar.
But we are just stating each other's opinions, and that's not a flamewar.
I'm afraid it *is* a flamewar, since we are discussing definition of freedom. It's even worse than discussing different axiomatics, since the notion of freedom is inherently subjective.
I think things and especially things like this should be discussed. Rationally.
Could you *please* find another mailing list for "BSD versus GPL" flamewars? Or add [BSD-versus-GPL-flame] to a subject, so I can easily redirect those mails to /dev/null. Best regards, Alexei -- All science is either physics or stamp collecting.
Hello! On Tue, Jan 01, 2008 at 02:24:33PM +0100, Ondrej Certik wrote:
I was recently at a Sage workshop, some of my notes here:
I've got some comments regarding SymPy and sage, I post them here (as 'Post a Comment' function on that page does not seem to work properly). I hope this is not off topic on the GiNaC list.
SAGE wraps Maxima, because Maxima is quite fast, very well tested, so it works well.
Although the algorithms implemented in Maxima are quite good, Maxima is dog slow and unreasonably memory-hungry. That stems from awful memory management facilities of the underlying LISP system (GCL). Unfortunately, Maxima maintainers ignore these issues. So people who need to get their calculations done were forced to write their own tools (GiNaC being one of them).
It's difficult to extend
That's not quite true. Maxima is just a custom LISP system (roughly, a LISP library), so it is possible to extend it either with LISP, or (via foreign function interface) with virtually any programming lagnuage.
and written in LISP and that's very bad.
Actually, that's very GOOD. One can concentrate on the problem being solved instead of learning (the lastest version of) some programming language which happens to be popular today.
it's in Python,
Life is to short to learn every (ill-designed) programming language out of there. Especially if existing programming languages (LISP/FORTRAN/C) cover every task in a CAS (and not only CAS) programming. It's very sad that people keep reinventing the wheel (or rather, rewriting it in their pet programming languages) instead of improving existing tools.
but currently slower than Maxima
Ouch!
rewriting parts of SymPy using Cython, or even C directly,
So, you've reimplemented GiNaC in Python, and now reimplementing that in C? This sounds like reinventing the wheel, doesn't it? And what's the point of that (leaving aside having fun :)? Best regards, Alexei -- All science is either physics or stamp collecting.
On Jan 1, 2008 6:04 PM, Alexei Sheplyakov <varg@theor.jinr.ru> wrote:
Hello!
On Tue, Jan 01, 2008 at 02:24:33PM +0100, Ondrej Certik wrote:
I was recently at a Sage workshop, some of my notes here:
I've got some comments regarding SymPy and sage, I post them here (as 'Post a Comment' function on that page does not seem to work properly). I hope this is not off topic on the GiNaC list.
SAGE wraps Maxima, because Maxima is quite fast, very well tested, so it works well.
Although the algorithms implemented in Maxima are quite good, Maxima is dog slow and unreasonably memory-hungry. That stems from awful memory management facilities of the underlying LISP system (GCL). Unfortunately, Maxima maintainers ignore these issues. So people who need to get their calculations done were forced to write their own tools (GiNaC being one of them).
It's difficult to extend
That's not quite true. Maxima is just a custom LISP system (roughly, a LISP library), so it is possible to extend it either with LISP, or (via foreign function interface) with virtually any programming lagnuage.
and written in LISP and that's very bad.
Actually, that's very GOOD. One can concentrate on the problem being solved instead of learning (the lastest version of) some programming language which happens to be popular today.
it's in Python,
Life is to short to learn every (ill-designed) programming language out of there. Especially if existing programming languages (LISP/FORTRAN/C) cover every task in a CAS (and not only CAS) programming. It's very sad that people keep reinventing the wheel (or rather, rewriting it in their pet programming languages) instead of improving existing tools.
but currently slower than Maxima
Ouch!
rewriting parts of SymPy using Cython, or even C directly,
So, you've reimplemented GiNaC in Python, and now reimplementing that in C? This sounds like reinventing the wheel, doesn't it? And what's the point of that (leaving aside having fun :)?
Fun is an important part. But the main reason is to have fast CAS in python. I am one of the authors of swiginac (so that we use the wheel, instead of reinventing it), but that's not the way. As to speed, we are improving. As shown here for example: http://groups.google.com/group/sympycore/browse_thread/thread/8062076c7bc880... we now have a prototype of a code, that is pure Python, but 2.5x to 5x faster than Maxima. And on some tests around 4x slower, thatn swiginac. Then rewriting some parts to C, we should (at least we believe) get comparable speeds as swiginac. Ondrej
Hello! On Thu, Jan 03, 2008 at 03:14:28PM +0100, Ondrej Certik wrote:
Fun is an important part. But the main reason is to have fast CAS in python. I am one of the authors of swiginac (so that we use the wheel, instead of reinventing it), but that's not the way. As to speed, we are improving. As shown here for example:
http://groups.google.com/group/sympycore/browse_thread/thread/8062076c7bc880...
Which LISP did you use to compile Maxima? How many times did you repeat the test? (for some bizzare reason the first call to virtually any function is much slower than subsequent ones). What's about more "interesting" operations, such as gcd(), evalf(), pattern matching? Best regards, Alexei -- All science is either physics or stamp collecting.
On Jan 4, 2008 12:34 PM, Alexei Sheplyakov <varg@theor.jinr.ru> wrote:
Hello!
On Thu, Jan 03, 2008 at 03:14:28PM +0100, Ondrej Certik wrote:
Fun is an important part. But the main reason is to have fast CAS in python. I am one of the authors of swiginac (so that we use the wheel, instead of reinventing it), but that's not the way. As to speed, we are improving. As shown here for example:
http://groups.google.com/group/sympycore/browse_thread/thread/8062076c7bc880...
Which LISP did you use to compile Maxima? How many times did you repeat the test? (for some bizzare reason the first call to virtually any function is much slower than subsequent ones). What's about more "interesting" operations, such as gcd(), evalf(), pattern matching?
Right, the LISP was the problem. I wrote about it here: http://ondrejcertik.blogspot.com/2008/01/sympysympycore-pure-python-up-to-5x... We didn't try much else. It is just a taste of the speed. Ondrej
Dear Ondrej, Ondrej Certik wrote:
I was recently at a Sage workshop, some of my notes here:
http://ondrejcertik.blogspot.com/2007/11/sage-days-6.html
and there we also discussed sympy and ginac and licensing issues and we came to the conclusion, that just by copying a C++ code to Python (by hand) is a derived work. That's what I did at the beginning - I used the same class structure and copied some of the algorithms from ginac. Ginac is GPL and sympy used to be too, so far so good. But then, we decided to use BSD, because it's more free and we think it's just better for sympy.
Good heavens. Let's not try to quantify this "free" thing too much, please. At the ICMS'2006 in Spain, someone started exactly the same discussion at the end of my talk about CLN: Some people really do believe that if you put your software under a BSD, LGPL, or MIT style license, then the entire closed-source software industry will miraculously be turned into saints and start helping your project by contributing code, doing the debugging for you, organizing events, giving you free lunch, etc. That is just so naive. At the ICMS'2006, the GMP (LGPL) developer explained in response, how much feedback he ever got back from Wolfram Research who ship libgmp with Mathematica: absolutely no feedback. Zero, vacuum, null, rien, nada, nix. There was a Wolfram employee in the room then, and I don't really know if the situation has changed since but I wouldn't bet it has. Oh, and interestingly, at the end of the old argument why CLisp is GPL you'll find someone foreseeing this problem with GMP: <http://cl-debian.alioth.debian.org/repository/pvaneynd/bzr-moved/clisp/doc/Why-CLISP-is-under-GPL> (CLN wasn't around at that time. But it borrows enough code from CLisp so that this argument applies to it, too. In the end, it's not far-fetched to argue that this decision set the course for GiNaC's license.) If you pick another license, that's fine. But, please, be careful not to offend other open-source developers who, by choice or by necessity, made a different pick.
However, we now changed almost everything in sympy, just the class structure stayed - but I mean - it's just a class structure (even that is not 100% the same, we don't use ex for example).
So I wanted to clarify with you, if it's ok, if we use BSD for sympy.
Ondrej, you're going to have fun if you are seriously bringing this up. IANAL, but you are obviously raising two questions: Is SymPy derived work of GiNaC? Personally, I do not know or care (but don't know about other contributor.) If *you* think it is, then, you must now clarify the situation with the copyright holder for GiNaC. According to the source files, that would be the University of Mainz, Germany. Please, do keep us posted about what comes out from the discussion with their lawyers, okay? Because I don't think they are reading this list. ;-) Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Dear Richy,
Good heavens. Let's not try to quantify this "free" thing too much, please. At the ICMS'2006 in Spain, someone started exactly the same discussion at the end of my talk about CLN: Some people really do believe that if you put your software under a BSD, LGPL, or MIT style license, then the entire closed-source software industry will miraculously be turned into saints and start helping your project by contributing code, doing the debugging for you, organizing events, giving you free lunch, etc.
I don't belong among people believing in that. One should use GPL, or some other copylefted license for that.
That is just so naive. At the ICMS'2006, the GMP (LGPL) developer explained in response, how much feedback he ever got back from Wolfram Research who ship libgmp with Mathematica: absolutely no feedback. Zero, vacuum, null, rien, nada, nix. There was a Wolfram employee in the room then, and I don't really know if the situation has changed since but I wouldn't bet it has.
Yep. One shouldn't blame Wolfram for that though, but those who made GMP LGPL and now cry (if they cry).
Oh, and interestingly, at the end of the old argument why CLisp is GPL you'll find someone foreseeing this problem with GMP: <http://cl-debian.alioth.debian.org/repository/pvaneynd/bzr-moved/clisp/doc/Why-CLISP-is-under-GPL> (CLN wasn't around at that time. But it borrows enough code from CLisp so that this argument applies to it, too. In the end, it's not far-fetched to argue that this decision set the course for GiNaC's license.)
Right.
If you pick another license, that's fine. But, please, be careful not to offend other open-source developers who, by choice or by necessity, made a different pick.
I am sorry if I offended you.
However, we now changed almost everything in sympy, just the class structure stayed - but I mean - it's just a class structure (even that is not 100% the same, we don't use ex for example).
So I wanted to clarify with you, if it's ok, if we use BSD for sympy.
Ondrej, you're going to have fun if you are seriously bringing this up.
IANAL, but you are obviously raising two questions: Is SymPy derived work of GiNaC? Personally, I do not know or care (but don't know about other contributor.) If *you* think it is, then, you must now clarify the situation with the copyright holder for GiNaC. According to the source files, that would be the University of Mainz, Germany. Please, do keep us posted about what comes out from the discussion with their lawyers, okay? Because I don't think they are reading this list. ;-)
I personally don't think SymPy is a derived work, so I am not going to do any actions. I however respect copyrights and licenses, but I am not a lawyer and I don't intend to become a lawyer, so I have just brought it to your attention, since you or other GiNaC developers may have other opinion on this than I do. Ondrej
participants (3)
-
Alexei Sheplyakov
-
Ondrej Certik
-
Richard B. Kreckel