Proposed: Moving yt from GPLv3 to BSD-like license
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-... 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
Yea. I agree that the IPython license and copyright statement are good fits to our style of collaboration. On Thu, Jul 11, 2013 at 1:02 PM, Matthew Turk <matthewturk@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@gmail.com john.zuhone@nasa.gov On Jul 11, 2013, at 4:02 PM, Matthew Turk <matthewturk@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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... On Thu, Jul 11, 2013 at 4:10 PM, Casey W. Stark <caseywstark@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@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Ok, good to know. This license stuff is always so strange... On Thu, Jul 11, 2013 at 5:18 PM, Nathan Goldbaum <goldbaum@ucolick.org>wrote:
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...
On Thu, Jul 11, 2013 at 4:10 PM, Casey W. Stark <caseywstark@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@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I, for one, say "Yea" to the re-licensing. Be Well Anthony On Thu, Jul 11, 2013 at 6:26 PM, Brian O'Shea <bwoshea@gmail.com> wrote:
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@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
"Yea" for the IPython license. SamL On Thu, Jul 11, 2013 at 8:13 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
I, for one, say "Yea" to the re-licensing.
Be Well Anthony
On Thu, Jul 11, 2013 at 6:26 PM, Brian O'Shea <bwoshea@gmail.com> wrote:
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@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Yea. On Thu, Jul 11, 2013 at 11:05 PM, Sam Leitner <sam.leitner@gmail.com> wrote:
"Yea" for the IPython license. SamL
On Thu, Jul 11, 2013 at 8:13 PM, Anthony Scopatz <scopatz@gmail.com>wrote:
I, for one, say "Yea" to the re-licensing.
Be Well Anthony
On Thu, Jul 11, 2013 at 6:26 PM, Brian O'Shea <bwoshea@gmail.com> wrote:
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@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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yea. On Fri, Jul 12, 2013 at 2:15 AM, Kacper Kowalik <xarthisius.kk@gmail.com>wrote:
Yea for iPython licence. Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
Hi all, as someone who has crossed over to the dark side (i.e. working for the man), I would say that a more permissive license is a good thing. In my short time in my new job we have already had discussions about whether or not we can use certain OS software from a legal standpoint. I don't think anyone wants to take OS work and sneakily use it or steal it, but we do want to create proprietary extensions and enhancements without fear of being forced to release our work. I think that a switch is a good thing. -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
Yea. I agree that this will benefit us more than it could potentially harm us. As for the particular license, the IPython license seems fine to me, though maybe we should follow the exact layout of the modified 3-clause BSD. Doesn't really matter. Sam On Fri, Jul 12, 2013 at 7:12 AM, Stephen Skory <s@skory.us> wrote:
Hi all,
as someone who has crossed over to the dark side (i.e. working for the man), I would say that a more permissive license is a good thing. In my short time in my new job we have already had discussions about whether or not we can use certain OS software from a legal standpoint. I don't think anyone wants to take OS work and sneakily use it or steal it, but we do want to create proprietary extensions and enhancements without fear of being forced to release our work.
I think that a switch is a good thing.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I'll vote +1 on this, but I'd really like to understand the GPL mode a bit better. I'm unclear on how that will work, and what it will mean for distribution. j On Fri, Jul 12, 2013 at 10:14 AM, Sam Skillman <samskillman@gmail.com>wrote:
Yea.
I agree that this will benefit us more than it could potentially harm us. As for the particular license, the IPython license seems fine to me, though maybe we should follow the exact layout of the modified 3-clause BSD. Doesn't really matter.
Sam
On Fri, Jul 12, 2013 at 7:12 AM, Stephen Skory <s@skory.us> wrote:
Hi all,
as someone who has crossed over to the dark side (i.e. working for the man), I would say that a more permissive license is a good thing. In my short time in my new job we have already had discussions about whether or not we can use certain OS software from a legal standpoint. I don't think anyone wants to take OS work and sneakily use it or steal it, but we do want to create proprietary extensions and enhancements without fear of being forced to release our work.
I think that a switch is a good thing.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Yea for the IPython license. Cheers, John On 07/11/2013 04:02 PM, Matthew Turk 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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech
Hi everyone, It sounds like switching is a good idea, but for my own curiosity at least, are there downsides that haven't been mentioned? Mechanically what is involved, and is there any external software currently shipped with yt which is under the GPL? Thanks, John On Fri, Jul 12, 2013 at 4:10 PM, John Wise <jwise@physics.gatech.edu> wrote:
Yea for the IPython license.
Cheers, John
On 07/11/2013 04:02 PM, Matthew Turk 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<http://nipy.sourceforge.net/software/license/johns_bsd_pitch.html#johns-bsd-...>
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.
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@lists.spacepope.org http://lists.spacepope.org/**listinfo.cgi/yt-dev-spacepope.**org<http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech
______________________________**_________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/**listinfo.cgi/yt-dev-spacepope.**org<http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>
Hi John, (Sorry about the delay; I was away from email all weekend.) This is a great question. I do not believe we need to modify our install_script.sh to install different software. However, I think that in a few cases, we will need to either move modules to a different source repository, ensure they are not imported by default, or push them upstream. I believe that the only instances where this will need to be done will be in the ExtJS source code used by Reason, which it's not clear to me we need to remove from our main repository anyway, and in the linking against rockstar, which is not done by default nor imported by default and so may not need to be removed. I'm going to consult with a few people about this, but I think we can likely manage it without too much friction. -Matt On Fri, Jul 12, 2013 at 7:40 PM, John Forbes <jforbes@ucolick.org> wrote:
Hi everyone,
It sounds like switching is a good idea, but for my own curiosity at least, are there downsides that haven't been mentioned? Mechanically what is involved, and is there any external software currently shipped with yt which is under the GPL?
Thanks, John
On Fri, Jul 12, 2013 at 4:10 PM, John Wise <jwise@physics.gatech.edu> wrote:
Yea for the IPython license.
Cheers, John
On 07/11/2013 04:02 PM, Matthew Turk 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-...
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all, All of the replies we've received have been in the assertive. Looking at the list of contributors (ordered by commit count) I have heard either on this list or personally in the affirmative from the top 15 or so, without exception. I think it's time to move on to the next stage, so over the next few days I will begin preparing the emails, sending them, and collecting the results. When they start going out, I will reply to this with a link to the google drive spreadsheet where I am collecting replies. I will include explicit wording about the 3-clause BSD license (rather than referring to it as the IPython license). Before that happens, if anyone has any objections or suggestions, please raise them now. -Matt On Thu, Jul 11, 2013 at 4:02 PM, Matthew Turk <matthewturk@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-...
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
The emails have all gone out. Here is the spreadsheet with replies and links to replies: http://goo.gl/3PFnf -Matt On Mon, Jul 15, 2013 at 11:12 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
All of the replies we've received have been in the assertive. Looking at the list of contributors (ordered by commit count) I have heard either on this list or personally in the affirmative from the top 15 or so, without exception.
I think it's time to move on to the next stage, so over the next few days I will begin preparing the emails, sending them, and collecting the results. When they start going out, I will reply to this with a link to the google drive spreadsheet where I am collecting replies. I will include explicit wording about the 3-clause BSD license (rather than referring to it as the IPython license).
Before that happens, if anyone has any objections or suggestions, please raise them now.
-Matt
On Thu, Jul 11, 2013 at 4:02 PM, Matthew Turk <matthewturk@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-...
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
participants (15)
-
Anthony Scopatz -
Brian O'Shea -
Britton Smith -
Cameron Hummels -
Casey W. Stark -
j s oishi -
John Forbes -
John Wise -
John ZuHone -
Kacper Kowalik -
Matthew Turk -
Nathan Goldbaum -
Sam Leitner -
Sam Skillman -
Stephen Skory