In de opensourcewereld maakt de term CRA velen zenuwachtig: de EU’s Cyber Resilience Act komt eraan. Deze wet stelt strenge beveiligingseisen voor slimme producten, op straffe van forse boetes. Omdat die vrijwel altijd vol zitten met open source, geeft dat natuurlijk meteen de vraag of je als vrijwilliger met dat ene OSS pakket die boetes voor de kiezen kan krijgen.
Veel zogeheten ‘slimme’ producten – zo niet allemaal – drijven op open source. Vanaf het begin waren er dan ook grote zorgen hoe de CRA zou uitpakken voor de gemeenschap van OSS-ontwikkelaars. Dat is opgepikt in de definitieve tekst: organisaties die als primair doel hebben opensourcesoftware te onderhouden en verspreiden (“stewards”) krijgen een veel lichter regime.
Grofweg zijn de eisen voor stewards van open source:
- Een cyberbeveiligingsbeleid hebben dat met name toeziet op het melden en oppakken van kwetsbaarheden (art. 24 lid 1).
- Handelen op verzoeken van de markttoezichthouders wanneer die een kwetsbaarheid of risico zien in een opensourcepakket dat door marktpartijen wordt gebruikt (art. 24 lid 2).
- Meewerken aan het melden van actief uitgebuite kwetsbaarheden (art. 14 lid 1) als je betrokken bent bij de productontwikkeling door marktpartijen.
Het corrigendum betreft artikel 64, lid 10 met de uitzondering voor open source. Dit verwijst naar leden 3 tot en met 9, de administratieve boetes voor zaken als niet-meewerken, geen technische documentatie bij je product of het valselijk voeren van het CE-keurmerk. Maar de pijn zit hem in de 15-miljoenboete voor niet naleven van de “essentiële cyberbeveiligingsvereisten” en díe staat in lid 2 van het artikel.
Een vorige week uitgekomen corrigendum bevestigt nu dat de uitzondering ook geldt voor lid 2. Het is dus niet mogelijk om als opensourcesteward een boete te krijgen als je pakket onder de maat is. Wel kun je worden bevolen dit te corrigeren conform Annex I (waar de essentiële eisen staan) en als je dat niet doet, krijg je stevige dwangsommen om de oren.
Arnoud
Overweging 19
en definitie in art 3 ” “opensourcesoftwaresteward”: een rechtspersoon die geen fabrikant is en die als oogmerk of doelstelling heeft om systematisch en duurzaam ondersteuning te verlenen voor de ontwikkeling van specifieke producten met digitale elementen die als vrije en opensourcesoftware kunnen worden aangemerkt en voor handelsactiviteiten bestemd zijn, en die de levensvatbaarheid van die producten waarborgt;”Closed software van ‘organisaties die als primair doel hebben opensourcesoftware te onderhouden en verspreiden’ valt dan niet onder de uitzondering. Mooi. Zijn Oracle (Redhat, MySQL) en Microsoft (https://github.com/microsoft) entiteiten die vrije en opensourcesoftware ontwikkelen en publiceren? Schijnbaar wel. Maar dat geldt juist niet voor zeg een bank, overheid of ZZP-er die graag een stukje zelfbouw als opensource wil delen met de wereld. Die hebben dat oogmerk niet. En die ene xkcd-meneer in Nebraska die geen stichting of bedrijf heeft maar wel wereldwijd zijn code gebruikt ziet worden ook niet. Door het op te hangen aan de organisatie en niet de code blijft het schijnbaar tricky.
Al is er natuurlijk veel voor te zeggen dat Oracle’s Linux en MySQL en er wel onder zouden mogen vallen, niet anders dan hun closed source databasesoftware.
Die meneer in Nebraska heeft toch niet “als oogmerk of doelstelling heeft om systematisch en duurzaam ondersteuning te verlenen”? Ik vind het al moeilijk verdedigbaar dat zhij in een zakelijke context opereert, dus ik denk dat deze hoe dan ook niet onder de definitie valt.
Dat is zoals ik het zie juist het probleem, eenpitters en bedrijven ‘die het erbij doen’ vallen zoals ik het lees niet onder de uitzondering maar wel onder de noemer van fabrikant. Er zijn bijv. allerhande Javascript libraries die worden onderhouden door privepersonen met een heel andere ‘day job’. Of bijvoorbeeld de Nasa die door derden in hoogvliegend materieel gebruikte frameworks als opensource heeft gedeeld.
Nu zijn dit uitermate voorbeelden van componenten waar de beveiliging uptodate moet blijven. Maar het voelt wat vreemd dat alleen dedicated softwareontwikkelbedrijven onder de uitzondering vallen – juist de partijen die minder snel “dan maar niet meer met de wereld delen” zullen denken dan een partij die het ‘erbij doet’.
Al zal de soep in de regel vast niet zo heet gegeten worden.
Zo’n open source stichting heeft toch geen budget om gratis werk te verrichten? Enkel omdat Microsoft heeft besloten ons stukje software in al hun stofzuigers te gebruiken moeten wij aan de bak? Dat kun je toch niet uitleggen aan de mensen en bedrijven die doneren aan de stichting?
Ik voorspel alvast dat elke stichting die zo’n dwangsom krijgt de onveilige functie in hun “bugfix” simpelweg uitschakelt. Of de stichting wordt snel weer opgedoekt, en de ontwikkelaars gaan iets ander doen…
Disclaimer: ik heb in het verleden voor zo’n stichting gewerkt.
Wie betaald dan de tijd van de ontwikkelaar, als die verplicht een patch moet gaan schrijven?
Mag je je opensource ding ook offline halen als je niet aan die eisen kunt voldoen?
Specifiek, stel dat je voor je werk iets hebt gemaakt wat alleen intern wordt gebruikt, maar dat ergens op github hebt staan met een standaard licentie er aan.
Verschillende reacties hierboven roepen om “wie betaalt dan voor die uren om een fix te maken”. Wat mij betreft de ontwikkelaar. Dat je iets vrijwillig doet betekent niet dat je geen verantwoordelijkheid hebt.
Ik heb lang voor Debian securityteam gewerkt. Debian is geheel en al vrijwilligers. Het team is er van overtuigd dat als je een OS de wereld in slingert waar zoveel mensen op verder bouwen, je het niet kan maken om bij issues toevallig geen tijd te hebben of te bedelen om budget. Idem vind ik het absoluut een goede daad als jij open source software ter beschikking van anderen stelt. Maar als die software security issues bevat, dan vind ik ook dat verwacht mag worden dat je je best doet om de impact daarvan te beperken, ook al was het oorspronkelijk een goede daad wat je deed.
De hoeveelheid effort voor zo’n fix heeft vermoedelijk ook vrij gelijke tred met de grootte van de software. Dus inderdaad, iemand/een organisatie die een klein tooltje opensourcet hoeft ook niet bang te zijn dat die vervolgens persoonsweken werk aan security issues heeft, dus het lijkt me ook niet onredelijk om een keer een fix te maken.
In de samenleving zien we dat volgens mij ook zo. Heel fijn dat jij vrijwilliger bent om de Koningsdag in de wijk te organiseren. Maar als het dan op enig moment in de dag tegen zit, vinden we het ook niet acceptabel dat je dan maar wegloopt en het uit je handen laat vallen. Vrijwilliger zijn is ook verantwoordelijkheid nemen voor het totaal.
Krijg jij dan een dwangsom aan je broek als je niet komt opdagen bij het Koningsfeest? (Dat jij je verplicht voelt is niet hetzelfde als verplicht zijn.)
Thijs zijn pleidooi onderstreept waarom zo’n dwangsom gerechtvaardigd is en waarom je dit uit eigen zak zou moeten betalen. Ja, je koos er voor en ja het was vrijwillig en onbetaald. Maar ook dat komt met verantwoordelijkheden, waaronder dingen oplossen als het misgaat. Op dat moment mag je niet weglopen van Koningsdag / weigeren patches te maken met als argument “ik krijg er niet voor betaald”.
Wat een vrijwilligersovereenkomst juridisch precies is, is iets voor een andere discussie maar ik zie zeker ruimte om een vrijwilliger te houden aan een toezegging op dag X iets te doen. Als ik daar op mag rekenen en de vrijwilliger doet het niet, dan is een dwangsom geen gekke maatregel in het recht.
Ik zie je punt, maar verplicht ‘dingen oplossen’ conflicteert keihard met de meest-gebruikte open source licenties. (…IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY… etc)
Wat moet je dan doen als ontwikkelaar? De software geheel terugtrekken? Het niet oplossen? Het toch tegen je zin oplossen?
Als je naar de ‘ vrijwiller-analogie’ kijkt, moet je die licenties niet vergelijken met een toezegging om te komen helpen op die dag, maar om een uiting van interesse om te komen helpen met als voorwaarde dat je je mag bedenken zonder uitleg.
Wet gaat boven licentie, is toch een vrij bekend uitgangspunt? Bovendien: er staat hier dat aansprakelijkheid in een civielrechtelijke relatie wordt uitgesloten. Geen schadeclaims voor jou. Maar als de overheid jou wil beboeten, helpen daar geen kleine letters bij.
De CRA kijkt niet naar je kleine letters maar wat je doet en waar je software gepositioneerd is. Als jij duurzaam en stelselmatig ondersteuning geeft, dan moet je dat óók doen als de toezichthouder het eist. Zet je software neer waar je zelden naar omkijkt, dan val je buiten de CRA.
Maar men heeft het over organisaties die als primair doel hebben open source software te ontwikkelen en verspreiden.
Heel veel OS code – inclusief mijn eigen code ooit 25 jaar geleden geschreven – zijn openbaar gemaakt onder een OS licentie omdat een ontwikkelaar voor zich zelf iets heeft gemaakt en dacht ‘misschien heeft een ander er iets aan’.
De licentie is door mij bewust gekozen met de gedachte hier heb je de code as-is you are on your own.
Onder welk regime vallen deze ontwikkelaars. Ze voldoen zeker niet aan de eerste volzin van deze reactie. Wet gaat boven licentie is leuk, maar niemand van deze groep gaat dat oplossen, of eeuwig onderhouden. Ik vermoed dat de enige reactie zal zijn wat ook de mijne is: deze software is end of life, zoek maar een alternatief.
Klopt, en het is ook beperkt tot organisaties met dat doel. Ontwikkelaars die voor de leuk software maken en onderhouden voldoen al niet aan “oogmerk of doelstelling heeft om systematisch en duurzaam ondersteuning te verlenen voor de ontwikkeling van specifieke producten”. Debian heeft als doel haar OS duurzaam te ondersteunen. Die meneer uit Nebraska doet met pijn en moeite regelmatig patchwerk, maar ze zijn onvergelijkbaar.
Kennelijk zijn er “stewards” (en niet de minste) die niet bereid zijn om gratis securitywerk te verrichten ten voordele van de tech bros:
https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-sending-bugs/
Laten we ons bij intreden van de dwangsommen verheugen op een toekomst zonder maintainers?
Er zijn meerdere beheerders van Open Source projecten die gepikeerd gereageerd hebben op door AI gegenereerde bug-rapporten, omdat deze (na dagen analyse) vaak onjuist bleken. Ik roep “denial of service” aanval door het insturen van teveel bug reports. Daar mag een project terecht over klagen.
Aan de andere kant kan Open Source alleen floreren als door de bijdragen vanuit de community. Bijdragen van bedrijven zijn welkom, dat kan variëren van het leveren van bugfixes tot het sponsoren van een ontwikkelaar. Een bedrijf dat alleen gebruikt en niets teruggeeft helpt Open Source niet vooruit.
Als open-source maintainers hun spullen laten vallen omdat ze de bug-reports van grootgebruikers zoals Amazon en Google niet bij kunnen benen, dan ontstaat de situatie dat die reparatieplicht nog steeds geldt op de producten van die molochen. Die zijn dan zelf verantwoordelijk dat te fixen, en kunnen dus ook die boetes krijgen. Dan moeten zij het dus zelf fixen, en vanwege de open-source licentievoorwaarden (indien onder GPL of vergelijkbaar gepupliceerd) waarschijnlijk ook die fixes daarna publiceren. Dan kan de oorspronkelijke maintainer ze weer oppakken, toepassen, en het werk hervatten.
De oplossing voor dit soort open-source projecten is dus eenvoudig: product end-of-life verklaren; wachten op de fix, en dan het product weer laten herleven.
Dit lijkt me geheel aan de intentie en presentatie te liggen. Als je je aanmeldt als vrijwilliger voor Koningsdag en daarbij zegt “ik kan niet garanderen dat ik dingen af kan maken”, en daar gaat men mee akkoord, dan kunnen ze vervolgens niet verwachten dat je de verantwoordelijkheid neemt om dingen af te maken – dat heb je vooraf al uitgesloten.
Op dezelfde manier zit er een groot verschil tussen “hier heb je een ding wat ik ooit geklust heb, misschien heb je er wat aan, geen garanties”, vs. “ik heb een ding voor de wereld gebouwd, gaan jullie het ook gebruiken?” en het actief ‘marketen’. Debian valt duidelijk onder die laatste categorie, en dan mag je wat mij betreft inderdaad een zekere verantwoordelijkheid verwachten, maar een hoop opensource-dingen (inclusief dingen die in commerciele producten terechtkomen!) vallen toch echt onder de eerste categorie en daar vind ik dat geen redelijke verwachting.
Net zoals het redelijk is om van mensen te verwachten dat ze aan hun beloftes voldoen, is het onredelijk om te verwachten dat de eenzijdige keus van de ene persoon zich vertaalt in een verplichting voor de ander.
Niemand zegt dan ook dat een pakketje ergens neerkwakken met een MIT of GPL licentie betekent dat je levenslang alle bugs van iedereen moet fixen. Ook de CRA niet.
De CRA verklaart je een OSS steward als je structureel en systematisch onderhoud en support geeft. Dat kán onbetaald zijn, maar is wel een hogere lat dan “je reageert soms op bug reports”.
Nu gaat het hier in de reacties veel over of de maintainer van een opensourceproject nu wel of niet verantwoordelijkheid draagt, maar er lijkt mij hier een veel basalere vraag van toepassing te zijn: is die maintainer uberhaupt als fabrikant aan te merken?
Als Microsoft ervoor kiest om een opensource-library van Pietje om de hoek in hun product te gebruiken, zonder dat Pietje bij die beslissing betrokken is, dan is het toch Microsoft die een product ‘fabriceert’, en de verantwoordelijkheid draagt over de veiligheid van dat product? Dat ze in dat product een onderdeel van een ‘leverancier’ gebruikt hebben (om de vergelijking nog even verder te trekken) lijkt me dan niet relevant; dat is toch normaliter iets dat onderling op contractniveau opgelost hoort te worden? En er is geen contract, dus dan heeft Microsoft pech en moeten ze het zelf maar zien te fixen, en moet het bevel daar dus naartoe.
Mis ik hier iets?