[yt-dev] Proposed: Moving yt from GPLv3 to BSD-like license

Nathan Goldbaum goldbaum at ucolick.org
Thu Jul 11 16:18:08 PDT 2013


Yup, it seems that many linux distributions list IPython's license as BSD
3-clause.

More info here:
http://opensource.org/licenses/BSD-2-Clause
http://opensource.org/licenses/BSD-3-Clause
http://ipython.org/ipython-doc/dev/about/license_and_copyright.html
http://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_.28.22Revised_BSD_License.22.2C_.22New_BSD_License.22.2C_or_.22Modified_BSD_License.22.29


On Thu, Jul 11, 2013 at 4:10 PM, Casey W. Stark <caseywstark at gmail.com>wrote:

> Yea! I didn't know this was an issue for yt, but I recently heard of some
> real headaches for a GPL science package. It would be a shame for licensing
> to impede any yt work.
>
> Just curious, is the ipython license the same as BSD 3 clause?
>
>
> On Thu, Jul 11, 2013 at 2:02 PM, Matthew Turk <matthewturk at gmail.com>wrote:
>
>> Hi everyone,
>>
>> I apologize for the long email, but because this is a relatively
>> important subject I need to address a few items in detail.
>>
>> This is meant as a discussion point.  I would like to ensure
>> investment in a change like this from the yt community, both
>> developers and users, and I think before a decision can be made to
>> either change or remain the same we should ensure that community
>> members are able to voice concerns or suggestions.
>>
>> = What =
>>
>> I'm writing to propose a change in the licesning scheme for yt.
>> Currently, yt is licensed under the GPLv3 license.  This license
>> brings with it an idealogy that I support -- free (as in freedom) and
>> open source software, and attempts to ensure that the spread of
>> software spreads those freedoms as well.  This is done through terms
>> of licensing; while there are several subtleties to how this plays
>> out, and the goals of FLOSS and the GPL align very well with my own, I
>> don't believe that it is appropriate for yt to be licensed under the
>> GPL any more.
>>
>> = Why =
>>
>> In the scientific software community, for the most part codes and
>> platforms are released under a permissive, BSD-like license.  This is
>> not universally true.  Within the scientific python ecosystem
>> (including projects such as AstroPy), BSD-like licenses are especially
>> prevalent.  These licenses place no restrictions on redistribution,
>> passing on freedoms to end users, or making a piece of software
>> closed-source.  A side effect is that if a piece of software is BSD
>> licensed, it cannot rely on GPL'd software without itself being
>> subject to those terms.  Specifically, a BSD licensed package that
>> requires an import of a GPL'd package is likely itself then subject to
>> the GPL -- this is why it has been termed "viral" in the past.  As
>> examples, many BSD-licensed packages exist in the scientific software
>> community: VisIt, ParaView, MayaVi, NumPy, Matplotlib, IPython, Python
>> itself, mpi4py, h5py, SymPy, SciPy, most of the scikits,
>> scikits-learn, NetworkX and so on.  Collaboration with these projects
>> is currently one-way because of our license.
>>
>> When I initially decided on a license for yt (seven years ago) it
>> seemed appropriate to use the licensing terms as a mechanism to
>> encourage contributions upstream.  However, within the current
>> ecosystem, it is clear that because of the virality of the GPL and the
>> prevailing mindsets of developers, it is actually an impediment to
>> receiving contributions and receiving mindshare.  John Hunter
>> described it very clearly in this document:
>>
>>
>> http://nipy.sourceforge.net/software/license/johns_bsd_pitch.html#johns-bsd-pitch
>>
>> While he focuses on commercial utilization, I believe that within the
>> scientific python ecosystem the picture can be broadened to include
>> any piece of software that is under a permissive license.  yt cannot
>> be used or relied upon as a primary component without that piece of
>> software then becoming subject to the terms of the GPL.  Additionally,
>> some private and public institutions are averse to providing code
>> under the GPL, specifically version 3 of the GPL.
>>
>> By transitioning to a permissive license, we may be able to receive
>> more contributions and collaborate more widely.  As a few examples,
>> this could include more direct collaborations with packages such as
>> Glue, IPython, VisIt, ParaView, and even utilization and exposing of
>> yt methods and operations in other, permissively-licensed packages.
>> For example, deep integration between permissively-licensed simulation
>> codes will benefit from this.  Furthermore, individuals who otherwise
>> could not contribute code under the GPL (due to employer restrictions)
>> will be able to contribute code under a permissive license.
>>
>> The GPL is designed to prevent turning FLOSS code proprietary.
>> Changing to a BSD license does not allow another entity to prevent us
>> from continuing to develop or make available any yt code.  It simply
>> means that others can utilize it however they see fit.
>>
>> I believe that we stand to gain considerably more than we stand to
>> lose from such a transition.
>>
>> More to the point, a few years ago on this mailing list we came up
>> with a mission statement for yt.  I think we can better serve that
>> mission statement by enabling broader collaborations within the
>> scientific software ecosystem.
>>
>> This is not motivated by any desire to create a proprietary
>> distribution of yt -- in fact, exactly the opposite.  Recently I have
>> begun to think about the future of yt if I, personally, end up having
>> to depart the community.  I believe that in the current ecosystem of
>> scientific software, yt will be more sustainable if it is under a
>> permissive license.
>>
>> = License=
>>
>> I specifically believe that the IPython license, which is itself the
>> modified BSD license, is the license we should move to.  I am willing
>> to entertain other options (such as the PSF license, which matplotlib
>> uses, or an MIT-like license).  While it is tempting to me to suggest
>> that we license under the LGPL, I don't think that this would provide
>> any benefits over moving directly to a fully permissive license.
>>
>> http://ipython.org/ipython-doc/dev/about/license_and_copyright.html
>>
>> While we are doing this, I would like to suggest we enumerate the
>> copyright model that IPython does, as that is exactly the copyright
>> model we exist under currently but it is not specifically identified
>> in the code base.
>>
>> yt will continue to have a GPL-mode, where we can link against GPL'd
>> libraries such as Rockstar, ExtJS and so on.  However, this mode will
>> be activated by a specific set of imports or items, and the core yt
>> functionality will by default not activate any of this mode.  This is
>> similar to how packages like VisIt and ParaView link against R, which
>> is itself GPL'd.
>>
>> = How =
>>
>> If we do decide to make this change, this is the process that it will
>> take:
>>
>>  1) I have created a spreadsheet of every contributor to yt.  This
>> spreadsheet will be public.
>>  2) I will individually write to each one, asking for their consent to
>> relicense their contributions under the new license.
>>  3) All responses will be directed to yt-svn (rather than yt-dev)
>> which is a publicly accessible and archived mailing list.  A link to
>> the archive post for each message will be placed in the spreadsheet.
>>  4) If we as a project decide that we are committed to moving to a
>> permissive license and an individual does not consent to change the
>> license of their code, we will need to either rewrite or remove it.
>> Alternately, this could serve as a veto for a transition.  We will
>> discuss this if it arises.
>>  5) Once complete, I will issue a pull request that changes the
>> license and makes explicit the copyright policy.
>>
>> All previous releases of yt will remain under the GPL, as will any
>> previous changesets of yt prior to the acceptance of item #5.
>>
>> = Votes / Discussion =
>>
>> At this time, I would like to request and solicit feedback or votes.
>>
>> If you have contributed a large amount of code to yt, please write
>> back to this email with a Yea or a Nay to this change and any comments
>> you have about it, or suggestions about a particular license other
>> than the IPython license.  In particular, if you are opposed to this
>> change, *please* make your voice heard so that we can have a
>> productive discussion about it.
>>
>> = Thank you =
>>
>> Thank you very much for taking the time to read this.  This email and
>> initiative is the result of a lot of soul-searching on my part.
>>
>> I have come to believe very strongly that as a project we can do more
>> to support goals of open science, open source, and build a stronger
>> community by rethinking how we fit into an ecosystem of scientific
>> software.
>>
>> -Matt
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130711/93573cc3/attachment.htm>


More information about the yt-dev mailing list