should sympy be LGPL?
Ondrej Certik
I think we should stay with BSD, but not everyone agrees with me and
when it reaches the point, that someone doesn't want to contribute
anymore, because we use too permissive license, it needs to be
discussed again, or at least clarified.
It started with this thread in sympy-patches:
http://groups.google.com/group/sympy-patches/browse_thread/thread/25c8fea6d51d2bf5
and read especially this why Kirr doesn't want to contribute anymore
(and license is the main problem):
http://groups.google.com/group/sympy-patches/msg/9e49c1b9f690e1cd
it's a very nice and honest email. Kirr has done a stellar job over
the past year and half and we definitely would not be as advanced with
sympy without him. I'll reply to his arguments in my next email.
But I'd like to use this occasion to make a survey among our
developers and users ---- do you think we should stay with BSD, or
switch to LGPL? I am interested in all opinions from anyone. Whenever
there is some occasion, I am discussing this with people around sympy
and so far my observation is that most people either prefer BSD, or
don't mind either, but would like to hear good arguments why LGPL
should be better. There are also some who clearly prefer LGPL, for
example Kirill or some people from the Sage community, but I think
given all the circumstances (i.e. sympy aspiring to become the
symbolic manipulation library for Python, and together with numpy,
scipy, matplotlib, mayavi and others form a BSD like environment for
scientific computing, that people can build on and given the community
where sympy belongs), the right license for sympy is BSD.
In my next email soon to this thread, I'll reply to particular points
raised by Kirr.
Ondrej
Robert Kern
>
> Hi,
>
> I think we should stay with BSD, but not everyone agrees with me and
> when it reaches the point, that someone doesn't want to contribute
> anymore, because we use too permissive license, it needs to be
> discussed again, or at least clarified.
>
> It started with this thread in sympy-patches:
>
> http://groups.google.com/group/sympy-patches/browse_thread/thread/25c8fea6d51d2bf5
>
> and read especially this why Kirr doesn't want to contribute anymore
> (and license is the main problem):
>
> http://groups.google.com/group/sympy-patches/msg/9e49c1b9f690e1cd
>
> it's a very nice and honest email. Kirr has done a stellar job over
> the past year and half and we definitely would not be as advanced with
> sympy without him. I'll reply to his arguments in my next email.
>
> But I'd like to use this occasion to make a survey among our
> developers and users ---- do you think we should stay with BSD, or
> switch to LGPL?
FWIW, my vote is for BSD. I, personally, don't work on (weak or
strong) copyleft projects. Copyleft licenses are intrinsically
attached to an agenda which I don't share so I don't use them. I'm not
a fan of agendas.
I can see the point for some pieces of software where there is a known
threat (e.g. the LGPLed work on GMP gets enhanced slightly by a
proprietary product and resold with lots of bragging about how they're
better than the open source GMP), but is there an actual threat to
sympy? Hypothetical threats don't impress me much.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
Ondrej Certik
<ki...@landau.phys.spbu.ru> wrote:
>
> On Wed, Nov 12, 2008 at 10:44:41AM +0100, Ondrej Certik wrote:
>> On Tue, Nov 11, 2008 at 1:36 PM, Friedrich Hagedorn <fried...@gmx.de> wrote:
>> >
>> > Hello Kirill,
>> >
>> > I am also against this patch. You did a good job in the sympy
>> > developement (fast patch reviewing, good patches, nice eMails, ...)
>> >
>> > It' pity that you say goodbye, but I think you need the time for
>> > your Ph.D. (btw, it sounds interesting). Anyway, it was a good time
>> > with you and I wish you many good ideas for you Ph.D.
>>
>> Exactly, my words. Kirill has done a phenomenal job with sympy and as
>> to me, he is welcomed back anytime!
>>
>> He told me he will reply in the evening, as he is busy at the moment.
>
> Thanks Ondrej and Friedrich for your good words, here is my story:
>
>
> In 2007/2008 when my cat was painfully dying, and my grandmother was
> dying too because of cancer, It could seem strange, but I was feeling
> strongly that sympy needs help and support because of
> http://code.google.com/p/sympy/wiki/SymPyCore
>
> Today my cat and grandmother are passed away, but at that time they were
> needing constant support and assistance and everything else, and this
> could seem just more strange, because at that time I was breaking like
> crazy in beetween assisting relatives and fighting for sympy. And I
> think you all know it was a hard work to make the whole development
> scheme go and to show that it is possible to do nontrivial development
> and to achieve progress incrementally in a we-can-work-together way.
>
> Though there are still a lot of room for improvements, I think the task
> to show that "evolution is possible" is complete.
Yes, I also think we have proved that we can improve with our current
codebase and I also hope we'll prove it in the future by merging the
new sympyx core (that we have written this summer) in.
I myself almost dropped out of my school because of sympy the last
year, so I couldn't invest more time in it than I did and I am very
much grateful to you, that you helped out so much.
> My journey with computers started at school, when I was 13 - I had not
> access to any machine -- pen, paper and basic were my tools then.
>
> Then I had my own ZX Spectrum, which I enjoyed using -->
>
> (we had our own FIDO-like network, disk operating system, C compiler,
> etc... In university years I even typed some of my TeX papers on ZX and
> translated them on a class computer... overall Speccy was a wonderful
> machine and a great learning playground for a lot of people).
>
> --> till the end of 2000 -- after graduating as bachelor and spending
> some time in army, parents bought me my first pc.
>
> First time I had trouble to install RedHat Linux 6.2 (because of
> non-standard ide controller), that's why I started studying Windows.
>
> And you know, I've came to a thought that "Windows is not the kind of
> environment I would like to change my Speccy to." Too much magic, too
> much internal inconsistency and dark corners, too complex sometimes with
> obscure bug'o'features. That was not for me.
>
> Fortunately, digging through internet helped to install Linux, and a
> wonderful world opened to me. I was charmed by UNIX ideas, and
> simplicity (now I understand that this is [1], but at that time I was
> not understanding it clearly). I learned learned learned ... - it was
> like a house for programming - a good house - and it was open and saying
> "welcome."
>
> I still believe I was very lucky having a very good book at hand
> (written by physicist Kai Petzke btw - [2] is a russian translation of
> [3]) to study things and digg them and understand them. Although one
> of my friend told me the book was pointless to him, I think the main
> value was in giving good starting points and good digging directions for
> those who want to learn, and from this point of view, this book is
> excellent.
>
>
> Now I even don't remember when I first started studying and hacking free
> software, maybe it was vgetty [4] into which I've hooked my software AON
> (russian analogue of Caller ID) decoding, today I can't say.
>
> The main point is that somehow I first started to learn-by-doing as a
> hobbyst. Then after we've met with nightbird people ([5], [6]) I had a
> wonderful ability to work on several things - general linux, audio
> capture/playback, the same for video, working with phone in data mode,
> in voice as fax, we even hooked nice IBM ViaVoice speach synthesis
> module into our system, and also russian "speaking mouse" _win32_ dll
> through wine (sic!), encrypted voluems on raid arrays, custom installer
> based on RedHat's anaconda, etc ... wow - this was all possible because
> all the building blocks were open, and a young guy like me could just
> take them, and study them, and adapt them to own needs, and to build
> something new, basing on other's shoulders.
>
> Today I understand that this was a great pleasure for me and that thanks
> to nightbird, I had so rare chance to self-educate at so many places,
> with so fast pace, that though the project was abandoned later, I
> strongly believe it opened doors to free software world to me changed my
> life forever.
>
> Serge, Mikhail, I want to say thanks to you. As with everything, first
> job is special, and I still miss you, and think of the time we spent
> together with nostalgy. It does not that matter C++ or Python -- human
> relations is what gives life to everything ...
Absolutely, human relations is what makes life fun to live and I very
much enjoy the social part of opensource too, and especially the
python scientific community. I've met really really great people
thanks to it.
> What I'm trying to show you, that being free for software is important.
> If a young guy or anyone else, could take it and study it, and modify it
> and share it with others, it's like as in university:
>
> all the knowledge done by previous people is avaliable to students
>
> and if you think of it, you'll understand that as students, we usually
>
> study the knowledge collected and distilled by others for
> _thouthands_ years, just in a say 4 years university course.
>
> We are all used to it, but I think this is a miracle, that human being
> is made *that* flexible, so that starting from scratch, young he or she
> can absorb the giant building of knowledge _easily_, just not
> understanding what kind of thing is happening, and thinking of learnt as
> of something usual.
>
> Besides humans being flexible, this is all possible only when the
> science is open - all knowledge comes for free - it's available for all
> people and for good.
>
> Likewise for software, when it comes for free as in free speech - open
> and available for studing, modification, sharing - it's like with a good
> science, humans absorb it and adapt it, and improve it for good. And a
> young man, e.g. like me can study and grow and absorb all the things
> done before, and go forward.
Yes, I agree. That's why I like Debian and it's strict license policy
so much --- because if I depend with my programs only on things from
Debian main, I can be (pretty) sure that I will always have all the
tools available to get the job done, no matter which company, or
university or place I am at. Just the internet connection is needed,
or just a big enough disk to handle the whole Debian archive.
>
> Compared to bad science, or locked down or proprietary software, it is a
> very good thing!
>
> I'd like to explain better, but now I'm too sleepy, and I have 10
> minutes left, and tommorow I have to go to work and concentrate there
> ...
>
> <so from now on it goes unstructured>
>
>
> What is important is that the software should be free as in free speech
> - one should always be able to:
>
> - run it
> - study it
> - modify it
> - share it
Yes. You should also be able to compile it (=run it) using only free
software. E.g. that's what Debian main distribution preserves.
>
> There are mechanisms to legally make contracts with software users,
> which protects this freedom, mainly strong copyleft (GPL) and weak
> copyleft (LGPL).
It is important to note, that not even GPL protects all kinds of
"abuse". In my opinion, the far bigger "threat" are the internet based
applications, like gmail, that are completely without sources and the
companies can even run GPLed code behind it --- but you have no chance
to study/run/modify or share the program.
But as long as I am not forced to use such a service, I don't mind.
And I use gmail, because it's good. But I don't have to, I can
administer my own email server and use mutt. As long as I have this
second option, I don't mind using non-free software (I also sometimes
use google earth and skype and picasa and other things). I just don't
want to depend on it.
> From almost the beggining I was talking to Ondrej that I think it's
> better to use LGPL for SymPy, that is anyone could be able to build
> application or other libraries whichever license they choose (including
> proprietary) on top of SymPy, but SymPy should always stays free as in
> free speech. Mainly one should be disallowed to "make private
> modifications to sympy and keep them secret."
Here we disagree. For me personally, this right is very important,
that not only I, but anyone can make any modification and do what he
wants with it, including keeping it secret.
> LGPL is a good compromise, and it does not force users of a library into
> any license, so why can't it be used.
Well, it depends on your personal point of view, but many people,
including me view it in a way that it forces, because LGPL is not
compatible with every license out there. Actually, I think there are
even some problems with mixing LGPL 2 and LGPL 3 code.
>
> Why on earth, say I as a hobbyst, spending my spare time, would want the
> result be used as a starting ground for closed software? BSD allows it
> explicitly, and this is not ok with me.
I respect your point of view and I think it's perfectly consistent.
But I don't share it --- I am also a hobbyist to some extent, well as
to sympy I still am, and I just want my code and my work to be used.
Because I believe it is good for me and the whole community in the
end. I do sympy because I very strongly believe in its potential and
that we get to a point (and we are almost there) where I could use it
regularly for my research. For example our recent work with Brian
shows, that we could actually do atomic physics using only open source
software in Python. That's very exciting.
And if someone uses it in some commercial product? I believe it will
help us, not hurt us. I believe it's about the community which is
around sympy. Commercial product can have a community, but a different
one --- I am pretty sure we all use sympy exactly because we have the
source code and because it's opensource.
>
> Actually at my work, With one of my collegues, we've made an
> observation, that usually motivated people, who are interested first in
> developing interesting things, to achive great result, to care about the
> project and it's ecosystem in general, and only then in money, usually
> prefer LGPL to BSD, and on contrary side, people who tend to work for
> money first, and care less about result, about fitting their development
> with others, about achiving good results, pushing harder when needed,
> prefer BSD. They usually say that "BSD is the license that companys
> prefer, and for which they pay money"
I think both ways are possible. I believe that Python itself and all
the BSD like tools around it show that people can do BSD software and
care about the project.
>
> Do you see the pattern?
>
> LGPL, being a fair contract, is good for everyone -->
Here we disagree. I respect that for you "LGPL is good for everyone".
But for me, "BSD is just as fair for everyone".
>
> (e.g. GTK+ is LGPL'ed, and there is a lot of free and proprietary
> software which uses it without a problem)
>
> --> is choosen by people who care, whereas BSD is choosen by people who
> want money first.
I understand what you mean. But I don't think that people around
sympy, or scipy or numpy don't care and want money first. So I
disagree with that statement.
>
> Money is ok, but I even can say that usually who want money first, get
> _less_ money than people who do care about the project in the first
> place.
Yes, I agree. I believe in american dream which says that you can get
what you want, but you need to work hard and it may take a long time,
but you'll get there eventually.
> Also I can say that in our company we use a lot of LGPL'ed software, and
> this is legally 100% ok, and that we even sponsor some LGPL'ed
> development, so to me there is just no rational reason why LGPL is not
> good for SymPy.
There are pros and cons to all three BSD and LGPL and BSD. You stated
the pros of LGPL. The cons is that LGPL creates a barrier of
contributions, from a lot (but not all) people and also usage, because
simply LGPL is more restrictive. Whenever you put more restrictions (I
am not saying it is necessarily bad) you lose some users. So while
LGPL is maybe good for sympy, BSD is imho better.
>
> I've failed to win Ondrej's mind, and I think I'll fail to convince most
> of you, and it makes me very sad, that so much evident common sence is
> not accepted, that I stopped thinking to be like at home with sympy
> recently.
I am sorry about that. But I think it is not a common sence.
>
>
> Also, when someone is in a deep overwork, it so happens, that there
> happens social issue, like e.g. quirelling with wife, after which I've
> felt hurt at everyone and decided to quit.
>
> Yes, it was childish, but it shows, that (at least some) good developers
> need good support, and also that spare time which can be spend for
I believe that everyone needs good support.
> either having a rest, going for a walk, for a talk with a human you
> love, or either to develop sympy, is _precious_.
I agree with this too. We all die once, so our time is limited and so
we should spend it very effectively.
>
> For me I just can't afford to spend that _precious_ spare time without
> legally protecting the result from abuse.
I think I understand how you feel. But as I said above, I think LGPL
maybe protects some abuse in some situations, but definitely not all
abuse in all situations (see my example with gmail above) and also
from the way you look at it, I don't even thinkl it is abuse --
depends on circumstances of course.
>
> I don't think this email will be of any use, but in case anyone is
> interested, we had a lenghty private email conversation with Ondrej, to
> which I'm ok to be opened in case this would be relevant.
I don't mind either, but please send it to me in private first to
check that I didn't write something I wouldn't like to be opened.
>
> I'm sad it turned out to be unstructured - usually I try to achive the
> results which I like myself, but I would not have time for it in a
> foreseable future.
>
> So, if there is someone who wants to better understand Kirr - you have a
> pleanty of raw material now.
>
> Time to go, bye.
Thanks for your email and I hope that we'll continue seeing you
around. And if not, then thanks again for everything you did for
sympy, it was and it is still a pleasure for me to work with you.
Ondrej
Andy Ray Terrel
disagree and agree with a large number of points made here. I
ultimately reject that the 4 freedoms of Richard M. Stallman (RMS) are
some how fundamental to a computer user. I prefer the arguments given
by Lawrence Lessig, that a free culture is a better more productive
culture. RMS does make a very nice point that a way to preserve this
free culture is to practice the 4 freedoms and require those who use
our software to comply. Lessig's Creative Commons licenses allow for
this structure as well as others. Nevertheless I also hold firmly
that it is rather the community of developers and not the legal
structure it stands on that make open source such a great experience.
I and many friends have developed BSD, GNU, and proprietary licensed
software with similar goals to promote technology and human progress,
much less motivated by secret agendas or monetary reward. A lesson I
have learned, projects that are *only* about money are never the
innovators of technology.
The debate I do agree with RMS on is in the view of labor rights of
the computer programmer. Programmers are not the first community of
artisans where it is easy to manipulate their works for personal gain
rather than that of the community. By following a copyleft license
the computer programmer is investing in her community and protecting
that investment from those who would falsely claim the work as their
own. Agreeing with Linus Torvalds, this does not mean to me one
cannot work with proprietary projects but rather the investment in the
community creates better software. The BSD license protects the
developer, the GNU set of licenses protect the community. I find a
nice balance in the LGPL license because it does allow proprietary
development and marketing but still protects the community.
You are going to lose users for many reasons. Losing them because do
not wish to conform to policies in place to protect the creative
investment of the community is not a bad reason. I think sympy is a
great community not because of its license but because of the people
and I will continue to invest in such a community no matter what the
license.
-- Andy
Vinzent Steinberg
support. You are certainly one of the most constructive persons I
know.
I think the problem is quite fundamental. Many developers are
investing quite a lot in an open source project, and they don't want
others to modify it without profiting from their modification. This
point I perfectly valid.
Given that sympy would be picked up by an company and they would turn
it into a closed source mathematica2, some sympy probably developers
would say: "Great, this draws much attention to our open source
project, and we will profit from the research they will do, because we
can see how they solved problems, even if they don't share their code
with us. And after all, it's better they invest in this area without
sharing code than not investing anything (due to restrictive
licenses)." For this kind of developers, the BSD license is better,
because they think it's better for the project and the code in their
opinion.
But others would mention: "I want my project to be open, closed source
is completely useless for me. I spent my work to let others share, not
that someone grabs it to make money with it without giving anything
back to the community. Freedom is one of the most important things
about our project, and this company is destroying freedom. Because
they have more resources they will have a more polished product and
drawing off our users and contributors. It's ok if they use it to earn
money, but they have to give something back"
These opinions are quite polarized and are probably not well
formulated by me. Mainly I want to say that both opinions are equally
right. It's up to everyone to decide which license and use of his very
work pleases him most and to respect the decisions and motivations of
developers preferring other licenses. You can't make both groups
happy.
An example for such an scenario is Wine. They switched from MIT to
LGPL due to a company not contributing changes back to the core
project.
I would count myself to the first group (I wouldn't mind if a company
would do such things to sympy), but I comprehend very well others like
Kirill who do not want this.
> "make private modifications to sympy and keep them secret."
force you to give modifications back. It only forces you to distribute
your program with sources. This means they can keep modifications
private as long as they don't sell the software. And this practically
means that modifications won't be secret of course. :)
I don't like that GPL is so viral. It's often incompatible to other
open source licenses. But it's a great choice if you want to to avoid
these "private and secret modifications".
Vinzent
Gael Varoquaux
> it's a very nice and honest email. Kirr has done a stellar job over
> the past year and half and we definitely would not be as advanced with
> sympy without him. I'll reply to his arguments in my next email.
I'll use my mail to reply mainly to Kirr (I hope he is still listening)
because I hugely respect and value a man who has invested a large amount
of quality time in a community project.
Kirr, you have been a fantastic actor of the project. You are now saying
that you are tired. This is actually a fairly common problem. We all
fight with lack of time, to many various interests. Software development
comes with its load of difficulties and disappointments. Too much
sacrifices ruin private life.
I am off course very sad if you quit this project that I follow (without
contributing, sorry) and in which I believe. However, what I really want
is to thank you for all your work. I hope you had as much fun as
possible, and I hope that your will keep good memories of your time with
sympy, rather than the reasons that made you quit. And besides, no
decisions is irreversible. I believe that you will have friends in the
sympy team whether you are contributing or not. Life and friendship are
more important than software.
> But I'd like to use this occasion to make a survey among our
> developers and users ---- do you think we should stay with BSD, or
> switch to LGPL? I am interested in all opinions from anyone. Whenever
> there is some occasion, I am discussing this with people around sympy
> and so far my observation is that most people either prefer BSD, or
> don't mind either, but would like to hear good arguments why LGPL
> should be better. There are also some who clearly prefer LGPL, for
> example Kirill or some people from the Sage community, but I think
> given all the circumstances (i.e. sympy aspiring to become the
> symbolic manipulation library for Python, and together with numpy,
> scipy, matplotlib, mayavi and others form a BSD like environment for
> scientific computing, that people can build on and given the community
> where sympy belongs), the right license for sympy is BSD.
We have discussed this a few times, including over a few beers in Prague,
you know my point of view. I won't dwell on it long.
Briefly. I personally realized that I don't care much about the license
of the software that I write. I care more that it is used by as many
people as much as possible. The thing that worries me most with software
is the amount of wheel reinvention, and lousy, half-complete,
implementations of a solution to a given problem. This is why I believe
free software has a future. This is indeed the Lessig point of view. The
reason I feel a BSD license help is that many companies (especially large
ones) are not afraid of hiring scores of developers to reinvent the
wheel, just because they want to possess it and control it. The driver
for free software adoption in companies is not cost, but control.
Of course the license debate changes whether you consider your software
as a component, that needs to be integrate in a larger infrastructure, or
as a finished good. Linux, (GPL, fantastic example of free software
success) is clearly a finished good. Wine (now LGPL) may also be a
finished good. Scientific computing libraries on the other hand, are not
finished goods. A company, or a research lab, may want to fork them to
keep a competitive advantage, and maybe not even redistribute the
resulting binaries. And that's fair enough by me, because I think the
world is a better place if these people use my software as a start,
rather than building on crappy bases. Besides, if they later decide to
share, it will be possible if the built on common abstraction. Finally, I
hope that as the world evolve, people (mostly managers and lawyers) will
understand the gain that there is to share 90% of the code, may it be
with 10% kept secret for a competitive advantage.
For me the golden example of successful free scientific software is VTK.
VTK is a 3D plotting library. 3D plotting is a forever-reinvented
problem. Each particular application is actually fairly simple, but when
you try to do something a bit more general, it gets really hard. So
people (companies, research labs) start out with a specific problem they
want to solve, and code a quick implementation, then as they evolve,
their small implementation grows to be a huge one, and most of the time
lies on crappy abstractions and data structure. VTK was born as a spin
off of GE: the code used in medical visualization was split off to a
start up (Kitware) and BSDed. GE still have their own proprietary bunch
of codes, for their medical devices, but VTK lives on, and unites the
efforts of many companies and labs with diverging problems and goals. In
the case of VTK, individual actors have learned that they need to
contribute back, because the cost of have their own abstraction and
algorithm to maintain and to impedance-match with the rest of the world
was very high. They make a careful decision as to what is open-sourced
and what isn't.
This is my model of development, and my 2 cents.
Gaël
Kirill Smelkov
This email is posted here in hope to reach people who share my
point of view, and to ask to please help to
_____________________________________________________
/\ \
\_| Advocate switching SymPy license from BSD to LGPL |
| |
| ________________________________________________|_
\_/__________________________________________________/
Start of this thread is here:
http://groups.google.com/group/sympy/browse_thread/thread/b5addd939ee0c803
Introduction
============
Currently SymPy is distributed under new BSD license.
But this was not always so -- originally the project was licensed under
GPL (!), but in the beginning of 2007, after Pearu Peterson has proposed
to switch to LGPL or BSD [1], developers decided to take permissive
approach -- BSD.
I've joined SymPy project later - in 2007 summer, and now I'm
proposing we change SymPy license to LGPL (Lesser GPL) which I
see as a golden median between beeing too permissive (BSD) and too
strict (GPL). |
|
v
BSD ---- LGPL ---- GPL
+------------------------->
strictness
Read below why
[1] http://code.google.com/p/sympy/issues/detail?id=138
On Wed, 12 Nov 2008 13:24:39 -0800, Robert Kern wrote:
> FWIW, my vote is for BSD. I, personally, don't work on (weak or
> strong) copyleft projects. Copyleft licenses are intrinsically
> attached to an agenda which I don't share so I don't use them. I'm not
> a fan of agendas.
>
> I can see the point for some pieces of software where there is a known
> threat (e.g. the LGPLed work on GMP gets enhanced slightly by a
> proprietary product and resold with lots of bragging about how they're
> better than the open source GMP), but is there an actual threat to
> sympy? Hypothetical threats don't impress me much.
Even if it is not evident to the casual observer, in the begginning of a
chess play, there is already a threat to your figures, and your king and
queen, so chessplayers usually try to analyze the situation early and
look into the future for at least several turns. And the player, who can
analyze more turns than the other, wins.
My understanding is that SymPy is close to enter "serious CAS" market,
and as Ondrej says below, SymPy has a lot of potential. To me what is
needed to be done for this is to go into compiled mode for core, and to
refine core design and it's data structures. Plus constantly trying to
apply SymPy to real-world problems, so that we could be sure we have
good engine connected to good user interface.
As during the last year I've touched both internal and high-level stuff
quite a bit, I think I'm keeping my hand at pulse here, and my
understanding is that together with all the polishing, assuming the
previous temp of work, this transition should take 6 - 12 months.
And after this transition is done, wouldn't it be like the case with
GMP, in which you say you see the points for LGPL?
Only then it would be late (or much more difficult than today) to protect
SymPy from abuse -- That's why I care *now*.
a nicely balanced LGPL license which allows proprietary development
> not wish to conform to policies in place to protect the creative
> investment of the community is not a bad reason.
A lot of people listed in our README already went away for various
reasons. Some did not fit into team-development and respect-each-other
and dont-break-existing stuff rule, some got afraid of patch review (I
suspect I was the main source of disaster), some got busy with other
stuff, etc...
It is not possible to be good for everyone -- that's why I don't try to
satisfy all the people, but instead try to be good for me myself, and do
whatever I think is better for me and for SymPy code, and if the result
could be somehow useful for others - I don't mind at all.
I hope that the last year shows that this approach worked quite well.
> I think sympy is a great community not because of its license but
> because of the people and I will continue to invest in such a
> community no matter what the license.
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
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.
Please read below, where I'm advocating LGPL in more details.
[1] http://code.google.com/p/sympy/wiki/SymPyCore
On Thu, 13 Nov 2008 09:27:29 -0800, Vinzent Steinberg wrote:
> First of all I want to thank you, Kirill, it was great to enjoy your
> support. You are certainly one of the most constructive persons I
> know.
reason to think that this time, I'm too proposing something
constructive.
> I think the problem is quite fundamental. Many developers are
> investing quite a lot in an open source project, and they don't want
> others to modify it without profiting from their modification. This
> point I perfectly valid.
>
> Given that sympy would be picked up by an company and they would turn
> it into a closed source mathematica2, some sympy probably developers
> would say: "Great, this draws much attention to our open source
> project, and we will profit from the research they will do, because we
> can see how they solved problems, even if they don't share their code
> with us. And after all, it's better they invest in this area without
> sharing code than not investing anything (due to restrictive
> licenses)." For this kind of developers, the BSD license is better,
> because they think it's better for the project and the code in their
> opinion.
I was working on some physics research and developed my own routines
pack for this. At seminar, after I've talked about current progress, one
of my collegues asked me:
"Kirill, you have done nice job with developing you routines pack,
may I borrow them for my research too?"
Sure, my answer was
"Yes, please. Here you are."
On the next seminar that collegue was talking about his progress, and he
mentioned my routines, and that he enhanced them a bit.
This time, I've asked him:
"Nice job, could you please give your versions of my routinse to me?
I'd like to use them too"
and, the answer was
"No, I can't. I need the result to be published first, so that I
have acknowledgment for my research. After I'll publish the
results, I'll give you your original routines enhanced by me"
I thought.
"Ok. I was not going to compete with this guy and steal his credits
in the first place anyway, but it seems he wants to be extra sure
in this, so even if it is a bit pity, that I can't use the
enhancements yet, so be it."
Time has passed, and on the next seminar, my collegue was talking about
his new progress, and mentioned his recently published paper with great
results obtained with the help of my routines. It turned out that this
time, they were again enhanced slightly more.
I've asked him:
"Now you have your paper published, could you please give me my
enhanced routines, so that I can use them for my research too?"
I was sure, he would say "yes, please", but I've made a mistake:
"No, if I give you your enhanced routines, this would make us equal,
and I could not be sure to win this tasty new grant we'll be
competing for on the next week."
I thought huh!? How is it possible that I've shared my research in the
first place, and now he says he is not going to do the same, even when
his work stood on my basis?
Needles to say, that the next time, when I talked about my progress and
new software which I had to develop along the way, I refused to give it
to my collegue, because I though that he plays unfair:
"Last time you took my routines and enjoyed using them, but when I
asked you to share your enhancements, you refused for various
reasons.
So why should I give my work to you this time?"
This conflicting situation became known to our management, and they
tried to analyze it and asked me:
"Kirill, at our department we do different kind of research, and we
have lots of groups. How we work was always cooperative in spirit -
we always used to share the results internally and give advices to
each other.
Yes, sometimes there is concurency between groups, but this was
never an obstacle for cooperative research, because everyone is
aware and confirming to good science ethics - not to publish
overlapping results before the original author.
Why are you refusing to share your work with collegue?"
I told them that we used to share codes, but somehow contributing flow
became unidirectional, and that I think this is not fair to only take
and not to give back:
"I'm ok with my collegues developing their own private codes, even
if they are using mine, but I'd like them to share back their
changes to _mine_ code. It's _their_ behaviour which is not
cooperative."
This story is imaginary, but I think it fairly well illustrates
qualitively the situation I have in mind. You can think of two
physicians, two mathematitians, or sympy development community v.s. some
company which ships locked down sympy to its customers.
And it's this "we only take and locally modify" which I propose to
legally prevent.
---
As to
"Great, this draws much attention to our open source
project, and we will profit from the research they will do, because we
can see how they solved problems, even if they don't share their code
with us. And after all, it's better they invest in this area without
sharing code than not investing anything (due to restrictive
licenses)."
Practice shows that instead, usually it's closed neighbour draw
developers (key developers are usually just hired) and users, but after
this happens, the main project stays with even less resources, and this
strikes back at both open and closed projects. End of story.
Please read below about how this happens.
> But others would mention: "I want my project to be open, closed source
> is completely useless for me. I spent my work to let others share, not
> that someone grabs it to make money with it without giving anything
> back to the community. Freedom is one of the most important things
> about our project, and this company is destroying freedom. Because
> they have more resources they will have a more polished product and
> drawing off our users and contributors. It's ok if they use it to earn
> money, but they have to give something back"
>
> These opinions are quite polarized and are probably not well
> formulated by me. Mainly I want to say that both opinions are equally
> right. It's up to everyone to decide which license and use of his very
> work pleases him most and to respect the decisions and motivations of
> developers preferring other licenses. You can't make both groups
> happy.
and every library on Linux system, including e.g. Python which is
BSD-like licensed, and every proprietary program which runs on GNU/Linux.
My point here is that LGPL (Lesser GPL) is a good compromise between
beeing too strict (GPL) and too permissive (BSD).
Actually my license would be the "Fair use of SymPy"
"""
Fair use of SymPy
-----------------
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 -- you have to share your modifications
to SymPy, your other code still stays yours.
To legally state what we think is our "Fair use of SymPy" we adopt LGPL
license.
"""
As last line says, its simply LGPL who is the closest-in-spirit
translation of this terms which is composed by legal-aware people and is
tested.
> An example for such an scenario is Wine. They switched from MIT to
> LGPL due to a company not contributing changes back to the core
> project.
And before switching, they were too wanting "Wine to be used as wide as
possible" - that's why they were licensed by MIT (similar to BSD).
But when they started to be abused by TransGaming (who developed closed
WineX and did not contributed back their changes), they decided to
switch to LGPL, because LGPL'ed Wine is still perfectly allowed to be
used by essentially any software (closed and open), but changes to Wine
itself have to be always made shared with whom you distribute Wine.
http://wiki.winehq.org/FAQ#head-72731b215bbd1ce36e3b84ac7ce114925ce16460
http://wiki.winehq.org/WineHistory
So they changed from BSD to LGPL and this is what happened:
"""
The immediate effect was the creation of the ReWind project to further
the X11-licensed codebase. Many key developers agreed to allow their
additions to be used by both the X11 and LGPL Wine code. Most have
decided to focus their efforts on synchronizing with the LGPL'ed Wine
and the vast majority of development and new features appear there
first. Picking a favorite software license is left as an exercise for
the reader.
Shortly after changing the license development began to pick up at a
greater pace. More patches began to appear, Alexandre made more CVS
commits, and more applications were reported to work. By the end of
2003 DLL separation achieved a milestone with the split of the
kernel32/ntdll combination. Most of the architectural changes to
support a beta release were in place. Another developer's conference
was held in January, 2004 in St. Paul Minnesota sponsored by
CodeWeavers. Once again, a roadmap was laid out for tasks that needed
to be completed.
"""
So it seems LGPL also boosted Wine development.
> I would count myself to the first group (I wouldn't mind if a company
> would do such things to sympy), but I comprehend very well others like
> Kirill who do not want this.
nothing back. As said above, I'm ok if anyone takes SymPy and uses it in
a closed-source proprieary product, but if he changes SymPy itself, I
strongly mind for that SymPy-changes to be closed.
> > "make private modifications to sympy and keep them secret."
>
> If I understand the GPL correctly, it won't prevent this. It does not
> force you to give modifications back. It only forces you to distribute
> your program with sources. This means they can keep modifications
> private as long as they don't sell the software. And this practically
> means that modifications won't be secret of course. :)
>
> I don't like that GPL is so viral. It's often incompatible to other
> open source licenses. But it's a great choice if you want to to avoid
> these "private and secret modifications".
I'm proposing LGPL which is a different, "non viral" license [1].
When you mix GPL here, you create confusion, and I think that confusion
is the first step towards creating FUD (Fear, Uncertainty and Doubt)
[2].
As to you statement - yes, I don't care about someone keeping private
modifications without redistributing them -- all I care about is
redistribution, and this is covered by LGPL.
[1] http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
[2] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
On Sat, Nov 15, 2008 at 12:48:59PM +0100, Gael Varoquaux wrote:
> On Wed, Nov 12, 2008 at 09:47:18PM +0100, Ondrej Certik wrote:
> > it's a very nice and honest email. Kirr has done a stellar job over
> > the past year and half and we definitely would not be as advanced with
> > sympy without him. I'll reply to his arguments in my next email.
>
> I'll use my mail to reply mainly to Kirr (I hope he is still listening)
> because I hugely respect and value a man who has invested a large amount
> of quality time in a community project.
>
> Kirr, you have been a fantastic actor of the project. You are now saying
> that you are tired. This is actually a fairly common problem. We all
> fight with lack of time, to many various interests. Software development
> comes with its load of difficulties and disappointments. Too much
> sacrifices ruin private life.
>
> I am off course very sad if you quit this project that I follow (without
> contributing, sorry) and in which I believe. However, what I really want
> is to thank you for all your work. I hope you had as much fun as
> possible, and I hope that your will keep good memories of your time with
> sympy, rather than the reasons that made you quit. And besides, no
> decisions is irreversible. I believe that you will have friends in the
> sympy team whether you are contributing or not. Life and friendship are
> more important than software.
Being friends is one thing, protecting the results of hard work from
abuse is another one. That's why I'm here.
project. That's why I think that SymPy should be independent from any
company at any give time.
Please read below about it.
> Of course the license debate changes whether you consider your software
> as a component, that needs to be integrate in a larger infrastructure, or
> as a finished good.
> Linux, (GPL, fantastic example of free software success) is clearly a
> finished good.
from almost the begginning. Also, please note, that in Linux kernel case
GPL works essentially like LGPL -- please read about it below.
So it *evoloved* to "finished good" with the license it carries today. And
even before Linux was _started_, FreeBSD & friends were already there,
right?
How it turned out that today Linux outperforms (my subjective point of
view) FreeBSD with respect to almost all areas? For example FreeBSD had
much better networking stack than Linux some years ago, but today the
situation is different.
Doesn't it points that somehow the license is too mixed into success?
To me, the answer is "yes" - read about below why.
> Wine (now LGPL) may also be a finished good.
the start, plus as said above Wine switched to LGPL to protect itself
from abuse back in 2002.
And even today, both Linux and WINE are _not_ finished goods.
They are developing at a very high pace - especially Linux. For example
transition from 2.6.26 to 2.6.27 which lasted for ~ 3 months brought a
lots of new features [1] and had ~ 10000 (ten thouthands) commits (!)
[2]. Compare this with SymPy, which has ~ 2500 commits for _all_ its
history! Roughly saying every new kernel version is like ~ 3-4 man-work
of the *whole* sympy development and this is even more, if you'll bear
in mind, that the kernel patch quality rules are much higher than in
sympy.
I'd not call it as "finished good."
[1] http://kernelnewbies.org/Linux_2_6_27
[2] http://lwn.net/Articles/302061/
> Scientific computing libraries on the other hand, are not
> finished goods. A company, or a research lab, may want to fork them to
> keep a competitive advantage, and maybe not even redistribute the
> resulting binaries. And that's fair enough by me, because I think the
> world is a better place if these people use my software as a start,
> rather than building on crappy bases.
Besides, don't this people constantly reinvent "lousy wheels"? And why
the world is a "better place" with those "louse wheels" forked from your
base.
Wouldn't it be better to cooperate on common playground?
> besides, if they later decide to
> hope that as the world evolve, people (mostly managers and lawyers) will
> understand the gain that there is to share 90% of the code, may it be
> with 10% kept secret for a competitive advantage.
something (or not), but create a world in which a manager that does not
understand this something, can't effectively manage, so he/she will just
have to educate him/herself.
Read about this below.
> For me the golden example of successful free scientific software is VTK.
> VTK is a 3D plotting library. 3D plotting is a forever-reinvented
> problem. Each particular application is actually fairly simple, but when
> you try to do something a bit more general, it gets really hard. So
> people (companies, research labs) start out with a specific problem they
> want to solve, and code a quick implementation, then as they evolve,
> their small implementation grows to be a huge one, and most of the time
> lies on crappy abstractions and data structure. VTK was born as a spin
> off of GE: the code used in medical visualization was split off to a
> start up (Kitware) and BSDed. GE still have their own proprietary bunch
> of codes, for their medical devices, but VTK lives on, and unites the
> efforts of many companies and labs with diverging problems and goals. In
> the case of VTK, individual actors have learned that they need to
> contribute back, because the cost of have their own abstraction and
> algorithm to maintain and to impedance-match with the rest of the world
> was very high. They make a careful decision as to what is open-sourced
> and what isn't.
>
> This is my model of development, and my 2 cents.
there are good projects under BSD license but wouldn't the same work if
VTK would be LGPL'ed?
Let's forget for a moment that some companies are afraid of *GPL, and
try to see -- what would be an obstacle to keep VTK, which is open,
under LGPL, and to keep private additional development private?
For me it's better to have clear rules, what _have_ to be always common
and belong to everyone. When such rules does _not_ force other
not-covered components (e.g. an aplication which uses sympy) into which
license to use, I call it non-intrusive.
And to me, LGPL is non-intrusive (read about glibc, libgcc, and wine
v.s. picassa) and it protects developers. That's why I propose we use
it.
spirit" first -- if we do - we'll work all the technical and wording
details out. Is my "Fair use of SymPy" ok? If so, let's just adopt
closest existing solution on license market which is not-intrusive.
Agree?
NB: Also I think that every time you say "I can" (administer your own
mail server, use mail client, ...), and someday you need to turn some of
this points into reality, multiply the probablility that the whole thing
will happen, say by 0.1 for each 'can'. Then you'll understand, that
when there are too much this "can(s)", what you get in essence is that
you can't.
> > From almost the beggining I was talking to Ondrej that I think it's
> > better to use LGPL for SymPy, that is anyone could be able to build
> > application or other libraries whichever license they choose (including
> > proprietary) on top of SymPy, but SymPy should always stays free as in
>
> that not only I, but anyone can make any modification and do what he
> wants with it, including keeping it secret.
modifications of sympy secret? Is there any reason this is good for
sympy?
As I've stated above I strongly mind about secret modification which are
redistribted in closed form, and I think this is not fair.
Read below about my understanding of why you need to reserve such rights
as "keeping modifications secret."
> > LGPL is a good compromise, and it does not force users of a library into
> > any license, so why can't it be used.
>
> Well, it depends on your personal point of view, but many people,
> including me view it in a way that it forces, because LGPL is not
> compatible with every license out there. Actually, I think there are
> even some problems with mixing LGPL 2 and LGPL 3 code.
which is used by essentially *every* program, is not a problem? What
about libgcc (GPL + linking exception) ?
I insist on that we should settle on "Fair use of SymPy", and if we do,
it would be straightforward to adopt the closest license out there on
the market, and work out all the details to eliminate license
incompatibility out there if any.
> > Why on earth, say I as a hobbyst, spending my spare time, would want the
> > result be used as a starting ground for closed software? BSD allows it
> > explicitly, and this is not ok with me.
>
> I respect your point of view and I think it's perfectly consistent.
> But I don't share it --- I am also a hobbyist to some extent, well as
> to sympy I still am, and I just want my code and my work to be used.
> Because I believe it is good for me and the whole community in the
> end. I do sympy because I very strongly believe in its potential and
> that we get to a point (and we are almost there) where I could use it
> regularly for my research. For example our recent work with Brian
> shows, that we could actually do atomic physics using only open source
> software in Python. That's very exciting.
>
> And if someone uses it in some commercial product? I believe it will
> help us, not hurt us. I believe it's about the community which is
> around sympy. Commercial product can have a community, but a different
> one --- I am pretty sure we all use sympy exactly because we have the
> source code and because it's opensource.
You can build a commercial product on top of open development. An
example of this is CodeWeavers (CrossOver -- WINE) and RedHat (RHEL --
Fedora)
I think commercial parties are ok, and essential for success, but the
whole thing works well, when there is no control in one hand, and when
parties (commercial or not) play by the same rules.
Also, since I propose we use LGPL, it would be perfectly possible to
build proprietary/closed software on top of sympy.
What's the problem with this?
> > Actually at my work, With one of my collegues, we've made an
> > observation, that usually motivated people, who are interested first in
> > developing interesting things, to achive great result, to care about the
> > project and it's ecosystem in general, and only then in money, usually
> > prefer LGPL to BSD, and on contrary side, people who tend to work for
> > money first, and care less about result, about fitting their development
> > with others, about achiving good results, pushing harder when needed,
> > prefer BSD. They usually say that "BSD is the license that companys
> > prefer, and for which they pay money"
>
> I think both ways are possible. I believe that Python itself and all
> the BSD like tools around it show that people can do BSD software and
> care about the project.
bad LGPL projects.
Every project is somewhat unique with additional balancing forces (e.g.
PostgreSQL - read below), but to mee the tendency is clear.
> > Do you see the pattern?
> >
> > LGPL, being a fair contract, is good for everyone -->
>
> Here we disagree. I respect that for you "LGPL is good for everyone".
> But for me, "BSD is just as fair for everyone".
time at evenings, and someone would just take it, work on it full-time
and enhance it, and sell it, and keep the modifications secret?
It seems we have different understanding of fairness.
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.
Another news: libgcc (The GCC low-level runtime library) is licensed by
GPL (!) + linking exception [2] and is used by every program which is
compiled with GCC !. No problem with this???
[1] http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
[2]
http://git.infradead.org/gcc.git?a=blob;f=gcc/libgcc2.c;h=5a82f82f7cd2f2e2ff8a19b157ec13529b3d8251;hb=HEAD
> > (e.g. GTK+ is LGPL'ed, and there is a lot of free and proprietary
> > software which uses it without a problem)
> >
> > --> is choosen by people who care, whereas BSD is choosen by people who
> > want money first.
>
> I understand what you mean. But I don't think that people around
> sympy, or scipy or numpy don't care and want money first. So I
> disagree with that statement.
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],
...
Other's (usually more young) just don't understand the issue and don't
care about licensing --
-- BSD is essentially a gift, and you know when you are a student you
can afford yourself to give gifts whatever way you like, and also there
was a culture in the university to share things "simply" -- this is all
good. -->
HISTORICAL REMARK: BSD-like licenses were born in the universities,
where the research and development were done on taxpayer's money, so
it was logical that the result belongs to all the taxpayers --
basically everyone -- commercial and open parties -- all the people.
That's why BSD-style licenses are so permissive -- actually BSD, MIT
and the like are very close to Public Domain.
Today most of the development is not done on taxpayer's money, so
likewise, there is no obligation for the result to stay close to
Public Domain -- that's why usually software developers who do the
actual work in their spare time are those who decide on which terms
they distribute the software.
--> But we are not in the university where there are > 95% good people, and
why would I want some bad guy to use the code I spent my time on to use
in a bad way? I say - 'use it as you like, but if you enhance it, you
cannot enjoy your advantages alone - you have to share this'. I think
this is 100% fair and thus LGPL is 100% ok with me.
[1] http://code.google.com/p/sympy/issues/detail?id=748#c25
[2] http://landau.phys.spbu.ru/~kirr/cgi-bin/hg.cgi/sympycore--hg/
[3] http://groups.google.com/group/sympy/msg/74a5c4bc7506ab68
> > Money is ok, but I even can say that usually who want money first, get
> > _less_ money than people who do care about the project in the first
> > place.
>
> Yes, I agree. I believe in american dream which says that you can get
> what you want, but you need to work hard and it may take a long time,
> but you'll get there eventually.
>
> > Also I can say that in our company we use a lot of LGPL'ed software, and
> > this is legally 100% ok, and that we even sponsor some LGPL'ed
> > development, so to me there is just no rational reason why LGPL is not
> > good for SymPy.
>
> There are pros and cons to all three BSD and LGPL and BSD. You stated
> the pros of LGPL. The cons is that LGPL creates a barrier of
> contributions, from a lot (but not all) people and also usage, because
> simply LGPL is more restrictive.
libgcc. Please answer in details about this barrier - to me it is
mythical.
2. What is the contribution barrier of LGPL? I know there are people who
hates GPL (no L) and automatically projects their attitude on LGPL,
and also that there are companies who like BSD and cultivated this
(read about it below).
But what rational is in this barrier?
Also, as you say that LGPL creates barriers, I state that BSD *TOO*
creates barriers:
Look, they say GPL is viral, and some time ago I undersood that BSD
is viral *too* -- it forces all to use BSD -- look at scipy -- they are
reluctant to take LGPL parts even it it is (maybe) legally ok to ship
combined BSD + LGPL library (part1 is BSD, part2 is LGPL)
so BSD creates barriers TOO.
This is also justifed by people like me, Gary from SAGE and others
refusing to contribute to a BSD licensing projects.
> Whenever you put more restrictions (I
> am not saying it is necessarily bad) you lose some users. So while
> LGPL is maybe good for sympy, BSD is imho better.
2. With BSD you loose (at least) some developers (me, Gary, other SAGE
people)
So why is BSD better, when LGPL being almost the same for users,
protects _developers_? Because companies can't "keep their modifications
secret"?
> > I've failed to win Ondrej's mind, and I think I'll fail to convince most
> > of you, and it makes me very sad, that so much evident common sence is
> > not accepted, that I stopped thinking to be like at home with sympy
> > recently.
>
> I am sorry about that. But I think it is not a common sence.
> > either having a rest, going for a walk, for a talk with a human you
> > love, or either to develop sympy, is _precious_.
>
> I agree with this too. We all die once, so our time is limited and so
> we should spend it very effectively.
wants to make money, he is effective in his own way.
I want sympy to be useful for me first, and to protect it from abuse.
Also I think in such a case it should be useful for people like me,
e.g. physicists.
Untill now I think I was effective in makeing SymPy useful, but not
effective in protecting SymPy from abuse.
And now I'm trying.
> > For me I just can't afford to spend that _precious_ spare time without
> > legally protecting the result from abuse.
>
> I think I understand how you feel. But as I said above, I think LGPL
> maybe protects some abuse in some situations, but definitely not all
> abuse in all situations (see my example with gmail above) and also
> from the way you look at it, I don't even thinkl it is abuse --
> depends on circumstances of course.
at least create some protection. and as i've already said LGPL is a
compromise between BSD and GPL.
I've tried to show in every possible detail, that with LGPL in fact
there is just *NO* barrier for users, and (to me) very irrational
barrier for developers + BSD creats its own barriers, while, as Andy
said LGPL protects the community.
Summary
=======
BSD is bad because weird companies can take the code and eat it and give
nothing back. Big examples are:
Microsoft, who took BSD IP stack,
Apple who took code from FreeBSD to their OSX
http://en.wikipedia.org/wiki/BSD_licenses#Proprietary_software_licenses_compatibility
Let's also look at what other developers think:
Linus: “making Linux GPL'd was definitely the best thing I ever did.”
http://en.wikipedia.org/wiki/History_of_Linux#Linux_under_the_GNU_GPL
Fernando: "I happen to actually really like the LGPL."
http://groups.google.com/group/sympy/msg/5f757166b695d35c
Gary: "I will never contribut to BSD project"
seen on IRC if I recall correctly
Gael: "Companies like BSD because they can keep their modifications
secret"
http://groups.google.com/group/sympy/msg/74a5c4bc7506ab68
Pearu: "May I propose something that is more relaxed licence model than
GPL: LGPL or BSD-like that numpy has?"
http://groups.google.com/group/sympy/msg/1a1ee12c8c2928c1
Ondrej: "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."
http://code.google.com/p/sympy/issues/detail?id=138
but then you conclude that "BSD is better than GPL"
Kirill: "I understand that licensing is only part of the game, and in
hard times I put the question on the shelve fighting against
the fork and defending SymPy, but now when I'm almost exhausted
I just cant afford myself spending _precious_ free time and
_health_ on SymPy if it is under BSD license, because companies
like M$ or Apple or someone else can take it and make it
proprietary.
I'm 100% ok for someone selling sympy, makeing proprietary
applications or other libraries on top of it, but I 100%
request for me that sympy itself must be always free as in free
speech.
LGPL is good for both: for me it's sympy protection, for
other's it's fair use, even if they want to make their products
proprietary.
It's fair, and it's a win-win for all!
Companies who benefit from BSD cultivated that "BSD is better
than GPL (and automatically LGPL)" mood just to benefit them.
When you are a student with lots of free time and energy, you
are "young and naive," and can afford yourself to ignore the
issue, but
I think when it boils down to that you have eps free time to
work on the project and you spend your health on it, you have
to think very carefully whether you can afford yourself to play
this game.
I still love SymPy very much, but the price to play this game
under BSD rules is just too high for me."
this mail
Also interesting:
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
http://www.dwheeler.com/essays/floss-license-slide.html
http://www.dwheeler.com/essays/gpl-compatible.html
http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd
In Linux kernel case, GPL effectively works like LGPL!
------------------------------------------------------
That's because we can think of the kernel like of a libary, to which we
make system calls from user space. And since GPL works only at kernel
space, user-space code can use whatever license it finds best, so see,
this
user-space | kernel-space
partitioning works similarly to
application | library,
or
library2 | library1
partitioning.
And since Linux license don't affect anything beyond that borded I claim
that in practice this works *exactly* like LGPL.
And now:
> Linus: “making Linux GPL'd was definitely the best thing I ever did.”
>
> http://en.wikipedia.org/wiki/History_of_Linux#Linux_under_the_GNU_GPL
and
> http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd
P.S. in that blog from 2006 dwheeler says that BSD projects can do fine
too, e.g. Apache.
I have news for you that now M$ is actively trying to affect apache
development:
http://lwn.net/Articles/291628/
P.P.S. BSD encourages companies to build on BSD code and hire brightest
developers, but as described in that blog entry from 2006 it's bad for
the project and it's bad for that developers in the long run.
For some time I started to think most of scipy/numpy/sympy developers
are positive about BSD because this opens job opportunities for them at
enthough/etc...
I really hope that Linux example shows that with good managment and
"must cooperate" (i.e. can't keep modifications secret) rules, talaneted
team and bright ideas, it should grow up and
set _our_ rules for companies instead of being driven by potential
sponsors wishes and desires.
This all shows that Protected-Freedom and Independence is always good.
And again, this is *weak* copyleft! Anyone can build proprietary things
on top of it!
If there are people, who share my views, please
__________________
( Vote for LGPL!!! )
------------------
o ^__^
o (oo)\_______
(__)\ )\/\
||----w |
|| ||
Thanks beforehand,
Kirill.
Appendix I
==========
For the reference here are some excerpts of our internal conversation
with Ondrej which I've edited and extended. I only quote myself so I
think this is ok.
The text is a bit sharp -- that because I call things by their names.
SymPy was already abused
------------------------
SymPy was already abused ("old new core" and [1]), and if i recall
correctly, it was me, who told you what to do ("lets do patch review")
and defended this and made everything possible to not letting the
project split.
Now I'm telling you that when we move forward, sooner or later, there
will be another kind of abuse, but you don't want to listen to me. It's
a pity and makes me sad.
[1] http://code.google.com/p/sympy/wiki/SymPyCore
Community is not weaker
-----------------------
The problem with your approach is that you implicitly assume that
community is always weakier and companies are always stronger, so it's
better to receive at least anything than nothing.
But I say, that is should be that every player plays on a common ground
-- a company, a developer, a community at large, another company -- all
must have equal rights with respect to sympy.
Freedom have to be protected
---------------------------
(1)
And when you are only in university environemtn that's ok, but I think I'm not
that dense case who got up almost up to phd in university and also to maybe the
same level in industry. And being in both this two places i can say for sure:
"freedom have to be protected" i think people part to those who know this, and
to those who will know this.
(2)
My another topic is that freedom *have* to be protected. BSD was ok in
universities when/where there was already a culture to share scientific
results, (at least after they are published).
But this days we have another situation -- there are a lot of greedy
people/companies, when SymPy matures they could take it as a start, hire
qualified developers, and run it.
We are hobbyst, it would be impossible to compete with full-time gang.
I hope you at least agree with "Fair use of SymPy". If yes, I take the
task to find relatevile easy way to make it legal and try to convince
people. ok?
On John Hunter's License Pitch
------------------------------
(http://www.scipy.org/License_Compatibility)
Grr, I'll sumarize what John pitches about LGPL:
1. many companies are still loath to use it because of their phobias
2. you cannot reuse LGPL code in a proprietary product
That's all.
My answers:
1. If a company does not understand what our license means what could we
do? All the world understands it, and if we'd put "Fair Use of Sympy"
before the license to show our spirit I think it would be clear for
99.9% of people.
2. You *can* reuse LGPL code in a proprietary product in the form of
library -- look at glibc - it is LGPL an every program reuses it. After
all good code reuse is not copy-paste, but reuse in form of libraries,
so what is the problem here??? (Yes, if you want to modify the library,
you have to share your changes, but only to the library, and other your
code stays only yours)
We all BSD, Proprietary, LGPL, GPL, DONTCARE *use* LGPL library - at
least glibc (LGPL) and libgcc (GPL + linking exception).
What's the problem?????!
LGPL is the golden median between BSD and GPL
---------------------------------------------
When I first knew about Linux and Free Software, it was a "no question"
for me that it is a good thing, and I just wanted to be part of it. And
I took it the balanced way - LGPL. For me it is absolutely ok when I use
LGPL'ed library at work when we ship proprietary software, and I just
don't understand why it is bad for others. I take BSD and GPL as
extremes in this respect, but why, just oh why the balance can't work?
LGPL examples in common use both in open and closed worlds
----------------------------------------------------------
Yes, and I've shown you other examples recently:
- winelib(LGPL) + google picassa (?) for linux (proprietary),
- gtk(LGPL) + lots of written stuff both open and closed,
- glibc (some small parts BSD, most LGPL) + everything,
- libgcc(GPL + linking exception) + everything.
On about most of scientific stuff around Python is BSD
------------------------------------------------------
Yes, it turns out most of scientific code around Python is BSD, and some of
the code was _forced_ to change it's license to BSD (IPython was
essentially _forced_ to go LGPL -> BSD [1])
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
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.
With LGPL we are _not_ forcing anyone to be of some particular license
-- software B which uses SymPy can be of esenntially _any_ license both
proprietary and open.
All we need then is good team and hard work and if we succeed they will
_have_ to use us.
But I really don;t care about whether we are in EPD.
What I care about is that SymPy is useful and fast for my physicists use
cases, and also I care about other guys problems who ask questions in a
constructive manner.
And I claim that doing so and starting from small set of goals, if we do
everything right we'll achieve greater goals. Success is _never_ planned
-- we should just do what is best for us. And it is _completey_ _fair_
to use some weak protections -- LGPL. By myself and Gary and a lot of
other developers I can say that they actually _care_ to which project to
contribute -- a lot of them tend say "will never contribute something
nontrivial to BSD."
[1]
http://projects.scipy.org/pipermail/ipython-dev/2004-October/001398.html
LGPL says "must cooperate"
--------------------------
Let's ask ourself - to help what?
If it is just used by Mathematica - that's no problem in any case -- in
BSD and in LGPL, because we explicitely allow that both in spirit and in
legal words.
But didn't Wolfram ever hit any bug in gmp? Even a small bug?
I doubt it -- no software is perfect.
So if
a) they are hitting a bug, and
b) they want to ship modified gmp
they _must_ cooperate on gmp.
Even if they don't send patches to gmp itself, they have to provide
sources to their users, and soon they should learn that maintaining lots
of patches could sometimes be problematic.
So they are essentially _forced_ to fix that bugs and contribute back.
In this sense LGPL helps, and BSD don't.
And also, should they wish to enhance gmp non-trivially they will _have_
to cooperate, because gmp is LGPL. I don't know what the probablility
for this is (Wolfram wants to enhance gmp), but I'm sure it is not zero.
And voala, all should benefit for _sure_.
BSD is in fashion
-----------------
(1)
Companies like Enthough and others who benefit from BSD code tought
some developers to "like" BSD. Some really believe BSD is better, some
just want to be in fashion and to have job oportunities.
I want fair use and freedom. (and I'm ok for others to build other
software components on top of SymPy whatever license they want,
including proprietary), so it's not viral!
(2)
I don't see much legal problems with LGPL v2 and LGPL v3 -- all problems
could be overcomed if one want this thing in spirit, but what I see now
is that new generation
"Does not want to care at all"
And all those viral BSD nature only helps it -- everyone wants to be
BSD, so there are no "legal obstacles and scary things" people could get
afraid of. That's it - most people just don't want to care because they
were taught not to, and the only lesson from history is complete
oblivion of all of its lessons, its only ~ 20 year ago, all the world
was "proprietary"...
Kirr wants protection
---------------------
(1)
Look at me, Fernando, Gary etc.
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. So you see, at
least from me and Gary "BSD is less patches," and also Fernando says he
likes LGPL very much, so I'm grateful to Pearu that he started his fork
-- I had to overwork myself and feel very strongly that the issue must
be resolved or I have to stop spending my time.
I don't want to force anyone, but also I don't want to force myself to
play by the rules I can't accept.
(2)
Because I don't want SymPy freedom to depend on us always being good
managers and always being full of time and energy etc.
I want protection and insurance, that in no case it goes proprietary.
Why? Becasue I've put and I want to put my energy and my soul into the
project, but I can't afford myself for SymPy to go proprietary or be
forked or be used unfair and I want to be 100% sure.
So not "why not LGPL," but I myself subjectively want a _must_ have
protection. For sure, 100%.
(3)
As I'm telling you all the time, BSD is ok for proprietary closed forks.
LGPL protects and enourage to give back.
Now with good management we'll have better chances to run, but even if
we fail at management, or will run completely out of time, or someone of
us is hired by e.g. Enthough,
SymPy always stays independent and free as in free speech.
With BSD they could hire some key developer(s) for full-time job and
tell them control SymPy -- _they_ will decide whether SymPy stays open
or closed. Developers are just "engenieers".
I think if I care about the project, I have to protect it from the above
scenario, and so I think you'd better too.
(4)
You ask "why LGPL?", the answer is that
LGPL does guarantee that something stays free as in free speech always.
In contrast BSD does not provide such guaranties - one can jump to
proprietary at any point.
(5)
But doing things right is always harder than flowing along the stream...
Unfortunately to prove myself right I'd need two things:
1. a lot of time passed to see what way SymPy evolves and how it is used
2. realized probability that SymPy is misused.
I don't have this two, and I admit that good managment could keep BSD
only project out of bad guys too, but this managment should be *really*
good and have to last forever...
Kirr thinks the same as DWheeler
--------------------------------
But isn't the following just my imagination?
Company X hires key developer Y.
Y develops advanced features that go to X's product only. It takes users
from 'open' version of the project and starting from some time you
either have to re-implement what Y did in their private branch or
somehow join them.
This is extreme case, but I think not so impossible.
Why companies like BSD and why LGPL should be good for them too
---------------------------------------------------------------
I know Google prefer BSD or X11 or whatever is equivalent.
They do so here like Enthough -- to have the ability to get the code at
any point and close it and make benefits from it.
I'm not saying they will do so, they try to do it socially first -- to
get momentum and benefit, but when things comes to serious competiotion
they will do so, I'm sure.
My example was that LGPL allowed Google perfectly ok to build its
proprietary product on top of WINE and that's ok for all.
If SymPy was first developed by some company it was that company choice
which license to use, but when it is developed by individauls I think
_we_ choose.
And you know I advocate for choosing for balanced protection.
On PostgreSQL
-------------
As to PostgreSQL - yes, it's BSD, but it was originated first in BSD
environment and now PG core developers team _carefully_ avoid working in
one company -- to keep the balance and independence.
So in PG case they managed to keep it up and running and be independent,
but I think everything would be simpler if it will be LGPL.
Too often I hear from people that they would not contribute to a BSD
licensed project exactly because of the reasons I think, and this is not
only around SciPy.
EPD can ship LGPL
-----------------
So my point is this:
a. for immediate users it is equally both good to have either BSD or
LGPL
b. but for users starting to be developers, and developers who put their
soul into a thing, it is important that the software stays free as in
free speech.
So if LGPL is ok for users, and LGPL protects software, what's wrong
with it?
They usually just compare BSD with GPL, and don't look at the golden
median. Some becase they don't understand the topic, others because they
want to benefit from BSD:
o companies: they can keep control on the code and release BSD+their
modifications closed, and tie customers to them
o developers: some of them want to be hired/contracted by such
companies, and thus they play by their rules.
I think _we_ should set the rules, not some company, and if _we_ manage
SymPy to be succcessful product, EPD would just be _forced_ to ship it.
It's just bullshit they can't ship LGPL.
Robert Kern
> EPD can ship LGPL
> -----------------
I'm not sure who is telling you that we can't. It's just not true. We
can and do ship LGPL and some GPLed packages. As a rule, we do prefer
BSD-licensed packages, though.
> I think _we_ should set the rules, not some company, and if _we_ manage
> SymPy to be succcessful product, EPD would just be _forced_ to ship it.
Huh. And I thought we were talking about freedom, here...
Brian Granger
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...
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.
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
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.
Thus, I am +1 on keeping sympy as BSD.
But, one question:
If sympy becomes LGPL, what license restrictions would my code have if
I subclass sympy.Basic?
Cheers,
Brian
Kirill Smelkov
>
> 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.
> 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.
An example of this are common libraries, e.g. GLibc (LGPL), libgcc (GPL
+ linking exception), WineLib (LGPL) -- which are used by both open and
closed software without _any_ problem.
This particular property makes LGPL good to me and to other people -- it
does not dictate software users which license to use.
This is covered in details in my original post:
http://groups.google.com/group/sympy/msg/c405c091076f6cfa
Also please read about it here:
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
--
Kirill
Kirill Smelkov
>
> On Sat, Nov 15, 2008 at 18:07, Kirill Smelkov <ki...@landau.phys.spbu.ru> wrote:
>
> > EPD can ship LGPL
> > -----------------
>
> I'm not sure who is telling you that we can't. It's just not true. We
> can and do ship LGPL and some GPLed packages. As a rule, we do prefer
> BSD-licensed packages, though.
Ok, we all do mistakes. If you can and ship LGPL -- MY APPOLOGIZES --
and I'm glad you do it.
> > I think _we_ should set the rules, not some company, and if _we_ manage
> > SymPy to be succcessful product, EPD would just be _forced_ to ship it.
>
> Huh. And I thought we were talking about freedom, here...
Yes, we are talking about freedom here -- freedom for users when they
receive software to run, study, modify and redistribute it.
When I say "forced" I mean "if a package is popular enough, and there is
users demand for it, popular distributions would just pick it."
In no way I disregard your freedom here.
--
Kirill
Kirill Smelkov
> 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*)
kirr@roro3:~$ which python
/usr/bin/python
kirr@roro3:~$ ldd /usr/bin/python
linux-gate.so.1 => (0xb7fa0000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7f69000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7f65000)
libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7f60000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7f3a000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7ddf000)
/lib/ld-linux.so.2 (0xb7fa1000)
Python is BSD-like licensed, while at least libptherad.so.0, libdl.so.2,
libutil.so.1, libm.so.6, libc.so.6 and ld-linux.so.2 are licensed under
"LGPL + credits for some small parts". On Debian system the exact terms
are here:
/usr/share/doc/python/copyright
/usr/share/doc/libc6/copyright
--
Kirill
Ondrej Certik
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
Ondrej Certik
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.
But it won't. LGPL will not at all give you 100% of protection. You
listed some examples of abuse (and I agree with you that I don't like
that either!), but LGPL will not at all help. Let me list it:
[story about your colleague not contributing his changes back]
> This story is imaginary, but I think it fairly well illustrates
> qualitively the situation I have in mind.
LGPL will not help, because he was not redistributing the code.
[your version of fair use]
> But if you change SymPy itself -- you have to share your modifications
> to SymPy, your other code still stays yours.
LGPL will only help if they redistribute the code and (see Brian's
email) it may only help sometimes. In all other cases, e.g. buildling
a web application, LGPL will *not* help us. 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.
> As to you statement - yes, I don't care about someone keeping private
> modifications without redistributing them -- all I care about is
> redistribution, and this is covered by LGPL.
Well, it is in direct contradiction to what you said above about your
physics colleague -- he was keeping it secret without redistributing
and you *did* care a lot. I agree that redistribution is covered by
LGPL to some extent (but see Brian's email).
> I can't say about VTK, because I don't know this area, and also I admit
> there are good projects under BSD license but wouldn't the same work if
> VTK would be LGPL'ed?
Maybe it would, but the point is that BSD works too.
[Wolfram and gmp]
> Even if they don't send patches to gmp itself, they have to provide
> sources to their users, and soon they should learn that maintaining lots
> of patches could sometimes be problematic.
>
> So they are essentially _forced_ to fix that bugs and contribute back.
>
> In this sense LGPL helps, and BSD don't.
LGPL neither. As far as I am aware, Wolfram doesn't contribute back to
gmp. Correct me if I am wrong.
> Yes, such kind of thing exists. Let's try to agree on our terms "in
> spirit" first -- if we do - we'll work all the technical and wording
> details out. Is my "Fair use of SymPy" ok? If so, let's just adopt
> closest existing solution on license market which is not-intrusive.
>
> Agree?
Yes, but we should only choose between well-known licenses, which are
MIT, BSD, LGPL, GPL, and maybe Apache.
And yes, let's discuss the "spirit" first. As I said above, I
completely disagree with the spirit you wrote, because you require
anyone to share the changes back. That is like the requirement of
scientific citation:
http://people.debian.org/~bap/dfsg-faq.html#citations
such a license is not free and would go to Debian non-free.
> Also, since I propose we use LGPL, it would be perfectly possible to
> build proprietary/closed software on top of sympy.
>
> What's the problem with this?
The problem is that most people around SymPy and scientific computing
in Python prefer BSD.
What is your problem with BSD? LGPL will not protect you as I
described above either.
> Companies like Enthough and others who benefit from BSD code tought
> some developers to "like" BSD. Some really believe BSD is better, some
> just want to be in fashion and to have job oportunities.
Enthought didn't teach me to like BSD.
> 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).
> 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!
> 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.
> 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 doi
> 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.
> 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. 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. You know that when we developed pyqm
as an addon to sympy with you:
http://code.google.com/p/pyqm/
because there were only you and me as developers and I don't mind any
license. But in SymPy it is not just about you and me. So whatever
license we choose, it needs to have support in our community. As I see
it currently, LGPL doesn't have such support as BSD.
Ondrej
Ondrej Certik
>> 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 doi
... 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.
> that?) could have other license. You know that when we developed pyqm
> as an addon to sympy with you:
>
> http://code.google.com/p/pyqm/
>
> because there were only you and me as developers and I don't mind any
Forgot to add that pyqm uses LGPL. Just as an example that I don't
mind either license.
Ondrej
Kirill Smelkov
My "Fair use of SymPy" requres more -- in any case to share changes to
SymPy itself when the code is distributed.
> >> 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?
No, as I understand it, it should be LGPL.
> 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?
As I've said many time already, for me the point in LGPL is that the
whole result can't be abused, i.e. always stays open, and in no
circumstances is distributed with private modifications applied and kept
in secret.
If I'm alone in this - no problem. Let's not waste time and put all
accents on i.
Kirill
Ondrej Certik
>> 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.
>
> My "Fair use of SymPy" requres more -- in any case to share changes to
> SymPy itself when the code is distributed.
Ah, ok. I thought you mean the Fair use of SymPy that we currently
have in our README. As I stated in my other email, I do not share your
new Fair use.
>
>> >> 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?
>
> No, as I understand it, it should be LGPL.
>
>> 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?
>
> As I've said many time already, for me the point in LGPL is that the
> whole result can't be abused, i.e. always stays open, and in no
> circumstances is distributed with private modifications applied and kept
> in secret.
>
> If I'm alone in this - no problem. Let's not waste time and put all
> accents on i.
Ok, imagine I am the greedy company that you want to protect against.
Imagine sympy is LGPL. What prevents me to keep my modifications and
additions to sympy private using the technique of separate files (thus
they don't have to be LGPL) and patching SymPy classes on the fly (at
runtime)? I know that for you the point of LGPL is to prevent this. My
point is that LGPL doesn't prevent this.
Ondrej
Kirill Smelkov
>
> >> 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.
> >
> > My "Fair use of SymPy" requres more -- in any case to share changes to
> > SymPy itself when the code is distributed.
>
> Ah, ok. I thought you mean the Fair use of SymPy that we currently
> have in our README. As I stated in my other email, I do not share your
> new Fair use.
Would it be ok if we correct fair use to only work when the code is
redistribured?
You can patch python files at runtime and it is perfectly ok with me,
since Python is a dynamic language where such interface is allowed.
Actually in this case you would use the _interface_ provided by our
library.
Also, since only library interface is used, it is ok with LGPL.
But how would you patch at runtime, compiled modules?
Also, patching at runtime is not always possible technically, i.e.
usually you can't do nontrivial patching.
--
Kirill
Kirill Smelkov
>
> 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?
> But it won't. LGPL will not at all give you 100% of protection. You
> listed some examples of abuse (and I agree with you that I don't like
> that either!), but LGPL will not at all help. Let me list it:
>
> [story about your colleague not contributing his changes back]
> > This story is imaginary, but I think it fairly well illustrates
> > qualitively the situation I have in mind.
>
> LGPL will not help, because he was not redistributing the code.
Yes, LGPL would not help here, but I wanted to show the spirit, and most
of the companies want to redistribute the code (i.e. when they sell it),
so LGPL would work here.
> [your version of fair use]
> > But if you change SymPy itself -- you have to share your modifications
> > to SymPy, your other code still stays yours.
>
> LGPL will only help if they redistribute the code and (see Brian's
> email) it may only help sometimes.
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:
kirr@roro3:~$ 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.
> In all other cases, e.g. buildling a web application, LGPL will *not*
> help us.
As I understand it, today there is a no DFSG-free license which protects
from such kind of abuse, so we just have to use the best thing from what
is awailable.
> 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.
"""
> > As to you statement - yes, I don't care about someone keeping private
> > modifications without redistributing them -- all I care about is
> > redistribution, and this is covered by LGPL.
>
> Well, it is in direct contradiction to what you said above about your
> physics colleague -- he was keeping it secret without redistributing
> and you *did* care a lot. I agree that redistribution is covered by
> LGPL to some extent (but see Brian's email).
see above.
> > I can't say about VTK, because I don't know this area, and also I admit
> > there are good projects under BSD license but wouldn't the same work if
> > VTK would be LGPL'ed?
>
> Maybe it would, but the point is that BSD works too.
Yes, in my main email I've said that there are too good BSD projects and
bad LGPL ones.
There are exceptions from every rule and from every pattern.
> [Wolfram and gmp]
> > Even if they don't send patches to gmp itself, they have to provide
> > sources to their users, and soon they should learn that maintaining lots
> > of patches could sometimes be problematic.
> >
> > So they are essentially _forced_ to fix that bugs and contribute back.
> >
> > In this sense LGPL helps, and BSD don't.
>
> LGPL neither. As far as I am aware, Wolfram doesn't contribute back to
> gmp. Correct me if I am wrong.
If they don't need to enhance gmp - that's ok with me -- GMP is just
used.
> > Yes, such kind of thing exists. Let's try to agree on our terms "in
> > spirit" first -- if we do - we'll work all the technical and wording
> > details out. Is my "Fair use of SymPy" ok? If so, let's just adopt
> > closest existing solution on license market which is not-intrusive.
> >
> > Agree?
>
> Yes, but we should only choose between well-known licenses, which are
> MIT, BSD, LGPL, GPL, and maybe Apache.
>
> And yes, let's discuss the "spirit" first. As I said above, I
> completely disagree with the spirit you wrote, because you require
> anyone to share the changes back. That is like the requirement of
> scientific citation:
>
> http://people.debian.org/~bap/dfsg-faq.html#citations
>
> such a license is not free and would go to Debian non-free.
This thing was corrected.
Please see "Fair use of SymPy v0.2" above.
> > Also, since I propose we use LGPL, it would be perfectly possible to
> > build proprietary/closed software on top of sympy.
> >
> > What's the problem with this?
>
> The problem is that most people around SymPy and scientific computing
> in Python prefer BSD.
>
> 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.
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.
----
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:
Copyright (c) 2006, 2007, 2008 SymPy Development Team
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
a. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
b. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
c. 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.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
> > Companies like Enthough and others who benefit from BSD code tought
> > some developers to "like" BSD. Some really believe BSD is better, some
> > just want to be in fashion and to have job oportunities.
>
> Enthought didn't teach me to like BSD.
I think this chain was with multi nodes.
> > 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?
> > 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.
But for me it's very strange that we understood each other in almost all
areas with the only exception being licensing.
> > 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?
> > 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.
> > 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.
> > 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).
> 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).
> You know that when we developed pyqm
> as an addon to sympy with you:
>
> http://code.google.com/p/pyqm/
>
> because there were only you and me as developers and I don't mind any
> license. But in SymPy it is not just about you and me. So whatever
> license we choose, it needs to have support in our community. As I see
> it currently, LGPL doesn't have such support as BSD.
Maybe, but first I'd like to hear what other SymPy developers think.
Guys, even if you prefer BSD, or LGPL or whatever, please state it
clearly, what licensing terms are ok with you.
--
Kirill
Riccardo Gori
Hello,
I prefer the LGPL licence, but my contributions to sympy are so small that I
don't mind too much about protecting my code from being "abused" by someone.
On the contrary Kirill contributions are big, so I totally understand his
point.
So +1 LGPL.
Riccardo
Ondrej Certik
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.
On Sun, Nov 16, 2008 at 3:02 PM, Kirill Smelkov
<ki...@landau.phys.spbu.ru> 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.
> 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:
>
> kirr@roro3:~$ 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.
>> 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.
>> 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.
>
> 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.
>> > 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.
>> > 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.
>> 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.
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.
Ondrej
ggellner
haven't contributed anything at all).
I prefer GPL/LGPL like licenses. Partially this is the spirit, but
mostly this is pragmatism.
As I user I don't care at all about these licensing issues, but I do
care about the hassle of having fragmented code because of license
arguments. Though the BSD is `more free`, to keep this purity it most
ignore all LGPL/GPL code like in the scipy community creating ghetto's
like the scikits, and great projects like cvxopt (by which I mean that
fundamental pieces of code are not put into scipy/numpy because of
needing only BSD like). This has also occurs in the matplotlib world.
For me the greatest sin is not being able to use R algorithms/code
which is the best of breed for statistics, so we reinvent the wheel,
or not at all, leaving the python ecosystem poorer as a result. So
their is still an agenda from my view from BSD like licenses, what is
nice about the [L]GPL licenses from my viewpoint is because it is the
most restricted I can look a the most code and use it, with BSD to
keep to ecosystem super free I can not, and we all suffer because of
this.
Now since the LGPL is intermediate to the GPL this may not be a big
issue in the CAS problem domain, it could be that things are either
BSD-like or GPL-like in which case the LGPL doesn't help in the way I
care about. I think this would be the best way to look at the problem:
see what could be possibly used/ported in the future and see if this
jives with the license that sympy is put under. I see this as one of
the great strengths of the SAGE communities use of the GPL. Otherwise
sympy will have to do what the scipy/numpy/matplotlib worlds have done
which as a user I find very annoying.
Gabriel
Kirill Smelkov
>
> Hi Kirr,
>
> 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
> <ki...@landau.phys.spbu.ru> 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'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.
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?
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
William stein
On Nov 15, 5:15 pm, "Robert Kern" <robert.k...@gmail.com> wrote:
> > EPD can ship LGPL
> > -----------------
>
> I'm not sure who is telling you that we can't. It's just not true. We
> can and do ship LGPL and some GPLed packages. As a rule, we do prefer
> BSD-licensed packages, though.
http://www.enthought.com/products/epdlicense.php
seems to me to be GPL incompatible, since I think the GPL does not
allow
one to so restrict redistribution of binaries of GPL'd software. In
particular,
were EPD to include GPL'd code, I think Enthought would be in
violation of
section 6e of the GPL. http://www.gnu.org/copyleft/gpl.html
I'm just a curious bystander asking a question; I'm not making any
claims or accusations!
-- William
Ondrej Certik
>> 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?
We can use any license that we agree upon.
>> 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?
Ondrej as developer.
>> 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
Excellent, I am glad to hear it.
> 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")
Kirr, isn't this exactly what you are fighting against? You first
stated how you didn't like that your physics colleague took your code
and didn't contribute anything back (I agree) and now you want to do
exactly the same thing! Take sympy code, put more restrictions on it
and then redistribute your changes, so that the original project
cannot use it.
Yes, BSD allows that, and yes, LGPL allows that too --- I can then
take your LGPL changes, make your whole repository GPL and say --
kirr, take these fixes, but you need to change to GPL. And let me say
that I don't find such a behavior polite.
So we are back at what I am saying all the time ---- the license
itself doesn't help against bad behavior. It's not about license, it's
about the community.
> 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.
I very strongly believe we should have only one project and work on it
and we should choose a license that best fit into our atmosphere.
Now let's wait for more developers and users to express their opinions
and I hope we can agree on common interests and find a solution. If
not, I'll make a decision which license my own releases are going to
use. And currently I am clearly for staying with BSD.
Ondrej
Brian Granger
> 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
No I don't mean that. While some legal documents are difficult to
understand because of legal jargon, that is not the main problem I
have with the GPL/LGPL. The problem is that their *interpretation* is
complex. A few examples:
* In a previous email you gave an example (the 2 physicists) intending
to show how the LGPL would provide certain kinds of protections. Yet,
as pointed out, the LGPL doesn't provide the protections you said it
would. In my mind, this shows that the LGPL is sufficiently complex
that even people who advocate for it can't keep it straight what it
actually says. I know, you will probably counter and say that this
was a bad/careless example, but that is my point - it is too easy for
all of us to get confused about what these licenses say. I know - I
have done this countless times myself.
* At some point in the last year, I was at a large, high profile
national meeting, where a core developer of a large GPL'd project was
giving a talk. Someone in the audience (who was not familiar with the
GPL) asked "what license restrictions will there be on my code if it
uses your GPL'd project." The speaker replied "none whatsoever, you
can do whatever you want with your code." There are a dozens of ways
of explaining this away, however, this is really what the speaker
said. Again, these licenses are complicated enough that even projects
who use the licenses can't keep it all straight.
* The only way of deciding which interpretation of a legal document is
correct is to have it tested in court. Because the subtle areas of
the GPL/LGPL have not been tested in court (please correct me if I am
wrong), it doesn't really matter to me that the LGPL has been around
and used for 15 years. That won't help me one bit if there is ever a
court ruling that goes against my interpretation of the license. To
me this involves risk that must be accounted for in these decisions.
BSD like licenses have very few grey areas.
Brian
Robert Kern
>
> On Nov 15, 5:15 pm, "Robert Kern" <robert.k...@gmail.com> wrote:
>> On Sat, Nov 15, 2008 at 18:07, Kirill Smelkov <k...@landau.phys.spbu.ru> wrote:
>> > EPD can ship LGPL
>> > -----------------
>>
>> I'm not sure who is telling you that we can't. It's just not true. We
>> can and do ship LGPL and some GPLed packages. As a rule, we do prefer
>> BSD-licensed packages, though.
>
> If that is true, is Enthought violating the GPL? The EPD license at
> http://www.enthought.com/products/epdlicense.php
> seems to me to be GPL incompatible, since I think the GPL does not
> allow
> one to so restrict redistribution of binaries of GPL'd software. In
> particular,
> were EPD to include GPL'd code, I think Enthought would be in
> violation of
> section 6e of the GPL. http://www.gnu.org/copyleft/gpl.html
>
> I'm just a curious bystander asking a question; I'm not making any
> claims or accusations!
The license is for the collection of binaries as a whole. Each
individual package has its own license, and we will provide the
sources for the GPLed and LGPLed packages if asked. We should just
have the tarballs up on the download site, and I believe we will
eventually do just that. Currently, I believe this is just mingw on
Windows, and we simply repackage the official upstream binaries.
IANAL, but I believe that this falls under "mere aggregation". This
term is not clearly defined in GPLv2, the operative license for this
version of GCC, but the FSF clarified it somewhat in GPLv3.
"""
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
"""
Once you have EPD, you have the same rights to the individual GPLed
and LGPLed packages as you would if you had gotten them separately.
The collection as a whole is a related, but distinct, entity and has
its own copyright.
I believe (but can't be certain) that OpenBSD includes or has included
at least GCC on its official CD sets. Theo holds a copyright on the
layout of the CDs and restricts redistribution of the CD layout in
much the same way.
Kirill Smelkov
This are *different* things. My code is always available, on fair terms
from my point of view, and the code is always free, and ready for use --
for example you could use it in an BSD application which uses such
LGPL'ed sympy + other BSD library.
> Yes, BSD allows that, and yes, LGPL allows that too --- I can then
> take your LGPL changes, make your whole repository GPL and say --
> kirr, take these fixes, but you need to change to GPL. And let me say
> that I don't find such a behavior polite.
Yes, from some point of view that's impolite, but that what the license
allows, and that's life.
Besides that, a lot of current sympy code was contributed by me, so it's
not like I take someone other's work, but like I take my work + other's
work covered by permissive license (then why in the first place you used
such a permissive license?) and continue working on it on my own terms.
And yes, you can take my code, and enhance it and put into GPL, and I
think that's fair. What is also fair, is that you'll can't put my
modified code into proprietary product and ship it - you'll either have
to:
- redistribute your changes to my code under LGPL to your customer
- upgrade the license to GPL and distribute the whole thing to customer
(but in this case, you can't put one part into GPL and other part into
proprietary license - GPL disallows this)
So the code always stays free, not proprietary.
Sure, you can think of it like a "crazy" Kirr, but isn't this a possible
scenario with subs(Kirr, SomeCompany)? Only some companies would not use
LGPL and would not send merge request emails.
Do you see the difference?
> So we are back at what I am saying all the time ---- the license
> itself doesn't help against bad behavior. It's not about license, it's
> about the community.
Yes, it about the community, right.
The license is one force which could protect that community from one
kind of "abuse", but not from all kinds. I'm not saying changing the
license would make us all immediatelly happy, but that kind of abuse I'm
talking about is real, sooner or later, so we'd better plug it, and
start doing other, more pleasant things, e.g. developing sympy itself.
> > 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.
>
> I very strongly believe we should have only one project and work on it
> and we should choose a license that best fit into our atmosphere.
>
> Now let's wait for more developers and users to express their opinions
> and I hope we can agree on common interests and find a solution. If
> not, I'll make a decision which license my own releases are going to
> use. And currently I am clearly for staying with BSD.
I too strongly believe in cooperation, and that we should have just one
project. That's why I've put every effort to compete with sympycore and
make it irrelevant today.
Saying unpleasant words is a dirty work, but someone have to do it one
way or another, always.
My understanding is that through SymPy developers I'm not alone in my
views, though I'm far not sure.
I've tried to say it all -- LGPL gives:
o Protection for the development community and for SymPy -- it always
stays Free Software.
o Loyality for users -- they are not forced to use any particular
license for their software which uses SymPy.
To me this is the perfect and fair balance, and I hope I'm not alone.
--
Kirill
Brian Granger
> care about the hassle of having fragmented code because of license
> arguments. Though the BSD is `more free`, to keep this purity it most
> ignore all LGPL/GPL code like in the scipy community creating ghetto's
> like the scikits, and great projects like cvxopt (by which I mean that
> fundamental pieces of code are not put into scipy/numpy because of
> needing only BSD like). This has also occurs in the matplotlib world.
> For me the greatest sin is not being able to use R algorithms/code
> which is the best of breed for statistics, so we reinvent the wheel,
> or not at all, leaving the python ecosystem poorer as a result. So
> their is still an agenda from my view from BSD like licenses, what is
> nice about the [L]GPL licenses from my viewpoint is because it is the
> most restricted I can look a the most code and use it, with BSD to
> keep to ecosystem super free I can not, and we all suffer because of
> this.
While I agree with you that it is a shame that there is fragmented
code because of license differences, I disagree that the blame lies
with the BSD license.
Using this same argument, can I assume that you think it is the BSD's
fault that numpy/scipy can't simply distribute/ship proprietary
things.
Vinzent Steinberg
by Apple. There were patches from Apple, but they could not be
integrated because they were too big and to Mac-specific. Years later
the fork became Webkit, and KHTML did not really profit from the
changes Apple made.
Why am I writing this? Because it shows that LGPL cannot force people
to cooperate. There is no license able to do that.
> When you mix GPL here, you create confusion, and I think that confusion
I think what I said holds for LGPL too, but that's not important.
Please don't take me too serious about this, I really don't care much
about licenses. I would slightly prefer BSD, but I'd be very fine with
LGPL too. Maybe this is the arrogance of the young and unexperienced;
I did not contribute as much as you to sympy. The license is not
important for me, as long as it's Open Source.
I care about people. So I would rather work with you, Kirill, than to
argue about licenses. :) If you feel so strong about LGPL, this is
much more important to me than having BSD.
Thus I'm +1 for LGPL.
Vinzent
Kirill Smelkov
On Sun, Nov 16, 2008 at 10:14:39AM -0800, Brian Granger wrote:
>
> > 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
>
> No I don't mean that. While some legal documents are difficult to
> understand because of legal jargon, that is not the main problem I
> have with the GPL/LGPL. The problem is that their *interpretation* is
> complex. A few examples:
>
> * In a previous email you gave an example (the 2 physicists) intending
> to show how the LGPL would provide certain kinds of protections. Yet,
> as pointed out, the LGPL doesn't provide the protections you said it
> would. In my mind, this shows that the LGPL is sufficiently complex
> that even people who advocate for it can't keep it straight what it
> actually says. I know, you will probably counter and say that this
> was a bad/careless example, but that is my point - it is too easy for
> all of us to get confused about what these licenses say. I know - I
> have done this countless times myself.
Yes, I was not careful enough to adjust it to LGPL. I've just wanted to
show the spirit, and also I'm very overworked - it was not from
misunderstanding -- it took me the whole day to compose that main mail,
and like no software is perfect, neither was my first iteration.
Some years ago I've carefully read both GPLv2 and LGPLv2, and though I
don't remember the exact words, all my understanding up to this day
about LGPLv2 in essence is "Fair use of SymPy v0.2":
"""
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.
(plus there are words about providing object files for relinking,
with newer version of the library, but for dynamically loaded
libraries this is not relevant)
"""
And also the same says Wikipedia page:
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
(note "Linking from code with a different license: Yes" for LGPL. for
GPL it is "No")
And also the same says practice (glibc, winelib, gtk+, cairo, other
LGPL'ed libraries)
> * At some point in the last year, I was at a large, high profile
> national meeting, where a core developer of a large GPL'd project was
> giving a talk. Someone in the audience (who was not familiar with the
> GPL) asked "what license restrictions will there be on my code if it
> uses your GPL'd project." The speaker replied "none whatsoever, you
> can do whatever you want with your code."
Then _that_ speaker was not correct, becase GPL does not allow "doing
whatever you want with your code" -- it wants your code under GPL too:
http://en.wikipedia.org/wiki/GNU_General_Public_License
("Linking from code with a different license: No")
> There are a dozens of ways
> of explaining this away, however, this is really what the speaker
> said. Again, these licenses are complicated enough that even projects
> who use the licenses can't keep it all straight.
Yes, law is difficult area. laws and licensing and copyright and trade
marks are even a bit slightly different in different countries, but even
if we consider US, it's law system was patched along ~ 200 years.
Needless to say, that it's a mess now :)
Seriously though - yes, it is difficult to understand GPL and LGPL
correctly, but this is definitely possible. For full correctness law
education is nesseccary. But we, developers can understand it too, and
there are a lot of developers to whom I personally trust who analyzed
those documents too, and got it spirit exactly like me.
So I have some confidence I've got GPL and LGPL right for common cases.
> * The only way of deciding which interpretation of a legal document is
> correct is to have it tested in court. Because the subtle areas of
> the GPL/LGPL have not been tested in court (please correct me if I am
> wrong), it doesn't really matter to me that the LGPL has been around
> and used for 15 years. That won't help me one bit if there is ever a
> court ruling that goes against my interpretation of the license. To
> me this involves risk that must be accounted for in these decisions.
> BSD like licenses have very few grey areas.
GPL was actually tested in court quite a bit:
http://www.heise-online.co.uk/news/GPL-violation-by-Skype-re-affirmed-by-court--/110703
and
http://www.gpl-violations.org/ e.g.
http://www.gpl-violations.org/news/20041024-linux-tomtom.html
http://www.gpl-violations.org/news/20060210-svc-gesundheitskarte.html
http://www.gpl-violations.org/news/20050601-targa-lidl-notebook.html
...
although I admit I can't find LGPL testing in court right now.
I think asking SFLC could help:
http://www.softwarefreedom.org/
Also interesting:
http://lwn.net/Articles/294767/
http://www.softwarefreedom.org/resources/2008/compliance-guide.html
--
Kirill
Riccardo Gori
> On 16 Nov., 01:07, Kirill Smelkov <k...@landau.phys.spbu.ru> wrote:
> > Yes, Wine is a good example.
>
> There is another example: KHTML. They are using LGPL and were forked
> by Apple. There were patches from Apple, but they could not be
> integrated because they were too big and to Mac-specific. Years later
> the fork became Webkit, and KHTML did not really profit from the
> changes Apple made.
> Why am I writing this? Because it shows that LGPL cannot force people
> to cooperate. There is no license able to do that.
But now we have WebKit, and "anyone" can use it because it's LGPL. If KHTML
were BSD probably now we would have another close source Web Engine!
> > When you mix GPL here, you create confusion, and I think that confusion
> > is the first step towards creating FUD (Fear, Uncertainty and Doubt).
>
> I think what I said holds for LGPL too, but that's not important.
> Please don't take me too serious about this, I really don't care much
> about licenses. I would slightly prefer BSD, but I'd be very fine with
> LGPL too. Maybe this is the arrogance of the young and unexperienced;
> I did not contribute as much as you to sympy. The license is not
> important for me, as long as it's Open Source.
>
> I care about people. So I would rather work with you, Kirill, than to
> argue about licenses. :) If you feel so strong about LGPL, this is
> much more important to me than having BSD.
>
> Thus I'm +1 for LGPL.
>
>
> Vinzent
Riccardo
Sebastian Haase
I'm not a sympy developer. I am working for many years with numpy and
have recently registered a google code project based in this.
I wanted to say that the BSD license seemed fine with we me for a long time.
But in general I would like to say that LGPL has some "felling" to it
that I often thought would be preferable.
Could someone please summarize (again) the risks and/or disadvantages of LGPL
from a COMPANY POINT OF VIEW !?
Or, in other words, who would be thrown off by LGPL ?
Thanks,
Sebastian Haase
ggellner
> While I agree with you that it is a shame that there is fragmented
> code because of license differences, I disagree that the blame lies
> with the BSD license.
>
> Using this same argument, can I assume that you think it is the BSD's
> fault that numpy/scipy can't simply distribute/ship proprietary
> things.
>
LOT of GPL science code, forcing BSD because it is more free is an
agenda), I simply mean pragmatically using the GPL allows the largest
set of open source code to be incorporated. BSD is great, but being
less restrictive, it is functionally MORE restrictive for what I can
use if I want to redistribute things, this is the case in numpy/scipy
and is not the case for SAGE, octave, R, and many other successful
open source projects. So the lack of proprietary code is a different
issue, I think it is fair to say that most open source code is either
BSD-like, LGPL-like or GPL-like going with the most restrictive of
these that you can handle allows for the most reuse.
If everything was BSD I wouldn't care, but it is not, and R, SAGE,
Giniac, Maxima, FFTW, GSL are not going away and in many cases have
more users than the python libraries. We are taking a hard stance that
forces a lot of code to be rewritten.
Gabriel
Gael Varoquaux
> Could someone please summarize (again) the risks and/or disadvantages of LGPL
> from a COMPANY POINT OF VIEW !?
Have you actually talked to companies? I know, it sounds stupid, and
irrantional, and I can't even repeat the arguments because I don't
understand them. But try to talk to companies.
> Or, in other words, who would be thrown off by LGPL ?
I can't mention names, I am not allowed, but most of the companies I know
about which there has been negociations.
One thing, thought: companies value their R and D very very badly. They tend
to be irrational about these things (for instance pretty much preventing
their employees from working because of the security constraints they put
upon them). So when the software is used for R and D, I suspect they go
berseck. If you haven't worked in the R and D departement of a big
company, you have no clue what it is like.
Gaël
Brian Granger
> LOT of GPL science code, forcing BSD because it is more free is an
> agenda), I simply mean pragmatically using the GPL allows the largest
> set of open source code to be incorporated. BSD is great, but being
> less restrictive, it is functionally MORE restrictive for what I can
> use if I want to redistribute things, this is the case in numpy/scipy
> and is not the case for SAGE, octave, R, and many other successful
> open source projects.
projects that I would love to use in IPython, but I can't as IPython
is BSD.
> So the lack of proprietary code is a different
> issue, I think it is fair to say that most open source code is either
> BSD-like, LGPL-like or GPL-like going with the most restrictive of
> these that you can handle allows for the most reuse.
> If everything was BSD I wouldn't care, but it is not, and R, SAGE,
> Giniac, Maxima, FFTW, GSL are not going away and in many cases have
> more users than the python libraries. We are taking a hard stance that
> forces a lot of code to be rewritten.
is the GPL that draws the line in the sand and says "our way and our
agenda or code it yourself."
Brian
> Gabriel
>
> >
>
Brian Granger
The company writes proprietary code for high performance computing
and computational physics. However, the company also collaborates
with dozens of open source projects. Here is a short summary of their
perspective (this is my reading of the *company wide feelings* - these
are not necessarily my own feelings).
* They recognized great value in open source in being able to use open
source projects.
* They always gave back modifications of open source code to the
projects, regardless of the license.
* They wanted AND needed to be able to build proprietary software
products and thus completely avoided GPL code.
* Projects with BSD-like licenses were just fine.
* LGPL was approached with caution and decisions were made on a case
by case basis.
> Could someone please summarize (again) the risks and/or disadvantages of LGPL
> from a COMPANY POINT OF VIEW !?
* The LGPL is more complicated and thus requires you to bring in
lawyers if you really want to CYA. In many cases, the cost of
bringing in lawyers would have been greater than simply rewriting the
project in question from scratch.
* The grey areas of the LGPL have not been tested sufficiently in
court and thus whatever the lawyers tell you must be taken with a
grain of salt.
Bottom line: if you are a company *using* open source software, LGPL
brings more risk, but no additional benefit compared to BSD.
I can't speak for a company that choose to *release* its own software
under the LGPL
Cheers,
Brian
Jim Jewett
>... I simply mean pragmatically using the GPL allows the largest
> set of open source code to be incorporated. BSD is great, but being
> less restrictive, it is functionally MORE restrictive for what I can
> use if I want to redistribute things,
Not really. The BSD license means that you have the right to fork
SymPy into a GPL version that you redistribute. And you can do that
all over again tomorrow to catch the updates.
The only catch is that your own users would then be in a ghetto; their
own contributions couldn't be reused except by your own small
community, unless they separately license them back to the main
project.
That is a choice the [L]GPL licenses makes explicitly; by using BSD,
Ondrej has to do more work himself, but in return, he can hope to
cooperate with both sides, at least a little.
-jJ
Jim Jewett
<ki...@landau.phys.spbu.ru> wrote:
> And also I say again that almost every program actually *uses* LGPL'ed
> libraries: for example glibc:
> kirr@roro3:~$ 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.
The python project is very careful to stick to the C89 standard. Not
even C99, let alone GNU extensions. The specific binary on your
machine happens to meet that pre-condition with glibc, but it doesn't
have to. The python on my windows box does not use glibc.
(There has been occasional discussion of the readline library, because
the gnu readline is different enough that you could argue the module
was only meaningful with the gnu version. And the module is often
disabled, for that reason.)
-jJ
ggellner
> > Giniac, Maxima, FFTW, GSL are not going away and in many cases have
> > more users than the python libraries. We are taking a hard stance that
> > forces a lot of code to be rewritten.
>
> If by "we" you mean the BSD licensed projects, I again disagree. It
> is the GPL that draws the line in the sand and says "our way and our
> agenda or code it yourself."
>
viewpoint
this doesn't matter. What I meant is that because the BSD is less
restrictive
the hard stance is having to be pure, and not cave into the GPL. But
from my
perspective as a user I miss having access to all the best code, and I
find
the BSD communities spend more time worry about this issue than GPL
(since the GPL
communities don't need to -- they can always just take the BSD code).
This is what
I mean by I don't care about licensing issues, BSD is fine, [L]GPL is
fine. I DO
care about having to worry about BSD compatibility, and watch good
code be
poorly rewritten because it can't make it into a BSD project.
From a quick look at:
http://en.wikipedia.org/wiki/Comparison_of_computer_algebra_systems
It seems that almost all open source CAS projects are [L]GPL, but
mostly GPL, so
from my view if sympy goes LGPL it doesn't help much, the project will
be unable to
port/look at all the other projects that are doing similar things
[including SAGE :-(],
and will have to redo everything when it is needed . . . so it goes.
Gabriel
Abderrahim KITOUNI
it's been a long time, I was following the project but didn't have
time to contribute.
2008/11/16 Riccardo Gori <goric...@gmail.com>:
>
> On Sunday 16 November 2008 15:02:44 Kirill Smelkov wrote:
[...]
>> Guys, even if you prefer BSD, or LGPL or whatever, please state it
>> clearly, what licensing terms are ok with you.
>
> Hello,
> I prefer the LGPL licence, but my contributions to sympy are so small that I
> don't mind too much about protecting my code from being "abused" by someone.
>
> On the contrary Kirill contributions are big, so I totally understand his
> point.
>
> So +1 LGPL.
I mostly agree with Ricardo here. When I first contributed to sympy, I
felt that this too permissive BSD wasn't the right thing, but didn't
want to disturb anyone because of this.
So +1 LGPL. (even if my vote doesn't count much).
Abderrahim
Vinzent Steinberg
On Nov 16, 10:09 pm, Riccardo Gori <goricca...@gmail.com> wrote:
> On Sunday 16 November 2008 20:20:22 Vinzent Steinberg wrote:
>
> > On 16 Nov., 01:07, Kirill Smelkov <k...@landau.phys.spbu.ru> wrote:
> > > Yes, Wine is a good example.
>
> > There is another example: KHTML. They are using LGPL and were forked
> > by Apple. There were patches from Apple, but they could not be
> > integrated because they were too big and to Mac-specific. Years later
> > the fork became Webkit, and KHTML did not really profit from the
> > changes Apple made.
> > Why am I writing this? Because it shows that LGPL cannot force people
> > to cooperate. There is no license able to do that.
>
> But now we have WebKit, and "anyone" can use it because it's LGPL. If KHTML
> were BSD probably now we would have another close source Web Engine!
>
project [1]. This is not due to licenses in my opinion.
Vinzent
[1] http://en.wikipedia.org/wiki/History_of_KHTML_and_WebKit
Kirill Smelkov
Thanks to all the people, who supported me -- I'm _very_ grateful to
you -- when one fights alone and is almost close to give up, and
suddenly there comes help -- it's a very good feeling that you are not
alone, that there are people who share your point of view and principles
who came to watch your back, and it is especially touchingly to receive
support from youth!
THANK YOU, GUYS!!!
Also I believe that life is a wonderful travel, and you never know,
because it is full of changes some of which are just impossible to
predict. Life is a miracle.
And it's not about being always "right, here and now." -- that would be
too simple and uninspired.
Saying goodbye, I'd like to also tell you, that you'll stay in my memory
for good. I remember most of you, especially how we got in touch the
first time.
So see you somewhere. Our planet is not that big after all :)
--
Всего хорошего, Кирилл.
P.S. I've just re-read my post from my first-year-with-linux days
http://groups.google.ru/group/fido7.ru.linux/browse_thread/thread/a3df577eb76c74ef
It's unusual to me now, how dummy and kiddish I was - besides other
naive questions, I was asking questions from the FAQ! :)
So don't hesitate - everything is given to those who learn just because
it is interesting and want to understand things in essence.
And it is your time now.
Ondrej Certik
Thank you Kirr! For everything that you did for sympy, your time, your
energy. And I especially appreciate that you contributed anyway, even
if you always believed we should use a different license.
I am sure all of us has learnt a lot from you, definitely I did ---
and I am really really glad I had a chance to work with you for more
than a year.
As to the license discussion, I am glad all of us stated clearly what
we want and fought for what each of us believe is right. And that's
how it should be. As I suggested in my other email, for those who
prefer a different license: feel free to use any license you want for
your own code or anything you do with sympy. In the long term, sympy
should be just the symbolic engine, that we all need, but your own
program can use any license -- and I encourage you to use such a
license, that you find the best.
> Also I believe that life is a wonderful travel, and you never know,
> because it is full of changes some of which are just impossible to
> predict. Life is a miracle.
Absolutely. It was wonderful you were around.
>
> And it's not about being always "right, here and now." -- that would be
> too simple and uninspired.
>
>
> Saying goodbye, I'd like to also tell you, that you'll stay in my memory
> for good. I remember most of you, especially how we got in touch the
> first time.
>
> So see you somewhere. Our planet is not that big after all :)
Let me know if you ever come to Prague --- but actually, I plan to
move to the US soon anyway. But maybe we'll meet at some conference.
>
> --
> Всего хорошего, Кирилл.
>
>
>
> P.S. I've just re-read my post from my first-year-with-linux days
>
> http://groups.google.ru/group/fido7.ru.linux/browse_thread/thread/a3df577eb76c74ef
>
> It's unusual to me now, how dummy and kiddish I was - besides other
> naive questions, I was asking questions from the FAQ! :)
>
> So don't hesitate - everything is given to those who learn just because
> it is interesting and want to understand things in essence.
>
> And it is your time now.
Yes, don't hesitate to ask anything.
Ondrej
Riccardo Gori
Thank _YOU_ Kirill, thanks for your great work and thanks for fighting.
I'm really sorry to see you leave this community but I'm sure we'll see you
again because, as you say, the world is a small place.
Let us know about your future projects, many of us would be happy to work with
you again, maybe with a better licence, of course! :-)
>
> Also I believe that life is a wonderful travel, and you never know,
> because it is full of changes some of which are just impossible to
> predict. Life is a miracle.
>
> And it's not about being always "right, here and now." -- that would be
> too simple and uninspired.
>
>
> Saying goodbye, I'd like to also tell you, that you'll stay in my memory
> for good. I remember most of you, especially how we got in touch the
> first time.
>
> So see you somewhere. Our planet is not that big after all :)
>
> --
> Всего хорошего, Кирилл.
>
Riccardo Gori