Clarifications on the Ethics section

[aschrijver]

In #81 @comradekingu brings up some issues with the Ethics section, namely the dichotomy of:

• Requiring code projects to be open source and having FSF-approved licenses.
• Some entries in Ethics propagating non-FSF-approved licenses.

It is a valid point to raise and highlights the need for additional clarification of the Ethics section.

From the start of this list the Ethics section was more of a 'special purpose' category, in that it typically does not highlight code projects, but rather resources aiming to define ethical best-practices for software development. Now Ethics in general are quite subjective and the broader discussion on their definition often leads to controversy. This broader discussion is important however, and must take place in the tech world for our collective insights to mature.

This list only collects pointers to ethics resources with the purpose to allow technologists to inform themselves, make up their own mind. In no way is this list implying "these are proper ethics to adopt". And if one wants to engage in a particular discussion they should do so at the initiatives where they take place, not on this list.

The above stance can be more clearly stated in the list itself. I will consider making the following changes:

• Add a descriptive sentence below the Ethics section header explaining its role on the list.
• Provide some more detailed explanation in the CONTRIBUTING.md document.
• Demote the Ethics section to appear just above the "Related awesomeness" section.

[comradekingu]

I am happy you are going about this in a logical way.

If your project is on this list then you are entitled to proudly wear our humanetech badge.

This is not a "pointer". The subsequent "instructions" of the README links to something that is scrolled past "requirements".
If those are only requirements of PRs to this repo, "your pull request adheres to" then that seems intentional in a way not resoundingly "ethical" in my book.

It makes no sense to list projects that don't pass for mustard by the logic or content of its own list.

Code projects must be open source and have a FSF-approved license.

When it isn't there (and it won't be) the other way is to scratch this requirement. Great idea, stick with it.

Projects should be relevant to the topic and (preferably) under active development.

I'd argue all such licenses are actively irrelevant by design, historical examples are nothing but, and that this time it isn't any different.
Relevantly, the listed license causes actual problems for the libre ecosystem that made it possible, wastes time, and hasn't solved a single problem to date(?)
In no uncertain terms is the effort as a whole misinformed, but it is described as such.
If it isn't ethical without a caveat asterisk, then it doesn't constitute "awesome".
Do one label and do it well. "Awesome" is clearly an endorsement, even if we subtract for "use of american English". ;)

The idea of listing anything calling itself "ethical" (only) at odds with what is libre software only serves the purpose of muddying the waters of what libre software and ethics are, and what the "humane tech" label used by projects means.
Similarly, every "Code of Conduct" would apply by the letter of its law, but the practice is neither voluntary or an extended democracy, nor functional.

As an aside, I don't find a requirement for what is a moral judgement on part of anyone as the ethical decision for what is "tech", much less in a license. That means it is both a requirement as distinct from an ethical consideration of the individual, and in the wrong place to be considered as such.
The latest version even has a provision for negotiating oneself into being a libre software license.
That is underhanded, and it really speaks volumes about how ethically minded the consideration is.

If you want to not work at company A, B and C, then saying no works. They will never adopt different license landscapes if they can help it, because that isn't their consideration of sought financial interest, and the actually relevant AGPLv3+ is specifically mentioned as forbidden by usual suspects.

As an implication of stating "ethical" beyond libre, not only is libre software already "ethical", but this non-free addition undermines that distinction, and as a personal consideration those requirements are better suited for the company scope of any business.
I have most of my money invested in a project that has an application for weapons, but has an immutable clause preventing it codified in its statures.

The "businesses" of war are already employed only under martial law (where I imagine licenses to be less important than application), and as an aside I find the logic of such actors caring in the least somewhat wanting…

What it does do is promise to remove supposed biases of libre software and feeding off its ethos and reputation, by actually inserting biases contrary to its meaning, which in turn is done in a way that is mutually exclusive between these crayon licenses, which destroys not only their practical use and further proliferates available licenses, but also the ecosystem of sharing at the most basic level. The name "Hippocratic" also lends itself to the medical field, and borrows what is a personal pledge for a use that is a small text addition to actual licenses.

Going with FSF-licenses and then writing "Open Source" about anything is somewhat ironic, in that this is specifically a term employed for the sole purpose of not focusing on ethics.

[aschrijver]

I am happy you are going about this in a logical way.

Yes, I am open to any improvement, if the arguments are good. My work for humane tech community is all voluntary in spare time and not funded in any way. I try my best to provide good info, but what constitutes humane tech is for everyone to get involved with. All my contributions are just my own 2 cents in that. Libre software is "ethical" I agree, and yet ethics in tech go beyond this as well. It has broader scope. In similar ways "humane tech" is a vast field that we are still discovering and has many fuzzy boundaries.

My own knowledge and insights in the topics of humane tech, and also my use of free software licenses, has matured in the last couple of years (due to being exposed to them). Personally I favor and promote the use of copyleft licenses, yet this list covers a broader range of them. I see your points.

I have just (re-)read a bunch of background articles on the subject matter, and I think I am largely in agreement on the problematic nature of having those 2 entries be part of the list. So I will honor your PR and have them removed. Other than that the above-mentioned changes are still needed, I think, so I will carry these out. Also I will look into the mention of "open source" and possibly replace all orccurences with "free software".

Do one label and do it well. "Awesome" is clearly an endorsement, even if we subtract for "use of american English". ;)

It is not a strong endorsement, and neither can it be as what is awesome or not is entirely subjective, in the "eye of the beholder". The top-level awesome project contains many lists I personally do not find awesome at all. And on this list I mention that people should check for themselves the 'fitness criteria' of an entry for their own use. Maybe that can be better formulated, though, I'll have a look.

As for the badge. That only states that the project has been included in this curated list, nothing more, nothing less. I cannot guarantee a thorough level of "humane tech compliance", plus a project may change at any time. If someone points out malpractices to me, I'll consider removing an entry, and ask for removal of the badge (which the project may or may not comply to). Though I am in general loathe to these marketing practices, the badge serves mostly to attract attention to the list and by extension help people to consider to do things in somewhat better ways (using their own judgment). For the same reason I value stars to this repo. Stargazing is okay for awesome lists ;)

BTW, I created an alternative to the Awesome project, namely the delightful project, and (co-)maintain a bunch of sublists. What is "delightful" is also subjective, but I thought it conveyed more value (in terms of 'humane tech') than "awesome". Delightful lists are exclusively for FOSS, Open Data, and Open Science, but even here the decision for inclusion is sometimes hard to make. For instance my delightful funding candidates contains proprietary platforms. They are however popular with FOSS developers, where getting proper funding is such a tough nut to crack.

[aschrijver]

Merged #81 removing 2 entries.