EU-Raad bepaalt standpunt over beveiligingseisen voor digitale producten

EU-lidstaten zijn het eens geworden over hun standpunt rond de Cyber Resilience Act. Dit wetsvoorstel moet cybersecurityeisen stellen aan digitale producten die op de Europese markt verschijnen. De lidstaten gaan in onderhandeling met het Europees Parlement.

De Raad van de Europese Unie, bestaande uit ministers van EU-lidstaten, is woensdag akkoord gegaan met een onderhandelingsmandaat over de Cyber Resilience Act. Daarmee gaat de raad dit najaar onderhandelen met het Europees Parlement over de definitieve inhoud van de wet, die dan later eventueel wordt aangenomen.

De EU-Raad, bestaande uit ministers van EU-lidstaten, hebben enkele aanpassingen aan het wetsvoorstel gedaan. Zo wil de EU-Raad dat fabrikanten beveiligingsupdates uitbrengen gedurende de levensduur die consumenten en bedrijven 'redelijkerwijs mogen verwachten' van het product. De Europese Commissie stelde een maximumtermijn van vijf jaar voor in haar eerste wetsvoorstel. Ook zijn er maatregelen in het voorstel verwerkt die 'kleine en microbedrijven' moeten ondersteunen bij het naleven van de voorgestelde wet.

Er wordt al langer gewerkt aan de Cyber Resilience Act. De Europese Commissie deed daar vorig jaar een eerste voorstel voor. Onder de wet worden fabrikanten onder meer verplicht om gratis beveiligingsupdates uit te brengen. Het wordt ook verplicht om kwetsbaarheden en incidenten binnen 24 uur te melden aan het Europese cybersecurityagentschap ENISA.

Verschillende opensourcestichtingen, waaronder de Linux Foundation Europe, ondertekenden eerder dit jaar een open brief waarin ze hun zorgen uitten over het wetsvoorstel. Ook de Electronic Frontier Foundation sprak eerder dit jaar zorgen uit over het wetsvoorstel. Die stichting schreef dat opensourceontwikkelaars die enige hoeveelheid geld voor hun werk krijgen, bijvoorbeeld via donaties, verantwoordelijk gesteld kunnen worden voor kwetsbaarheden in hun software. Dat zou ook kunnen gelden als hun software wordt verwerkt in een ander product, zelfs als ze dat product zelf niet hebben ontworpen, stelde de EFF. Volgens de EFF kan dat ervoor zorgen dat opensourceontwikkelaars stoppen met het uitbrengen van hun projecten. Volgens de stichting is de verplichte openbaarmaking van kwetsbaarheden ook gevaarlijk, omdat dit kan betekenen dat kwetsbaarheden openbaar worden gemaakt voordat een patch beschikbaar is.

Reacties (71)

[Stijnvi]

Ik heb toch wel wat problemen met het volgende stuk:

Ook de Electronic Frontier Foundation sprak eerder dit jaar zorgen uit over het wetsvoorstel. Die stichting schreef dat opensourceontwikkelaars die enige hoeveelheid geld voor hun werk krijgen, bijvoorbeeld via donaties, verantwoordelijk gesteld kunnen worden voor kwetsbaarheden in hun software. Dat zou ook kunnen gelden als hun software wordt verwerkt in een ander product, zelfs als ze dat product zelf niet hebben ontworpen, stelde de EFF. Volgens de EFF kan dat ervoor zorgen dat opensourceontwikkelaars stoppen met het uitbrengen van hun projecten. Volgens de stichting is de verplichte openbaarmaking van kwetsbaarheden ook gevaarlijk, omdat dit kan betekenen dat kwetsbaarheden openbaar worden gemaakt voordat een patch beschikbaar is.

Het lijkt alsof deze partij problemen zoekt die er eigenlijk niet zijn.
In het wetsvoorstel is namelijk de volgende passage opgenomen:

Om innovatie of onderzoek niet in de weg te staan, mag vrije en opensourcesoftware die buiten het kader van een handelsactiviteit wordt ontwikkeld of geleverd, niet onder deze verordening vallen. Dit geldt met name voor software, met inbegrip van de broncode en gewijzigde versies ervan, die openlijk gedeeld en vrij toegankelijk, bruikbaar, veranderbaar en herdistribueerbaar is. In de context van software omvat een handelsactiviteit mogelijk niet alleen het in rekening brengen van een prijs voor een product, maar ook het in rekening brengen van een prijs voor technische ondersteuningsdiensten, het aanbieden van een softwareplatform waarmee de fabrikant andere diensten te gelde maakt, of het gebruik van persoonsgegevens voor andere redenen dan uitsluitend de verbetering van de beveiliging, compatibiliteit of
interoperabiliteit van de software.

De 'klacht' van het EFF is dat handelsactiviteit te breed gedefinieerd zou zijn.
Hoewel er geen vaste grens is vastgesteld, is het redelijk duidelijk wat wel een geen handelsactiviteit is. Zeker gezien de eerste zin van het wetsartikell: "Om innovatie of onderzoek niet in de weg te staan".

Als jij als individu een 'innovatief' stukje opensource code schrijft zonder het doel daar geld mee te verdienen, valt het gewoon onder deze bescherming. Als jij namelijk als individu een oude videokaart op 'Vraag & Aanbod' verkoopt ben je namelijk ook niet ineens een zakelijke elektronicaverkoper.

Ook is er duidelijk gedefinieerd wat sowieso wel wordt gezien als 'handelsactiviteit', namelijk:

In de context van software omvat een handelsactiviteit mogelijk niet alleen het in rekening brengen van een prijs voor een product, maar ook het in rekening brengen van een prijs voor technische ondersteuningsdiensten, het aanbieden van een softwareplatform waarmee de fabrikant andere diensten te gelde maakt, of het gebruik van persoonsgegevens voor andere redenen dan uitsluitend de verbetering van de beveiliging, compatibiliteit of interoperabiliteit van de software.

In het artikel van Tweakers staat:

Die stichting schreef dat opensourceontwikkelaars die enige hoeveelheid geld voor hun werk krijgen, bijvoorbeeld via donaties, verantwoordelijk gesteld kunnen worden voor kwetsbaarheden in hun software.

Dat schreef de organisatie dus inderdaad heel erg mooi, maar is in het wetsvoorstel dus nergens terug te lezen.

Bovendien is door de EU-raad inmiddels het volgende standpunt toegevoegd:

De Raad zou echter bepaalde punten uit het Commissievoorstel graag anders zien:
[...]
- ondersteuning voor kleine en micro-ondernemingen
[...]

Zelfs als jouw opensource code dus gezien wordt als 'handelsactiviteit', en je hebt die slechts met een paar man geschreven, dan zou je dus alsnog ondersteund worden door de EU.
Maar de EU zal dus maar heel weinig kleine projecten willen bestempelen als 'handelsactiviteit', aangezien ze dan dus deze steun moeten leveren.
Praktisch gezien zal dus geen enkele opensource codeur hierdoor in de problemen komen.
Want voordat je project zowel wordt gezien als 'handelsactiviteit' en je valt niet meer onder de noemer 'kleine onderneming', dan ben je echt wel heel erg serieus bezig, en heb je dus waarschijnlijk gewoon een winstoogmerk.

Volgens de definitie van de EU (bron), heeft een micro of kleine onderneming namelijk 49 of minder werknemers in dienst, een omzet van minder dan 7 miljoen euro per jaar, of een balanstotaal van minder dan 5 miljoen.
Je moet dus wel bizar groot zijn als opensource leverancier en ontzettend veel donaties ontvangen om buiten alle beschermingen te vallen.

De originele 'klacht' van de EFF wordt hiermee dus al helemaal teniet gedaan.
Ik ben dus wel een klein beetje kritisch op Tweakers dat ze een volledige paragraaf wijten aan een 'klacht', die eigenlijk al vergezocht was, en bovendien in het nieuwe akkoord helemaal wordt opgelost.

[Verwijderd]

stel ik heb een MIT license op mijn software:

Dit stuk:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NON INFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Geeft toch duidelijk aan dat er geen garantie op de software zit, hoe wil de eu hier een standpunt over innemen ?

[WhatsappHack]

Dat je iets schrijft wil niet zeggen dat het dan ook rechtsgeldig is of blijft natuurlijk. Dus als jij gewoon een stukje software wil schrijven en uitgeven voor iedereen, dan kan het door deze wet blijkbaar (ik heb hem nog niet gelezen, even puur afgaand op wat er in het artikel staat) zo zijn dat je dus wel verantwoordelijkheden en aansprakelijkheden moet gaan aannemen onder bepaalde omstandigheden (zoals donaties om je te helpen benodigdheden (eg: internet, laptop, whatever) te financieren) - wat zeker voor opensource een ramp kan zijn. (Ik draag zelf bij aan veel opensource projecten waaronder een aantal medische DIY-apps, daar wil je al helemaal geen gelazer hebben; maar veel mensen kunnen niet zonder die apps. )

[devices]

Ik ben geen jurist, maar alleen het accepteren van donaties lijkt mij er niet onder te vallen. Het gaat echt om commerciële activiteiten.

In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.

[svenk91]

This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable.

Het is maar de vraag welke open source licenties hier aan voldoen. Veel licenties beperken toch tot in zekere mate die vrijheid (vrijwel alle licenties eigenlijk, zelfs iets als cc zero beperkt je in dat je geen verdere beperkingen kan opleggen ). Dat stuk tekst is dus flink aan interpretatie onderhevig.

[devices]

Het gaat niet om vrijheid of niet, maar om toetsbare eigenschappen. De EU heeft de eigenschappen ook aardig helder uitgelegd in dit document: https://joinup.ec.europa....delines%20EN%20Joinup.pdf

Ik vind dat wel duidelijk genoeg eigenlijk en zie niet wat er aan interpretatie onderhevig is. Een rechter gaat dat echt niet allemaal zelf bedenken, maar gebruikt dit soort documenten voor definities.

[graey]

De verantwoordelijkheid voor het gebruik van software die onder deze voorwaarden wordt aangeboden lijkt mij niet bij de aanbieder te liggen.

[Olaf van der Spek]

Geeft toch duidelijk aan dat er geen garantie op de software zit, hoe wil de eu hier een standpunt over innemen ?

Die software mag je hier dus niet verkopen..

[Verwijderd]

Ja maar in heel veel software zit een stukje /onderdeel een MIT license of een andere die er op lijkt. stel mijn software bevat een externe library die moet ik dan forken (onderhouden). Hierdoor wordt alles alleen maar onbetaalbaar.

Daarnaast wordt de ENISA de bron van CVE's. Is toch raar dat ik moet melden dat er wat aan de hand is in mijn software. Als ik dit met mijn klanten deel moet dit toch afdoende zijn, lijkt me

[The Zep Man]

Ja maar in heel veel software zit een stukje /onderdeel een MIT license of een andere die er op lijkt. stel mijn software bevat een externe library die moet ik dan forken (onderhouden). Hierdoor wordt alles alleen maar onbetaalbaar.

"Ja, maar ontwikkelen kost geld!"

Het is helemaal niet gek om op je verantwoording gewezen te worden als je een product verkoopt met open source/public domain onderdelen. Je draagt dan zelf eindverantwoording voor de bugs die erin zitten die jouw product negatief beïnvloeden. Als je slim bent upstream je je fixes, zodat je in toekomstige versies van het betreffende onderdeel de gewenste fix er gewoon in zit en je daar verder geen onderhoud meer aan hebt.

Iemand gaat de rekening betalen voor onveilige software. Wie is een betere partij om die rekening bij neer te leggen dan degenen die aan software verdienen? Natuurlijk wordt dat naar klanten doorberekend, en dat open ruimte voor concurrentie. Niets mis mee.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:17]

[gedonie]

Als je als bedrijf wordt afgerekend op fouten die open source producten maken die je verwerkt in een commercieel product dan gebruik je dus niet meer. Moet ieder bedrijf dan alle open source gaan scannen op potentiële bugs en exploits. Dan kunnen ze het net zo goed zelf bouwen, klassieke not invented here syndroom.

Met als gevolg dat de geld stromen opdrogen voor open source, want commerciële bedrijven sponseren open source flink.

[The Zep Man]

Als je als bedrijf wordt afgerekend op fouten die open source producten maken die je verwerkt in een commercieel product dan gebruik je dus niet meer.

Zie maar wat goedkoper is: upstream een bug fixen of het gehele open source project vervangen voor iets dat je zelf ontwikkelt of laat ontwikkelen.

Moet ieder bedrijf dan alle open source gaan scannen op potentiële bugs en exploits.

Je klinkt verbaast over dat een bedrijf verantwoordelijk wordt gehouden voor code die die verkoopt. Natuurlijk wordt die daarvoor verantwoordelijk gehouden. Het geluk heeft dat security assessments op open source code makkelijk te regelen zijn. Overigens zal dat bedrijf dat ook met diens eigen code moeten doen, die ook nog eens ontwikkeld moet worden.

Al wil je de vruchten plukken van open source code, dan moet je soms ook op de blaren zitten. Natuurlijk kan je ook zelf ontwikkelen, maar dan heb je enkel meer blaren en geen vruchten.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:17]

[svenk91]

Er is nog een derde optie buiten OSS en in-house, je laat je software leveren door een derde partij. Een partij waarmee je een contract sluit voor 5+ jaar om de support te leveren.

[The Zep Man]

Er is nog een derde optie buiten OSS en in-house, je laat je software leveren door een derde partij.

Zie maar wat goedkoper is: upstream een bug fixen of het gehele open source project vervangen voor iets dat je zelf ontwikkelt of laat ontwikkelen.

[svenk91]

Dat ligt er natuurlijk aan hoeveel bugs er zijn. Voor kleinere software heb je helemaal gelijk, maar bedrijven vallen bij grotere software al snel over op een service contract, ook voor bijv. Linux en andere open source software.

[blorf]

Volgens mij ligt de motivatie van die act in werkelijkheid ergens anders.
Een klein aantal bedrijven kunnen zo een kunstmatig elitaire positie handhaven. Veel beter zou het zijn om de makers van 'digitale produkten' te verplichten alle meegeleverde software voor de eindgebruiker bereikbaar, aanpasbaar en vervangbaar te maken. Het verplichten tot een termijn van periodieke software-updates steunt precies het tegenovergestelde. Dat is de eind-autoriteit bij 1 partij leggen en suggereren dat dichtgetimmerde computers veiliger zijn.

[derkesthai]

Daarom ook een doodssteek voor open source, vind ik.

Als je alles zelf moet bouwen of open source moet forken en onderhouden dan gaat de kwaliteit van de software echt niet beter worden...

[The Zep Man]

Daarom ook een doodssteek voor open source, vind ik.

Als je alles zelf moet bouwen of open source moet forken en onderhouden dan gaat de kwaliteit van de software echt niet beter worden...

Er staat nergens dat je alles moet bouwen of open source moet forken en onderhouden. Je moet bugs oplossen in software die je verkoopt. Daar is niets mis mee.

"Ja, maar dat is open source of public domain code. Dat onderhoud ik niet, ook al lever ik het en verdien ik eraan."

Dat klopt natuurlijk ergens niet.

[derkesthai]

Maar moet je dan ook bugs oplossen in open source code die je hebt gebruikt in je software? Of anders gezegd, wie is er verantwoordelijk voor het oplossen van security issues in de 3rd party componenten die je in jouw software gebruikt? Ofwel bij jij verantwoordelijk voor security issues in bijv. Java of .Net core, om maar even wat te noemen? Het lijkt me dat het best ingewikkeld kan worden. Ik kan me voorstellen dat je dan als software bouwer dan maar zelf dingen gaat maken in plaats van open source te gebruiken zodat je niet afhankelijk bent van een derde partij.

En je gebruikt natuurlijk componenten van een derde partij om iets te doen waarvan je zelf de kennis niet hebt, of niet voldoende. Idioot natuurlijk als je dat ineens moet gaan onderhouden, dan kun je net zo goed investeren in kennis zodat je geen 3rd party component of library meer nodig hebt.

[Reactie gewijzigd door derkesthai op 22 juli 2024 19:17]

[The Zep Man]

Maar moet je dan ook bugs oplossen in open source code die je hebt gebruikt in je software? Of anders gezegd, wie is er verantwoordelijk voor het oplossen van security issues in de 3rd party componenten die je in jouw software gebruikt?

Je bent zelf eindverantwoordelijk voor programmatuur die jij verkoopt. Jouw klanten hebben een overeenkomst met jou, niet met jouw onderleveranciers.

Al verdien je eraan ben je eindverantwoordelijk. You can't have your cake and eat it too.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:17]

[derkesthai]

In principe ben ik het met je eens, maar jij ziet hoop ik ook wel in dat dat in de praktijk best ingewikkeld kan worden. Stel er zit een security issue in Java ofzo, daar ben je toch echt van afhankelijk dan. Hoeveel kan je er dan zelf aan doen om dat (snel) op te lossen?

[The Zep Man]

Stel er zit een security issue in Java ofzo, daar ben je toch echt van afhankelijk dan. Hoeveel kan je er dan zelf aan doen om dat (snel) op te lossen?

• Nieuwe kwetsbaarheden netjes melden bij Oracle. Die hebben best wel een aardige geschiedenis waarin zij kwetsbaarheden oplossen.
• Je programmatuur zodanig ontwikkelen dat het niet afhankelijk is van een verouderde Java-versie.
• JRE niet meeleveren en eisen dat je klanten zelf JRE installeren, en dat ze het zelf actueel moeten houden (ook met nieuwe versies van jouw software in het achterhoofd, die uiteraard enkel door Oracle ondersteunde JRE's ondersteunen).

Zo moeilijk is het niet, maar het is uiteraard wel meer als 'ik lever één keer en kijk er nooit meer naar om'. Je zal zelf aan de slag moeten om software die jij verkoopt veilig te houden.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:17]

[derkesthai]

* Maar je bent dan wel afhankelijk van Oracle. Als zijn besluiten de kwetsbaarheid niet als hotfix op te lossen bijv. dan zit je wellicht voor een tijd vast aan de kwetsbaarheid. Hoe gaat de wet hier mee om?
* Uiteraard kun je in programmatuur bepaalde maatregelen nemen, ben ik ook met je eens, en sommige kwetsbaarheden zijn vast op te lossen met een (tijdelijke) workaround.
* Je kan JRE niet meeleveren, maar volgens mij vind de wet nog steeds dat het jouw verantwoordelijkheid is als er een kwetsbaarheid in de JRE zit, want jouw software is er van afhankelijk.

'ik lever één keer en kijk er nooit meer naar om' is natuurlijk wel het andere eind van het spectrum.
Ik ben echt wel voor de eigen verantwoordelijkheid om je eigen software veilig te houden, maar soms is het 'out of your hands' (of misschien wel vaker dan soms) en daar zal de nieuwe wet toch echt op een of andere manier in moeten faciliteren.

[Zer0]

Je moet bugs oplossen in software die je verkoopt. Daar is niets mis mee.

Als je fixes aanlevert bij de beheerder van de source, maar deze niet meewerkt zul je toch weer zelf moeten gaan forken.....

[joenevd]

Ik denk dat software leveranciers sowieso wat kritischer mogen zijn wat ze aan externe libraries gebruiken. Ik als "systeembeheerder" heb een applicatie leverancier onlangs erop gewezen dat ze een 10 jaar oude 7-Zip versie hebben verwerkt in hun applicatie, terwijl er bekende kwetsbaarheden in zitten. Het ergste nog is dat de leverancier mijn opmerking negeert en vrolijk doorgaat met gebruik ervan.

Dit is 1 voorbeeld, er zijn echter veel voorbeelden van software leveranciers met dergelijke beveiligingsproblemen die niet aangepakt worden. En de systeembeheerders worden als irritant ervaren...

[derkesthai]

Ben ik ook met je eens! Ik hamer er op om 3rd party libraries en componenten altijd up-to-date te houden, maar het is soms lastig om management te overtuigen van de noodzaak hiervan -> "hoezo, het werkt toch goed?"

[wild_dog]

Jij bent de gene die, voor software waar je voor betaald word en waarvoor je dus garantie moet leveren, gekozen hebt om in jouw eigen code gebruik te maken van externe open source software waar uitdrukkelijk geen enkele garantie richting jou op zit.

Jij bent dus aansprakelijk voor problemen met de software die jij gelevert hebt en bent dus ook verantwoordelijk voor jouw gebruik van deze externe library en de gevolgen daarvan.

[Verwijderd]

Ja, uitschakelen indien mogelijk, klagen gebruikers daar weer over.

[WillySis]

Voor commerciële software moet men gewoon zorgen dat lekken gemeld en gepatcht worden. Als men daarvoor een opensource library gebruikt, heeft men ook de plicht om die lekken te melden en te patchen.

[WillySis]

Maar wel gratis weggeven.

[True]

De MIT license is niet bepaald geschikt voor het verkoop van je eigen software, immers geef je onder die license iedereen toegang tot het (her)gebruik van je product (wat onder MIT valt) mits er copyright notice instaat en alles ook onder MIT blijft vallen.

[dakka]

Probleem is als je verder bijv. donaties of sponsoring krijgt voor je gratis OS project, of een ander bedrijf verwerkt het in hun software en dat gaat fout, dat je als ontwikkelaar mogelijk alsnog verantwoordelijk gehouden kan worden met dit voorstel.

Terwijl een MIT licentie in principe een "gebruik op eigen risico" disclaimer is.

[Reactie gewijzigd door dakka op 22 juli 2024 19:17]

[devices]

Het is toch het bedrijf dat verantwoordelijk wordt gehouden voor de veiligheid en niet de ontwikkelaar(s) van de FOSS? Het bedrijf biedt het product namelijk aan.

[dakka]

Dat is dus het probleem met dit voorstel, als dat bedrijf een datalek heeft, en die kwetsbaarheid ligt in de library die jij heb ontwikkeld als FOSS, bestaat de mogelijkheid, onder dit voorstel, dat jij aansprakelijk gehouden kan worden.

Het is in de wettekst te vaag/breed blijkbaar wat er onder "commerciële activiteiten" valt.

https://www.eff.org/deepl...-source-and-cybersecurity

[Reactie gewijzigd door dakka op 22 juli 2024 19:17]

[Frame164]

Zoals ik het lees staat dat er niet. Degene die het product naar de markt brengt is verantwoordelijk. En aangezien het open source is hoef jij dat stuk FOSS niet aan te passen. De leverancier vn het product moet dat regelen. Die kan een andere component opnemen in het product of developers vragen het te fixen. Dat is het leuke van open source.

[Verwijderd]

Wat als jou software wordt gebruikt bij hacken en is verkregen bij hacken en je dat niet kunt aantonen, ik zie alleen maar problemen met deze wet...

[dakka]

Ja, dat is het leuke van open source, op dit moment, maar zoals het voorstel er nu ligt zijn best wel grote zorgen bij niet de minste partijen dat hier verandering in zal komen in de EU.

[devices]

Ik vind dat de eff er wel een rare lezing op nahoudt. Overal in de wettekst gaat het over de aanbieder van een device of software. Als ik een pakket uitbreng die een library van jou bevat met een beveiliggingslek, dan ben ik daar alsnog verantwoordelijk voor.

Uit artikel 1(c):

essential requirements for the vulnerability handling processes put in place by manufacturers to ensure the cybersecurity of products with digital elements during the whole life cycle, and obligations for economic operators in relation to these processes;

Artikel 10 en 11 gaat specifiek over manufacturers. In het voorbeeld ben ik dat, niet jij.

Dan in Annex I, artikel 2:

Manufacturers of the products with digital elements shall:

(1)identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product;

Daar lees ik dat de aanbieder verantwoordelijk is. Zelfde met de volgende 7 leden.

De manufacturer, ik, zou jou natuurlijk (deels) aansprakelijk kunnen stellen als jij het commercieel aanbied:

In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.

Maar als jij geen winstoogmerk hebt, en naar mijn mening zijn alleen het feit dat jij donaties accepteert dat niet, dan val jij er dus buiten.

[Reactie gewijzigd door devices op 22 juli 2024 19:17]

[dakka]

Ik ga ervan uit dat organisaties zoals de EFF of de EDRi, die meerdere juristen hebben rondlopen, dit niet zomaar roepen, en ze maken er ook een specifiek punt van.

Hier een voorstel voor het aanpassen en verduidelijken van de wettekst.
https://edri.org/wp-conte...t-position-EDRi_final.pdf

De Python software foundation heeft ook hun zorgen geuit dat het impact op python zelf zou kunnen hebben https://pyfound.blogspot....sed-cra-law-may-have.html

[Reactie gewijzigd door dakka op 22 juli 2024 19:17]

[Verwijderd]

Ik dacht dat op mijn framework (heeft momenteel een MIT licentie) gewoon allerlei (ook proprietary licenses) software gebouwd mag worden. Stel je gebruikt mijn framework (die is gratis) en je bouwt er een app mee (proprietary = betaald) dat dat mocht met de MIT licentie.

[derkesthai]

Van wikipedia: "De enige voorwaarde is dat het copyright statement in alle kopieën moet blijven staan. Verder mag de software ook gebruikt worden als onderdeel van propriëtaire software."

[Kapiteiniglo]

Vrij simpel, wetgeving (ook Europese) kan contracten tussen privé personen doorkruizen. Stel je spreekt in een contract af dat je de andere mag doodmaken. Dan blijft dat nog steeds illegaal...

[Illegal_Alien]

Een license agreement staat niet boven de wet; alleen hoe dat dan verder moet is een goede vraag.

[beerten]

Ze kunnen er in zetten wat ze willen, maar de wet gaat voor kleine lettertjes.

[Frame164]

De wet gaat altijd boven eigen voorwaarden.

(Edit) hmmm, toen ik dit typte stonden de vergelijkbare antwoorden er niet....

[Reactie gewijzigd door Frame164 op 22 juli 2024 19:17]

[Verwijderd]

Ja maar dan houdt linux op gratis te zijn denk ik. Waarom moet er nu een verdien model komen. Niemand in de opensource gemeenschap kan en wil die commitment. Als het gratis is, kunnen er toch geen eisen gesteld worden lijkt mij. En daarom ook die zin. Vroeger heb ik met mijn software de com poort van een pc opgeblazen op school, gewoon te hoge snelheid en het brande door. Is dit dan mijn schuld, of de driver auteur? In dit geval was ik dat ook, maar goed. Iedereen wil straks onze software, want max 5 jaar garantie. Een data lek, wie gaat dat vergoeden? Zeker ook de software maker. Zo moet je dus al een advocaat hebben als ondernemer, een boekhouder, noem maar op. Hoe kunnen starters ooit van de grond komen op die manier? Ook een dure verzekering die je indekt tegen data lekken, al dat soort ongein...

Of is het zo: iemand gebruikt jouw software wellicht niet binnen de licentie overeenkomst wat vaak zal voorkomen, want dat worden ingewikkelde constructies. Hoe kun je nog software schrijven voor een ander waarbij de veeleisende klant altijd trammelant veroorzaakt. En je dan ook nog gratis beveiligingsupdates moet verstrekken. Tijd is geld dus niet gratis dus moet dus ongespecificeert op de rekening. Net zoals de verzekering.

[WillySis]

De wet gaat altijd boven de bepalingen die fabrikanten of ontwikkelaars aan hun producten toevoegen.

De wet geldt voor commerciële software. Of die open source wordt uitgebracht of niet doet er niet toe. Gratis software wordt niet verkocht, waardoor de wet daarvoor niet geldt.
Voor (zeer) kleine bedrijven en liefhebbers lijkt er wel een regeling te komen waarbij ze aanspraak kunnen maken op een vergoeding om de lekken te dichten en daar ook meer tijd voor krijgen.

[Olaf van der Spek]

De Europese Commissie stelde een maximumtermijn van vijf jaar voor in haar eerste wetsvoorstel.

Waarom zou je een maximumtermijn voorstellen?
Moet dit niet minimumtermijn zijn?

[WhatsappHack]

Ze kunnen dan maximaal 5 jaar verplicht stellen. Dus 5 jaar is de maximum termijn voor verplichtstelling, maar als je het andersom wil beredeneren betekent het dus minimaal 5 jaar updates uitbrengen. Het is maar hoe je het bekijkt. Ik vind "Moeten verplicht minimaal 5 jaar updates uitbrengen" ook logischer klinken, maar zo te zien kan het dus zijn dat voor sommige producten een minder lange termijn gaat gelden (eg: 1 of 2 jaar); en dan is het wel logisch om in de wet te gaan praten over maximums ipv minimums.

[Verwijderd]

Wat ik mij dan weer afvraag is: stel mijn software is 5 jaar oud en die verkoop ik. dan ben ik daarna niet meer verplicht om de software bij te houden bij een incident ? ik vindt het bijzonder...

[ComputerGekkie]

Ik weet de exacte wettekst niet, maar dikke kans dat het geld vanaf het laatste moment van verkoop. Dus in je voorbeeld 5 jaar vanaf nu + de periode die je verkoopt. Anders zou software die 5 jaar in ontwikkeling is ook geen beveiligings updates krijgen.

[hamsteg]

In tegenstelling tot hardware wordt het kopiëren van een software release vaak bekeken vanuit de datum van creatie van die release (vrijgave). Maar ik ben benieuwd naar wat er straks in de Europese richtlijnen komt te staan. Ik moet er niet aan denken voor specialistische niche producten die in hele kleine aantallen jaren lang verkocht worden; na de laatste verkoop nog 5 jaar?

De wet lijkt te gaan over relatie producent-consument, als dit business-to-business ook gaat gelden is de impact echt heftig.

[Frame164]

Over het algemeen geldt de releasedatum. Al is deze case vrij theoretisch. Software waar gedurende 5 jaar geen aanpassingen voor nodig waren zijn extreem zeldzaam.

[Verwijderd]

Ik gebruik er nu eentje die bijvoorbeeld af is en niet meer wordt doorontwikkeld. Nu is dat javascript en die software zou ik niet meer kunnen gebruiken omdat de schrijfstijl zodanig is, dat ik er geen brei van kan maken. Een zogenaamd minified ding. Als daar een beveiligingslek in komt moet ik van merk wisselen nu, omdat ik de source dan niet heb. Maar het wordt gewoon een onderhoudscontract a 79 euro per jaar. Heb je als starter gelijk 1000 klanten nodig, lekker dan zodat je die tijd in onderhoud kan steken. Haal je maar 20 klanten het eerste jaar en je wilt dezelfde omzet dan is dat dus 3950 per jaar. Vrij fors voor een newbie on the Block.

[ari3]

Waarom zou je een maximumtermijn voorstellen?
Moet dit niet minimumtermijn zijn?

Nouja, de normale garantie geldt natuurlijk al, maar dat is voor veel producten te kort. Ik zou eigenlijk een aanvullende regel willen voorstellen:
- Zodra een fabrikant geen onderhoud meer wil of kan geven, dan vervalt de broncode van software, firmware en microcode alsook de specificaties van hardware registers van het product onmiddellijk in het publieke domein met een licentie die aanpassingen mogelijk maakt zodat derden het product kunnen patchen.
- Het moet dus altijd mogelijk zijn zelf software te vervangen op ieder apparaat.

Zo'n regel maakt het mogelijk dat beveiligingsproblemen ook na garantie opgelost kunnen worden door derden (via open-source initiatief of tegen betaling via crowd-sourcing). Ook zorgt het dat producten langer meegaan wat natuurlijk beter is voor het milieu.

[Stijnvi]

De minimumtermijn is de 'redelijk te verwachten levensduur'.
Voor sommige producten, zoals low-end telefoons zal dat grofweg 2 jaar zijn, voor high-end telefoons 3 tot 4, of misschien wel 5 jaar. Maar de levensduur van een auto is tientallen jaren. En zo goed als iedere auto wordt tegenwoordig geleverd met een infotainment systeem, en dus software. En het lijkt me niet echt wenselijk om bijvoorbeeld een autofabrikant te verplichten bijvoorbeeld twintig jaar lang updates te leveren. Vandaar dus de maximumtermijn. Bovendien kan ik ook maar weinig elektronica bedenken van ik daadwerkelijk een levensduur van meer dan 5 jaar verwacht waarbij ik na die 5 jaar ook nog echt behoefte heb aan beveiligingsupdates.

[Olaf van der Spek]

En het lijkt me niet echt wenselijk om bijvoorbeeld een autofabrikant te verplichten bijvoorbeeld twintig jaar lang updates te leveren.

Waarom niet? Na vijf jaar is het okay als de auto onveilig is?

voor high-end telefoons 3 tot 4, of misschien wel 5 jaar.

Doe mij maar gewoon minimaal 7 jaar beveiligingsupdates.

waarbij ik na die 5 jaar ook nog echt behoefte heb aan beveiligingsupdates.

Waarom niet?

[Maurits van Baerle]

Ik weet niet of je nu borrelpraat herhaalt of ergens maar een half verhaal hebt gehoord maar dat is niet echt hoe het werkt. Laat ik het zo zeggen, ik ben nog nooit een verhaal tegengekomen waarbij iemand het heeft over dat de Europese Commissie ongekozen is dat niet gevolgd werd door ofwel klinkklare onzin ofwel ronduit leugens. Mensen die namelijk weten wat er wel werkt, niet werkt, of hoe het beter kan op EU niveau zullen het nooit hebben over dat leden van de Commissie ongekozen zijn. Net zoals we het bij de problemen bij Ajax het nooit hebben over dat Dušan Tadić ongekozen is.

De individuele leden van de Europese Commissie worden voorgedragen door de lidstaten, het Europees Parlement moet dan die voordracht goedkeuren voordat ze door het EP kunnen worden geïnstalleerd.

Het komt bovendien voor dat het EP van tevoren al aangeeft nooit kandidaat X of Y goed te keuren als die voorgedragen zou worden. Het EP kan de hele voordracht wegstemmen als ze over maar één kandidaat ontevreden zijn, en tijdens de rit kan het EP de hele Commissie naar huis sturen. Dat is een stuk democratischer geregeld dan in Nederland waarbij Ministers ook niet gekozen worden en goedkeuring door het parlement veel implicieter is. Zowel Ministers in Den Haag als Commissarissen in Brussel krijgen hun democratisch mandaat van het parlement.

Voorts heeft de Europese Commissie geen beslissingsmacht, ze mogen alleen voorstellen doen en, eenmaal aangenomen, voorstellen uitvoeren. Het zijn de Raad van de Europese Unie en het Europees Parlement waar de beslissingsbevoegdheid ligt en die moeten stemmen voordat iets ingevoerd mag worden. Daar ligt de macht, niet bij de Commissie. Het grote spanningsveld ligt dus ook tussen de indirect ‘gekozen’ leden van de Raad en de direct gekozen leden van het Parlement, de Commissie komt daar niet bij kijken.

Kortom, er wordt in EU verband niets geïmplementeerd zonder dat het EP daar mee heeft ingestemd. Het Europees Parlement gebruikt de democratische macht die het heeft, gebruikt het vaak en soms erg krachtig. En ook dit voorstel kan pas uitgevoerd worden nadat een meerderheid van het Europees Parlement hem heeft goedgekeurd. Dat is hun macht, en dat zijn ze verplicht aan de kiezer.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 19:17]

[Frame164]

Perfect beschreven. Ik had het niet beter kunnen doen 😁

Dit zou gewoon verplichte kost voor iedere burger moeten zijn.

[Reactie gewijzigd door Frame164 op 22 juli 2024 19:17]

[devices]

Hoe past de Raad in jouw verhaal ovet macht? Die wordt expliciet genoemd in het artikel, maar komt gek genoeg niet voor in jouw betoog. De Raad bestaat namelijk wel uit gekozen vertegenwoordigers.

[Wilin]

Een afbeelding van vrtnws over hoe de goedkeuring gebeurd van de natuurherstelwet (uiteraard zelfde voor deze). https://images.vrt.be/w12...1ee-91d7-02b7b76bf47f.png

Ja, de commissie is de entiteit met recht op initiatief, maar zonder de lidstaten en het parlement (beiden direct verkozen) kan niets worden goedgekeurd. Het parlement en de lidstaten kunnen ook vragen/afdwingen dat een bepaald onderwerp door de commissie wordt voorbereid tot verordening. https://commission.europa...ning-and-proposing-law_nl

Verder zijn de commissie leden voorgesteld door de regeringen van de lidstaten (dus indirect verkozen), krijgen ze een "examen" voor het parlement en kan het parlement de commissie naar huis sturen met een vertrouwensstemming. https://european-union.eu...tions-and-appointments_nl, niet zo anders als regeringen in de lidstaten (in België moeten ministers bijvoorbeeld geen parlementsleden zijn)

[Frame164]

Dat jij niet weet hoe het werkt betekent niet dat het daarom slecht is.

[jinvanthee]

Zoals een andere comment hier zei, betekent dit dat alle open-source programmeurs wettelijk verplicht worden om hun software te onderhouden en veilig te houden, ondanks een MIT-licentie?

Ik heb een open-source project die ik al een paar maanden niet heb aangeraakt, maar het is wel een paar honderd keer gedownload. Zelf voel ik geen motivatie om verder te werken aan het project, dus zou deze wet mij verplichten om alsnog verder te gaan met het toevoegen van beveiligingsupdates?

[NielsFL]

Alleen als je een donatie voor je werk hebt ontvangen.

Ben benieuwd hoe dat in de praktijk werkt. Stel dat je helemaal niet om donaties vraagt, maar ik stuur je toch 5 euro via PayPal. Ben dan het haasje?

Of een wat grijzere versie: je vraagt om donaties voor koffie, niet voor het werk dat je gratis beschikbaar stelt. Hebben we daar straks een maas in de wet? Of kan dat ook niet?

[devices]

De EFF heeft het over een uitzondering voor not-for-profit open source software. Het lijkt mij niet dat donaties gelijk staat aan for profit.

[WhatsappHack]

Die laatste paragraaf zet wel te denken en laat het klinken alsof dit de zoveelste wet over een digitaal onderwerp is van een groep analoge ambtenaren; en wederom eentje die meer schade aanricht dan goed doet dankzij een aantal absurde randvoorwaarden (ondanks dat de intentie van de wet zelf goed is en een aantal erg goede elementen bevat.). Is er dan helemaal niets gedaan met de kritiek vanuit de experts?

[Roel1966]

Op zich vind ik het wel een goede zaak dat er vanuit de EU beveiligingseisen gesteld worden aan digitale producten maar er zitten ook wel een aantal keerzijdes aan vast. Het eerste wat mij opvalt is dat de Raad van de Europese Unie bestaat uit ministers van diverse EU lidstaten. Dan zit ik mij zo af te vragen in hoeverre dat deze ministers kennis hebben van digitale techniek en beveiliging hiervan.

Daaarnaast krijg je het punt levensduur van een apparaat waarvan ik mij dan afvraag op welke basis die levensduur dan bepaald gaat worden. Word dit vanuit de zakelijke wereld bepaald of vanuit de consumentenwereld want daar zit nogal een verschil in. In de zakelijke wereld is de afschrijving van apparatuur een stuk korter dan voor consumenten. Wie gaat daar dan op controleren en wie gaat bepalen welke levensduur redelijk is.

Positieve kant is wel dat als deze wet goed uitgevoerd word dat er in elk geval een stuk minder e-waste zal zijn. Dan denk ik b.v. aan smartphones die vaak onbruikbaar werden puur en alleen doordat er geen softwareupdates meer beschikbaar waren. Maar ook bedrijven als Microsoft zullen dan misschien eens aangepakt worden vooral met hun praktijken met Windows 11.

Als ik dan kijk naar Windows 11 dan heeft Microsoft ergens moedwillig oudere pc's en laptops uitgesloten doordat Windows 11 officieel deze niet meer ondersteund. En tuurlijk, ergens moet een grens worden gestrokken maar bij Windows 11 is die grens gewoon nergens voor nodig. Blijkt in de praktijk dat met dan een paar aanpassingen dat Windows 11 ook op oudere systemen nog prima werkt.

[svenk91]

Gaat dit ook werken voor alle bloatware op bijv. mobieltjes? Dat zal wel eens een stuk minder kunnen worden als de verkoper/uitgever 5 jaar support op al die troep moet leveren.

[commjoenie2011]

Ik vraag me af: hoe zit het dan met vulnerable software zoals https://github.com/OWASP/wrongsecrets en dingen als WebGoat? Kunnen die nog wel gebouwd en gepubliceerd worden?

[kimborntobewild]

De EU-Raad, bestaande uit ministers van EU-lidstaten, hebben enkele aanpassingen aan het wetsvoorstel gedaan. Zo wil de EU-Raad dat fabrikanten beveiligingsupdates uitbrengen gedurende de levensduur die consumenten en bedrijven 'redelijkerwijs mogen verwachten' van het product. De Europese Commissie stelde een maximumtermijn van vijf jaar voor in haar eerste wetsvoorstel. Ook zijn er maatregelen in het voorstel verwerkt die 'kleine en microbedrijven' moeten ondersteunen bij het naleven van de voorgestelde wet.

Ik ben het daar hardgrondig mee oneens. Het is beter voor het milieu en de veiligheid om een minimumtermijn van vijf jaar in te stellen.
En vaak kunnen apparaten véél langer mee dan 5 jaar. Ik vind 5 jaar dan ook te weinig. Ik denk eerder aan bijv. 10, 20 of 30 jaar; mede afhankelijk van het type apparaat. M'n wasmachine is zo'n 25..30 jaar oud, en doet het nog prima.
https://en.wikipedia.org/wiki/Planned_obsolescence: dát moet hoognodig verboden worden. Ook moet het verboden worden om patenten/octrooien te kopen/houden die goed zijn voor het milieu, maar dat je ze met opzet niet gebruikt louter omdat je omzet/winst dan naar beneden gaat.

'Redelijkerwijs mogen verwachten': is natuurlijk erg vaag. Er bestaan trouwens wel getallen (het aantal jaren) voor bepaalde productcategorieën. Maar die getallen zijn veel te kort.