<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 2, 2020 at 5:06 PM John Preston <<a href="mailto:gizmoguy1@gmail.com">gizmoguy1@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you all for your input on this proposal. I am very grateful for<br>
the time you have all spent to provide such well reasoned critiques<br>
and I'm especially glad to see that this thread has triggered<br>
discussion of other, more pragmatic, actions that the community can<br>
take in pursuit of climate justice. 🙂<br>
<br>
I found Stanley's analogy of this proposal being a "backwards<br>
incompatible [legal] API change" particularly insightful, and Daniele<br>
has illustrated exactly the kind of chaos this would create<br>
downstream, threatening both NumPy itself (due to the packaging<br>
requirements of distributors like Debian and Fedora) and its dependent<br>
packages like Conda. Fundamentally I see this issue as a philosophical<br>
one around how we define, and the importance of, 'free software' and<br>
'open source software'. From a principles-based perspective, I agree<br>
with Ryan that "equal rights except" is not truly equal, and that<br>
changing the definition(s) of F/OSS would damage the movement by<br>
making it much less clear what is and isn't F/OSS. On the other hand,<br>
from a pragmatic perspective, I care less about if software I use is<br>
strictly F/OSS, and more about if I can do what I want with it, and<br>
who else gets to enjoy those privileges -- I choose the word<br>
'privilege' here specifically to highlight that the core of F/OSS is<br>
rights, which are unconditional, whereas this proposal would make<br>
those rights contingent on conditions that cannot be met by all<br>
actors, and therefore they would be privileges, not rights. So<br>
essentially, this proposal is asking "are there some uses of NumPy<br>
which are so ethically wrong, that it would be better for NumPy to be<br>
non-F/OSS in order to prevent those uses, than for NumPy to be F/OSS,<br>
and advance the F/OSS movement, while also allowing those uses?"<br>
<br>
Answering this question requires an awareness of the broader context<br>
within which NumPy sits. Ilhan has pointed out that O&G companies<br>
cannot be coerced by more restrictive licensing of NumPy because there<br>
are commercial options that they could use instead. Therefore, without<br>
evidence that NumPy powers a significant chunk of the analytics at<br>
major O&G companies, and that relicensing NumPy would cause<br>
significant disruption to those companies and their ability to carry<br>
out their operations, it is much more likely that any negative effect<br>
on O&G, and therefore any positive effect on the climate, would be<br>
outweighed by the harm caused to downstream packages.<br>
<br>
I agree that the first term is particularly vague, and I would love to<br>
see input from lawyers on how the software community can adopt rigid<br>
clauses in licenses for software that needs this, because although<br>
F/OSS may be "good by default" in that for most software, most of the<br>
time, releasing as F/OSS will be good, this does not mean that there<br>
is no software which requires stricter licensing. I would draw an<br>
analogy with responsible disclosure of vulnerabilities: vendors are<br>
provided with a window of time to fix a vulnerability before<br>
researchers publish their findings, on the basis that immediate<br>
publication of the findings presents more of a threat than a benefit,<br>
because malicious actors could weaponise and abuse the vulnerability<br>
before it is patched. In other words, as software creators, we have a<br>
responsibility to weigh the potential and actual uses of our software<br>
to determine if we are in a position to prevent harm by licensing or<br>
relicensing our software appropriately. <br></blockquote><div>.<br></div><div>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.  <br></div><div><br></div><div>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.</div><div><br></div><div>This isn't a hypothetical issue, people have tried putting additional restrictions on their software like this, and it tends to kill the project.  <br></div></div></div>