[SciPy-user] Re-releasing Python Equations under a new license?

[Gabriel Gellner]

At risk of sounding like a troll . . .

This is an issue I have noticed that the python science world has VERY
strong opinions about . . . and I was hoping that maybe people would
answer my final questions before becoming a BSD'er ;-)

In John Hunters very good pitch, I find his main points being:
1) GPL generally can not be comfortably/legally used by companies, so
you cut off these developers needlessly.
2) The safety that the GPL offers is a straw man, as in general
companies do not steal from the community.
3) GPL is generally used by developers without thinking about the
above, and they use it because it is popular.

Re 1): I have never understood why this is the case. GTK+,
gcc stack, and many other libraries are LGPL and are used by companies
for there products (like acrobat for linux, and OS X as far as I know
(gcc stack)), and I have never heard of their code being 'infected'.

If so then could it be that the problem is not point 3, but rather
that companies do not understand that the LGPL does not take their
code, and stop them from making proprietary products with it (you
would only have to release bug fixes to the library, anything else
would just link to the library and then be able to be closed)?

I would love it if anyone can set me straight. I promise this is
the last thing I will say on the issue, as I have seen the response on
these lists when someone advocates the GPL before . . . I am neutral,
but confused.

Gabriel

On Thu, Jan 18, 2007 at 02:47:53PM -0700, Fernando Perez wrote:
> On 1/18/07, zunzun at zunzun.com <zunzun at zunzun.com> wrote:
> > Can I get any advice on which software license to distribute
> > my code?  The sourceforge URL, which I forgot to post before, is
> >
> > http://sourceforge.net/projects/pythonequations
> >
> > I'm just interested in feedback from users, whether someone uses
> > the code in a commercial application is not particulary important
> > to me personally.  I would like people to know where to get the
> > source code itself if someone does redistribute, again so that
> > the chance of feedback on the source code is increased.
> >
> > I'm not chained to the GPL, I'm just naive and inexperienced.
> > Any advice would be greatly appreciated, and my thanks to
> > Glen Mabey for his thoughts below.  Re-releasing would happen
> > this weekend if I knew which license to use other than the GPL.
> 
> John Hunter has a standardized and extremely well-written response to
> this question.  Rather than poorly paraphrasing him, I just hit 'jdh
> bsd pitch' in my gmail search box, and I'll let his words tell the
> rest.
> 
> This should (with John's permission) probably go into the scipy FAQ...
> 
> Cheers,
> 
> f
> 
> ###### Written by John Hunter in response to this same question
> 
> Would you consider licensing your code under a more permissive
> license?  Most of the essential scientific computing tools in python
> (scipy, numpy, matplotlib, ipython, vtk, enthought tool suite, ....)
> are licensed under a BSD-ish style license, and cannot reuse GPLd
> code.
> 
> My standard "licensing pitch" is included below::
> 
> I'll start by summarizing what many of you already know about open
> source licenses. I believe this discussion is broadly correct, though
> it is not a legal document and if you want legally precise statements
> you should reference the original licenses cited here. The
> Open-Source-Initiative is a clearing house for OS licenses, so you can
> read more there.
> 
> The two dominant license variants in the wild are GPL-style and
> BSD-style. There are countless other licenses that place specific
> restrictions on code reuse, but the purpose of this document is to
> discuss the differences between the GPL and BSD variants, specifically
> in regards to my experience developing matplotlib and in my
> discussions with other developers about licensing issues.
> 
> The best known and perhaps most widely used license is the GPL, which
> in addition to granting you full rights to the source code including
> redistribution, carries with it an extra obligation. If you use GPL
> code in your own code, or link with it, your product must be released
> under a GPL compatible license. I.e., you are required to give the source
> code to other people and give them the right to redistribute it as
> well. Many of the most famous and widely used open source projects are
> released under the GPL, including linux, gcc and emacs.
> 
> The second major class are the BSD-style licenses (which includes MIT
> and the python PSF license). These basically allow you to do whatever
> you want with the code: ignore it, include it in your own open source
> project, include it in your proprietary product, sell it,
> whatever. python itself is released under a BSD compatible license, in
> the sense that, quoting from the PSF license page
> 
>  There is no GPL-like "copyleft" restriction. Distributing
>  binary-only versions of Python, modified or not, is allowed. There
>  is no requirement to release any of your source code. You can also
>  write extension modules for Python and provide them only in binary
>  form.
> 
> Famous projects released under a BSD-style license in the permissive
> sense of the last paragraph are the BSD operating system, python and
> TeX.
> 
> I believe the choice of license is an important one, and I advocate a
> BSD-style license. In my experience, the most important commodity an
> open source project needs to succeed is users. Of course, doing
> something useful is a prerequisite to getting users, but I also
> believe users are something of a prerequisite to doing something
> useful. It is very difficult to design in a vacuum, and users drive
> good software by suggesting features and finding bugs. If you satisfy
> the needs of some users, you will inadvertently end up satisfying the
> needs of a large class of users. And users become developers,
> especially if they have some skills and find a feature they need
> implemented, or if they have a thesis to write. Once you have a lot of
> users and a number of developers, a network effect kicks in,
> exponentially increasing your users and developers. In open source
> parlance, this is sometimes called competing for mind share.
> 
> So I believe the number one (or at least number two) commodity an open
> source project can possess is mind share, which means you want as many
> damned users using your software as you can get. Even though you are
> giving it away for free, you have to market your software, promote it,
> and support it as if you were getting paid for it. Now, how does this
> relate to licensing, you are asking?
> 
> Many software companies will not use GPL code in their own software,
> even those that are highly committed to open source development, such
> as enthought, out of legitimate concern that use of the GPL will
> "infect" their code base by its viral nature. In effect, they want to
> retain the right to release some proprietary code. And in my
> experience, companies make for some of the best developers, because
> they have the resources to get a job done, even a boring one, if they
> need it in their code. Two of the matplotlib backends (FLTK and WX)
> were contributed by private sector companies who are using matplotlib
> either internally or in a commercial product -- I doubt these
> companies would have been using matplotlib if the code were GPL. In my
> experience, the benefits of collaborating with the private sector are
> real, whereas the fear that some private company will "steal" your
> product and sell it in a proprietary application leaving you with
> nothing is not.
> 
> There is a lot of GPL code in the world, and it is a constant reality
> in the development of matplotlib that when we want to reuse some
> algorithm, we have to go on a hunt for a non-GPL version. Most
> recently this occurred in a search for a good contouring algorithm. I
> worry that the "license wars", the effect of which are starting to be
> felt on many projects, have a potential to do real harm to open source
> software development. There are two unpalatable options. 1) Go with
> GPL and lose the mind-share of the private sector 2) Forgo GPL code
> and retain the contribution of the private sector. This is a very
> tough decision because their is a lot of very high quality software
> that is GPL and we need to use it; they don't call the license viral
> for nothing.
> 
> The third option, which is what is motivating me to write this, is to
> convince people who have released code under the GPL to re-release it
> under a BSD compatible license. Package authors retain the copyright
> to their software and have discretion to re-release it under a license
> of their choosing. Many people choose the GPL when releasing a package
> because it is the most famous open source license, and did not
> consider issues such as those raised here when choosing a
> license. When asked, these developers will often be amenable to
> re-releasing their code under a more permissive license. Fernando
> Perez did this with ipython, which was released under the LGPL and
> then re-released under a BSD license to ease integration with
> matplotlib, scipy and enthought code. The LGPL is more permissive than
> the GPL, allowing you to link with it non-virally, but many companies
> are still loath to use it out of legal concerns, and you cannot reuse
> LGPL code in a proprietary product.
> 
> So I encourage you to release your code under a BSD compatible
> license, and when you encounter an open source developer whose code
> you want to use, encourage them to do the same. Feel free to forward
> this document on them.
> 
> Comments, suggestions for improvements, corrections, etc, should be
> sent to jdhunter at ace.bsd.uchicago.edu
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-user