Revise methodology to account for non-public works at target companies

[wcerfgba]

After discussing adoption of Climate Strike License terms over on the numpy-discussion mailing list, I consider strong evidence of use and possibility of disruption to be a blocker for adoption. The maintainers of and contributors to any projects we lobby may be sympathetic to the issue of climate emergency, but unless we can demonstrate that the pro-climate effect of adopting these clauses outweighs the existential threats to the project and its downstream dependents , people will not want to adopt the clauses.

In the case of NumPy specifically, it's completely possible that Shell, Exxon, and other big players have no NumPy dependent code in their major operations -- they might be using MATLAB, or some other commercial package. Ideally we need to determine what is really powering their stacks, and this could extend not only to statistical packages, but also machine learning, and even industrial control or monitoring software, or maybe even something indirect like their logistics management platform. Rather than survey the handful of open-source code from these corps, let's try and determine the software which powers their critical paths from more targeted research. If we can go to a project and say "we know that Shell rely on your code to do X, and if you relicense then it will effectively shut them down" then we have a much greater chance of convincing people to adopt, because we are promising results, rather than asking them to gamble massive disruption on a shot in the dark. If we find commercial software in use, we may still be able to effectively lobby those producers as well, we need not lobby only open-source.

Here is how I reasoned about it in my reply in the thread [1]:

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.

and here is one of many responses concerned about effect on downstream [2]:

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.

[1] https://mail.python.org/pipermail/numpy-discussion/2020-July/080820.html
[2] https://mail.python.org/pipermail/numpy-discussion/2020-July/080823.html