Permission to steal

[Imam Tashdid ul Alam]

Hello all,

Recent sympy user here. Need advice on license issues. I am thinking of writing a library with much in common with sympy but the plan is nowhere near complete at the moment.

What I would like to know more about is the implications of sympy license. I am thinking of indiscriminately copying the sympy codebase when and where I need it. If I read the license correctly, that should be fine if I license my code under BSD as well. But the problem is, I think I like GPL more for my purpose. I do not understand the subtlety involved in deciding between GPLv2 and GPLv3, but let's say I go for GLPv3.

Wikipedia (https://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing) seems to suggest that it is okay for me to release my code under GPLv3 (since sympy is BSD-3), but I would appreciate guidance regarding where not to go overboard with this. For the sake of argument, can I just fork sympy and just change the license to GPLv3? Does not seem quite right to me.

Also, acknowledgements. Let's say I appropriate a sizable part of sympy (as I intend to). And maybe I have a file called AUTHORS. I think BSD-3 says that I do not put the names in AUTHORS in the sympy tree in it. I will of course acknowledge the heavy reliance on sympy in the documentation and elsewhere, but is there anything more I should do to give credit to individuals?

End of questions. Just a bit more on what I am trying to do just in case. I am not currently interested in all the sympy modules but just the core. My primary goal I think is to experiment with a more simplified representation of expressions at the expense of usability so that I can provide more control over the generation of LaTeX code.

Thanks in advance and thanks for this awesome program.

[Ondřej Čertík]

Hi Imam,

On Sun, Feb 7, 2016 at 11:28 PM, Imam Tashdid ul Alam
<imam...@gmail.com> wrote:
> Hello all,
>
> Recent sympy user here. Need advice on license issues. I am thinking of
> writing a library with much in common with sympy but the plan is nowhere
> near complete at the moment.
> What I would like to know more about is the implications of sympy license. I
> am thinking of indiscriminately copying the sympy codebase when and where I
> need it. If I read the license correctly, that should be fine if I license
> my code under BSD as well. But the problem is, I think I like GPL more for
> my purpose. I do not understand the subtlety involved in deciding between
> GPLv2 and GPLv3, but let's say I go for GLPv3.
>
> Wikipedia
> (https://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing)
> seems to suggest that it is okay for me to release my code under GPLv3
> (since sympy is BSD-3), but I would appreciate guidance regarding where not
> to go overboard with this. For the sake of argument, can I just fork sympy
> and just change the license to GPLv3? Does not seem quite right to me.

Yes, my understanding is that you can do that, i.e. that you can take
parts of SymPy, optionally add your own stuff, package it, and use any
license you want to distribute it. Let's say you only sell binaries
using some commercial license. Then all you have to do is to put the
SymPy's BSD license somewhere in documentation. If you want to use GPL
and distribute the sources, then you can do that as well (as long as
you copy the BSD license somewhere), at least that is my
understanding.

You can look at the Linux kernel how they do that, since the kernel as
a whole is GPL2 licensed, but they also include some code that was
originally BSD licensed.

>
> Also, acknowledgements. Let's say I appropriate a sizable part of sympy (as
> I intend to). And maybe I have a file called AUTHORS. I think BSD-3 says
> that I do not put the names in AUTHORS in the sympy tree in it. I will of
> course acknowledge the heavy reliance on sympy in the documentation and
> elsewhere, but is there anything more I should do to give credit to
> individuals?

You only have to copy the BSD license. You do not need to copy the AUTHORS file.

>
> End of questions. Just a bit more on what I am trying to do just in case. I
> am not currently interested in all the sympy modules but just the core. My
> primary goal I think is to experiment with a more simplified representation
> of expressions at the expense of usability so that I can provide more
> control over the generation of LaTeX code.
>
> Thanks in advance and thanks for this awesome program.

I am glad you found SymPy useful. If you implement some new things
that you think would be useful for SymPy itself, we are always
interested in getting a pull request.

Ondrej

[Imam Tashdid ul Alam]

Hi Ondrej,

Thanks for your reply. An interesting discussion (http://opensource.stackexchange.com/questions/304/can-i-take-bsd-licensed-code-and-distribute-it-under-gpl) also pointed me to the linux kernel case. I looked at the source tree on Github. The top-level COPYING says nothing about the BSD license issue but files inside the tree contain it.

So I am back to square one. Seems like the right thing to do is to mark the code that I take from sympy with the BSD license. Only if I modify it enough should I be able to call it mine and dispense with the BSD license. Reminds me of Sorites paradox (https://en.wikipedia.org/wiki/Sorites_paradox). Who knew contributing to libre software has its own riddles.

But since I have your attention for the moment, do you have any suggestions about rewriting the core? Is there a set of design choices you wish someone would explore? I like it that the expression-tree is immutable. Would you recommend following a lens-based approach (https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial) to manipulate it? My main goal is to make both the expression-tree and the allowed transformations serializable so that people can share math bits over the internet. Pointers and caveat about potential dangers will be very much appreciated.

Again, thanks for sympy. I wish it was more popular among physicists. As an aside, I am also currently enjoying your ongoing theoretical physics book. Forgive me if I am mistaken and that's not you. If you are, I will be very happy to contribute to the book. And of course, I intend to contribute to sympy if I can as well. 

[Ondřej Čertík]

Hi Imam,

On Mon, Feb 8, 2016 at 9:08 AM, Imam Tashdid ul Alam
<imam...@gmail.com> wrote:
> Hi Ondrej,
>
> Thanks for your reply. An interesting discussion
> (http://opensource.stackexchange.com/questions/304/can-i-take-bsd-licensed-code-and-distribute-it-under-gpl)
> also pointed me to the linux kernel case. I looked at the source tree on
> Github. The top-level COPYING says nothing about the BSD license issue but
> files inside the tree contain it.
>
> So I am back to square one. Seems like the right thing to do is to mark the
> code that I take from sympy with the BSD license. Only if I modify it enough
> should I be able to call it mine and dispense with the BSD license. Reminds
> me of Sorites paradox (https://en.wikipedia.org/wiki/Sorites_paradox). Who
> knew contributing to libre software has its own riddles.

I think it's actually pretty simple. In the case of SymPy, people who
contributed the individual patches (see the git history) own the
copyright to them, and they give SymPy a copyright license to use the
code under the SymPy's BSD license. That BSD license allows you to
take the code and distribute under your own terms, say, under the GPL
license. You copy the SymPy's BSD license somewhere in the code or
documentation. So people who you distribute the code to must follow
the GPL license, and if those people distribute the code further, they
need to follow GPL, and they still need to keep the copy of the
SymPy's BSD license somewhere in the documentation or code.

Regarding when you can call it yours, it depends on what you mean by
"yours". If by "yours" you mean when you'll have the rights to license
the code to the people you distribute it to under your own terms, then
you have this right already (as given by the BSD license), so it is
already "yours". If by "yours" you mean when you'll own the copyright
of the code, then the answer is never, unless you get the copyright
transfer from all the authors of SymPy.

The rule of thumb is that you should never transfer the copyright of
code that you contribute to open source, you should keep it. (You must
give the project a copyright license of course to use it under their
license.) One exception is the FSF, e.g. if you contribute a patch to
gcc, you transfer your copyright to FSF, and they give back to you a
copyright license to use the code --- but then I think legally you
can't take the code that you contributed, and give somebody else a
copyright license, since you don't own the copyright to your own code.

I could be wrong on any of the above, but that's my understanding how
licensing works.

>
> But since I have your attention for the moment, do you have any suggestions
> about rewriting the core? Is there a set of design choices you wish someone
> would explore? I like it that the expression-tree is immutable. Would you

I have some ideas regarding speed, and I essentially implemented most
of them into SymEngine (https://github.com/symengine/symengine), we
are still exploring a few more ideas. But that design proved very fast
already.

> recommend following a lens-based approach
> (https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial)
> to manipulate it? My main goal is to make both the expression-tree and the

I quickly read through the tutorial, but I don't understand what the
"lense" are good for, I would need to spend more time with it. So I
don't have any opinion on that.

> allowed transformations serializable so that people can share math bits over
> the internet. Pointers and caveat about potential dangers will be very much
> appreciated.

Yes, being able to serialize an expression is essential. In SymPy, you
can print it to a file and load it, or you can use Python's pickle,
which is a lot faster, but then the file is not human readable.

>
> Again, thanks for sympy. I wish it was more popular among physicists. As an
> aside, I am also currently enjoying your ongoing theoretical physics book.
> Forgive me if I am mistaken and that's not you. If you are, I will be very

If you are talking about this book:
http://www.theoretical-physics.net/, then yes, that's me. I am glad
you found it useful.

> happy to contribute to the book. And of course, I intend to contribute to
> sympy if I can as well.

Definitely, looking forward to both.

Ondrej

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/a6b05082-fa66-4733-bbec-09eb78d1eddf%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Aaron Meurer]

First off, I recommend just reading the license. Especially the BSD license, which is very simple. That will tell you exactly what you can do.

The basic idea is this: there are two main licenses, BSD and GPL. If code is licensed BSD (like SymPy), then you can use it absolutely however you want. You can modify the code, relicense it (say, under GPL), even take it and sell it without making it open source. There are no restrictions. You have, essentially, permission to steal. The only requirements (which are outlined in the license) are that you distribute the copyright notice (effectively, letting people know that you did indeed use the SymPy code).

For GPL, you can only use the code if your code is also GPL, meaning it has to be open source (the GPL has stipulations that require that the source code be made available). So for example, for Linux, I can fork it and make my own kernel based off it, but if I distribute it, I have to distribute the source code as well, and make that GPL.  An important additional constraint is that if you have a GPL compiled library, you can't link against it without also being GPL (the LGPL removes this restriction).

Now, an important point here is that because GPL code has to stay GPL, you can't take GPL code and integrate it into a BSD open source project. This, for instance, if you were to fork SymPy and make it GPL, you could continue to take code from SymPy, but SymPY could not take code from your project (unless you also agreed to relicense those specific code bits as BSD, but at that point you might as well just license the whole thing as BSD and make everyone's life easier). 

This is the primary reason why I prefer BSD and recommend everyone to use it. 

If you prefer philosophy, the philosophy of the GPL is outlined at https://www.gnu.org/philosophy/pragmatic.en.html and the philosophy of the BSD is outlined at http://copyfree.org/ (that's a bit of a misnomer, though. The BSD itself doesn't really come endowed with a philosophy like the GPL does, but, at least for me, the copyfree standard indicates how and why BSD-style licenses are to be preferred). 

The third aspect is the social/pragmatic side. Some people won't touch GPL code. Others avoid BSD (there are more people in the former camp in my experience). Many businesses have paranoid lawyers who (correctly or not) avoid using anything GPLed at all. 

If you are going to integrate into an ecosystem, it's best to match the license of that ecosystem.  For example, the scientific Python ecosystem is almost all BSD. A GPL scientific Python library would be frowned upon by a large portion of the community because it would be impossible to integrate code from it into other scientific Python libraries. Also a large portion of the community prefers the philosophy behind the BSD license, see http://www.astrobetter.com/blog/2014/03/10/the-whys-and-hows-of-licensing-scientific-code/ and http://nipy.sourceforge.net/nipy/devel/faq/johns_bsd_pitch.html.

Aaron Meurer

--

You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.