Free software during wartime

The free-software community has, indeed, proved resilient to many events in the wider world. The dotcom bust mostly brought an end to the silliness and accelerated our work toward useful goals. The September 11 attacks (and the horrors that followed) had little direct effect on the community; the same is true of the 2008 economic crisis. The pandemic closed down much of the world, but seemingly sped up free-software development. Even the war in Ukraine and the upheavals around it have, apparently, barely touched our community. All of these events had (and are still having) horrific consequences for many of the people involved, but the development community as a whole was often able to carry on as if many of the world's troubles were taking place in another universe.

Recently, though, our community has been lightly touched in a couple of ways. The ipmitool repository at GitHub was locked, and its maintainer denied access, as a result of his status as an employee of the sanctioned Russian firm Yadro. And, in the kernel community, a developer with the Russian firm Baikal Electronics was told by a networking maintainer that "We don't feel comfortable accepting patches from or relating to hardware produced by your organization". The specific reasons for this discomfort were not spelled out, and no policy for the kernel project as a whole has been expressed, but one possible motivation, as described by Konstantin Ryabitsev, is:

So, in reality, accepting code for any hardware into the Linux kernel means helping to test, maintain, and debug that code for years to come. The resources for that are pooled from many device manufacturers with the understanding that these efforts will be part of the tide that "lifts all boats," including their own. However, in the case of Baikal Elektroniks the situation becomes tricky. Yes, Linux is free software (free as in libre), but maintainers and CI infrastructure require funding. BE is placed under strict sanctions in many countries due to its direct affiliation with the Russian military, so companies funding CI and maintainer efforts have to consider if their money is directly benefiting a sanctioned company (and, indirectly, the Russian military).

It's worth noting that the developer involved is still active in other parts of the kernel community, but appears to have stopped sending from the Baikal Electronics domain. Meanwhile, there has been an ongoing low rumble across the net in response to the decision not to accept patches into one kernel subsystem from this company. The free-software community, some say, is without borders and should be above these sorts of disagreements.

It is true that our community often operates as if international borders did not exist. We cooperate across the globe and, often, have no idea of where our collaborators actually are. We exchange patches and projects with no worries of border checks or customs duties. The Internet and the free-software development model have truly opened up the globe to a type of obstacle-free cooperation that has not been seen before.

That said, it is naïve, at best, to think that the onset of a major war in Europe would be without consequences for our community. Millions of lives have been disrupted (or worse), economies have been upended, and the nature of world trade has changed. We are not so independent that we can expect to not be touched by such a thing. Indeed, it is arguably surprising that its effects have, so far, been so light.

For better or for worse, our "independent" development community is strongly tied to corporations. They employ many of us directly to work on our software commons. They own and run many of the resources, such as hosting sites and forges, that support our work. These companies often have no choice about whether to obey the mandates — such as the implementation of sanctions on some Russian companies — that are imposed by the governments of the world. If some free-software activity is seen (rightly or wrongly) by a company as putting it at risk of violating this kind of requirement, that company will almost certainly act to disassociate itself from that activity.

Individual developers, of course, have their opinions as well, and some of them will act on their opinions. That, too, may throw sand into the free-software machinery. But we should not blame developers who feel that specific acts run counter to either their conscience or the rules they are required to follow.

Things could be a lot worse. Our repositories are full of code from $COUNTRY_A, while $COUNTRY_B thinks that $COUNTRY_A is a threat to its ongoing prosperity or existence. We have already seen plenty of examples of countries making rules against the use of technological products coming from other countries (or specific companies within those countries). An expansion of such rules to apply to code contributions could put the status of much free software in jeopardy.

At this point, that type of mandate would likely be too crippling to consider. But the export of technology, including software, has often come under governmental scrutiny. Those of you who were not paying attention to the first release of PGP — just months before the first Linux kernel release — may want to read up on that history. It is not hard to imagine a world where, say, Linux is considered too powerful a tool to be allowed to be exported to $THAT_COUNTRY; the result could be a severe disruption of how our community works.

We are not at that point, and hopefully will not get there. For the most part, the free-software community is thriving despite the current global turmoil and, with luck, that will continue. But there can be no doubt that Barlow's declaration of independence was more aspiration than reality. We write software for the real world, and we are still intimately tied to it. Those ties will certainly make themselves felt at times. We have some control, sometimes, over how we respond to governmental mandates, but ignoring them is increasingly not an option.