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