Development

Software-ontwikkeling
ontwikkelaar

Verantwoord gebruik open source begint bij jezelf

Slachtoffers van wraakactie hebben alleen zichzelf te verwijten.

© CC0 - Unsplash.com Kelly Sikkema
12 januari 2022

Slachtoffers van wraakactie hebben alleen zichzelf te verwijten.

Een wraakactie waarbij de ontwikkelaar van open source libraries colors.js en faker.js afgelopen weekend zijn eigen werk saboteerde, laat nog eens zien hoe de verantwoordelijkheden liggen bij het gebruik van open source software.

Of Marak Squires nu een punt heeft of niet met zijn frustratie dat multinationals zijn software gebruiken zonder hem daarvoor iets terug te geven, de manier waarop hij daar uiting aan gaf kan op weinig waardering rekenen.

Uit de reacties op vele nieuwssites, waaronder AG Connect, blijkt dat veel opensource-ontwikkelaars vinden dat Squires (of Marak zoals hij op GitHub bekend staat) beter had moeten nadenken over de licentie waaronder hij zijn werk beschikbaar stelt. Er zijn ook licentievormen voor vrij beschikbare software waarbij commercieel gebruik wordt uitgesloten, alleen voldoet zo’n licentie dan niet meer aan de formele definitie van open source. Squires heeft voor de MIT-license gekozen. Die legt nauwelijks beperkingen op het gebruik op naamsvermelding na. Er zit dus vrijwel geen copyright op om het opensource-karakter te bewaken.

Professionele suïcide

Zijn actie tegen de multinationals roept veel afkeuring op. Je eigen werk saboteren door een corrupte nieuwe versie te publiceren, zorgt ervoor dat niet alleen het mikpunt van je agressie er last van heeft, maar iedereen die deze hulpmiddelen gebruikt. Het is een suïcidale actie wat betreft je werk als ontwikkelaar. Nu blijkt dat deze Mark Squires een wat zonderlinge figuur is die nog al een keer van het voorbereiden van een gewelddadige actie is verdacht.

De slachtoffers van zijn acties dit weekend hebben er maar beperkt schade van ondervonden. NPM - de partij die zorgt voor de distributie van de betreffende libraries - heeft de wijzigingen al snel teruggedraaid. GitHub heeft hem zelfs de toegang tot al zijn projecten afgenomen.

Dat slachtoffers door de actie misschien niet gelijk konden doorwerken aan hun projecten wijst er nog eens op dat de verantwoordelijkheid voor het gebruik van opensourcesoftware geheel bij de gebruiker ligt. "Het hanteren van goede processen om nieuwe versies in gebruik te nemen, is een belangrijk deel van het verhaal", zegt Michiel Leenaars, directeur strategie bij NLnet. Daarbij moet iedereen duidelijk voor ogen hebben waar het betreffende opensourcepakket vandaan komt. "Vrijwel alle serieuze partijen - inclusief alle grote softwaredistributies - hebben doorlopende integratie geïmplementeerd waarbij letterlijk iedere wijziging aan de software een batterij testen veroorzaakt om te kijken of alles nog werkt (in het Engels Continuous Integration). Alleen als alles klopt, wordt een voorgestelde wijziging toegelaten."

Let op herkomst

"Bij grote projecten zoals Linux-distributies zullen serieuze fouten de 'normale' gebruiker of integrator nooit bereiken", stelt ook Jos Vos, eigenaar van X/OS Experts in Open Systems. Dat is anders bij een individuele ontwikkelaar die een paar softwarepakketjes onderhoudt. Vos: "Dit was een heel zichtbare 'sabotage'. Veel gevaarlijker is het als het een meer verborgen wijziging was geweest, die misschien zelfs pas op een bepaald tijdstip actief wordt. In theorie kan dat natuurlijk ook bij niet-open source software zo zijn: een veel gehoord argument voor opensourcesoftware is juist dat code meestal door veel mensen wordt gezien/gereviewed. Ook bij een commercieel bedrijf kan er iemand gek worden..."

De aansprakelijkheid van de maker van open source is echter in de licentie afgedekt. Er is hooguit een mogelijkheid dat bijvoorbeeld onder het Nederlands recht een uitzondering kan worden gemaakt voor moedwillig aangebrachte schade.

Leenaars: "Het is een bedrijfsrisico dat er af en toe iemand uit de bocht vliegt: van kleine onwenselijkheden (een barvrouw die ongezien in een pilsje spuugt van een hufterige klant), tot zware gevallen (een verpleegster die de geneesmiddelen van patiënten achterhoudt of een arts in een vruchtbaarheidskliniek die bij iedereen zijn eigen zaad insemineert). Dit gebeurt zelfs met ontevreden werknemers, die bijvoorbeeld servers onklaar maken. Op individuele schaal is dat niet te voorkomen."

Beroepscode biedt wat houvast

Testen voor je een update van software in gebruik neemt is dus de enige remedie. En als die testen er niet zijn, moet je ze zelf maken. "Code van een ander opnemen in je project neemt hen feitelijk op in je 'trusted computing base'. Je introduceert een afhankelijkheid. Je kunt niet aannemen - niet eens van een collega - dat iets werkt zoals het beschreven staat. En al helemaal niet dat dat gedrag stabiel is", zegt Leenaars. "Het risico wordt verder verkleind door te werken met betrouwbare mensen, professionals die zich houden aan ethische beroepscode, bijvoorbeeld die van ACM, de grootste vereniging van computerexperts ter wereld. Dat bevat expliciet 'Avoid harm'. In dit geval zou deze persoon die bewust software van anderen saboteert, zijn lidmaatschap kwijtraken."

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.