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

Thu Jul 11 13:59:12 PDT 2013

Hi Matt,

My vote is Yea for the IPython license.

Best,

John

John ZuHone
Laboratory for High-Energy Astrophysics
NASA/Goddard Space Flight Center
8800 Greenbelt Rd., Code 662
Greenbelt, MD 20771
(w) 301-286-2531
(m) 773-758-0172
jzuhone at gmail.com
john.zuhone at nasa.gov

On Jul 11, 2013, at 4: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