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 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 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, 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: 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
