Re: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy
On Wed, 2020-07-01 at 12:48 -0700, Stephan Hoyer wrote: > On Wed, Jul 1, 2020 at 12:23 PM Sebastian Berg < > sebast...@sipsolutions.net> > wrote: > > > This is a WIP, but allows nicely to try out how the new API > > could/should look like, and see the potential impact to code. The > > current choice is for: > > > > np.sort(arr, keys=(arr.real, arr.image)) > > > > for example. `keys` is like the `key` argument to pythons sorts, > > but > > unlike python sorts is not passed a function but rather a sequence > > of > > arrays. > > > > Alternative spellings could be `by=...`? Or maybe someone has a > > different API idea. > > > > I really like the look of np.sort(arr, by=(arr.real, arr.image)). > - This avoids adding an extra function sortby into NumPy's API. The > default > behavior (by=None) would of course be to sort by the arrays being > sorted, > so it's backwards compatible. > - Calling the new argument "by" instead of "key" avoids confusion > with the > behavior of Python's sort/sorted (which take functions instead of > sequences). I just noticed that `DataFrame.sort_values()` uses `by=...` with a list of column names. However, I guess that is fairly compatible with this usage. - Sebastan > The combination of lexsort() and take_along_axis() makes it possible > to > achieve this behavior currently, but it is definitely less clear than > a > single function call. > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies
On 01-07-2020 12:34, John Preston wrote: > Hello all, > > The following proposal was originally issue #16722 on GitHub but at > the request of Matti Picus I am moving the discussion to this list. [snip] Hello John, I don't have copyright on any of the Numpy code, however would like to express a few problems I see in this proposal. First, as you write, such a license does not qualify as Free Software as defined by OSI or the DFSG. Adopting this license would mean that Numpy could not be included in many distributions that give their users the guarantee that the softer they receive is Free Software. Debian would remove Numpy from its archive, for example. Fedora would probably do the same. Conda would need to do the same, but being Numpy at the base of the Python scientific stack, this would effectively kill Conda. This would have immediate ripercussions on companies that offer services based on Numpy and on software that depends on Numpy. Second, the term of the license are extremely vague, at least in a legal framework. In particular, "used for or aid in" is a very poor choice of words. It could be argued that if I use Numpy in the code that handles the orders for my pizza shop and I am asked to deliver pizzas to Exon employer working late at night I am "aiding in the "the exploration, extraction, refinement, processing, or transportation of fossil fuels". Thus, someone that has copyright on (even very small) part of the Numpy code could sue me and demand a free lifetime supply of pizza for me to continue to be able to use Numpy. In practice this would make everyone avoid using Numpy in their software by being scared of violating these clauses. At the same time, the wording may be too vague to be enforceable in court. This in practice would mean that most of the "good guys" (as per the Climate Strike License definition) would be avoiding to use Numpy because they do not have the resources to fight alleged license violations in court, while the "bad guys" will continue to do it because they have a whole legal department to handle something like this. Third, if a software project would be to adopt something like the Climate Strike License, why shouldn't it adopt licenses whose terms are thought to advance some other political agenda? While the fact that the reliance on fossil fuels is the cause of climate change is widely (but not universally) acknowledged and we may agree that the the big economical interests in the enterprises related to fossil fuels are holding back alternative solutions, there are many other causes on which an agreement would be very difficult and would drag the project members into interminable discussions. Fourth, are we sure that making fossil fuel companies and companies that rely on fossil fuels less efficient (by forbidding access to the Python scientific software stack) would make them less dangerous for the climate? Absurdly, the Climate Strike License forbids a company that wants to migrate from a busyness model based on fossil fuels to something more sustainable to use a software with this license to evaluate and form their plans. Free Software (in its copyleft or permissive licensing variants) has been so successful also because its promoters have not tried to leverage it for other (noble or otherwise) scopes. There has been talk in the past to incorporate other clauses in the Free Software license to advance other causes (from "cause no harm" kind of things to provision to ensure the economical viability of the development) and the conclusion has always been that it is not a good idea. The reasons presented ere are just some. I am sure you can find more detailed essays from authors much more authoritative than me on this matter. Cheers, Dan ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies
Hi, I can respect where this comes from, especially as someone who works in atmospheric science. I'm glad people are trying to do what they can. With that said, I am -1000 on this. In my opinion, a software license is a wholly inappropriate venue for trying to do this. At the top of the home page for the Free Software Foundation: "Free software developers guarantee everyone equal rights to their programs". What you're proposing is essentially "everyone equal rights so long as they aren't working on things I disagree with". The nobility of the cause in my opinion doesn't justify compromising the values behind free software. As someone with some miniscule commits in the numpy codebase, I would not want them distributed under the modified license. As a developer of other downstream projects, I would switch to the BSD fork of the project that would inevitably materialize. Ryan On Wed, Jul 1, 2020 at 12:35 PM John Preston wrote: > Hello all, > > The following proposal was originally issue #16722 on GitHub but at > the request of Matti Picus I am moving the discussion to this list. > > > "NumPy is the fundamental package needed for scientific computing with > Python." > > I am asking the NumPy project to leverage its position as a core > dependency among statistical, numerical, and ML projects, in the > pursuit of climate justice. It is easy to identify open-source > software used by the oil and gas industry which relies on NumPy [1] > [2] , and it is highly likely that NumPy is used in closed-source and > in-house software at oil and gas extraction companies such as Aramco, > ExxonMobil, BP, Shell, and others. I believe it is possible to use > software licensing to discourage the use of NumPy and dependent > packages by companies such as these, and that doing so would frustrate > the ability of these companies to identify and extract new oil and gas > reserves. > > I propose NumPy's current BSD 3-Clause license be extended to include > the following conditions, in line with the Climate Strike License [3] > : > > * The Software may not be used in applications and services that > are used for or >aid in the exploration, extraction, refinement, processing, or > transportation >of fossil fuels. > > * The Software may not be used by companies that rely on fossil > fuel extraction >as their primary means of revenue. This includes but is not > limited to the >companies listed at https://climatestrike.software/blocklist > > I accept that there are issues around adopting such a proposal, including > that: > > addition of such clauses violates the Open Source Initiative's > canonical Open Source Definition, which explicitly excludes licenses > that limit re-use "in a specific field of endeavor", and therefore if > these clauses were adopted NumPy would no longer "be open-source" by > this definition; > there may be collateral damage among the wider user base and project > sponsorship, due to the vague nature of the first clause, and this may > affect the longevity of the project and its standing within the > Python, numerical, statistical, and ML communities. > > My intention with the opening of this issue is to promote constructive > discussion of the use of software licensing -- and other measures -- > for working towards climate justice -- and other forms of justice -- > in the context of NumPy and other popular open-source libraries. Some > people will say that NumPy is "just a tool" and that it sits > independent of how it is used, but due to its utility and its > influence as a major open-source library, I think it is essential that > we consider the position of the Climate Strike License authors, that > "as tech workers, we should take responsibility in how our software is > used". > > Many thanks to all of the contributors who have put so much time and > energy into NumPy. ✨ ❤️ > > [1] https://github.com/gazprom-neft/petroflow > [2] https://github.com/climate-strike/analysis > [3] https://github.com/climate-strike/license > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- Ryan May ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies
While well intentioned, this is not something that NumPy (or the rest of the scientific Python stack) should consider doing. Philosophically, I think this is something that those of us who work on Open Source have to accept: some people are going to use it for things we think make the world a better place and some people are going to use it for things we think make the world a worse place. The mechanisms that ensure we can get the tools into the hands of the first group also means we can not keep them out of the hands of the second (independent of how any given person defines the groups). Tom On Wed, Jul 1, 2020 at 3:32 PM Andrea Gavana wrote: > On Wed, 1 Jul 2020 at 21.23, gyro funch wrote: > >> Hello, >> >> I greatly respect the intention, but this is a very slippery slope. >> >> Will you exempt groups within these companies that are working on >> 'green' technologies (e.g., biofuels)? >> >> Will you add to the license restrictions companies who make use of oil >> and gas extracted by these companies (automotive, chemical/polymers, >> etc.)? >> >> Will you follow the chain from extraction to consumption and add the >> links to the license 'blacklist'? >> >> -gyro > > > Thank you for injecting some sense and a few reality checks into the > discussion. > > Andrea. > > > >> >> >> On 7/1/2020 12:34 PM, John Preston wrote: >> > Hello all, >> > >> > The following proposal was originally issue #16722 on GitHub but at >> > the request of Matti Picus I am moving the discussion to this list. >> > >> > >> > "NumPy is the fundamental package needed for scientific computing with >> Python." >> > >> > I am asking the NumPy project to leverage its position as a core >> > dependency among statistical, numerical, and ML projects, in the >> > pursuit of climate justice. It is easy to identify open-source >> > software used by the oil and gas industry which relies on NumPy [1] >> > [2] , and it is highly likely that NumPy is used in closed-source and >> > in-house software at oil and gas extraction companies such as Aramco, >> > ExxonMobil, BP, Shell, and others. I believe it is possible to use >> > software licensing to discourage the use of NumPy and dependent >> > packages by companies such as these, and that doing so would frustrate >> > the ability of these companies to identify and extract new oil and gas >> > reserves. >> > >> > I propose NumPy's current BSD 3-Clause license be extended to include >> > the following conditions, in line with the Climate Strike License [3] >> > : >> > >> > * The Software may not be used in applications and services that >> > are used for or >> >aid in the exploration, extraction, refinement, processing, or >> > transportation >> >of fossil fuels. >> > >> > * The Software may not be used by companies that rely on fossil >> > fuel extraction >> >as their primary means of revenue. This includes but is not >> > limited to the >> >companies listed at https://climatestrike.software/blocklist >> > >> > I accept that there are issues around adopting such a proposal, >> including that: >> > >> > addition of such clauses violates the Open Source Initiative's >> > canonical Open Source Definition, which explicitly excludes licenses >> > that limit re-use "in a specific field of endeavor", and therefore if >> > these clauses were adopted NumPy would no longer "be open-source" by >> > this definition; >> > there may be collateral damage among the wider user base and project >> > sponsorship, due to the vague nature of the first clause, and this may >> > affect the longevity of the project and its standing within the >> > Python, numerical, statistical, and ML communities. >> > >> > My intention with the opening of this issue is to promote constructive >> > discussion of the use of software licensing -- and other measures -- >> > for working towards climate justice -- and other forms of justice -- >> > in the context of NumPy and other popular open-source libraries. Some >> > people will say that NumPy is "just a tool" and that it sits >> > independent of how it is used, but due to its utility and its >> > influence as a major open-source library, I think it is essential that >> > we consider the position of the Climate Strike License authors, that >> > "as tech workers, we should take responsibility in how our software is >> > used". >> > >> > Many thanks to all of the contributors who have put so much time and >> > energy into NumPy. ✨ ❤️ >> > >> > [1] https://github.com/gazprom-neft/petroflow >> > [2] https://github.com/climate-strike/analysis >> > [3] https://github.com/climate-strike/license >> > ___ >> > NumPy-Discussion mailing list >> > NumPy-Discussion@python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >>
Re: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy
On Wed, Jul 1, 2020 at 12:23 PM Sebastian Berg wrote: > This is a WIP, but allows nicely to try out how the new API > could/should look like, and see the potential impact to code. The > current choice is for: > > np.sort(arr, keys=(arr.real, arr.image)) > > for example. `keys` is like the `key` argument to pythons sorts, but > unlike python sorts is not passed a function but rather a sequence of > arrays. > > Alternative spellings could be `by=...`? Or maybe someone has a > different API idea. > I really like the look of np.sort(arr, by=(arr.real, arr.image)). - This avoids adding an extra function sortby into NumPy's API. The default behavior (by=None) would of course be to sort by the arrays being sorted, so it's backwards compatible. - Calling the new argument "by" instead of "key" avoids confusion with the behavior of Python's sort/sorted (which take functions instead of sequences). The combination of lexsort() and take_along_axis() makes it possible to achieve this behavior currently, but it is definitely less clear than a single function call. ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies
On Wed, 1 Jul 2020 at 21.23, gyro funch wrote: > Hello, > > I greatly respect the intention, but this is a very slippery slope. > > Will you exempt groups within these companies that are working on > 'green' technologies (e.g., biofuels)? > > Will you add to the license restrictions companies who make use of oil > and gas extracted by these companies (automotive, chemical/polymers, etc.)? > > Will you follow the chain from extraction to consumption and add the > links to the license 'blacklist'? > > -gyro Thank you for injecting some sense and a few reality checks into the discussion. Andrea. > > > On 7/1/2020 12:34 PM, John Preston wrote: > > Hello all, > > > > The following proposal was originally issue #16722 on GitHub but at > > the request of Matti Picus I am moving the discussion to this list. > > > > > > "NumPy is the fundamental package needed for scientific computing with > Python." > > > > I am asking the NumPy project to leverage its position as a core > > dependency among statistical, numerical, and ML projects, in the > > pursuit of climate justice. It is easy to identify open-source > > software used by the oil and gas industry which relies on NumPy [1] > > [2] , and it is highly likely that NumPy is used in closed-source and > > in-house software at oil and gas extraction companies such as Aramco, > > ExxonMobil, BP, Shell, and others. I believe it is possible to use > > software licensing to discourage the use of NumPy and dependent > > packages by companies such as these, and that doing so would frustrate > > the ability of these companies to identify and extract new oil and gas > > reserves. > > > > I propose NumPy's current BSD 3-Clause license be extended to include > > the following conditions, in line with the Climate Strike License [3] > > : > > > > * The Software may not be used in applications and services that > > are used for or > >aid in the exploration, extraction, refinement, processing, or > > transportation > >of fossil fuels. > > > > * The Software may not be used by companies that rely on fossil > > fuel extraction > >as their primary means of revenue. This includes but is not > > limited to the > >companies listed at https://climatestrike.software/blocklist > > > > I accept that there are issues around adopting such a proposal, > including that: > > > > addition of such clauses violates the Open Source Initiative's > > canonical Open Source Definition, which explicitly excludes licenses > > that limit re-use "in a specific field of endeavor", and therefore if > > these clauses were adopted NumPy would no longer "be open-source" by > > this definition; > > there may be collateral damage among the wider user base and project > > sponsorship, due to the vague nature of the first clause, and this may > > affect the longevity of the project and its standing within the > > Python, numerical, statistical, and ML communities. > > > > My intention with the opening of this issue is to promote constructive > > discussion of the use of software licensing -- and other measures -- > > for working towards climate justice -- and other forms of justice -- > > in the context of NumPy and other popular open-source libraries. Some > > people will say that NumPy is "just a tool" and that it sits > > independent of how it is used, but due to its utility and its > > influence as a major open-source library, I think it is essential that > > we consider the position of the Climate Strike License authors, that > > "as tech workers, we should take responsibility in how our software is > > used". > > > > Many thanks to all of the contributors who have put so much time and > > energy into NumPy. ✨ ❤️ > > > > [1] https://github.com/gazprom-neft/petroflow > > [2] https://github.com/climate-strike/analysis > > [3] https://github.com/climate-strike/license > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies
Hello, I greatly respect the intention, but this is a very slippery slope. Will you exempt groups within these companies that are working on 'green' technologies (e.g., biofuels)? Will you add to the license restrictions companies who make use of oil and gas extracted by these companies (automotive, chemical/polymers, etc.)? Will you follow the chain from extraction to consumption and add the links to the license 'blacklist'? -gyro On 7/1/2020 12:34 PM, John Preston wrote: > Hello all, > > The following proposal was originally issue #16722 on GitHub but at > the request of Matti Picus I am moving the discussion to this list. > > > "NumPy is the fundamental package needed for scientific computing with > Python." > > I am asking the NumPy project to leverage its position as a core > dependency among statistical, numerical, and ML projects, in the > pursuit of climate justice. It is easy to identify open-source > software used by the oil and gas industry which relies on NumPy [1] > [2] , and it is highly likely that NumPy is used in closed-source and > in-house software at oil and gas extraction companies such as Aramco, > ExxonMobil, BP, Shell, and others. I believe it is possible to use > software licensing to discourage the use of NumPy and dependent > packages by companies such as these, and that doing so would frustrate > the ability of these companies to identify and extract new oil and gas > reserves. > > I propose NumPy's current BSD 3-Clause license be extended to include > the following conditions, in line with the Climate Strike License [3] > : > > * The Software may not be used in applications and services that > are used for or >aid in the exploration, extraction, refinement, processing, or > transportation >of fossil fuels. > > * The Software may not be used by companies that rely on fossil > fuel extraction >as their primary means of revenue. This includes but is not > limited to the >companies listed at https://climatestrike.software/blocklist > > I accept that there are issues around adopting such a proposal, including > that: > > addition of such clauses violates the Open Source Initiative's > canonical Open Source Definition, which explicitly excludes licenses > that limit re-use "in a specific field of endeavor", and therefore if > these clauses were adopted NumPy would no longer "be open-source" by > this definition; > there may be collateral damage among the wider user base and project > sponsorship, due to the vague nature of the first clause, and this may > affect the longevity of the project and its standing within the > Python, numerical, statistical, and ML communities. > > My intention with the opening of this issue is to promote constructive > discussion of the use of software licensing -- and other measures -- > for working towards climate justice -- and other forms of justice -- > in the context of NumPy and other popular open-source libraries. Some > people will say that NumPy is "just a tool" and that it sits > independent of how it is used, but due to its utility and its > influence as a major open-source library, I think it is essential that > we consider the position of the Climate Strike License authors, that > "as tech workers, we should take responsibility in how our software is > used". > > Many thanks to all of the contributors who have put so much time and > energy into NumPy. ✨ ❤️ > > [1] https://github.com/gazprom-neft/petroflow > [2] https://github.com/climate-strike/analysis > [3] https://github.com/climate-strike/license > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > pEpkey.asc Description: application/pgp-keys ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy
On Sat, 2020-06-27 at 16:08 -0700, Rakesh Vasudevan wrote: > Hi all, > >Following up on this. Created a WIP PR > https://github.com/numpy/numpy/pull/16700 > > As stated in the original thread, We need to start by having a sort() > function for complex numbers that can do it based on keys, rather > than > plain arithmetic ordering. > > There are two broad ways to approach a sorting function that supports > keys > (Not just for complex numbers). > Thanks for this. I think the idea is good in general and I would be happy to discuss details here. It was discussed briefly here: https://github.com/numpy/numpy/issues/15981 This is a WIP, but allows nicely to try out how the new API could/should look like, and see the potential impact to code. The current choice is for: np.sort(arr, keys=(arr.real, arr.image)) for example. `keys` is like the `key` argument to pythons sorts, but unlike python sorts is not passed a function but rather a sequence of arrays. Alternative spellings could be `by=...`? Or maybe someone has a different API idea. There are also some implementation details to figure out, since internally it probably will do an `argsort` over all key arrays which is much like, but a bit faster than, `np.lexsort`+`np.take_along_axis`. I like this approach in general, since I do not think complex lexicographic sorting is "obvious" and this also allows the choice of: np.sort(complex_arr, keys=(abs(complex_arr,)) to get convenient (although maybe not fastest) sorting by magnitude seems like a reasonable API choice. So I am happy if Rakesh pushes this forward, and if anyone has doubts about the API choice in general or the implications to complex sorting specifically it would be good to discuss this. The PR allows some testing of the feature already. Cheers, Sebastian >1. Add a key kwarg to the sort() (function and method). To support > key >based sorting on arrays. >2. Use a new function on the lines off sortby(c_arr, > key=(c_arr.real, >c_arr.imag) > > In this PR I have chosen approach 1 for the following reasons > >1. > >Approach 1 means it is easier to deal with both in-place method > and the >function. Since we can make the change in the c-sort function, we > have >minimal change in the python layer. This I hope results, minimal > impact on >current code that handles complex sorting. One example within > numpy is is >linalg module's svd() function. >2. > >With approach 2 when we deprecate complex arithmetic ordering, > existing >methods using sort() for complex types, need to update their > signature. > > As it stands the PR does the following 3 things within the Python-C > Array > method implementation of sort > >1. Checks for complex type- If array is of complex-type, it > creates a >default key(When no key is passed) which mimics the current > arithmetic >ordering in Numpy . >2. Uses the keys to perform a Py_LexSort and generate indices. >3. We perform the take_along_axis via C call back and copy over > the >result to the original array (pseudo in-place). > > I am requesting feedback/help on implementing take_along_axis logic > in C > level in an in-place manner and the approach in general. > > This will further feed into max() and min() as well. Once we figure > this > out. Next step would be to deprecate arithmetic ordering for complex > types > (Which I think will be a PR on it's own) > > > Regards > > Rakesh > > On Thu, Jun 4, 2020 at 9:21 PM Brock Mendel > wrote: > > > Corresponding pandas issue: > > https://github.com/pandas-dev/pandas/issues/28050 > > > > On Thu, Jun 4, 2020 at 9:17 PM Rakesh Vasudevan < > > rakesh.nvasu...@gmail.com> > > wrote: > > > > > Hi all, > > > > > > As a follow up to gh-15981 < > > > https://github.com/numpy/numpy/issues/15981>;, > > > I would like to propose a change to bring complex dtype(s) > > > comparison > > > operators and related functions, in line with respective cpython > > > implementations. > > > > > > The current state of complex dtype comparisons/ordering as > > > summarised in > > > the issue is as follows: > > > > > > # In python > > > > > > > > cnum = 1 + 2j > > > > > cnum_two = 1 + 3j > > > > > > # Doing a comparision yields > > > > > cnum > cnum_two > > > > > > TypeError: '>' not supported between instances of 'complex' and > > > 'complex' > > > > > > > > > # Doing the same in Numpy scalar comparision > > > > > > > > np.array(cnum) > np.array(cnum_two) > > > > > > # Yields > > > > > > False > > > > > > > > > *NOTE*: only >, <, >= , <= do not work on complex numbers in > > > python , > > > equality (==) does work > > > > > > similarly sorting uses comparison operators behind to sort > > > complex > > > values. Again this behavior diverges from the default python > > > behavior. > > > > > > # In native python > > > > > clist = [cnum, cnum_2] > > > > > sorted(clist, key=lambda c: (c.real, c.imag)) > > > [(1+2j),
Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies
I think it is important to acknowledge that, regardless of the merits of such a license change on its own, NumPy's position in the dependency stack of PyData makes a license change that restricts an existing class of users impossible without causing a lot of chaos for non-NumPy developers who may not be involved in the decision. Imagine if NumPy switched to GPL (which also conflicts with the IT policy for many companies). This would immediately trigger a fork of NumPy at the last BSD licensed release. Ignoring the trademark issues, let's assume the fork is called "numpy-nogpl". Now every single PyData package that depends on NumPy now has to decide whether to depend on numpy or numpy-nogpl. A project sticking with "numpy" effectively means they are now forcing their user base to accept GPL software (even though their own package license has not changed), so likely many will have to push out a release that depends on numpy-nogpl, at least until they can decide whether they are willing to lose some of their users. Now every PyData package (of which there are many) is trying to decide which NumPy fork to depend on, and those packages that aren't updated have a new user policy forced on them. This is not unlike the problem with NumPy releasing a backward incompatible API change and breaking downstream packages, but in this case the incompatibility is legal, rather than functional. The deeper a project is in the dependency stack, the bigger the collateral disruption will be. I think the only way to do something like this would be for the NumPy development community to choose to fork themselves, pick a new project name, stop working on the original NumPy, and then lobby the community to switch to their fork. On Wed, Jul 1, 2020 at 1:35 PM John Preston wrote: > Hello all, > > The following proposal was originally issue #16722 on GitHub but at > the request of Matti Picus I am moving the discussion to this list. > > > "NumPy is the fundamental package needed for scientific computing with > Python." > > I am asking the NumPy project to leverage its position as a core > dependency among statistical, numerical, and ML projects, in the > pursuit of climate justice. It is easy to identify open-source > software used by the oil and gas industry which relies on NumPy [1] > [2] , and it is highly likely that NumPy is used in closed-source and > in-house software at oil and gas extraction companies such as Aramco, > ExxonMobil, BP, Shell, and others. I believe it is possible to use > software licensing to discourage the use of NumPy and dependent > packages by companies such as these, and that doing so would frustrate > the ability of these companies to identify and extract new oil and gas > reserves. > > I propose NumPy's current BSD 3-Clause license be extended to include > the following conditions, in line with the Climate Strike License [3] > : > > * The Software may not be used in applications and services that > are used for or >aid in the exploration, extraction, refinement, processing, or > transportation >of fossil fuels. > > * The Software may not be used by companies that rely on fossil > fuel extraction >as their primary means of revenue. This includes but is not > limited to the >companies listed at https://climatestrike.software/blocklist > > I accept that there are issues around adopting such a proposal, including > that: > > addition of such clauses violates the Open Source Initiative's > canonical Open Source Definition, which explicitly excludes licenses > that limit re-use "in a specific field of endeavor", and therefore if > these clauses were adopted NumPy would no longer "be open-source" by > this definition; > there may be collateral damage among the wider user base and project > sponsorship, due to the vague nature of the first clause, and this may > affect the longevity of the project and its standing within the > Python, numerical, statistical, and ML communities. > > My intention with the opening of this issue is to promote constructive > discussion of the use of software licensing -- and other measures -- > for working towards climate justice -- and other forms of justice -- > in the context of NumPy and other popular open-source libraries. Some > people will say that NumPy is "just a tool" and that it sits > independent of how it is used, but due to its utility and its > influence as a major open-source library, I think it is essential that > we consider the position of the Climate Strike License authors, that > "as tech workers, we should take responsibility in how our software is > used". > > Many thanks to all of the contributors who have put so much time and > energy into NumPy. ✨ ❤️ > > [1] https://github.com/gazprom-neft/petroflow > [2] https://github.com/climate-strike/analysis > [3] https://github.com/climate-strike/license > ___ > NumPy-Discussion mailing list >
[Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies
Hello all, The following proposal was originally issue #16722 on GitHub but at the request of Matti Picus I am moving the discussion to this list. "NumPy is the fundamental package needed for scientific computing with Python." I am asking the NumPy project to leverage its position as a core dependency among statistical, numerical, and ML projects, in the pursuit of climate justice. It is easy to identify open-source software used by the oil and gas industry which relies on NumPy [1] [2] , and it is highly likely that NumPy is used in closed-source and in-house software at oil and gas extraction companies such as Aramco, ExxonMobil, BP, Shell, and others. I believe it is possible to use software licensing to discourage the use of NumPy and dependent packages by companies such as these, and that doing so would frustrate the ability of these companies to identify and extract new oil and gas reserves. I propose NumPy's current BSD 3-Clause license be extended to include the following conditions, in line with the Climate Strike License [3] : * The Software may not be used in applications and services that are used for or aid in the exploration, extraction, refinement, processing, or transportation of fossil fuels. * The Software may not be used by companies that rely on fossil fuel extraction as their primary means of revenue. This includes but is not limited to the companies listed at https://climatestrike.software/blocklist I accept that there are issues around adopting such a proposal, including that: addition of such clauses violates the Open Source Initiative's canonical Open Source Definition, which explicitly excludes licenses that limit re-use "in a specific field of endeavor", and therefore if these clauses were adopted NumPy would no longer "be open-source" by this definition; there may be collateral damage among the wider user base and project sponsorship, due to the vague nature of the first clause, and this may affect the longevity of the project and its standing within the Python, numerical, statistical, and ML communities. My intention with the opening of this issue is to promote constructive discussion of the use of software licensing -- and other measures -- for working towards climate justice -- and other forms of justice -- in the context of NumPy and other popular open-source libraries. Some people will say that NumPy is "just a tool" and that it sits independent of how it is used, but due to its utility and its influence as a major open-source library, I think it is essential that we consider the position of the Climate Strike License authors, that "as tech workers, we should take responsibility in how our software is used". Many thanks to all of the contributors who have put so much time and energy into NumPy. ✨ ❤️ [1] https://github.com/gazprom-neft/petroflow [2] https://github.com/climate-strike/analysis [3] https://github.com/climate-strike/license ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
