Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies

[Juan Nunez-Iglesias]

Hi everyone,

If you live in Australia, this has been a rough year to think about climate 
change. After the hottest and driest year on record, over 20% of the forest 
surface area of the south east was burned in the bushfires. Although I was 
hundreds of kilometres from the nearest fire, the air quality was rated as 
hazardous for several days in my city. This brought home for me two points.

One, that "4ºC" is not about taking off a jumper and going to the beach more 
often, but actually represents a complete transformation of our planet. 4ºC is 
what separates us from the last ice age, so we can expect our planet in 80 
years to be as unrecognisable from today as today is from the ice age.

Two, that climate change is already with us, and we can't just continue to 
ignore the problem and enjoy whatever years of climate peace we thought we had 
left. Greta has it right, we are running out of time and absolutely drastic 
action is needed.

All this is a prelude to add my voice to everyone who has already said that 
messing with the NumPy license is absolutely *not* the drastic action needed, 
and will be counter-productive, as many have noted.

Having said this, I'm happy that the community is getting involved and getting 
active and coming up with creative ideas to do their part. If someone wants to 
start a "Pythonistas for Climate Action" user group, I'll be the first to join. 
I had planned to give a lightning talk in the vein of the above at SciPy, 
which, and believe me that I hate to hate on my favourite conference, recently 
loudly thanked Shell [1] for being a platinum sponsor. (Not to mention that 
Enthought derives about a third of its income from fossil fuel companies.) 
Unfortunately and for obvious reasons I won't make it to SciPy after all, but 
again, I'm happy to see the community rising.

Perhaps this is derailing the discussion, but, anyone up for a "Python for 
Climate Action" BoF at the conference? I can probably make the late-afternoon 
BoFs given the time difference.

Juan.

[1]: https://twitter.com/SciPyConf/status/1276898138977193984___
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

[Ralf Gommers]

On Thu, Jul 2, 2020 at 10:58 AM Juan Nunez-Iglesias 
wrote:

> Hi everyone,
>
> If you live in Australia, this has been a rough year to think about
> climate change. After the hottest and driest year on record, over 20% of
> the forest surface area of the south east was burned in the bushfires.
> Although I was hundreds of kilometres from the nearest fire, the air
> quality was rated as hazardous for several days in my city. This brought
> home for me two points.
>
> One, that "4ºC" is not about taking off a jumper and going to the beach
> more often, but actually represents a complete transformation of our
> planet. 4ºC is what separates us from the last ice age, so we can expect
> our planet in 80 years to be as unrecognisable from today as today is from
> the ice age.
>
> Two, that climate change is already with us, and we can't just continue to
> ignore the problem and enjoy whatever years of climate peace we thought we
> had left. Greta has it right, we are running out of time and absolutely
> drastic action is needed.
>
> All this is a prelude to add my voice to everyone who has already said
> that *messing with the NumPy license is absolutely *not* the drastic
> action needed*, and will be counter-productive, as many have noted.
>
> Having said this, I'm happy that the community is getting involved and
> getting active and coming up with creative ideas to do their part. If
> someone wants to start a "Pythonistas for Climate Action" user group, I'll
> be the first to join. I had planned to give a lightning talk in the vein of
> the above at SciPy, which, and believe me that I hate to hate on my
> favourite conference, recently loudly thanked Shell [1] for being a
> platinum sponsor. (Not to mention that Enthought derives about a third of
> its income from fossil fuel companies.) Unfortunately and for obvious
> reasons I won't make it to SciPy after all, but again, I'm happy to see the
> community rising.
>
> Perhaps this is derailing the discussion, but, anyone up for a "Python for
> Climate Action" BoF at the conference? I can probably make the
> late-afternoon BoFs given the time difference.
>

Thanks for this Juan. I don't think it's derailing the discussion. Thinking
about things we *can* do that may have a positive influence on the climate
emergency we're in, or the state of the world in general, are valid and
probably the most productive turn this conversation can take. Changing the
NumPy license isn't feasible, because of many of the pragmatic reasons
already pointed out. That said, the "NumPy is just a tool" point of view is
fairly naive; I think we do have a responsibility to at least think about
the wider issues and possibly make some changes.

One thing I have been thinking about recently is the educational material
and high level documentation we produce. When we use data sources or write
tutorials, we can incorporate data and examples related to climate issues,
social issues, ethics in ML/AI, etc.

Another thing to think about is: what do we, NumPy maintainers and
contributors, choose to spend our time on? Not each issue/PR opened
deserves our time equally - we're (almost) all volunteers after all. A PR
that for example improves the classroom experience of teaching NumPy may be
prioritized over a PR that helps fix an issue for .

I'd be interested to hear if others back thought about this before or have
any ideas.

Cheers,
Ralf
___
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

[Ilhan Polat]

Ralf basically wrote the email that I was about the send in a much more
structured way so thanks for that. I'd like to mention also that oil&gas
industry practically cannot be cornered by these restrictions. So even the
cause is very noble and I wholeheartedly agree, forcing this type of
exclusions only will make their hand stronger in going to other commercial
software (they can really afford even acquiring whole companies) and
forcing their employees using it and finally boomeranging back to the
reduction of the potential contributors to open source who would have
otherwise contributed back just because they liked it (like most of us did
back in the day). For example, Shell and Intel are corporate level
collaborators. Should we ban also usage of MKL? Of course not, because this
is not about driving Shell and others to software starvation but actually
forcing them to take concrete steps towards the climate crisis. This is not
to say we are desperate, quite the contrary, however this strategy seems
dire against the possible outcomes.

I really would like to take a more concrete approach that Ralf outlined.
Again, it is not a crusade against commercial software, I truly think all
have different shoes to fill in. However, making the switch from commercial
software to open source as smooth as possible would actually emit the
message that we are not bound to conglomerate structures to achieve noble
goals. Thus this would make a bolder statement as far as what software can
manage to display. Signal processing can make fuel consumption notebooks,
stats can display bicycle usage results and their impact etc. Again it is a
mentality that we are trying to build so it shouldn't be up to the level of
annoyance so that everyone can hop on the bandwagon.



On Thu, Jul 2, 2020 at 12:14 PM Ralf Gommers  wrote:

>
>
> On Thu, Jul 2, 2020 at 10:58 AM Juan Nunez-Iglesias 
> wrote:
>
>> Hi everyone,
>>
>> If you live in Australia, this has been a rough year to think about
>> climate change. After the hottest and driest year on record, over 20% of
>> the forest surface area of the south east was burned in the bushfires.
>> Although I was hundreds of kilometres from the nearest fire, the air
>> quality was rated as hazardous for several days in my city. This brought
>> home for me two points.
>>
>> One, that "4ºC" is not about taking off a jumper and going to the beach
>> more often, but actually represents a complete transformation of our
>> planet. 4ºC is what separates us from the last ice age, so we can expect
>> our planet in 80 years to be as unrecognisable from today as today is from
>> the ice age.
>>
>> Two, that climate change is already with us, and we can't just continue
>> to ignore the problem and enjoy whatever years of climate peace we thought
>> we had left. Greta has it right, we are running out of time and absolutely
>> drastic action is needed.
>>
>> All this is a prelude to add my voice to everyone who has already said
>> that *messing with the NumPy license is absolutely *not* the drastic
>> action needed*, and will be counter-productive, as many have noted.
>>
>> Having said this, I'm happy that the community is getting involved and
>> getting active and coming up with creative ideas to do their part. If
>> someone wants to start a "Pythonistas for Climate Action" user group, I'll
>> be the first to join. I had planned to give a lightning talk in the vein of
>> the above at SciPy, which, and believe me that I hate to hate on my
>> favourite conference, recently loudly thanked Shell [1] for being a
>> platinum sponsor. (Not to mention that Enthought derives about a third of
>> its income from fossil fuel companies.) Unfortunately and for obvious
>> reasons I won't make it to SciPy after all, but again, I'm happy to see the
>> community rising.
>>
>> Perhaps this is derailing the discussion, but, anyone up for a "Python
>> for Climate Action" BoF at the conference? I can probably make the
>> late-afternoon BoFs given the time difference.
>>
>
> Thanks for this Juan. I don't think it's derailing the discussion.
> Thinking about things we *can* do that may have a positive influence on the
> climate emergency we're in, or the state of the world in general, are valid
> and probably the most productive turn this conversation can take. Changing
> the NumPy license isn't feasible, because of many of the pragmatic reasons
> already pointed out. That said, the "NumPy is just a tool" point of view is
> fairly naive; I think we do have a responsibility to at least think about
> the wider issues and possibly make some changes.
>
> One thing I have been thinking about recently is the educational material
> and high level documentation we produce. When we use data sources or write
> tutorials, we can incorporate data and examples related to climate issues,
> social issues, ethics in ML/AI, etc.
>
> Another thing to think about is: what do we, NumPy maintainers and
> contributors, choose to spend our time on? Not each i

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20

[Inessa Pawson]

Hi, Juan!
I’m still in the process of scheduling live networking sessions at SciPy’20
and would be happy to set up one on the topic of Python for Climate Action.
We could host it on July 8th or 10th at 5 - 6 p.m. CDT. Would you be
available to moderate it?


> -- Forwarded message --
> From: Juan Nunez-Iglesias 
> To: Discussion of Numerical Python 
> Cc:
> Bcc:
> Date: Thu, 2 Jul 2020 18:58:11 +1000
> Subject: Re: [Numpy-discussion] Proposal to add clause to license
> prohibiting use by oil and gas extraction companies
> Hi everyone,
>
> If you live in Australia, this has been a rough year to think about
> climate change. After the hottest and driest year on record, over 20% of
> the forest surface area of the south east was burned in the bushfires.
> Although I was hundreds of kilometres from the nearest fire, the air
> quality was rated as hazardous for several days in my city. This brought
> home for me two points.
>
> One, that "4ºC" is not about taking off a jumper and going to the beach
> more often, but actually represents a complete transformation of our
> planet. 4ºC is what separates us from the last ice age, so we can expect
> our planet in 80 years to be as unrecognisable from today as today is from
> the ice age.
>
> Two, that climate change is already with us, and we can't just continue to
> ignore the problem and enjoy whatever years of climate peace we thought we
> had left. Greta has it right, we are running out of time and absolutely
> drastic action is needed.
>
> All this is a prelude to add my voice to everyone who has already said
> that *messing with the NumPy license is absolutely *not* the drastic
> action needed*, and will be counter-productive, as many have noted.
>
> Having said this, I'm happy that the community is getting involved and
> getting active and coming up with creative ideas to do their part. If
> someone wants to start a "Pythonistas for Climate Action" user group, I'll
> be the first to join. I had planned to give a lightning talk in the vein of
> the above at SciPy, which, and believe me that I hate to hate on my
> favourite conference, recently loudly thanked Shell [1] for being a
> platinum sponsor. (Not to mention that Enthought derives about a third of
> its income from fossil fuel companies.) Unfortunately and for obvious
> reasons I won't make it to SciPy after all, but again, I'm happy to see the
> community rising.
>
> Perhaps this is derailing the discussion, but, anyone up for a "Python for
> Climate Action" BoF at the conference? I can probably make the
> late-afternoon BoFs given the time difference.
>
> Juan.
>
> [1]: https://twitter.com/SciPyConf/status/1276898138977193984
>
>
> --
Every good wish,
*Inessa Pawson*
Albus Code
ine...@albuscode.org
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20

[Juan Nunez-Iglesias]

Hi Inessa,

Thanks for offering! I definitely want to participate but I would *love it* if 
an actual climate scientist or even *any* atmospheric scientist would step up 
to chair the session! I have not thought all that deeply about this problem, 
and mostly I feel helpless and frustrated.

If no one else volunteers though I'm happy to do it.

I much prefer the Wednesday session. Let's book it in!

Thank you all,

Juan.

> On 2 Jul 2020, at 8:38 pm, Inessa Pawson  wrote:
> 
> Hi, Juan!
> I’m still in the process of scheduling live networking sessions at SciPy’20 
> and would be happy to set up one on the topic of Python for Climate Action. 
> We could host it on July 8th or 10th at 5 - 6 p.m. CDT. Would you be 
> available to moderate it?
> 
> 
> -- Forwarded message --
> From: Juan Nunez-Iglesias mailto:j...@fastmail.com>>
> To: Discussion of Numerical Python  >
> Cc: 
> Bcc: 
> Date: Thu, 2 Jul 2020 18:58:11 +1000
> Subject: Re: [Numpy-discussion] Proposal to add clause to license prohibiting 
> use by oil and gas extraction companies
> Hi everyone,
> 
> If you live in Australia, this has been a rough year to think about climate 
> change. After the hottest and driest year on record, over 20% of the forest 
> surface area of the south east was burned in the bushfires. Although I was 
> hundreds of kilometres from the nearest fire, the air quality was rated as 
> hazardous for several days in my city. This brought home for me two points.
> 
> One, that "4ºC" is not about taking off a jumper and going to the beach more 
> often, but actually represents a complete transformation of our planet. 4ºC 
> is what separates us from the last ice age, so we can expect our planet in 80 
> years to be as unrecognisable from today as today is from the ice age.
> 
> Two, that climate change is already with us, and we can't just continue to 
> ignore the problem and enjoy whatever years of climate peace we thought we 
> had left. Greta has it right, we are running out of time and absolutely 
> drastic action is needed.
> 
> All this is a prelude to add my voice to everyone who has already said that 
> messing with the NumPy license is absolutely *not* the drastic action needed, 
> and will be counter-productive, as many have noted.
> 
> Having said this, I'm happy that the community is getting involved and 
> getting active and coming up with creative ideas to do their part. If someone 
> wants to start a "Pythonistas for Climate Action" user group, I'll be the 
> first to join. I had planned to give a lightning talk in the vein of the 
> above at SciPy, which, and believe me that I hate to hate on my favourite 
> conference, recently loudly thanked Shell [1] for being a platinum sponsor. 
> (Not to mention that Enthought derives about a third of its income from 
> fossil fuel companies.) Unfortunately and for obvious reasons I won't make it 
> to SciPy after all, but again, I'm happy to see the community rising.
> 
> Perhaps this is derailing the discussion, but, anyone up for a "Python for 
> Climate Action" BoF at the conference? I can probably make the late-afternoon 
> BoFs given the time difference.
> 
> Juan.
> 
> [1]: https://twitter.com/SciPyConf/status/1276898138977193984 
> 
> 
> -- 
> Every good wish,
> Inessa Pawson 
> Albus Code
> ine...@albuscode.org 
> 
> ___
> 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] Python for Climate Action session at SciPy'20

[Dr. Mark Alexander Mikofski PhD]

I can repost this on pvlib (solar energy photovoltaic library) Python
Google group (https://groups.google.com/forum/m/#!forum/pvlib-python). We
have plenty of both climate and atmospheric scientists, and we are avid
users of Numpy, SciPy, and the scientific stack. We would love to share
constructive uses of Python in climate science.

On Thu, Jul 2, 2020, 7:18 AM Juan Nunez-Iglesias  wrote:

> Hi Inessa,
>
> Thanks for offering! I definitely want to participate but I would *love
> it* if an actual climate scientist or even *any* atmospheric scientist
> would step up to chair the session! I have not thought all that deeply
> about this problem, and mostly I feel helpless and frustrated.
>
> If no one else volunteers though I'm happy to do it.
>
> I much prefer the Wednesday session. Let's book it in!
>
> Thank you all,
>
> Juan.
>
> On 2 Jul 2020, at 8:38 pm, Inessa Pawson  wrote:
>
> Hi, Juan!
> I’m still in the process of scheduling live networking sessions at
> SciPy’20 and would be happy to set up one on the topic of Python for
> Climate Action. We could host it on July 8th or 10th at 5 - 6 p.m. CDT.
> Would you be available to moderate it?
>
>
>> -- Forwarded message --
>> From: Juan Nunez-Iglesias 
>> To: Discussion of Numerical Python 
>> Cc:
>> Bcc:
>> Date: Thu, 2 Jul 2020 18:58:11 +1000
>> Subject: Re: [Numpy-discussion] Proposal to add clause to license
>> prohibiting use by oil and gas extraction companies
>> Hi everyone,
>>
>> If you live in Australia, this has been a rough year to think about
>> climate change. After the hottest and driest year on record, over 20% of
>> the forest surface area of the south east was burned in the bushfires.
>> Although I was hundreds of kilometres from the nearest fire, the air
>> quality was rated as hazardous for several days in my city. This brought
>> home for me two points.
>>
>> One, that "4ºC" is not about taking off a jumper and going to the beach
>> more often, but actually represents a complete transformation of our
>> planet. 4ºC is what separates us from the last ice age, so we can expect
>> our planet in 80 years to be as unrecognisable from today as today is from
>> the ice age.
>>
>> Two, that climate change is already with us, and we can't just continue
>> to ignore the problem and enjoy whatever years of climate peace we thought
>> we had left. Greta has it right, we are running out of time and absolutely
>> drastic action is needed.
>>
>> All this is a prelude to add my voice to everyone who has already said
>> that *messing with the NumPy license is absolutely *not* the drastic
>> action needed*, and will be counter-productive, as many have noted.
>>
>> Having said this, I'm happy that the community is getting involved and
>> getting active and coming up with creative ideas to do their part. If
>> someone wants to start a "Pythonistas for Climate Action" user group, I'll
>> be the first to join. I had planned to give a lightning talk in the vein of
>> the above at SciPy, which, and believe me that I hate to hate on my
>> favourite conference, recently loudly thanked Shell [1] for being a
>> platinum sponsor. (Not to mention that Enthought derives about a third of
>> its income from fossil fuel companies.) Unfortunately and for obvious
>> reasons I won't make it to SciPy after all, but again, I'm happy to see the
>> community rising.
>>
>> Perhaps this is derailing the discussion, but, anyone up for a "Python
>> for Climate Action" BoF at the conference? I can probably make the
>> late-afternoon BoFs given the time difference.
>>
>> Juan.
>>
>> [1]: https://twitter.com/SciPyConf/status/1276898138977193984
>>
>>
>> --
> Every good wish,
> *Inessa Pawson*
> Albus Code
> ine...@albuscode.org
>
> ___
> 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

[Dr. Mark Alexander Mikofski PhD]

Thank you everyone. This is a fascinating thread, and very interesting to
see how it has transformed into constructive discussion of positive action.
Along that line I think it could be useful to curate a list of Python (and
OpenSci) packages using Numpy, SciPy, or any part of the Python scientific
stack.

For example I know there are several clean, renewable energy packages that
depend on Numpy, etc, especially in solar energy. The lead maintainer for
pvlib python presented a list at our annual IEEE PV Specialists conference
2 years ago, it's on GitHub here
https://openpvtools.readthedocs.io/en/latest/

In particular pvlib python and rdtools are two widely used tools that
depend on Numpy, SciPy, etc. (Disclaimer, I am one of the maintainers for
pvlib.)

I think we could pull together projects from the journal of open source
(JOSS), OpenSci, and NumFOCUS. Then we could host/link/highlight examples,
case studies, and projects that use Numpy to combat climate change. There
is already a separate thread started by Inessa Pawson (Re:
[Numpy-discussion] Python for Climate Action session at SciPy'20) following
up on Juan's idea for BoF at SciPy to highlight climate change action by
the Python scientific community. We could try to encourage more climate
change and clean energy projects to participate in SciPy and PyCon.
Conversely, we could even promote Numpy with climate and clean energy
scientists at their conferences like AMS and IEEE PVSC. For example, next
year we are planning to host a Python tutorial at PVSC as part of the
tutorial program that preceeds the conference, but we need support with
logistics. (Thanks already to Yuvi Panda for help with mybinder & TLJH.)
This could be the opportunity for the Python scientific community, clean
energy & climate scientists, academic, & national labs to collaborate and
synergize.

I volunteer to participate in whatever capacity I can to develop this
collaboration if folks think it is useful. I'm not sure how to proceed, but
whatever the result I believe some momentum is forming here, so there's an
opportunity to carpe diem.

Cheers,
Mark

On Thu, Jul 2, 2020, 3:35 AM Ilhan Polat  wrote:

> Ralf basically wrote the email that I was about the send in a much more
> structured way so thanks for that. I'd like to mention also that oil&gas
> industry practically cannot be cornered by these restrictions. So even the
> cause is very noble and I wholeheartedly agree, forcing this type of
> exclusions only will make their hand stronger in going to other commercial
> software (they can really afford even acquiring whole companies) and
> forcing their employees using it and finally boomeranging back to the
> reduction of the potential contributors to open source who would have
> otherwise contributed back just because they liked it (like most of us did
> back in the day). For example, Shell and Intel are corporate level
> collaborators. Should we ban also usage of MKL? Of course not, because this
> is not about driving Shell and others to software starvation but actually
> forcing them to take concrete steps towards the climate crisis. This is not
> to say we are desperate, quite the contrary, however this strategy seems
> dire against the possible outcomes.
>
> I really would like to take a more concrete approach that Ralf outlined.
> Again, it is not a crusade against commercial software, I truly think all
> have different shoes to fill in. However, making the switch from commercial
> software to open source as smooth as possible would actually emit the
> message that we are not bound to conglomerate structures to achieve noble
> goals. Thus this would make a bolder statement as far as what software can
> manage to display. Signal processing can make fuel consumption notebooks,
> stats can display bicycle usage results and their impact etc. Again it is a
> mentality that we are trying to build so it shouldn't be up to the level of
> annoyance so that everyone can hop on the bandwagon.
>
>
>
> On Thu, Jul 2, 2020 at 12:14 PM Ralf Gommers 
> wrote:
>
>>
>>
>> On Thu, Jul 2, 2020 at 10:58 AM Juan Nunez-Iglesias 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> If you live in Australia, this has been a rough year to think about
>>> climate change. After the hottest and driest year on record, over 20% of
>>> the forest surface area of the south east was burned in the bushfires.
>>> Although I was hundreds of kilometres from the nearest fire, the air
>>> quality was rated as hazardous for several days in my city. This brought
>>> home for me two points.
>>>
>>> One, that "4ºC" is not about taking off a jumper and going to the beach
>>> more often, but actually represents a complete transformation of our
>>> planet. 4ºC is what separates us from the last ice age, so we can expect
>>> our planet in 80 years to be as unrecognisable from today as today is from
>>> the ice age.
>>>
>>> Two, that climate change is already with us, and we can't just continue
>>> to ignore the problem and enjoy whatev

Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies

[John Preston]

Thank you all for your input on this proposal. I am very grateful for
the time you have all spent to provide such well reasoned critiques
and I'm especially glad to see that this thread has triggered
discussion of other, more pragmatic, actions that the community can
take in pursuit of climate justice. 🙂

I found Stanley's analogy of this proposal being a "backwards
incompatible [legal] API change" particularly insightful, and Daniele
has illustrated exactly the kind of chaos this would create
downstream, threatening both NumPy itself (due to the packaging
requirements of distributors like Debian and Fedora) and its dependent
packages like Conda. Fundamentally I see this issue as a philosophical
one around how we define, and the importance of, 'free software' and
'open source software'. From a principles-based perspective, I agree
with Ryan that "equal rights except" is not truly equal, and that
changing the definition(s) of F/OSS would damage the movement by
making it much less clear what is and isn't F/OSS. On the other hand,
from a pragmatic perspective, I care less about if software I use is
strictly F/OSS, and more about if I can do what I want with it, and
who else gets to enjoy those privileges -- I choose the word
'privilege' here specifically to highlight that the core of F/OSS is
rights, which are unconditional, whereas this proposal would make
those rights contingent on conditions that cannot be met by all
actors, and therefore they would be privileges, not rights. So
essentially, this proposal is asking "are there some uses of NumPy
which are so ethically wrong, that it would be better for NumPy to be
non-F/OSS in order to prevent those uses, than for NumPy to be F/OSS,
and advance the F/OSS movement, while also allowing those uses?"

Answering this question requires an awareness of the broader context
within which NumPy sits. Ilhan has pointed out that O&G companies
cannot be coerced by more restrictive licensing of NumPy because there
are commercial options that they could use instead. Therefore, without
evidence that NumPy powers a significant chunk of the analytics at
major O&G companies, and that relicensing NumPy would cause
significant disruption to those companies and their ability to carry
out their operations, it is much more likely that any negative effect
on O&G, and therefore any positive effect on the climate, would be
outweighed by the harm caused to downstream packages.

I agree that the first term is particularly vague, and I would love to
see input from lawyers on how the software community can adopt rigid
clauses in licenses for software that needs this, because although
F/OSS may be "good by default" in that for most software, most of the
time, releasing as F/OSS will be good, this does not mean that there
is no software which requires stricter licensing. I would draw an
analogy with responsible disclosure of vulnerabilities: vendors are
provided with a window of time to fix a vulnerability before
researchers publish their findings, on the basis that immediate
publication of the findings presents more of a threat than a benefit,
because malicious actors could weaponise and abuse the vulnerability
before it is patched. In other words, as software creators, we have a
responsibility to weigh the potential and actual uses of our software
to determine if we are in a position to prevent harm by licensing or
relicensing our software appropriately.

I do not think the second clause is vague or unenforceable, as it
should be demonstrable by any company what its primary revenue sources
are and if any of those activities constitute fossil fuel extraction.
However, the second clause by itself may not be sufficient to prevent
use of software by O&G: Shell could form a company Shell Analytics,
which carries out all analytical work for the other departments, and
thus the primary business of that company would be "numerical
services".

Regarding other political agendas, as an advocate of
responsible/ethical/political/... software licensing (where
appropriate), I would like to see a set of lawyer-vetted clauses that
could be plugged into base licenses and combined in a compatible way.
While there are many other causes (arms manufacture, animal rights,
...) which are more controversial than the climate emergency which
could be discussed in the context of software use and software
licensing, I do not think that it would be a bad thing for these
discussions to be able to take place.

Regarding companies migrating their business models, this is a great
point but I have no ideas how I would structure a clause that could
allow this without potentially opening an unwanted loophole. I suppose
any company that wished to pivot like this could incorporate a new
entity which would be permitted to use the software, effectively the
inverse of the Shell Analytics example.

I believe I have addressed all of the issues which have been raised.
In the interest of keeping discussion here focused on NumPy and
ac

Re: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy

[Rakesh Vasudevan]

I agree with the idea of setting apart the parameter from python , "by"
sounds like a good alternative

Rakesh



On Wed, Jul 1, 2020, 18:45 Sebastian Berg 
wrote:

> 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
>
> ___
> 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] Help us to make NumPy better

[Inessa Pawson]

Yes, it’s a survey. But it’s very important.

Having limited human and financial resources is a common challenge for open
source projects. NumPy is not an exception. Please join this structured
dialogue with the NumPy leadership team to better guide and prioritize
decision-making about the development of NumPy as software and a community.

What started as a humble project by a dedicated core of user-developers has
since transformed into a foundational component of the widely-adopted
scientific Python ecosystem used by millions worldwide. To engage
non-English speaking stakeholders, the inaugural NumPy community survey is
offered in 7 additional languages: Bangla, Hindi, Japanese, Mandarin,
Portuguese, Russian, and Spanish.

The survey will take about 15 minutes of your time and close on July
17th. Click
here  to get started.

Inessa Pawson

NumPy Survey Team
___
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

[Todd]

On Thu, Jul 2, 2020 at 5:06 PM John Preston  wrote:

> Thank you all for your input on this proposal. I am very grateful for
> the time you have all spent to provide such well reasoned critiques
> and I'm especially glad to see that this thread has triggered
> discussion of other, more pragmatic, actions that the community can
> take in pursuit of climate justice. 🙂
>
> I found Stanley's analogy of this proposal being a "backwards
> incompatible [legal] API change" particularly insightful, and Daniele
> has illustrated exactly the kind of chaos this would create
> downstream, threatening both NumPy itself (due to the packaging
> requirements of distributors like Debian and Fedora) and its dependent
> packages like Conda. Fundamentally I see this issue as a philosophical
> one around how we define, and the importance of, 'free software' and
> 'open source software'. From a principles-based perspective, I agree
> with Ryan that "equal rights except" is not truly equal, and that
> changing the definition(s) of F/OSS would damage the movement by
> making it much less clear what is and isn't F/OSS. On the other hand,
> from a pragmatic perspective, I care less about if software I use is
> strictly F/OSS, and more about if I can do what I want with it, and
> who else gets to enjoy those privileges -- I choose the word
> 'privilege' here specifically to highlight that the core of F/OSS is
> rights, which are unconditional, whereas this proposal would make
> those rights contingent on conditions that cannot be met by all
> actors, and therefore they would be privileges, not rights. So
> essentially, this proposal is asking "are there some uses of NumPy
> which are so ethically wrong, that it would be better for NumPy to be
> non-F/OSS in order to prevent those uses, than for NumPy to be F/OSS,
> and advance the F/OSS movement, while also allowing those uses?"
>
> Answering this question requires an awareness of the broader context
> within which NumPy sits. Ilhan has pointed out that O&G companies
> cannot be coerced by more restrictive licensing of NumPy because there
> are commercial options that they could use instead. Therefore, without
> evidence that NumPy powers a significant chunk of the analytics at
> major O&G companies, and that relicensing NumPy would cause
> significant disruption to those companies and their ability to carry
> out their operations, it is much more likely that any negative effect
> on O&G, and therefore any positive effect on the climate, would be
> outweighed by the harm caused to downstream packages.
>
> I agree that the first term is particularly vague, and I would love to
> see input from lawyers on how the software community can adopt rigid
> clauses in licenses for software that needs this, because although
> F/OSS may be "good by default" in that for most software, most of the
> time, releasing as F/OSS will be good, this does not mean that there
> is no software which requires stricter licensing. I would draw an
> analogy with responsible disclosure of vulnerabilities: vendors are
> provided with a window of time to fix a vulnerability before
> researchers publish their findings, on the basis that immediate
> publication of the findings presents more of a threat than a benefit,
> because malicious actors could weaponise and abuse the vulnerability
> before it is patched. In other words, as software creators, we have a
> responsibility to weigh the potential and actual uses of our software
> to determine if we are in a position to prevent harm by licensing or
> relicensing our software appropriately.
>
.
I think you are still grossly underestimating just how disastrous this
change would be to numpy.  For one thing, this would make numpy
GPL-incompatible.  No GPL software would be legally able to use numpy as a
dependency anymore, killing likely thousands of downstream projects.  And
it isn't always under the control of the project, since a lot of projects
have non-Python dependencies that are GPL.  For example PyFFTW could no
longer exist, since FFTW3 is GPL.  RPY2, which lets R and Python interact,
would be effectively killed, since R and many core packages are GPL, and it
is essentially useless without numpy or other packages that depend on
numpy.

The end result would be an instant fork of the project at the point the
license changed.  There are just too many packages that use GPL to make
such a change feasible.  So this would end up fracturing and hurting the
community without actually accomplishing your goal.

This isn't a hypothetical issue, people have tried putting additional
restrictions on their software like this, and it tends to kill the
project.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion