[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 <gizmoguy1 at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200702/9f74eb14/attachment.html>