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

[Brian O'Shea]

Hi Matt,

I'm not a yt contributor, but I *am* a yt user and strong supporter of the
yt project in a variety of ways. For what it's worth, I find your arguments
very compelling, and I totally agree with you - a more permissive license
will enable broader use of the code, and the obvious upsides are much
greater than any potential negatives (at least as far as I can tell).  So,
please take this as my (non-binding, somewhat irrelevant) +1 of the idea.
:-)

--Brian



On Thu, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130711/a920d9e0/attachment.html>