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 NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
