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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/c050abfb-1ad7-45be-ba5b-add20f0ac071n%40googlegroups.com. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2B7nYbn%3DEw_EmgopUJikf1h8%3DsqhHJ4BW33nOMGpxXrCQ%40mail.gmail.com.
