On Sun, Nov 16, 2008 at 11:08 AM, Kirill Smelkov <[EMAIL PROTECTED]> wrote: > > On Sat, Nov 15, 2008 at 05:22:25PM -0800, Brian Granger wrote: >> >> I am almost a sympy developer (my recent work has not been merged >> yet). I also don't know much about the history Kirr's contributions, >> so I apologize if I say anything (unintentionally) to hurt already >> sour relations. So... > > No problem here. We all do our own first steps some time, and please > don't be afraid to hurt me. > > As to history of contributions - if you are interested, I suggest to run > gitk or `git shortlog` and study it. > >> Like Gael, I have the goal of wanting as many people as possible to be >> able to use software that I write. Thus I prefer a BSD-like license. >> Then, the only people who then can't use it (essentially) are those >> who choose not to. > > Many developers start from this proposition. While the goal is good (as > many people as possible to be able to use software), the way to achieve > this (BSD-like license) sometimes does not work. Yes, in the beggining > it works very well, but without feedback the original software sometimes > stagnates. > > Many think that "must cooperate" licensing helps development, e.g. > please read my original post > > http://groups.google.com/group/sympy/msg/c405c091076f6cfa > > and this blog post from 2006 by David A. Wheeler about "why GPL rocketed > Linux to success": > > http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd > > But also *please* read in my original post that > > GPL for kernel = LGPL for user splace libraries. > > >> I do think both the GPL and LGPL license are useful in certain contexts. >> >> Even though they are useful in certain contexts, I think they have a >> critical flaw. The flaw is that both the GPL and the LGPL are too >> complicated. Why do I say this: >> >> * I have spent many hours talking with people about the LGPL and GPL >> and have read lots about them (including the actual license text), but >> I am still not sure exactly how to interpret them. (OK, you may say >> that I am not that smart, but...) >> >> * Many other smart people still have huge disagreements and >> misunderstandings about the interpretation of the GPL and LGPL. And >> these diff-interpretations are not just symantic in nature (e.g., how >> word "freedom" is used). They are substantial and made by equally > > In LGPL-2.1 the word "freedom" is used only in Preamble section which > in legal context serves as introduction only. > > http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt > > And I'm sure it says about "freedom" in the way how fsf understands it: > > http://www.gnu.org/philosophy/free-sw.html > >> bright people on both sides of the argument. >> >> * If you have any doubts about their complexity, just read >> http://www.gnu.org/licenses/gpl-faq.html >> >> Thus, even if I did want/need the protections of the GPL or LGPL, I am >> not sure that I really trust the licenses, because I am not sure of >> what they actually say (mean). At least not until all the grey areas >> are tested in court, which at this point they haven't been. > > Yes, legal texts are a tricky area. That's why I propose we first > clearly state our intent with the "Fair use of SymPy" before the license > text (please read my original post). > > Another thing is LGPL *is* very widely depolyed and is non-intrusive (e.g. > on Linux systems, the _basic_ library GLibc is covered by LGPL, though > any software can use and uses it -- Python (BSD), protprietary > applications... *any*) > > And also big advantage of LGPL is that it was tested in real action - in > court with success. > > So if we agree on basic words (Fair use of SymPy) I suggest just to > adopt the license which is close in translation to it.
I am all for Fair use of SymPy, as an informal way of saying that it is (at least) polite to for example cite us and consider contributing the changes back, because in the end, it helps everyone. But the BSD license covers that --- it requires to give credit were credit is due. > >> But, one question: >> >> If sympy becomes LGPL, what license restrictions would my code have if >> I subclass sympy.Basic? > > If you subclass sympy.Basic from your outside-of-sympy code, and sympy > is LGPL'ed, in essence your code could be covered by *any* license you > like - be it BSD, LGPL, GPL, closed, etc -- any. But what if I want to subclass Basic and keep the class in the same file? Can half the file be LGPL and half BSD? And btw, what is the point of being LGPL at all, if people who do not want to contribute changes back will just subclass Basic and keep their contributions in separate files, that they do not need to redistribute? Ondrej --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sympy?hl=en -~----------~----~----~----~------~----~------~--~---
