BSA lobbyt tegen nieuwe consumentenbescherming

Het is “onzinnig en schadelijk” als digitale diensten zoals cloud computing en betaalde downloads en streams in de nieuwe Europese regels voor consumentenbescherming worden opgenomen, las ik bij Webwereld woensdag. De softwarelobbygroep is er fel op tegen dat software en online diensten onder het consumentenrecht geschaard worden, wat het plan is met de in behandeling zijnde Consumentenrechtenrichtlijn.

Het zal wel aan mij liggen, maar de reactie van de BSA vind ik dan weer onzinnig:

Er ontstaan hierdoor namelijk hele rare en mogelijk schadelijke situaties, schetst Francisco Mingorance van de BSA. Zo eist de nieuwe richtlijn dat producten bij het afleveren niet defect zijn. Dit zou softwareleveranciers ontslaan van de plicht om later patches en updates te leveren, ten nadele van de consument.

Dat is natuurlijk niet wat “niet defect mogen zijn” betekent. Wat er nu al in de wet staat – en de ontwerprichtlijn niet verandert – is dat als producten tóch defect zijn, de winkelier die gratis moet herstellen. Of dat voor software geldt, is onduidelijk, hoewel in juni het Gerechtshof Arnhem oordeelde van wel. Lijkt me ook niet meer dan terecht eigenlijk.

Overigens betekent de conformiteitseis niet dat software per se foutvrij moet zijn. Als inherent aan software is dat er enige fouten in zullen zitten, dan hoort dat bij de redelijkerwijs gewekte verwachtingen. En díe bepalen waar je recht op hebt. Zeg maar, je weet dat Windows lek zal zijn maar dat er updates komen, dus meer dan updates bij ontdekte lekken kun je niet verwachten.

Door dit artikel werd ik wel weer geprikkeld om die ontwerprichtlijn eens te gaan lezen. Deze heeft als doel alle consumentenrechtgerelateerde richtlijnen te consolideren én de positie van de consument meteen maar te versterken.

Ik had goede hoop dat men software er ook expliciet onder zou schuiven, maar dat zie ik nergens in de tekst terug. Het enige dat ik over software zie, is de uitzondering op het retourrecht die nog steeds geformuleerd is alsof het 1995 is:

de levering van verzegelde audio- en video-opnamen en computerprogrammatuur waarvan de verzegeling door de consument is verbroken;

Kennelijk zwerft er dus ergens een recentere tekst rond waar wél meer over software in staat. Het persbericht van de EC van januari is informatief maar helpt niet echt. Iemand enig idee waar de geconsolideerde tekst staat?

Update (7 maart): Met dank aan PdL gevonden: het rapport plus het procedure-overzicht. Ik vermoed dat de BSA hierover valt:

Digital content: digital content transmitted to the consumer in a digital format, where the consumer obtains the possibility of use on a permanent basis or in a way similar to the physical possession of a good, should be treated as goods for the application of the Directive which apply to sales contracts. However, a withdrawal right should only apply until the moment the consumer chooses to download the digital content.

Met deze definitie is software (maar ook muziek en films) inderdaad onder de conformiteitseis te scharen. En, minstens zo leuk, je wordt dan eigenaar van je kopietje (en dus niet slechts licentienemer).

Arnoud

27 reacties

  1. Prof. Edsger Dijkstra draait zich drie keer om in zijn graf. Het is niet inherent aan software dat er fouten in zitten. Software kan namelijk langs wiskundige weg worden geconstrueerd en geverifieerd. Zie bijvoorbeeld het algoritme van Euclides, dat dateert van ca. 375 v.Chr., waarvan wiskundig is aangetoond dat het vrij is van fouten. Op de Wikipedia-pagina staat de software-implementatie in verschillende programmeertalen.

    Het is wel een gegeven dat de software-industrie de wetenschappelijke inzichten op dit gebied al decennia aan zijn laars lapt en op een ambachtelijke manier software ontwikkelt. De gangbare software is daarbij zo complex en onhanteerbaar geworden, dat het achteraf foutvrij maken daarvan ondoenlijk is. Hierdoor worden wij in de praktijk opgezadeld met software die stijf staat van de defecten. Juridisch en wetenschappelijk gezien een zeer onbevredigende situatie.

    De EU verbiedt dit nu en stelt kennelijk de wiskundige methode van de grond af verplicht. Immers, aangezien het construeren van foutvrije software al decennia aan informaticastudenten op de universiteiten wordt gedoceerd, is het een redelijke verwachting dat leveranciers deze werkwijze bij het ontwikkelen van hun producten toepassen.

    De nieuwe EU-consumentenrichtlijn is een grote sprong voorwaarts voor de toepassing van de wetenschappelijke informatica. Het zal een hoop nieuwe werkgelegenheid opleveren en zal foutrijke producten als Microsoft Windows, MacOS, Word, Excel etc. naar het rijk der vergetelheid doen verdwijnen. Aantoonbaar foutvrije software wordt de nieuwe norm. Hulde voor de innovativiteit en daadkracht van de EU!

  2. Helaas. Met de huidige architectuur van computers is het onmogelijk om wiskundig te bewijzen dat er geen fouten in software zitten. Een van de oorzaken hiervoor is het gebruik van interrupts.

    Zie hier: http://www.c2.com/cgi/wiki?ProofsCantProveTheAbsenceOfBugs

    Wat wel te bewijzen is, is dat software werkt volgens de gestelde requirements (zoals beschreven in het artikel hierboven). Alleen dan blijft de vraag: hoe foutvrij zijn deze requirements? 😀

  3. Ik begrijp niet dat de auto industie niet op zijn achterste benen staat. Of is dit niet van toepassing op embedded software waardoor auto’s niet remmen/te hard gaan rijden? 😉

    @Rene. Theoretisch is het mogelijk maar in de praktijk bijna onmogelijk. Hier hebben ze en goede gooi gedaan http://ertos.nicta.com.au/research/l4.verified/ Er staat een halve pagina bij wat niet en ze hebben het over what this implies.

    En dit is maar een heel kleine kernel 7500 lines of c (ex asembly ex bootcode ex compiler errors) en dan maar hopen dat er geen fouten zitten in de 200000 lines van het proof script

    Dus er is nog een lange weg te gaan

  4. Dat is natuurlijk niet wat ???niet defect mogen zijn??? betekent

    De vraag is maar of software wel makkelijk defect kan zijn in juridische zin. De software kan niet doen wat verwacht wordt of fouten bevatten. Is dat echter een defect.

    Een defect is over het algemeen iets afwijkend. Software pakketten bestaat echter uit identieke digitale kopie van een origineel. Er kan dus eigenlijk geen defecte software zijn (puur theoretische situaties waarbij een bit omgevallen is uitgesloten). Het is zoiets als stellen dat een film of een audiotrack defect zou kunnen zijn zonder dat de drager (CD/DVD) stuk is.

    Er kunnen dan nog steeds wel fouten in het software pakket product zitten of het product kan niet voldoen aan de gestelde eisen/verwachtingen. Producten zijn echter nooit perfect en dat geldt ook voor software.

  5. “Defect” in juridische zin betekent “voldoet niet aan de redelijkerwijs gewekte verwachtingen”. Een wrak dat je van de autosloop koopt voor 100 euro zal niet rijden, maar die auto is daarom nog niet defect. Een auto bij de dealer die niet rijdt is w?l defect want bij de dealer heb je de redelijke verwachting dat de auto zal rijden.

    De vraag is dus welke verwachting je mag hebben bij software en of de software daaraan voldoet.

  6. @dotNetCoder: Sorry, maar je betoog rammelt aan alle kanten. Het ene moment houd je correctheid voor onmogelijk vanwege interrupts, het andere moment ben je de interrupts vergeten en stel je dat correctheid wel mogelijk is in relatie tot de requirements. Je verwijst naar een wiki waarop anonieme amateurs hun onzin kunnen plaatsen, die weegt natuurlijk niet op tegen de gedocumenteerde resultaten van decennia technisch-wetenschappelijk onderzoek (om het over het meer dan twee millennia oude algoritme van Euclides maar niet te hebben).

    Interrupts zijn overigens volledig formeel te defini?ren en onderworpen aan de normale wiskunde en technische constructieleer in de wetenschappelijke computertechniek. Een programma met interrupts kan daarom net zo goed aantoonbaar foutvrij zijn als een programma zonder. Niet dat het veel uitmaakt, want de meeste applicaties worden geprogrammeerd op een hoger abstractieniveau, waar interrupts geen rol spelen (het operating systeem moet uiteraard wel aantoonbaar correct zijn m.b.t. interrupts).

    Maar goed, laten we Arnoud’s blog niet belasten met een eindeloze discussie over computertechnische zaken. Waar het om gaat is dat aantoonbare foutvrijheid redelijkerwijs van software verwacht mag worden.

  7. @Ren? Prof. Edsger Dijkstra was natuurlijk in die zin een dromer dat hij uitging van heldere, in wiskundige termen geformuleerde vereisten; dan kun je inderdaad formeel aantonen dat je programma daar aan voldoet of niet. In de praktijk bestaat dat echter niet, en is zelfs het vaststellen van je (gedetailleerde) vereisten het grootste struikelblok, en in tegenstelling tot code, moeten die zijn opgesteld in een taal waarmee je met de klant kunt spreken, met al haar ambigu?teiten en tegenstrijdigheden.

    Met deze ‘klantentaal’ kom je dus weer terug op wat je redelijkerwijs mag verwachten, en dan geldt gewoon dat je een product van de gebruikelijke kwaliteit moet leveren, en dat eventueel, net zo gebruikelijk, moet patchen als er kleine problemen mee ontstaan. Als een product echt “bagger” is (crasht om de haverklap, etc.), dan moet ook dat verholpen worden. De interpretatie van Arnoud lijkt me dan ook alleszins redelijk, en het standpunt van de BSA is voor mijn gevoel niets anders dan een poging onder de gebruikelijke kwaliteitsgaranties uit te wroeten, ipv die verantwoordelijkheid te nemen en eindelijk een volwassen industrie te worden…

  8. @Ren?: Natuurlijk is er theoretisch van alles mogelijk. Maar net als bijvoorbeeld de OV-chipkaart in theorie onkraakbaar zou kunnen zijn, is dat voor de beoogde prijs simpelweg niet haalbaar. Het resultaat is een tussenvorm, waarin software zeker niet foutloos is, maar wel betaalbaar.

    Ik schrijf dit overigens vanuit mijn achtergrond als software-ontwikkelaar en kan je vertellen dat er echt veel tijd wordt gestoken in het verifi?ren van software, denk bijvoorbeeld aan Unit Testing.

    Maar vaak is de prijs van de software voor de klant veel belangrijker en wordt je als ontwikkelaar gedwongen zaken snel (en dus goedkoop) op te leveren, i.p.v. zo foutloos mogelijk. Anders kun je simpelweg niet concurreren met andere softwareleveranciers.

    Er zijn natuurlijk specifieke toepassingen, zoals Automatische Piloten en allerlei software bij Defensie, waarvoor de correctheid zwaarder weegt dan de prijs.

  9. @Ren?: betekent dat software die niet volgens de methode van Dijkstra is gemaakt als ondeugdelijk mag worden gezien zodra er problemen in worden geconstateerd? Is dit een minimumvoorwaarde die je aan de manier van werken van de bouwer mag stellen? Ongeveer zoals de uitbater van een restaurant ook een bugvrije keuken dient te gebruiken?

  10. Laat ik maar heel bot mijn stelling dumpen:

    De vereiste kwaliteit van de software is afhankelijk van het beoogde gebruik.
    Een tekstverwerker mag vaker crashen dan de embedded software in een beademingsapparaat. Maar als het gebruik van een systeem verandert wijzigen de eisen ook: Met de opkomst van “online bankieren” wordt de mate waarin besturingssystemen en webbrowsers de privacy bewaken belangrijker.

  11. Dat lijkt me duidelijk. Maar zijn er misschien andere argumenten om software niet als alle andere consumentenprodukten te behandelen?

    Ik denk dat een ander belangrijk verschil is of het om een vast produkt gaat of om maatwerk. Veel software is zozeer maatwerk dat er continue dienstverlening van de makers aan de gebruikers nodig is. Zo zullen bijvoorbeeld de wensen van de klant vaak veranderen, en dan passen de makers de zaak vaak aan. Zoiets wordt met huizen en zo ook wel gedaan maar een architect kan toch altijd wel van zijn produkt weglopen zonder dat het onbruikbaar wordt. Je kunt je afvragen in hoeverre zulk extreem maatwerk aan regels moet voldoen die waarschijnlijk op standaardprodukten zijn afgesteld.

  12. @Ron: misschien had je het artikel moeten lezen, want mensen als Kent Beck en Ron Jeffries amateurs noemen???

    Om even wat uit te leggen: jij stelt dat we niets met interrupts te maken hebben omdat software op een hoger abstractienivo wordt geschreven. Dat is zoiets als een huis dat in brand vliegt door kortsluiting in de elektrische kookplaat, maar de eigenaar wil de brandweer niet bellen, want ‘ik kook elektrisch, dus er kan geen vuur zijn.’. Natuurlijk heb je met interrupts te maken. Om aan te tonen dat jouw software correct is, moet je ook (kunnen) aantonen dat de gebruikte compiler en op zijn minst het onderliggende OS correct zijn. En omdat interrupts op elk willekeurig moment kunnen optreden, betekent dit dat het aantal mogelijke punten die je moet bewijzen binnen een tijdsbestek waarin jouw software draait oneindig nadert. Dus theoretisch ZOU het mogelijk zijn om de hele keten van software mathematisch correct te verklaren. Tegen de tijd dat je dat voor elkaar hebt is het huidige heelal waarschijnlijk al ge?indigd (en ook meer dan eens).

    De argumentatie van de BSA is natuurlijk onzin (of in ieder geval verkeerdom geredeneerd), maar ik snap wel dat het heel vervelend voor softwarebouwers wordt als software inderdaad onder het consumentrecht zou vallen. Software is (praktijkervaring; ik schrijf zelf ook software) niet foutvrij te maken. Of alleen tegen hele hoge kosten zoals Jonas al aangeeft. Mathfox geeft mijns inziens goed weer waar de grens moet liggen: het beoogde gebruik. Zo zou een besturingssysteem betrouwbaarder mogen worden geacht dan een spelletje of tekstverwerker, en software voor life-support systemen betrouwbaarder dan een gemiddeld OS. Het zou mooi zijn wanneer een dergelijke ‘uitzondering’ voor software gemaakt zou worden; software is niet snel een standaard product te noemen zoals auto’s, huizen of eletronica. En dat is waar het huidige consumentenrecht voornamelijk voor bedoeld is/was.

  13. Voor maatwerk heb je een onderhandelbaar contract, kwaliteitseisen horen daar een deel van uit te maken. Ik neem aan dat een belangrijk deel van de “BSA” pijnpunten in de “””standaard software””” of “””standaard diensten””” ligt. Software bakkers hebben de neiging om aansprakelijkheid voor incompetentie uit te sluiten en ik vind dat een buitengewoon slecht idee. (Als context: Mijn baas heeft mij de functie-omschrijving “software ontwerper” toegekend.) Ik vind dat een klant een goed product verdient. “””Goed””” is afhankelijk van hoeveel de klant wil betalen voor kwaliteit, maar “””gratis””” diensten moeten ook een redelijke kwaliteit bieden.

  14. Ik lees erg interessante reacties hier (op goed technisch niveau), maar ik vrees, dat het abstractie-niveau van deze discussie te hoog is voor bij voorbeeld euro parlementari?rs. De definitie van foutvrije software is verre van makkelijk, vooral omdat je als software leverancier in de consumenten markt altijd van derde partijen afhankelijk bent. Want, we levert de hardware, het besturingssysteem en de applicaties compleet? Dat is wel een vereiste voor foutvrije software. Anders is het altijd de vraag, waar een fout nu zit. Is het een probleem van jou applicatie, als jou printer niet werkt, of is het een probleem van de printer driver (van het besturingssysteem) in verband met jou software. Of nog beter, is het een ander pakket, wat in de weg zit (Anti Virus, welke de driver blokkeert…) Welke software bevat dan de fout? Deze discussie leeft ook zonder consumentenbescherming al heel lang en we kunnen dagelijks over dergelijke problemen lezen…

    Wij ontwikkelen online (cloud) software en als Microsoft een nieuwe versie van zijn browser uitbrengt en onze software heeft daar een probleem mee, wiens fout is dat dan? Ik weet, hoe de gemiddelde klant reageert (hij zou niet Microsoft bellen…) Uit mijn eigen ervaring weet ik, dat sommige klanten het jou als leverancier ook kwalijk nemen, als jou software niet op de nieuwste beta-versie van een browser werkt…

    Dan de vraag over de definitie van een software fout. Is het een fout in de software, als pakket A een actie trager uitvoert als pakket B (omdat de ontwikkelaar van pakket B net een iets handigere database query geschreven heeft, of een loop is wat beter uitgevoerd)?

    Ik heb het vermoeden, dat de redenen voor verzet tegen deze nieuwe regelgeving toch uit een ander hoek komt. Als een software pakket tegenwoordig bijvoorbeeld een merk printer niet ondersteund, maar in een latere versie wel, is het aan de leverancier om te bepalen, of jij als consument voor deze update moet betalen of niet. Met de nieuwe regelgeving zou daar nog wel een verandering in kunnen komen.

  15. Juergen, de wet spreekt over “voldoen aan de redelijke verwachtingen van de klant”. Dit betekent dat software fouten mag hebben, zolang die het werk van de klant niet dwars zitten. Wanneer productaansprakelijkheid voor software ingevoerd wordt, betekent dit dat de leverancier (wederverkoper) verantwoordelijk is voor het oplossen van het probleem. Wanneer je software in verschillende winkels koopt heb je nog steeds het probleem van wie er nu echt aansprakelijk is, maar je kunt vaste klant worden bij de zaak die het probleem oplost.

    Ik verwacht dat de aanbieder van een web-dienst de beta’s en release candidates van zijn ondersteunde browsers gebruikt om compatibiliteit met de nieuwe release te bereiken. Een klant met een beta browser mag meehelpen met het vinden van issues.

    Mijn mening is dat een klant voor software die niet voor hem werkt, zijn geld terug dient te krijgen. Geef eens een goede reden waarom software hier anders behandeld moet worden dan een stuk gereedschap dat je in de ijzerhandel koopt.

  16. @rene: Zijdelings: Ik heb wel eens wat gespeeld met het maken van een testengine voor de wat complexere SQL-queries. Zeg maar ‘ik heb vijf records van type A en die moeten geagregeerd worden tot een totaalrecord; komt de output overeen met de input voor verschillende inputs?’

    Dat lijkt best aardig, alleen geeft dat in no-time een combinatoriele explosie. Je zou dat kunnen ondervangen door het iets abstracter op te schrijven: de som van ‘a,b,c,d,e’ moet gelijk zijn aan a+b+c+d+e. Alleen: je gaat dan als snel toe naar een notatie die heel erg lijkt op SQL. Maar dan anders. Om jwz te quoten: ‘now you have two problems’.

    Je zou zoiets nog kunnen proberen te verkopen als ‘als je je probleem uitdrukt in een andere notatie wordt je probleem (en eventuele edge-cases) duidelijker.’, maar helaas: je hebt nu problemen van de interactie van de werkelijkheid met je SQL, interactie van je testsysteem met SQL (SQL doet het goed maar je testbeschrijving is niet goed), en interactie van je testsysteem met de werkelijkheid (je testbeschrijving is geen goede beschrijving van wat er gebeurt in het echt).

    Wat de mensen hierboven al aan proberen te geven: ‘correctheidsbewijzen’ is een tak van sport die last heeft van ‘moving goalposts’; je kunt bewijzen dat een stuk code correct is, maar wie zegt dat dat stuk code ook doet wat je in je hoofd hebt?

    (en dan heb ik ’t nog niet gehad over meneer G?del die hier de hele tijd op het raam staat te tikken)

  17. Het is niet mogelijk software op correctheit te toetsen. Waar hier op gedoeld wordt is dat het wel mogelijk is te toetsen of een stukje software een correcte omzetting is van de vooraf gedefinieerde functie die het moet hebben. Dit vereist (1) dat je de functie van de software formeel kunt opschrijven, dit is niet bij alle typen programma’s even triviaal, (2) je de functie van de software ook daadwerkelijk correct opgeschreven hebt.

    Voorbeeld: Je maakt een programma om de kortste route tussen twee punten te berekenen. Stel dat je over het hoofd ziet dat er wel eens geen route tussen twee punten kan zijn. Als je deze situatie vergeet in de formele functie van de software op te schijven, dan kan het programma wel een correcte implementatie van de gedefinieerde functionaliteit zijn, er zal toch een bug in zitten.

    De bedoelde bewijsmechanismen zijn gemaakt voor deterministische machines. Niet-determistische effecten als interrups, of gebruikersinteractie zorgen dat de mechanismes niet werken. Echter: Het feit dat een computer interrupts ontvangt, verhindert hem niet een programma op een deterministische manier uit te voeren, het is het besturingssysteem dat de interrupts ontvangt en dus niet met deze methodes getoetst kan worden, maar het besturingssysteem zorgt dat programma’s die draaien weer wel deterministisch draaien, zodat je die weer op correctheid kunt toetsen.

    Moraal van het verhaal: Het op correctheid toetsen van software kan een nuttig hulpmiddel zijn minder bugs in software te krijgen. Het is echter niet meer dan een hulpmiddel, een wondermiddel om bugs uit te roeien bestaat helaas niet.

  18. Nu kom ik zelf uit de kerk van Dijkstra hoor, maar ik vraag me toch af of we niet wat erg streng zijn door te zoeken naar software die bewezen 100% correct is. In andere technologie?n is dat ook niet een vereiste. Een auto zal nooit 100% perfect zijn, ieder exemplaar heeft wel iets. Alleen zitten de fouttoleranties zo laag dat je daar in de praktijk zelden tegenaan loopt (rijdt?). Het stickertje van de alarmlichten zit 2mm hoger, een snoertje is al na 8000 km versleten in plaats van na 10.000, dat werk. Maar ontploffen doen ze zelden tot nooit meer (de Ford Pinto daargelaten). Zijn er geen technieken bij softwareontwikkeling om ook de fouttoleranties zo te beperken?

  19. @Arnoud: Ja dat soort technieken zijn er genoeg, er is een hele safety wereld ook voor software met formele(re) methoden. Klassieke voorbeeld is besturing in kerncentrales, mogelijk cruciale software in vliegtuigen, maar ook de embedded software zoals ABS in autos wordt volgens die technieken gemaakt. Typisch doel daar is om tegen 1 foute meting / beslissing bestand te zijn. Het is niet goedkoop om daar goed aan te voldoen (vooral als je ook 1 foute designbeslissing wil afvangen), je hebt snel 3 design teams nodig en 3 verschillende implementaties.

    Grote moeilijkheid als eerder gezegd is om te verwoorden wat precies die verwachtte functionaliteit is. Er zijn leuke verhalen van fly-by-wire vliegtuigen die ondersteboven gingen vliegen wanneer ze over de evenaar gingen (minteken fout in de formele specificatie, niet gezien door de steller + 3 design teams!). Wij hebben beiden in de informatica opleiding de Dijkstra methoden steeds gezien vanaf schone wiskundige probleemdefinitie, maar het probleem zit hem in het maken van die definitie (de rest is immer “maar” afleiding). En dan moet je dat nog kunnen lezen om te kunnen zien dat wat gecontroleerd is, echt wel is wat je wil hebben (daar gaat volgens mij dat L4 bewijs fors en onbegrijpelijk de fout in).

    In minder strenge variant kun je als programmeur al een hoop afvangen door gewoon het RFC-adagium “be liberal in what you accept, be restrictive in what you send” aan te houden, ook intern in je programma. Helaas is dat echt een zeldzame houding/vaardigheid/gewoonte, zelfs in de security wereld waar ik in zit en dat vrijwel een functionele eis is.

    Het kan wel veranderen. Mijn favoriete voorbeeld is Microsoft’s Secure Programming Development Lifecycle en vooral dat het daar doorgevoerd is. Deel van het process is fuzzing, simpelweg gezegd: rotzooi naar de software gooien en kijken dat het niets raars doet. Met de eis aan de programmeurs om het te repareren, maakt de software een stuk robuuster. Ik ben zeer onder de indruk dat men het daar met tienduizenden programmeurs die tientallen tot honderden miljoenen regels code genereren ingevoerd hebben, en je kunt het zien: Windows XP was voor service pack 2 vrij schieten, Windows 7 is best een uitdaging.

  20. Ik wou net inderdaad ms secure programming development lifecycle als voorbeeld geven, want dat kan de robuustheid wat user input betreft inderdaad aanzienlijk vergroten.

    Toch betekent ook dit niet alles. Wat auto’s en vliegtuigen betreft, deze zijn niet 1:1 te vergelijken met computers van eindgebruikers. Bij een auto en vliegtuig weet je precies van te voren op welke hardware ’t komt te draaien en bouw je ’t OS zelf. Bij de gemiddelde consumenten pc gaat ’t anders. Je hebt immers gebruikers die allerlei patches van microsoft installeren, 10 virussen, 2 rootkits, 3 virusscanners en 3 firewalls op 1 computer hebben staan. en elk van die dingen kan de werking van ’t platform waar ’t op moet draaien aanzienlijk beinvloeden.

    Je kan natuurlijk requirements opstellen als:

    Een juiste werking van deze software kan enkel gegarandeerd worden op een pc welke bestaat uit, een AMD processor welke beschikt over instructieset A, B en C, en een grafische kaart van het merk Nvidia uit de 9000 serie. Vervolgens moet op de computer Windows XP Home installatie staan te herkennen aan versie 5.1.2600, zonder enige updates of andere software, waarbij er geen andere schijven of partities beschikbaar zijn dan de C schijf, welke dient te verwijzen naar een lokale SATA2 hardeschijf welke geen ondersteuning biedt voor het TRIM commando. Tevens kan een juiste werking niet gegarandeerd worden als er andere programma’s dan mspaint geinstalleerd zijn.

    Maar ik weet niet wat de juridische waarde is als een particulier nu ook nog ms word op z’n computer installeert(?). Daarnaast koop je de auto ‘as a whole’, waarbij een eventuele schuldvraag duidelijk is, dat is gewoon de leverancier/fabrikant van de auto. Maar als mijn software programma nou vastloopt, en ik zeg dat dat komt omdat een ander programma mijn programma expres loopt te jammen, kan ik daar dan verantwoordelijk voor gehouden worden? En wie moet dan bewijzen waar de fout ligt?

    Of wat als de videokaart kapot is (of er een bug in diens drivers zit), waardoor de pc altijd (en alleen) crasht als mijn programma wordt opgestart, moet ik dan geld teruggeven omdat de drivers/hw defect zijn?

  21. @Jeroen#7: Bij sommige software, zoals een informatiesysteem voor een organisatie, is het opstellen van de vereisten inderdaad een groot struikelblok. Dat is echter geen argument om af te zien van het correctheidsbewijs ten opzichte van de vereisten zoals die uiteindelijk zijn opgesteld. In die zin was Dijkstra zeker geen dromer, zoals de meeste ontwerpend ingenieurs die wiskunde toepassen geen dromers zijn. Het is ook geen argument om na te laten bugs te voorkomen die niks met de complexiteit van de vereisten te maken hebben (denk bijvoorbeeld aan vastlopende smartphones op 31 december van een schrikkeljaar). En het is zelfs geen struikelblok bij een heleboel andere software, waarvan de vereisten goed zijn op te stellen.

    @Jonas#9: Dat een deugdelijke ov-chipkaart economisch niet haalbaar zou zijn is geen feitelijk gegeven, het is machtsspel van een marktpartij die probeerde een hogere prijs te krijgen. De bankkaarten zijn een stuk deugdelijker en zijn ook economisch haalbaar. Je concurrentieargument kan ik volgen en dat lijkt me ook de reden waarom dit probleem door de wetgever moet worden opgelost in plaats van door de markt. Nogmaals hulde voor de EU!

    @Reinier#10: Ja, van allerlei technische artefacten verwachten we om juridische, economische of maatschappelijke redenen een zeer hoog kwaliteitsniveau dat wordt bereikt met allerlei formele, vaak wiskundige, methoden en technieken. Dat is in verschillende takken van techniek de normaalste zaak van de wereld. Het is mij een raadsel waarom software daarvan zou zijn uitgezonderd.

    @DotnetCoder#13: Ja, er is alleen een correct eindproduct als de hele hardware/software-stapel aangetoond correct is, inclusief de CPU, compilers, run time libraries, third party components, operating system etc. En zoals ik al zei spelen interrupts met name in het OS een grote rol. Maar als aan deze correctheid voldaan is, dan doen interrupts op applicatieniveau niet ter zake, want daar zijn ze niet (daar zijn wel verstoringen als signals, events, requests, maar dat zijn andere asynchrone concepten). Het oneindigheidsargument snijdt geen hout. Wiskundig redeneren doe je nou juist om de oneindigheid van de testbenadering te voorkomen, dat is een a-b-c-tje van het eerste jaar informatica. Zelfs een 64-bits opteller (hardware) valt nauwelijks te testen vanwege de 2^128 mogelijkheden, maar heel goed wiskundig te verifi?ren. Overigens ontgaat me bij dit soort argumentaties waarom de uitdagingen zonder gebruik van wiskunde dan wel op te lossen zouden zijn. Als een probleem zo intrinsiek onoplosbaar zou zijn met wiskunde, hoe kunnen we het dan zonder wiskunde oplossen?

    @Juergen#15: Die afhankelijkheid van derde partijen is er juridisch gezien vrijwel altijd. Een ijssalon moet jou een ijsje leveren dat vrij is van gifstoffen, maar daarbij is hij afhankelijk van allerlei leveranciers van ingredi?nten en apparatuur. Juridisch gezien is er vaak sprake van complexe ketens van verantwoordelijkheid en aansprakelijkheid. Ik zie geen reden om bij software van die juridische gang van zaken af te wijken en partijen vanwege de afhankelijkheid van derden van hun aansprakelijkheid te ontslaan.

    @ookalex: Bij testen heb je inderdaad snel te maken met combinatorische explosie, vandaar dat je beter gebruik kunt maken van een wiskundig correctheidsbewijs. Zie mijn reactie op @DotnetCoder#13. En wat de ‘moving goalposts’ betreft, zie mijn reactie op @Jeroen#7. SQL is een beetje een ongelukkige uitvinding, die tegenwoordig massaal oneigenlijk gebruikt wordt. Het is in de jaren 70 van de vorige eeuw uitgevonden als een soort pseudo-natuurlijke taal, zodat de baas van Dilbert zelf kon intypen “Geef me alle werknemers van afdeling 13 die langer dan een jaar in dienst zijn”, zonder Dilbert te hoeven lastigvallen om daarvoor een programmaatje te schrijven. SQL had al lang in onbruik moeten zijn geraakt. Dat het tegenwoordig op zeer grote schaal gebruikt wordt in applicaties (dus niet door mensen achter een tekstterminal), is een historische vergissing van de programmeurs. De nieuwe EU-regels zullen dit waarschijnlijk duidelijk maken en leiden tot vervanging van SQL door een betere, wiskundig elegantere, datamanipulatie en -bevragingstaal.

    @Dani?l#21: Non-deterministische verschijnselen zijn een theoretische complicatie, maar het is te kort door de bocht om te stellen dat “de mechanismes niet werken” en dat wiskundige bewijsvoering alleen bedoeld is voor deterministische machines. Ik verwijs gemakshalve maar even naar ‘Correctness concerns and, among other things, why they are resented’, Edsger Dijkstra, 1975 (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD450.html), waarin hij elegant uitlegt dat een bepaalde vorm van non-determinisme theoretisch gezien geen enkel probleem is.

    @Arnoud#22: Ja, helemaal mee eens. meer dan de helft van de bugs die ik in mijn werk als software engineer ben tegengekomen vielen in de categorie “was te voorkomen geweest met formele methoden”. Je kunt heel diep zoeken naar redeneringen die bugs aanwijzen die niet op die manier te voorkomen zouden zijn, maar dat neemt het nut van formele methoden niet weg. Het zoeken naar grenzen van formele methoden is de ladder tegen de verkeerde muur zetten.

    P.S. Arnoud, de hippe feature van je weblog dat de previewtekst live wijzigt terwijl ik in het tekstvak type, crashte mijn browser! 🙂

  22. @ Arnoud, 20: prelex voor dingen bij de raad en commissie, oeil voor de behandeling in het Europees parlement.

    @ allemaal: het is de consumenten rechten richtlijn, dus het gaat niet om industriele systemen en vliegtuigbesturing. Verder gaat het om juridische conformiteit, dus zijn formele en wiskundige benaderingen niet relevant. Het zijn rechters die erover zullen moeten beslissen, dus tja. Mijn inschatting zou zijn dat als een programma het niet doet op een bepaalde systeemconfiguratie, je aan die mensen inderdaad geld terug moet geven (drivers en videokaarten enzo), maar alleen aan diegenen met dat systeem. Dingen als niet kunnen plakken/knippen op Windows Mobile lijkt me dan weer wel ‘defect’, omdat dat er tegenwoordig gewoon bij hoort. Om maar eens een andere invalshoek te geven.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.