Sending the wrong message =========================== I'm pretty sure everybody agrees that being inclusive is more than just using the right words. Being truly inclusive means not caring about the origin, birth, age, sex, skin color (amongst other things) at all. This means not judging people based on these factors, and being friendly, inviting and supportive with everybody in everyday life by default. On the street, in hallways and rooms, and on the internet. This behavior also includes using words and phrases that are non-offensive. So as a result, the proposed patch advocates avoiding words such as "slave" and "blacklist".
However, as it was already said in this discussion by other parties, "context is everything". Quite ironically, this was said in a slightly different context, but it doesn't change the importance and general truth of these words. I'll go out on a limb and claim that nobody who wrote "master-slave" during development of a device driver, or used the word "blacklist" was actually thinking of African people or human slavery. In the context of the Linux kernel (and in computing in general), these words have a long history and have zero bad connotation, no racism, and absolutely null offense. One could argue that recommending to retroactively remove such references (which the original proposal does) assumes that these were offensive, hence suggesting to a certain degree that past developers who have used these words were possibly racists. Retroactively removing those occurrences from code is thus, I honestly think, disrespecting and insulting to the original authors. Because why remove them if they didn't mean anything bad? And before you say "because those instances could still be interpreted as offensive", I'll get to that soon. The proposal is just a surface treatment =========================== ... and a bad one at that. The "black" in "blacklist" has nothing to do with African or Afro-American people. No matter how many occurrences of "black" we eradicate from our dictionary, the word "black" will always have bad connotations. This connotation stems from darkness, the absence of beautiful colors, and historically from the coldness, darkness and insecurity of the night. Dan W. dismisses this by saying this is an etymological argument, but we cannot dismiss arguments just because they are unbeneficial (is that even a word?) to our cause. The true problem is not that the word "black" has bad connotations, but that people with dark skin color have been labeled with a word that has a bad connotation. If we don't want to be offensive, (as a small step) we must stop thinking of African and Afro-American people as "black" and ban this labeling of them. Note the big difference: Instead of banning the use of a simple color in some contexts which have nothing to do with oppression, hate or slavery, we should instead stop referring to groups of people with a word that incites bad feelings. For this reason, I argue that banning "blacklist" is just a surface treatment that doesn't recognize the true problem behind it, and even if implemented will stay ineffective. Accepting this proposal is like fixing an error message in the kernel logs by simply removing the error message instead of fixing the underlying bug. To fix the bug in our language, we must stop referring to "black" people as black people. A measure where proponents of the patch fail at most. Being respectful =========================== The case for "slave" is a bit different, obviously, because the etymology here does link to actual human slavery. Again, it is important to note the context however. In computing, this means something completely different, end of sentence. Supporters of the patch will come and say, "it doesn't need to be meant offensively to be taken offensively". That's true, of course, but only if it is a misunderstanding, which in the computing context has zero chance. If you know and understand what the other party *really* meant, then something that wasn't meant offensively cannot be taken offensively. The right word here is not "offensive", but one or more of "uncomfortable", "disturbing", or "upsetting". Now *that* is understandable. If you have a history of you or your ancestors been oppressed, then talking about slavery understandably generates unwelcome emotional reactions. But this has nothing to do with inclusion, racism, or hate. However, because we don't want to emotionally upset people, I actually support avoiding references to "slave" in the future. Importantly though, this support is out of respect, and not because it has anything to do with being offensive. In this context, we should, and for correctness sake must, stop referring to "offensiveness". Though even this logic is borderline: just recently, half a million people have fallen victim to COVID-19 in over just a couple of months. The number of affected relatives are probably 2-3x of that, who are now emotionally shaken and uncomfortable about talking about the virus. Imagine where we would be now (or where we will be in half a year) if we stopped referring to COVID to avoid emotionally upsetting these people. About that argument with efficiency =========================== The patch author goes into detail to "illustrate" how avoiding these words will improve efficiency. I'm sorry to call this out, but this is utterly bogus and distracting from the issue at hand. First of all, not any maintainer has been slowed done or has worked less efficiently because they saw the word "blacklist" or "slave" in the kernel sources. These *technical* phrases are not like bad code formatting where disconformity leads to worse readability or makes the coding intent harder to follow or understand. Quite the contrary, if anybody read the proposed "denylist" instead of "blacklist", they will stop for a second, think "what an odd choice of words...", and if it wasn't for the current black-lives-matter movement, would have a year ago probably even refactored the code (or requested a v2-patch) with the usual terminology of "blacklist". In other words, this argument has zero real-life basis and will, if implemented, achieve the opposite effect of what it is claiming. If we do this, there is no end to politics =========================== Let me start with an example. The patch author neglectfully forgets about proposing to ban "whitelist", not just "blacklist". If we agree that "blacklist" is wrong because it assumes that everything "black" is always bad (and thus black people'd be bad), then obviously we *have to* remove whitelist too. Because "whitelist" then assumes that everything "white" is always good, and now since we're unable to ignore the reference to skin-color, so this is just as racist (actually even worse), suggesting white supremacy. It is obvious that whoever thought out the exclusion of "blacklist" didn't think this through. But we all know, these words to be replaced all stem from outside our community, and the current patch is not the result of careful consideration, but the result of giving-in to external pressure, and to political and media waves. The Linux community should stand strong and be inclusive by *being* welcoming, friendly and helpful to everybody irrespective of skin color, not by *saying* what current political activists expect us to say. It might even be better to stop talking about skin color in the context of kernel development altogether, because skin color doesn't matter here. Here people judge others by technical competency. Any discussions otherwise are fueled by external factors and are a distraction. Note this does *not* mean we turn our backs to racism or offensive behavior. If we see any such poisonous activity among our circles now or in the future, we must and will single them out and teach them better, and for incorrigible cases we distance ourselves from them. But these will be one-off cases that will be handled appropriately. Unless it becomes a common problem among Linux developers, it is not our responsibility to write down each and every desirable human behavior (again, see top about "sending the wrong message"). We've successfully avoided pests from infecting our circles in the past and we'll continue to do so. Avoiding the word "blacklist" makes no difference here. How do I know? Because let's be real: The use of the word "blacklist" has not deterred a developer from joining our community yet... for about 25 years now. On the other hand this discussion is now wasting everybody's time. With that last sentence in mind, sorry for this mail turning out so long. Raschko T.
