Internet access and human rights
Off the Beat: Bruce Byfield's Blog
This morning, Tim O'Reilly linked with apparent approval to Vinton G. Cerf's New York Times editorial, "Internet Access Is Not a Human Right". Technically, Cerf is correct, but I'm not sure that the distinctions he makes are ones that should be insisted upon too strongly.
Internet technologies have been an enabler of the Arab Spring, and a few countries -- notably Estonia and France -- have declared Internet access a human right. However, Cerf begs to differ. Defining rights as "the outcomes we are trying to ensure," he insists that technology "is an enabler of rights, not a right in itself," regardless of whether you consider them human rights (that is, natural ones), or civic rights (that is, given by law). He then suggests that such arguments are beside the point, and urges engineers to be aware of their responsibility for empowering users.
Cerf doesn't bother to give reasons for the distinction, evidently considering it self-evident. Given that he is writing an op-ed, he shouldn't be expected to -- and, in fact, I don't disagree with him. But I find the emphasis on the distinction troubling, because, if given too much importance, I suspect it leads to a theoretical defense of rights while being unconcerned about a practical inequality.
Rights and equal access
Most people would agree that freedom of speech is not equally applied when one person stands up in a park to speak to passersby while their opponent speaks on prime time television. At best, the first person's opinions are heard by dozens, and only by those who happen to be nearby. By contrast, their opponent has a potential audience of millions, and what the opponent says can be easily repaid and recorded, and listened to many times. In any effort to sway public opinion, the first person is at an almost insurmountable disadvantage.
This same argument is used to justify universal Internet access, and is at the foundation of the free software movement. Not only people, but entire regions and countries are at a disadvantage if they don't have the operating system and connections to use the Internet.
Technically, they might have freedom of speech, but they have limited freedom of speech compared to those who are connected. They have less access to information, so their opinions are likely to be less informed. Nor can they participate in online debate, which is now a major forum for creating public opinion. In every possible way, their freedom of speech is lessened.
The trouble with insisting on Cerf's definition of rights as the desired outcome is that it is too abstract to deal with such a problem. In fact, if you insist on this definition, there is nothing wrong with such inequalities. After all, the speaker in the park and the unconnected theoretically have freedom of speech. In theory, the speaker can book TV time for thousands of dollars, and in theory the unconnected can pay for hardware and Internet connections. So who cares about that the practice is quite different, and they can only do such things with considerable difficulty, or at all?
Well, modern industrial society does, for one. As flawed as democratic ideals can be in some ways, they are very clear on one point: whether natural or civil, rights must be universally accessible to be meaningful. That's why basic education is available to all. It's why education was de-segregated in the United States a generation or two ago. It's why, in countries that have universal health care, any attempt to base user fees on ability to pay is strongly resisted. Any type of right only becomes meaningful when it is equally applied.
The addition of technology makes equal application of rights more expensive, but the principle is no different. Cerf does acknowledge that efforts at universal service for telephones and the Internet "are edging into the idea of Internet access as a civil right" but the principle is much more widespread than he implies. At least until recently, in many parts of the world, telephone companies were obliged to provide a minimal number of pay phones. Similarly, the idea that the right to an education lacks meaning without computer training has led to countless local groups stepping in when governments have been slow to provide the necessary training.
In such situations, the distinction between basic rights and the means to the right becomes meaningless in practical terms. When you can't have one without the other, insisting on the distinction becomes a debating point, not a real world consideration.
More than gatekeepers
Cerf is on more solid ground when he argues that engineers need to be socially responsible (even though the segue from his point about rights is obscure). One of the most attractive aspects of free and open source software is that so many of its developers are concerned about the social implications of their work For many, this concern is the main reason they work in the field.
However, the way Cerf argues this point is as unsatisfactory as the way he argues about rights. Behind Cerf's argument lurks the all-too-common elitism of engineers, which has not only crippled free software as it has become more popular, but which is also fundamentally untrue.
If you are a developer, the idea that you are a gate-keeper for responsibility no doubt gives you satisfaction and a sense of purpose. Nor is it entirely untrue. But engineers are not the only ones who are responsible for how technology is used; in many cases, they have no veto over what they work on or what is done with it, and too many engineers remain indifferent to such issues, being content instead to keep their heads down and do their jobs.
Like Cerf, I would prefer that engineers of all sorts felt responsible for what they are doing. However, this responsibility is everyone's in a company or a project or user base. With their special knowledge, engineers can aid other peoples' understanding of the issues, but that shouldn't be taken as meaning that they should necessarily make the ethical decisions by themselves. As in his discussion of rights, Cerf is making distinctions that muddy practicalities instead of clarifying them.
comments powered by DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Systemd Fixes Bug While Facing New Challenger in GNU Shepherd
The systemd developers have fixed a really nasty bug amid the release of the new GNU Shepherd init system.
-
AlmaLinux 10.0 Beta Released
The AlmaLinux OS Foundation has announced the availability of AlmaLinux 10.0 Beta ("Purple Lion") for all supported devices with significant changes.
-
Gnome 47.2 Now Available
Gnome 47.2 is now available for general use but don't expect much in the way of newness, as this is all about improvements and bug fixes.
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.