Free softwareDigital culture

Code Doesn’t Vote: When Open Source Becomes an Ideological Battlefield

Code Doesn’t Vote: When Open Source Becomes an Ideological Battlefield

When open source confuses digital freedom with ideological belonging.

There is something deeply political about free software, but perhaps in recent years we have started to forget what kind of politics sat at the base of that movement.

Richard Stallman did not build Free Software by asking developers who they voted for, what their sexual orientation was, which war they supported or which ideological current they belonged to. His battle was political in a far more concrete sense: it was about control over technology and the balance of power between those who produce software and those who use it.

The question was who really had control over the user's computer, who could study a program, modify it, redistribute it and verify what it actually did. The problem was to stop software from becoming a tool able to limit people's freedom, to watch them with no possibility of oversight, or to make them permanently dependent on a single vendor.

Privacy, freedom, autonomy, access to knowledge and control over your own machine were not incidental slogans. They were the political heart of the matter.

Stallman has always described Free Software as a movement tied to freedom and justice, distinguishing it from Open Source understood mainly as a development methodology. The fundamental freedoms of free software concern the ability to run the software, study it, modify it and redistribute it. The birth of the term "open source", at the end of the nineties, is telling too: a more pragmatic terminology was chosen partly to make the model more acceptable to the corporate world and to separate it, at least in part, from the openly philosophical and political framing of Free Software.

This historical distinction helps us understand how strange the thing happening today really is. Saying that software has a political dimension does not mean that every political question must automatically enter software development. It is perfectly sensible to discuss privacy, surveillance, DRM, lock-in, interoperability, telemetry, censorship, access to the code, data ownership and the freedom to modify a program, because all of these subjects concern the relationship between technology and power directly.

It is far harder to understand why a developer's personal position on a war, a party, an identity issue or a culture-war conflict should determine the technical value of their contribution.

The personal identity of whoever writes the code deserves respect, of course, but it does not decide whether a patch is correct. In the same way, being conservative, socialist, liberal, anarchist or completely uninterested in politics does not automatically make a function better or worse. Opinions on Israel, Palestine, Russia, Ukraine, the United States or any other conflict do not change the behaviour of an algorithm.

The point is not to claim that software has no political consequences at all. That would be absurd. A program can be used to watch people, to censor, to control workers or to run military systems. An algorithm can make decisions that weigh heavily on people's lives. But precisely for this reason it is important to distinguish between the concrete consequences of a technological system and the ideology someone decides to attach symbolically to the code.

A line of code is not fascist, communist, socialist, conservative or progressive. It has no gender identity and no sexual orientation. It can be written well or badly, be secure or vulnerable, readable or unintelligible, efficient or inefficient. It can respect a licence or violate it. It can protect privacy or collect information for no reason. It can work or not work.

This does not mean context does not count. It simply means we should judge software for what it does, for the power it exercises, for the rights it grants or takes away and for the conditions under which it is distributed, instead of assigning it a moral belonging derived from the political opinions of the people who produce or use it.

One of the historically most interesting principles of Open Source is precisely non-discrimination. The Debian Free Software Guidelines state that a free licence should not discriminate against people or groups and should not forbid the use of a program in particular fields of activity. Those guidelines also became the basis of the Open Source Definition.

It is a less comfortable principle than it may seem, because it means accepting that a real freedom has to keep applying even when the software is used by people we deeply disagree with. If freedom exists only for those who belong to the group that is culturally or politically accepted at a given moment, then it is no longer a universal freedom but a concession.

The Debian case

The recent debate about artificial intelligence inside Debian makes this conflict particularly visible. In the summer of 2026 the project discussed a General Resolution on the use of generative systems and LLMs. The concerns behind the discussion were serious and, in many respects, absolutely legitimate. There were problems related to copyright, to licences, to the quality of the generated code, to the pressure placed on maintainers asked to review large amounts of material, to resource consumption and to the use of public infrastructure by automated systems.

These are exactly the questions a project like Debian should tackle. If a person submits code produced with an LLM, it is reasonable to ask who takes responsibility for it, whether that code was actually understood and verified, whether it might contain material incompatible with the project's licence, or whether confidential data, credentials or sensitive information were sent to an external service during the process.

The problem starts when a discussion of this kind stops focusing on the concrete effects of the technology and begins to be described through increasingly absolute ideological categories.

Alongside the technical arguments, some contributions pushed the discussion onto a different plane, tying artificial intelligence to environmental cost, to the concentration of power in the hands of a few large companies and, in some cases, to fascism. The proposal by Holger Levsen, among the most critical of LLMs, revolved for example around the energy and water cost of generative systems, presented almost as a moral duty to avoid them.

The sharpest case came after the vote. The developer Antoine Le Gonidec announced that he was leaving the project and wanted to make clear, in his own words, that he wished the consequences of Debian embracing a "fascist-backed technology" to be known, adding that pretending to hold a neutral stance in the face of fascism is not neutrality but a form of active collaboration.

It is important, though, to be precise, because an article against polarisation should not build a caricature of the opposing side. It would not be correct to say simply that Debian declared anyone who uses artificial intelligence a fascist. The positions expressed were varied, and one of the proposals most opposed to LLMs stated explicitly that it wanted to criticise the use of the technology, not the people who used it.

So the interesting problem is not to establish whether the entire Debian project adopted a particular ideology. It did not. The point is to observe how quickly a perfectly legitimate technical and political discussion can turn into a battle of moral belonging.

In the end Debian adopted a far more pragmatic position. The winning proposal, "Responsible Use of Generative AI", neither approves of artificial intelligence indiscriminately nor bans it. Instead it establishes that, whatever tool is used to produce a contribution, the same requirements of quality, correctness, maintainability and legality remain in force. Whoever submits a contribution keeps responsibility for it and must understand it, verify it and test it.

It is probably the solution most consistent with the technical culture that open source should defend. It does not mean ignoring the risks of artificial intelligence, but addressing them on their merits. If a cloud service receives proprietary code or private information, there is a privacy problem. If it is not possible to establish the provenance of the generated material, there can be a licensing problem. If producing thousands of lines of code becomes extremely cheap while verifying them takes hours of human work, a strong asymmetry is created between those who produce and those who review. If automated systems overload servers maintained by volunteers, the problem is concrete. If a developer incorporates code they do not understand simply because it was generated by a machine, the technical and security responsibility remains theirs.

You do not need to call artificial intelligence fascist to discuss all of this seriously, just as you do not need to call anyone who would ban it a communist.

From politics to tribalism

The biggest problem of contemporary open source is therefore not the presence of politics, because politics has always existed in free software. The problem is its transformation into tribalism.

The original movement could be radical, but at least the conflict was clearly defined. It was about the user's right to control their own computer, the ability to study and modify software, the right to share knowledge, the need to avoid artificial dependence on a single vendor and the risk that proprietary systems would become instruments of surveillance and control.

They were political questions because they had concrete consequences.

Today, instead, the technology debate is more and more often pulled into the same mechanism that dominates social networks. Before even discussing a subject, people try to work out which group the person proposing it belongs to. A position is read through the categories of progressive or conservative, socialist or capitalist, pro-Israel or pro-Palestine, for or against a given culture-war battle. In this way the concrete content of the discussion slips into the background.

And this is where the paradox emerges. While technology communities argue obsessively about their internal identities, the digital world keeps moving toward a growing concentration of power. More and more services collect data, more and more everyday activities depend on centralised platforms, more and more software is delivered as a service that cannot be inspected, and more and more fundamental functions of digital life are handed to infrastructure over which the user holds no real control.

So we fight over labels precisely while privacy and freedom, the very subjects that gave rise to the political component of Free Software, risk being gradually eroded.

This does not mean open source communities should ignore discrimination, harassment or abusive behaviour. A community has to be able to set rules of coexistence and let very different people collaborate without being attacked for who they are. But protecting people should not mean demanding ideological uniformity.

A genuinely pluralist community should be able to make people with very different opinions work together, as long as they respect others and contribute seriously to the project. If instead respect is gradually confused with the obligation to share a particular political, cultural or social vision, a Code of Conduct can turn from a tool of coexistence into a tool of conformity.

The technical criterion should stay much simpler. A contribution should be judged for its quality, its security, the ability to maintain it over time, its compatibility with the project's licences and its respect for users. If it introduces needless data collection, problematic dependencies or undocumented behaviour, it should be criticised for those reasons. If it is written badly, it should be rejected because it is written badly. If it works and conforms to the project's principles, the judgement should not depend on the personal opinions of whoever wrote it.

Why free software was revolutionary

The final paradox is perhaps that the Free Software of the early days was politically far more radical than many contemporary symbolic battles. Stallman was not simply asking for more cultural sensitivity. He questioned the very distribution of technological power and argued that the user should be able to really control the software they use.

It was a concrete shift from the exclusive control of the vendor to greater autonomy for the user and the community. Making the code available meant turning a black box into something that could be studied. Allowing modification meant reducing dependence on whoever originally created the program. Allowing redistribution meant preventing technical knowledge from being completely subordinated to the permission of an owner.

That was political because it actually changed the balance of power.

Privacy and freedom are still political questions. Control over your own data still is. The ability to know what a program installed on your computer does still is. The ability to escape surveillance and lock-in still is.

But demanding that every open source project take a stance on every war, identity, political movement or culture-war conflict means confusing two completely different planes.

We can respect people without demanding that they share all our opinions. We can analyse the social effects of artificial intelligence without assigning an ideology to a mathematical model. We can criticise a company harshly without declaring morally tainted any technology it uses. We can build inclusive communities without turning them into ideologically uniform environments.

Above all, we can remember why free software was revolutionary.

Not because it claimed to tell us what to think, but because it tried to stop us from losing control over our computers.

A line of code does not vote, does not belong to a party and holds no political identity. It can, however, increase the control someone exercises over us or reduce it. It can defend our autonomy or limit it.

That is what open source should go back to focusing its battle on.

Sources

Écrit par Claudio