Request permission to use "SymPy" in SymPy Gamma fork

[Qijia Liu]

Dear SymPy Development Team,

I'm Qijia Liu (github.com/eagleoflqj), both SymPy user and contributor.

I'm in the final stage of porting SymPy Gamma from browser-server to browser-only, where server only provides static files. Moreover, there's also migration from jQuery to modern front end frameworks.

In a word, the project equals to SymPy Gamma + (Pyodide - GAE - django) + (Vue + Naive UI - jQuery).

I'll release source code in an OSI approved license, while keeping the files derived from SymPy Gamma their original license.

I'd like to use SymPy+another Greek letter to name this project, just like Wolfram Alpha and SymPy Gamma. The problem is, the 3-clause BSD License of SymPy Gamma says

"

Neither the name of the SymPy nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.

".

So I'm requesting a permission to name this project in that pattern.

Best,

Qijia Liu

[Aaron Meurer]

To sidestep the question a bit, would you be interested in
contributing this back to SymPy Gamma itself? We are very interested
in porting SymPy Gamma to pyiodide, as the GAE hosting costs for it
are starting to grow past what we can reasonably pay, but no one in
the SymPy core team really has the technical know-how or time to do
this. In fact, if we aren't able to do something about the current
state of SymPy Gamma soon, we may have to shut it down, as it is
costing too much.

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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/99a8a56e-4ff8-4ac2-9a9a-51ac79e12383n%40googlegroups.com.

[Qijia Liu]

There are something I'm not quite satisfied with the current state of SymPy Gamma:

1. As a SaaS project, the license it uses is too permissive. I totally understand this choice across all sympy community projects (every community has its own philosophy). But working in a company that uses open source intensively but makes no contribution, I feel sad and don't want it happen to this project. The license I choose is AGPLv3.

2. I'm not against telemetry, but I'm against proprietary Google Analysis being used in SymPy Gamma. The decision to add it to SymPy Gamma was made without any discussion/vote. At least, there should have been a "clean" master branch, while these kind of thing should be optional in another branch for production.

3. As a SymPy contributor, I totally respect the Code of conduct. But I just don't like any irrelevant political terms to be mixed with a pure-technology project.

I know my concerns conflict with the philosophy of SymPy community. Sorry about that. But the good thing is, the technology towards serverless is not too complicated. If you don't care outdated front end technology, replacing django with Pyodide is quite straightforward. If you also want to upgrade front end to use modern technology, Vue is easy to learn (I have zero front end knowledge 2 months ago and I learn by migrating SymPy Gamma). React is also a good choice.

Qijia Liu

[Aaron Meurer]

On Tue, Dec 14, 2021 at 9:05 PM Qijia Liu <liu...@pku.edu.cn> wrote:
>
>
> There are something I'm not quite satisfied with the current state of SymPy Gamma:
>
> 1. As a SaaS project, the license it uses is too permissive. I totally understand this choice across all sympy community projects (every community has its own philosophy). But working in a company that uses open source intensively but makes no contribution, I feel sad and don't want it happen to this project. The license I choose is AGPLv3.

Keeping the license the same as SymPy means it is easy to move code
from Gamma into SymPy itself if that becomes something that you'd want
to do.

In my experience, code that is licensed as AGPL doesn't get reused by
anyone. Most companies can't use it, but neither can most open source
projects. It typically ends up hurting open source projects more than
companies. In this case, it would hurt projects like SymPy and other
projects in the scientific ecosystem that might want to reuse the
code. In my opinion, the most important thing when choosing a license
is to keep the same license as used by the rest of the ecosystem. This
old blog post from the late John Hunter summarizes it well
http://nipy.sourceforge.net/software/license/johns_bsd_pitch.html#johns-bsd-pitch.

To put it another way, if you fork SymPy Gamma and release it under a
license that makes it impossible for us to reuse the code, then how is
that any different from the companies which you accuse of using open
source code without contributing back?

Also, if SymPy Gamma is converted to operate completely client-side,
would it even be a SaaS at that point? The entire thing would be a
static webpage which anyone could copy to their own site at no cost to
us.

> 2. I'm not against telemetry, but I'm against proprietary Google Analysis being used in SymPy Gamma. The decision to add it to SymPy Gamma was made without any discussion/vote. At least, there should have been a "clean" master branch, while these kind of thing should be optional in another branch for production.

I'm not opposed to removing Google Analytics or replacing it with
another provider. As it stands now I don't see any point in avoiding
Google for Gamma since it already runs on Google Cloud (which has its
own backend data collection), but if we move off of GAE it may make
sense to remove Google Analytics as well. FWIW we don't even really
use the telemetry, so I'm not sure why it was added.

I'm also not opposed to any reorganization of the Gamma code.

> 3. As a SymPy contributor, I totally respect the Code of conduct. But I just don't like any irrelevant political terms to be mixed with a pure-technology project.

I'm not really sure I understand the impression you have about our
code of conduct. I would consider political discussions to be off
topic in SymPy discussion forums, and most political discussions tend
to veer toward things that are against the CoC, which is a good reason
to avoid them. So I would say it opposes politics being mixed with the

project.

>
> I know my concerns conflict with the philosophy of SymPy community. Sorry about that. But the good thing is, the technology towards serverless is not too complicated. If you don't care outdated front end technology, replacing django with Pyodide is quite straightforward. If you also want to upgrade front end to use modern technology, Vue is easy to learn (I have zero front end knowledge 2 months ago and I learn by migrating SymPy Gamma). React is also a good choice.

I'm sure it is quite straightforward for someone like you who knows
what you are doing. But we in the SymPy core team do not know anything
about web development. You would really be doing the project a huge
benefit if you help us migrate it.

Even if it isn't too hard, I at least don't have time to do it. If
someone else wants to take this on, please let me know.

If you don't, and no one else does, we are going to shut it down,
because it is costing us ~$100 a month, and even ignoring costs we
don't have the ability to maintain it. I had planned to do this by the
end of the year but I didn't get around to it, but I am definitely
going to do so next month, unless you or someone steps up and helps us
migrate it to something cheaper.

Of course, no one can force you. I'll try to see if I can find a good
answer to your original question (about using the name "SymPy"). I'm
not completely clear about how that clause in the BSD license actually
works, nor what the best practices are about projects not directly
affiliated with the project (but using it) using its name. My initial
answer is that it would probably be fine, unless someone objects, so
long as you don't use the name to imply that the project is directly
affiliated with SymPy when it isn't.

Aaron Meurer

>
> Qijia Liu
>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/c050abfb-1ad7-45be-ba5b-add20f0ac071n%40googlegroups.com.

[Qijia Liu]

1. As I said, I'll keep code derived from SymPy Gamma BSD licensed. To be more specific, all python code under logic directory, factordiagram.js, plot.js (and CSS, if anyone cares). So there will be no barrier for moving code bidirectionally. For Pyodide and new UI part, since no one in SymPy core team has knowledge/time/willingness to maintain, I don't see benefits to keep them BSD. Moreover, most part of the current SymPy Gamma is 9 years old. Could an unmaintained project be hurt by being forked and re-licensed?

Please notice, SymPy is a library, while SymPy Gamma is a service for end user. I respect John Hunter as matplotlib author. Matplotlib is also a library, thus being BSD-style do benefit it as he said. However, an end user application can only be reused/redistributed as another application, and a service can only be reused/redeployed as a service. Once being permissive, there is far less interest/necessity for re-users to contribute back an application/service than a library. So to protect the project, keeping the core permissive but application/service viral is very common in open source community. That's what I believe.

Making it AGPL is very different from what the companies I accuse did, because AGPL is an OSI-approved Free and Open Source license. The reason that it prevents anybody to use it, is their prejudice towards (A)GPL or their compromise to proprietary software vendors. It's not AGPL's fault.

Even though SymPy Gamma can be self-deployed, SymPy team still pay to deploy it. We all know the importance of having an available service for users to directly use. The new project still needs a server for hosting static files, including compiled packages. As long as there's need for that, AGPL is a better fit than GPL.

2. I don't care that much about server side data collection, or the proprietary server platform itself, or Google the company. I myself would like to host the project on vercel. I just don't like the way that browser fetches the Google Analytics and run it on client. I simply want to gain control of what code runs on my device, whenever I could.

3. Though contributing to SymPy, I personally prefer the No Code of Conduct that diofant chooses. That was one of the reason Sergey B Kirpichev started the fork. It is for me too.

I saw some people outside SymPy team that interested in migrating to Pyodide at issue 83 of sympy live. That was also the place I got the idea and decided to work on this. Hopefully they are not so busy as I am (I'm working from 9am to 8pm 5 days). And, thanks for your initial answer. I'll keep working and release it soon. I also don't want people pass this conversation by, think "hey you say so much words against the community's philosophy, but where is your code?" for too long.

Qijia Liu

[Aaron Meurer]

On Wed, Dec 15, 2021 at 1:45 PM Qijia Liu <liu...@pku.edu.cn> wrote:
>
> 1. As I said, I'll keep code derived from SymPy Gamma BSD licensed. To be more specific, all python code under logic directory, factordiagram.js, plot.js (and CSS, if anyone cares). So there will be no barrier for moving code bidirectionally. For Pyodide and new UI part, since no one in SymPy core team has knowledge/time/willingness to maintain, I don't see benefits to keep them BSD. Moreover, most part of the current SymPy Gamma is 9 years old. Could an unmaintained project be hurt by being forked and re-licensed?
>
> Please notice, SymPy is a library, while SymPy Gamma is a service for end user. I respect John Hunter as matplotlib author. Matplotlib is also a library, thus being BSD-style do benefit it as he said. However, an end user application can only be reused/redistributed as another application, and a service can only be reused/redeployed as a service. Once being permissive, there is far less interest/necessity for re-users to contribute back an application/service than a library. So to protect the project, keeping the core permissive but application/service viral is very common in open source community. That's what I believe.
>
> Making it AGPL is very different from what the companies I accuse did, because AGPL is an OSI-approved Free and Open Source license. The reason that it prevents anybody to use it, is their prejudice towards (A)GPL or their compromise to proprietary software vendors. It's not AGPL's fault.

Prejudice or not, the fact remains that we cannot use code unless it
is licensed at least as permissively as SymPy.

>
> Even though SymPy Gamma can be self-deployed, SymPy team still pay to deploy it. We all know the importance of having an available service for users to directly use. The new project still needs a server for hosting static files, including compiled packages. As long as there's need for that, AGPL is a better fit than GPL.

Maybe I misunderstood the technical aspects of pyiodide. I was under
the impression that the whole thing could just be put on GitHub pages,
which costs us nothing. I understand you have to compile wasm versions
of SymPy and any other Python packages, but I don't think this needs
to be done very often. Just doing it once per SymPy release (typically
a few times a year) should be fine. There might also be free CDNs that
will host Python WASM packages, I'm not sure.

But it's possible I am missing something here, so if I am please let
me know. If we still have to pay for hosting with pyiodide, that
gives me pause. Even if it's much less than what we are paying now,
having to deal with a server and server costs is a lot of complexity
that I'd like to eliminate entirely.

>
> 2. I don't care that much about server side data collection, or the proprietary server platform itself, or Google the company. I myself would like to host the project on vercel. I just don't like the way that browser fetches the Google Analytics and run it on client. I simply want to gain control of what code runs on my device, whenever I could.

Like I said. I don't think we even use the analytics on Gamma, so I
personally have no problems with removing them, even now independently
of all the other things discussed here.

OTOH, since we do have analytics there, maybe they can be used to help
us understand why it is costing us so much. I've had a hard time
figuring out how to extract this information from the Google Cloud
console. If someone knows how to do this, let me know.

>
> 3. Though contributing to SymPy, I personally prefer the No Code of Conduct that diofant chooses. That was one of the reason Sergey B Kirpichev started the fork. It is for me too.
>
> I saw some people outside SymPy team that interested in migrating to Pyodide at issue 83 of sympy live. That was also the place I got the idea and decided to work on this. Hopefully they are not so busy as I am (I'm working from 9am to 8pm 5 days). And, thanks for your initial answer. I'll keep working and release it soon. I also don't want people pass this conversation by, think "hey you say so much words against the community's philosophy, but where is your code?" for too long.

Yes, we want to move Live to pyiodide too. But Gamma is actually a
higher priority because it is currently costing us twice as much as
Live.

Aaron Meurer

>
> Qijia Liu
>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d7ed5d30-de51-43f8-805c-fcea5b632b49n%40googlegroups.com.

[Qijia Liu]

In case anyone wants a preview, here it is: https://lambda-steel.vercel.app/

Note: It's still WIP, no source available now, the site may be down any time, the name is undecided yet.