Published in News

Open source might be a Ukraine war casualty

by on21 March 2022


Weaponised and bogged down

Open source and cloud technology might be collateral damage in the war between Russia and Ukraine.

Open source developers are worried about if not providing updates or cutting off services to Russian might damage the software’s reputation.

In On the Weaponisation of Open Source, software engineering consultant Gerald Benischke examines how the Russian invasion of Ukraine has spilled over into areas of software development, with some unintended consequences. In particular, Benischke looks at the decision by MongoDB to cut off services in Russia, the destructive change in a node library that deleted files on Russian IPs, and even a change in the code/licence in a community terraform module to assert that Putin is a 'dickhead.'

Benischke said: "My problem is that this weaponisation is killing off trust. I think the temptation of using open-source projects as weapons against Russia should be resisted because it sets a dangerous precedent and may ultimately set back the open-source movement and push organisations back into seeking refuge in commercial software with all its opaqueness and obscurity. It's not about sitting on the fence or taking sides in a war. It's about what open source has achieved over the last 30 years and I think that's now at risk of become collateral damage."

Mike Melanson's column "This Week in Programming" said that the open-source Initiative's (OSI) definition of open-source software is quite clear on the matter — there must be "no discrimination against persons or groups" and "no discrimination against fields of endeavour" — the issue of who should be allowed to use open-source software, according to ethical considerations, has long been debated.

So basically, if you weaponise open-source code against the Russians, you are violating the non-discrimination clause implicit in the Open Sauce movement.

Bradley M. Kuhn, a policy fellow and hacker-in-residence at the Software Freedom Conservancy spent nearly 3,000 words on the topic saying that "FOSS licenses are not an effective tool to advance social justice causes other than software freedom" and that, instead, developers have a moral obligation to take stances by way of other methods.

"For example, FOSS developers should refuse to work specifically on bug reports from companies who don't pay their workers a living wage," Kuhn offers in an example.

Regarding Russia specifically, Kuhn again points to distribution as an avenue of protest, while still remaining in line with the principles of free and open source software.

"Every FOSS license in existence permits capricious distribution; software freedom guarantees the right to refuse to distribute new versions of the software. (i.e., Copyleft does not require that you publish all your software on the Internet for everyone, or that you give equal access to everyone — rather, it merely requires that those whom you chose to give legitimate access to the software also receive CCS). FOSS projects should thus avoid providing Putin easy access to updates to their FOSS," writes Kuhn.

As an open-source outsider this all seems to smack of ways of defending a religion rather than something practical. Sure in an ideal world you would want your code only to be used by vegen, fluffy bunny lovers who cross the road to avoid snails. But if you don’t want your code to be used by people who want to masturbate their leader’s egos by flattening residential buildings while invading another country in an unprovoked war it should be your right too.

Such arguments that you should ignore what your customers do with your code are like those used by IBM Germany when it used tech to help make Hitler's death camps more efficient.  They are also ignoring the fact that a lot of Ukrainian open-source programmers are going to die or be maimed in that war.  Any movement that condones the death of its own members for the sake of its "ideals" is not worth being involved with and will make for some very uncomfortable open-source conferences in the future.

 

Last modified on 21 March 2022
Rate this item
(4 votes)

Read more about: