Proposal to add clause to license prohibiting use by oil and gas extraction companies

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to add clause to license prohibiting use by oil and gas extraction companies

John Preston
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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

Stanley Seibert
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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

Gyro Funch
In reply to this post by John Preston
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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

pEpkey.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

Andrea Gavana
On Wed, 1 Jul 2020 at 21.23, gyro funch <[hidden email]> 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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

Thomas Caswell
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 <[hidden email]> wrote:
On Wed, 1 Jul 2020 at 21.23, gyro funch <[hidden email]> 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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion


--
Thomas Caswell
[hidden email]

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

Ryan May-3
In reply to this post by John Preston
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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion


--
Ryan May


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

Daniele Nicolodi
In reply to this post by John Preston
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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

Juan Nunez-Iglesias-2
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.


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

ralfgommers


On Thu, Jul 2, 2020 at 10:58 AM Juan Nunez-Iglesias <[hidden email]> 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 <insert big corp framework that's not contributing back in any way>.

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

Cheers,
Ralf






_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:


On Thu, Jul 2, 2020 at 10:58 AM Juan Nunez-Iglesias <[hidden email]> 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 <insert big corp framework that's not contributing back in any way>.

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

Cheers,
Ralf





_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add clause to license prohibiting use by oil and gas extraction companies

Mark Mikofski-2
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 <[hidden email]> 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 <[hidden email]> wrote:


On Thu, Jul 2, 2020 at 10:58 AM Juan Nunez-Iglesias <[hidden email]> 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 <insert big corp framework that's not contributing back in any way>.

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

Cheers,
Ralf





_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: 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
actions that this community can take towards solving the climate
emergency and achieving climate justice, I would ask that any further
non-NumPy-specific criticism of the proposal be directed towards the
Climate Strike License repo at GitHub [1], and I am very happy to
continue discussing these issues via email or in another public forum
of people's preference. 🙂 I think the most critical blow to this
proposal is the lack of evidence that relicensing NumPy would
significantly frustrate the operation of major O&G extraction
companies.

I think Juan's suggestion of a "Pythonistas for Climate Action" sounds
fantastic and I'm really glad to see Inessa Pawson has started another
thread for establishing a "Python for Climate Action" session at
SciPy'20. It is disappointing to hear of the sponsorship of the
conference by Shell. 🙁 Perhaps we should call on the organisers to
drop Shell as a sponsor? I am happy to draft a petition letter if
anyone is willing to sign, and very open to other suggestions.

Finally, I would like to point everyone towards ClimateAction.tech
[2], "a global community of tech professionals using our skills,
expertise and platforms to support solutions to the climate crisis".

[1] https://github.com/climate-strike/license
[2] https://climateaction.tech/

Many thanks again for all of your responses,
John

On Thu, 2 Jul 2020 at 18:19, Dr. Mark Alexander Mikofski PhD
<[hidden email]> wrote:

>
> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Thu, Jul 2, 2020 at 10:58 AM Juan Nunez-Iglesias <[hidden email]> 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 <insert big corp framework that's not contributing back in any way>.
>>>
>>> I'd be interested to hear if others back thought about this before or have any ideas.
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> [hidden email]
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> [hidden email]
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion