On Sun, Nov 16, 2008 at 04:05:07PM +0100, Ondrej Certik wrote:
> 
> Hi Kirr,
> 
> well, today is a licensing weekend. I wanted to release today, but
> let's get this discussed, I think it is important. It'd have to be
> discussed anyway sooner or later.

I too needed to work on video encoding issues all the weekend, but this
beast got out of the bottle.

> On Sun, Nov 16, 2008 at 3:02 PM, Kirill Smelkov
> <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, Nov 16, 2008 at 01:36:30PM +0100, Ondrej Certik wrote:
> >>
> >> Hi Kirr,
> >>
> >> let me say that I am not convinced that LGPL is better for SymPy.
> >>
> >> It seems to me that you think that LGPL will protect you 100% and keep
> >> you happy:
> >>
> >> > Initially I was in a shape and could afford myself working on sympy
> >> > without protection, but when it started to be very tough, I have to
> >> > either have 100% protection or stop risking my health.
> >
> > No, not 100%. It's an older quote. In my main post I say that "licensing
> > is only part of the game", and also I understand that LGPL would not
> > protect from every-possible abuse.
> >
> > But it protects again some class of abuses, and a very common class.
> >
> > Yes, it does not protect against putting modified software on a server
> > and making a service from it, but as I know neither of any DFSG-free
> > license do. Or am I wrong?
> 
> Well, read this post:
> 
> http://www.miriamruiz.es/weblog/?p=192
> 
> so the answer is yes and no. Which means AGPL is on the edge between
> free and non-free, as viewed by many people around Debian.
> I definitely want sympy to be on the safe side of the edge.

So you say we can't use AGPL now, right?

If it would be considered as DFSG-free, I'm not against that A, and I'm
ok with ALGPL.

> > I agree that LGPL works only when the code is redistributed, and this is
> > fine with me.
> >
> > Brian email: do you mean that it is difficult to understand legal
> > wording? Hm, yes, legal texts are difficult, but LGPL is with us for
> > ~ 15 years already, and I personally always thought that there is a
> > clear traction of it, e.g. as written here:
> >
> > http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
> >
> > And also I say again that almost every program actually *uses* LGPL'ed
> > libraries: for example glibc:
> >
> > [EMAIL PROTECTED]:~$ ldd /usr/bin/python
> >        linux-gate.so.1 =>  (0xb7f32000)
> >        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7efb000)
> >        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7ef7000)
> >        libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7ef2000)
> >        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7ecc000)
> >        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d71000)
> >        /lib/ld-linux.so.2 (0xb7f33000)
> >
> > While Python itself stays BSD.
> >
> > That's why I personally think that the LGPL is a well established and
> > tested ground.
> 
> Yes, I believe that from all the other options, if we want more
> restrictions, we should use either LGPL or GPL (2 or later, so that we
> are compatible with other programs, like Sage). Another problem is
> that I really, really don't like the phrase 2 or later. I like exact
> terms that are valid at the point in time when we released the
> software.

I'm not a lawyer, but I'll quote http://www.fsf.org/licensing/licenses/

"""
GNU Lesser General Public License (LGPL) version 2.1
----------------------------------------------------

This is the previous version of the LGPL: a free software license, but
not a strong copyleft license, because it permits linking with non-free
modules. It is compatible with GPLv2 and GPLv3. 
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"""

Is this what we want?


> >> According to you "fair use", what you really want is to have a license
> >> that says --- whatever you do with our code, you *have* to share your
> >> modifications. Well, that is a non-free license to me.
> >
> > No, I want my "fair use" to only work when the code is redistributed.
> > I'm sorry it is ambigous. Let's correct it. Would the following be ok?
> >
> > """
> >    Fair use of SymPy v0.2
> >    ----------------------
> >
> >    You can use SymPy as you want, and we encourage you to build various
> >    products on top of SymPy including commercial and closed-source ones.
> >
> >    Your own code that uses SymPy as a library can perfectly stay
> >    proprietary.
> >
> >    But if you change SymPy itself *and* redistribute SymPy with this
> >    changes, you have to also provide your modifications to whom you
> >    distribute SymPy.
> >
> >    Your other code still stays yours and can be distributed on whatever
> >    terms you like.
> >
> >    To legally state what we think is our "Fair use of SymPy" we adopt LGPL
> >    license.
> > """
> 
> Yes, now I think it is free software.

Great! And is it ok for SymPy now?

> >> What is your problem with BSD? LGPL will not protect you as I
> >> described above either.
> >
> > Most users would even don't notice if sympy is lgpl -- they could
> > perfectly ok be using sympy with essentially any license for their own
> > software.
> 
> If they use it as a black box -- yes. But at least my intention always
> was to treat each user as a developer so that we work on one thing
> together.

The same for me. But when those yesterday users and today's developers
start to work more and more, at least some of them (like me) would want
to protect the result from "abuse".

So for me it is good for everyone.


> > But next the question comes to sympy developers.
> >
> > As a developers I want to care into which hands the result go, and yes,
> > LGPL is not a silver bullet, and bad hands is bigger than "fair use of
> > sympy" abuse. But to me LGPL is at least something and practical in
> > protecting from common scenarious.
> >
> > The question is what other developers think.
> 
> Yes, I am also interested what other people think.
> 
> > ----
> >
> > And also I'd like to remind you, that even if SymPy stays BSD, *anyone*
> > can take it, and modify it, and redistribute by *another* license, e.g.
> > proprietary, LGPL, GPL, or anything else -- just three points of BSD
> > license have to be respected as well as additions:
> 
> Yes, exactly.
> 
> >> > And what about GLibc which is LGPL'ed? Any problems in using this
> >> > library? I bet 90% of people out there even dont _think_ of this issue
> >> > when they run their programs, that they depend on Glibc.
> >>
> >> Yes, I have no problems using LGPL or GPLed software (or even non-free
> >> software).
> >
> > So what would be the problem in using LGPL'ed SymPy?
> 
> Using? No problems. Developing? Yes, that's what this all discussion is about.
> 
> >> > I've put licensing stuff on shelve in harder times, just to concentrate
> >> > on technical bits and defend SymPy. But after that investment (it was in
> >>
> >> And I appreciate that. Thanks for everything you did!
> >
> > Now I regret I was doing it for too long without (as you've told me so
> > many times) resolving the licensing issue.
> 
> Yes, I knew we would utterly disagree here, so I tried to push you to
> discuss it sooner.
> 
> >
> > But for me it's very strange that we understood each other in almost all
> > areas with the only exception being licensing.
> 
> Well, I am sure there are more things, like politics where we would
> disagree too. But the point is that we both have a common aim with
> sympy, so as long as we are able to work together, it benefits both
> and it benefits sympy.

Yes. I think I very honestly and clear state my aim -- to make sympy do
what is needed for my own research. I try to do it as good as I can, and
it seems the result was useful not only for me.

> >> > spare time + several day offs, compare with e.g. 6 months full-time
> >> > grant sponsored development of sympycore [1]), it became much more 
> >> > evident
> >> > that developers effort have to be protected.
> >> > Yes, to me developers effort have to be respected and protected. And if
> >> > this could be done in a compromise way, it should be done.
> >>
> >> LGPL would *not* prevent the development of sympycore.  All I am
> >> saying is that those things are orthogonal to the license. The way to
> >> deal with these issues is not LGPL (it won't help), but to meet the
> >> people, talk with them, talk about what you want, what they want and
> >> trying to find ways to work together, because it helps both parties. I
> >> did exactly that at EuroSciPy. Again, let me stress, that even if we
> >> didn't reach some consensus, LGPL would not help.
> >
> > What I was saying here, is that when there was a threat, we provided
> > adequate-answer to this threat, and in particular this was the reason I
> > was not starting licensing discussion, not to loose concentration.
> >
> > Now I'm telling that there will *maybe* other threats in the future. So
> > why not to protect the project? The more you work, the more you put your
> > soul into the project, the stronger you want this protection.
> >
> > No? Irrational?
> 
> I think it is perfectly rational to protect against threats. Every
> protection comes with a price and considering the protection of LGPL
> and the price of it, I prefer BSD.

Are you saying this as "Ondrej, the developer", "Ondrej, the manager" or
"Ondrej, the project leader"? And if the latter, does this mean SymPy
stays BSD?

> >> > Actually some people we all know want money first [1], or stop working
> >> > on their "babies" after their grant is finished [2], or want to be paid
> >> > working for companies which want to keep their modifications secret [3],
> >>
> >> So what? I know all those people personally and I think they are
> >> they are helping our community, not hurting. Well, if sympycore
> >> meant our community would split, that would hurt, but
> >> as I said above, LGPL would not help here.
> >
> > Do you know evey possible user or developer of SymPy in advance? I think
> > that knowing each other is good and essential, but also there should be
> > written rules of what is allowed and what is not.
> 
> Yes, I believe it too, that having written rules is essential.
> 
> >
> >> > I claim again, that because it benefits some companies, they created
> >> > such a pro-BSD athmosphere and they've reached criticall mass.
> >> >
> >> > But again I say -- just open your mind and drop this bullshit -- you
> >>
> >> I don't think it's bullshit. If you have the need, write me a private
> >> email or call me and you are free to use any expressions you want. But
> >> on our public list, please don't use such words. Unless you really
> >> mean it.
> >
> > I really meant it, but I've got you -- I'll try not to use such kind of
> > words anymore in sympy list.
> 
> Well, I thought you said it because you were upset. If you really
> meant it after you calmed down, then I think we should not be
> discussing this anymore, because I expect people to respect each
> other's opinions.
> 
> >> > started from fair rules:
> >> >
> >> > """
> >> > What I like on GPL is that if someone takes it, he needs to distribute
> >> > his
> >> > changes and code also as GPL, and cannot just steal it and used it in a
> >> > proprietary product without releasing his code as opensource. I have
> >> > nothing against someone taking our code and selling it, however, I want
> >> > him
> >> > to release it as open-source (GPL). I think that's fair.
> >> > """
> >> >
> >> > Just substitude GPL -> LGPL and this is ok for all.
> >>
> >> Yes I changed my mind on this. And I am not fanatically against any
> >> license.
> >
> > To me you've changed from one extreme case (GPL) to another extreme
> > (BSD), while I propose the median (LGPL).
> 
> Because it seems to me that LGPL doesn't have enough protection (as
> GPL) and yet it looses the advantages of BSD.

How it does not have enough protection? It protects sympy itself without
affecting clients code. Is this not enough? Why doing it "all or
nothing"?

> >> But I listen to people around SymPy, our users and developers. I know
> >> you very strongly want LGPL. But most other people
> >> prefer BSD, including me. Are you willing to make compromises? For
> >> example some addons to sympy (maybe the C core if you want to develope
> >> that?) could have other license.
> >
> > LGPL is already a compromise.
> >
> > I've used to touch sympy everywhere, starting from pprint, integrator (a
> > bit) and ending touching Add, Mul and Basic internals. You said that "every
> > developer should feel that the whole project is his/her, that he can
> > change every file, etc..." and this was indeed in spirit of sympy
> > development (at least for me), so if I have not support from other
> > developers, I'd better quit, and hack my own solution of what I
> > personally need starting from BSD sympy and LGPL it (and this is
> > perfectly legally ok).
> 
> Sure. But then Kirill2 will come and take your code and make it GPL,
> because LGPL is not protective enough. He will use the exact same
> arguments as you are using now. Clearly you can add as many
> restrictions as you want and always the flow of code will be
> unidirectional.  So it's again about particular people and their
> willingness to work together, or not.

Yes, I've said in my main mail that licensing is only part of the game.

> So if you propose you want to fork sympy, make it LGPL, what do you
> mean to "hack your own solution"? What is your aim? Is it the same aim
> as sympy aim? If so, do you want to split our community and get some
> developers working on the LGPL version and some developers on the BSD
> version? Sure, if this is what you believe in, do it. But as I said
> many times, it would be much better for all of us if we could find
> common ground and work together, instead of against each other.

My goal is not to split the community, or somehow otherwise achieve any
social result. My only goal is to have

    useful CAS tool for me myself for my research


I know it is better to merge early, merge often, but if I had no chance
to protect the result inside sympy, I'll need to protect it myself:

If I'll need to enhace sympy to do some nontriviall things for me, I'll
just create a git branch 'kirr', commit my anhancements there, and will
periodically merge with main sympy. If I need more enhancements, I'll
commit on 'kirr' branch again and as time goes would merge with sympy.

I would keep my repository on say repo.or.cz, so that I can always
access it, so either can anyone else - I don't mind it.

I would even try (if you would not mind) to periodically send email to
sympy patches with "Ondrej, All, please consider pulling 'kirr' branch
from here, to recieve the follwing updates ..." (with the first patch
being "switch to LGPL")

I'm not saying I'll have to do it -- first, existing SymPy could be
enough for my tasks (but until now it was not enough capable). Second - I
still believe we should and can make a consensus on the topic.

-- 
                                Kirill

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to