-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Needs clarity on indirect harm #16
Comments
Bitcoin mining would be a similar use case. With stryker, I don't see any harm because the 4hrs of build server time are being used to enhance the quality of software. It is useful work and it is arguably much more efficient than having a human spend 40 hours doing the same type of testing. The utility of bitcoin mining is much more dubious as the alternatives (e.g. proof of stake or the visa network) are much more energy efficient. |
The main concern here is that potential adopters of JWL licensed software won't find themselves prosecuted unexpectedly. For the license to be widely adopted people need to feel reasonably confident that they would never fall afoul of it because a judge interprets the contract differently, or because we changed our minds about what we think is ok. The only real protection they have against this is clarity in the wording of the license. Even though we all agree here that 4 hrs extra of build time is not an issue, if fossil-fuels were added to 4a, it could be interpreted that they could find themselves in trouble with that clause. |
So, in my understanding this would be at least partially covered by the part that says “or gets substantial part of revenue by supporting a company that does [unethical stuff]”. I think I agree with @chrisjensen that while it’s a good intention to make the whole dependency chain stick to these principles and license, this is hard to achieve. Maybe this could be done in a similar way to how Creative Commons licensing works—with different levels of restriction. This would allow authors to decide if this software could be used only very restrictive (including the complete dependency chain to comply) or less restrictive (only direct revenue stream, as is now in the license). |
I'm a bit confused about what we mean by indirect harm. Can we run through a few scenarios? Scenario one: extra CPU usageThe Stryker example was that by running their software, more server time is needed and that server might be running off a coal power station. That doesn't seem to violate the license. There is no statement against consuming fossil fuels, only a statement against trying to block efforts to combat climate change. If the company using Stryker were to make a public statement saying "Stryker is awesome because it gives us an excuse to burn coal and coal will make America great again!" that would be a direct violation. Scenario two: evil dependenciesI might be misunderstanding your point @anselmh - my take on it is that if Stryker adopted the license but their software was using a node module produced by the makers of Hatreon, that would be indirect harm. I'd be ok with leaving that out of scope. |
To add some other scenarios: Senario three: Cloud hostingThis sits between scenario one and fossil fuel production - should a cloud service provider that uses predominantly fossil fuels be excluded? Scenario four: Your host practices union bustingWhat if your service provider practices union busting, engages in oppressive foreign labor practices? Scenario five: You use the software on hardware built from conflict mineralsThis is pretty much every hardware manufacturer last time I checked. Scenario six: You are a F&B giant like Unilever and some of your products use non-RSPO certified palm oil(likely contributing to burning of forests in Indonesia) On scenario 2, it's hard to argue that using a node module benefits or supports the organisation that made it. Maybe if the project using it is huge and reputable and credits the org on their homepage, but in 99% of cases there'd be no material benefit so I agree an exclusion on this basis is not necessary (and would probably exclude almost all developers from using NoHarm packages). |
Scenario Seven: You are Adobe, someone uses your products to promote the Oil industryCurrently excluded: No This would end up excluding all SaaS users from using the library as most would not be interested in policing their clients. Maybe theres room for an AGPL style variant (#14, #12 ) for those that want to take a more hardline approach on this |
I think scenario 3 would be allowed under the license. If a host is using entirely power from fossil fuel generation, they're not They're deriving a majority of income from providing hosting services. I think this is acceptable and I don't think the climate impact solely falls on them, it also falls on the energy generator and the legal environment they all operate in. We should of course encourage adoption of renewable energy (as the license does) but I think it's a bad precedent to restrict usage by companies who rely on fossil fuels for power (since that's still, unfortunately, the majority of the world). If folks agree, we might be able to close off this issue. |
I've tried to clarify this into a table. We may need to rejig the sections of the license based on this. The trickiest part is the "Collaboration" side of things. For the most part, by nature of the license, simply those engaged in harm would not be allowed to use software or derivatives under the NoHarm license. So if you make some general tool, and sell it to lots of people, then the license simply precludes you from selling that software to people causing harm (or more specifically, you could sell it, but they wouldn't be allowed to use it). However, there might be some things for which there's a zero tolerance approach. This was the approach Lerna took with ICE collaborators - that the software was not to be used for any purpose by the companies, even if their collaboration didn't specifically involve the software, the collaborator is banned from using the software for any purpose. (In the table yes means permitted, no means disallowed by the licence)
1 Would exclude basically all tech companies that create any hardware due to conflict minerals, possibly also much of the garment industry This still doesn't solve the issue of large entities with a variety of products, if some are harmful and some are not, do we ban use in only the harmful ones, or is the entire company banned from using the software. I'm inclined to go with the first one (ban use only in production of harmful products) |
(edited for grammar errors) |
Everyone, we cannot close this issue yet because we need to discuss some things. First, the
I also think we should replace: - * industrial processes that generate waste products that threaten life
+ * industrial processes that generate *unnecessary* waste products that threaten life because most people would argue that we cannot feed our households without creating emissions. |
As highlighted in stryker-mutator/stryker-js#1061 we'd need some clarity around indirect harms resulting from using services of a company that uses services of a company that causes harm.
The text was updated successfully, but these errors were encountered: