Eurocommissarissen willen garantie op software

Meer dan driehonderd reacties bij het Tweakers-bericht dat Eurocommissarissen Viviane Reding en Meglena Kuneva een voorstel hebben gelanceerd om de consumentenbescherming bij de aankoop van fysieke goederen uit te breiden naar software. “De softwaremakers zijn hier niet erg blij mee.” Joh, echt?

In de zogeheten digitale agenda van de Europese Commissie staat een voorstel om consumenten die software in licentie nemen, dezelfde rechten toe te kennen als software die fysieke producten kopen. Zulke producten moeten gedurende hun economische levensduur voldoen aan de “redelijkerwijs gewekte verwachtingen” (de conformiteitseis), en dat zal dan ook voor software gaan gelden. Of eigenlijk voor alle producten die je onder licentie afneemt als ik het goed lees, dus ook voor bijvoorbeeld gedownloade muziek of abonnementen op webdiensten.

Een goede zaak, wat mij betreft. De software-industrie heeft al veel te lang kunnen doen alsof software inherent buggy is en dat men daarom geen enkele garantie kan geven. Onzin; met goede ontwikkel- en programmeertechnieken zijn heel veel bugs te voorkomen, en er zijn genoeg tools om vrijwel alle resterende bugs te ondervangen bij het testen. Maar ja, dan moet je gestructureerd werken en controleren en specificeren wat je wilt, en dat valt niet voor alle programmeurs mee.

Natuurlijk, de kans is aanwezig dat die software dan duurder wordt. Maar dat hoeft niet. Met duidelijke disclaimers en informatie over de beperkte functionaliteit kun je ook de redelijke verwachting van consumenten bijstellen. Zet op je auto “Dit is een wrak en u kunt er niet mee rijden” en de consument heeft bar weinig wettelijke rechten meer.

Ik heb nooit begrepen waarom softwarebedrijven zo onwillig zijn om meer garanties af te geven, of gewoon te aanvaarden dat ze fouten moeten repareren in hun software. Bij ZDNet draait de Business Software Alliance zich bijvoorbeeld in alle mogelijke bochten om maar niet te hoeven zeggen dat dit eigenlijk gewoon hartstikke logisch is:

creators of digital content cannot predict with a high degree of certainty both the product’s anticipated uses and its potential performance.

De makers van televisies ook niet, maar toch slagen die erin een televisie te maken die niet elke maand antivirusupdates nodig heeft of elke maandag gereset moet worden.

Ook de overige argumenten zijn pure kul. Je keuzevrijheid als consument zou worden ingeperkt omdat je een contract voor 2 jaar (de minimale conformiteitstermijn) zou moeten aangaan: zulke consumentencontracten zijn op elk moment opzegbaar. De eis zou ook voor beta’s gelden: onzin, bij een beta weet je dat je bugs kunt verwachten en dan kun je geen aanspraak op correctie daarvan maken. Compatibiliteit komt in gevaar: hoezo, als de combinatie van twee producten tot onverwachte neveneffecten leidt dan is dat mijn risico tenzij de leverancier me die combinatie aanraadt?

Ook open source zou in gevaar komen, want ook daar zou je conformiteitseisen kunnen leggen. Dat hangt er vanaf, levert een bedrijf me tegen betaling die software of pluk ik het zelf van internet? In het laatste geval dien je meer risico voor lief te nemen, net zo goed als wanneer je een product bij een tweedehandswinkel koopt in plaats van bij de officiële dealer. En trouwens, sjonge, sinds wanneer maakt de BSA zich zorgen over het welzijn van open source?

Update (20:21) daarnet mocht ik op de radio bij BNR Juridische Zaken vertellen over wat de Commissie van plan is en wat voor gevolgen dit zal hebben. “Maar we zijn niet allemaal Engelfrietjes”. Ahem.

Arnoud

20 reacties

  1. Lijkt inderdaad logisch, hoewel het maken van geavanceerde software moeilijker (b)lijkt dan het maken van een goede tv.

    Klein tikfoutje:

    dezelfde rechten toe te kennen als software die fysieke producten kopen.

    software moet denk consumenten zijn.

  2. Ik denk dat het inderdaad goed is de reactie van de BSA met een flinke korrel zout te nemen. En dat het goed zou zijn als softwareproducenten op zijn minst verplicht werden om bugs en kwetsbaarheden snel te fixen.

    Maar de vergelijking met een TV gaat denk ik veel te ver, vooral daar er een miljoenen’industrie’ bezig is met het zoeken naar dergelijke bugs (om er vervolgens misbruik van te maken). Soms worden die snel gevonden. Soms drie jaar nadat het product uitgebracht is. Kun je in het laatste geval nog zeggen dat de ontwikkelaars beter hadden moeten testen?

    Ik denk bovendien dat het niet goed is als de consument denkt dat software volledig bugvrij kan zijn, want dat zal tot veel onvoorzichtigheid leiden.

    (In hoeverre denk je trouwens dat dit er toe gaat leiden dat alle software –ook de commerci?le– met een “werking niet gegarandeerd, gebruik kan ernstige schade aan computer en/of bankrekening opleveren” disclaimer komen?)

  3. Maar wat is precies het effect op open source software? Een programma waar ik aan meewerk bevat de disclaimer “This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.” Hoe rechtsgeldig is dat nog? Krijg ik straks claims als mijn software data van de gebruiker kwijtraakt, door een fout van deze software? (Dat wil zeggen, waar ligt het “meer risico” dat je beschrijft?)

    Verder ben ik het wel eens met de strekking van je stuk (fabrikanten moeten goede software afleveren en niet miepen over hoe moeilijk het wel allemaal niet is), maar je bagatelliseert naar mijn idee wel een beetje de complexiteit van software development. Ik weet niet hoeveel ontwikkel-ervaring je zelf hebt, maar goede ontwikkel- en programmeer-technieken zijn (tenzij in extreme, zoals bij NASA — en dan enorm duur) geen panacea, en ook tools helpen maar voor een zeer beperkt deel bij het vinden van bugs.

    Overigens zou ik zeggen dat dit probleem hem vooral zit in een groot tekort aan goede ontwikkelaars en aan de druk van de markt op de prijzen (en tussen beide zit vast ook wel een causaal verbandje).

  4. Beste Arnoud, dank voor deze post.

    Ik ben van mening dat je het hier volledig bij het juiste eind hebt. Zelf heb ik 10+ jaar ervaring in softwareontwikkeling, waarbij ik over het hele spectrum van embedded software en low level device drivers tot aan enterprise-grade telecommunicatie en data management software actief ben geweest als ontwerper/programmeur (in meer talen dan ik vingers heb).

    Hoewel ik allerminst kan beweren dat (goede) software schrijven een simpele opgave is, integendeel, ken ik ook geen enkel vakgebied dat zo onrealistisch overschat en overgewaardeerd wordt als dat van softwareontwikkeling. Met name de overwaardering van de producten van grote software- en automatiseringsbedrijven, meestal het gevolg van een ijverige marketing/verkoop afdeling, is in veel gevallen ronduit stuitend als je kijkt naar hun (ontbrekende) aansprakelijkheid.

    Ik vind het tekenend dat veel tegenstanders keer op keer potenti?le situaties aanhalen die buiten de redelijkheid vallen. Enerzijds lijken ze dit nodig te hebben om hun weerzin te rechtvaardigen, maar daarmee diskwalificeren ze volgens mij tevens hun argumenten. Het voorstel stelt, als ik het goed begrepen heb, namelijk dat je alleen aansprakelijk bent voor wat redelijkerwijs verwacht zou mogen worden. Met andere woorden, als je er als fabrikant voor kiest om zo min mogelijk aan bugsfixes te werken teneinde een zo hoog mogelijke winst te behalen, dan zit je fout. Probeer je in de eerste plaats een deugdelijk product te maken waarbij financieel gewin geen compromitterende factor is, dan zit je volgens mij goed.

    Ik denk dat dit voorstel (op den duur) zeer goed voor de software industrie is. Misschien niet voor de vele matige tot slechte programmeurs, waarvan er met name in grote bedrijven nog al wat rond lopen. Zeker ook niet voor bestuurders die softwareontwikkeling, en de bijna magische staat die het bij veel mensen heeft die er geen verstand van hebben, zo veel mogelijk uitbuiten voor enkel financieel gewin. Hoe eerder de markt gezuiverd wordt van dergelijk volk des te beter. Ze hebben de markt reeds lang genoeg kapot gemaakt. De huidige stand van zaken leidt in ieder geval tot een ronduit schrikbarende kapitaalvernietiging die uiteindelijk toch echt zijn oorsprong vindt in ondeugdelijke software. Dat niemand daarvoor verantwoordelijk gehouden kan worden lijkt mij onacceptabel.

    Tot slot, Open Source is met name in gevaar daar waar het ondermijnd wordt door commerci?le belangen (Oracle/Novel/Microsoft?). Bij de community projecten spelen commerci?le of andere functionaliteit compromitterende belangen meestal een ondergeschikte rol. Ik vraag me dan ook af hoe je een dergelijk project van onredelijkheid zou kunnen betichten waar het gaat om het verhelpen van bugs.

  5. Eerlijk gezegd denk ik dat de hele industrie redelijk verziekt is (en ik werk nog wel in die industrie).

    Voorbeeld uit de vliegtuig industrie een specialisatie die heeeeel veel controles toepast: bij aanschaf van een JSF-vliegtuig door Japan, vliegt het toestel van de VS naar Japan en bij het oversteken van de tijdsgrens vallen alle (dubbel uitgevoerde) systemen uit en moet het vliegtuig terugkeren met behulp van andere vliegtuigen voor de navigatie.

    ‘geweldig’ staaltje van goed gecontroleerde software. 😉

    Op dit moment zie ik eerder gebeuren dat er gewoon meer ‘cover your ass’-management wordt toegepast, daar hebben we namelijk heel geavanceerde vormen van in deze industrie en dat het voor de consument niks oplevert. Er komt iemand voor een rechter en die zegt: kijk onze grootte dikke stukken papier over hoeveel we wel niet hebben gecontroleerd, dat die bug niet is gevonden is pure pech.

    Wanneer is een manier van werken, controleren en testen goed genoeg ? Wie bepaald dat ? Een rechter ?

  6. @Jakob Buis: De regeling gaat (mogelijk/waarschijnlijk) gelden voor software die door EUropese consumenten gekocht wordt bij een EUropese leverancier. De EU kan deze regeling is niet afdwingen buiten de EU (of de EEZ), wat betekent dat het iets is waar de importeurs rekening mee moeten houden.

    @elmo: mooi verhaal en 100% met je eens. Ik wil toevoegen dat bedrijven die serieus aan kwaliteitsmanagement doen vaak effici?nter werken (meer produceren voor hetzelfde geld) dan bedrijven waar een “hack en crash” mentaliteit heerst.

  7. Hoe hoger de eisen aan de software, des te langer de ontwikkelingsduur. Het feit is dat in veel situaties “redelijk werkend” goed genoeg is. En in tegestelling tot bij een televisie, kun je bij software nog gemakkelijk achteraf verbeteringen aanbrengen, door updates. Goede ontwikkelaars hebben helpt wel, maar de meeste ontwikkelaars zijn niet goed, en zullen dat ook nooit worden. Goede tools hebben helpt ook, maar er zijn nog geen tools die zo goed zijn dat ze matige ontwikkelaars het werk kunnen laten doen van goede ontwikkelaars. En ik verwacht ook niet dat die er in de nabije toekomst zullen komen. Dat neemt niet weg dat er geen goede tools beschikbaar zijn die de software in ieder geval beter kunnen maken dan dat het nu is. En aan de andere kant zou software beter worden als bepaalde tools die slechte software in de hand werken en die nu gebruikt worden, zouden worden afgeschaft. Ik zie eigenlijk wel wat in een verbod op Perl. 😉

  8. Zelf hoop ik al jaren op betere software. In allerlei embedded doosjes, zoals consumentenelectronica, is deze software vaak erg beroerd (crashes, grove beveiligingsfouten, enzovoort) en veel bedrijven willen of kunnen niet eens beveiligingsupdates maken omdat ze de technische kennis niet hebben, of omdat het gewoon veel en veel te duur is om te doen (consumentenelectronica is een markt met hele lage marges en veel concurrentie).

    En, zelfs al doen ze het, waar leg je de verantwoordelijkheid van de fabrikant en waar die van de consument. Als er een firmware update is, hoe verplicht je de consument deze dan te installeren (zonder een autoupdatemechanisme, dat eventueel weer andere dingen kapot maakt)? Binnen wat voor termijn moet de consument een firmware geinstalleerd hebben zodat de consument en niet de fabrikant aansprakelijk is (als er al 1 jaar een firmware update is bijvoorbeeld). Daarnaast, hoe kwantificeer je kwaliteit?

  9. Goeie, MathFox!

    Wat me opvalt in veel van de berichten (bij Tweakers, Slashdot en elders) is dat men er vanuit gaat dat “conformiteit” gelijk staat aan “perfectie”. Software zou geen bugs meer mogen hebben, of als die er wel zijn dan kun je torenhoge claims leggen. Dat lijkt me niet de bedoeling van dit wetsvoorstel.

    Auto’s, televisies en andere zaken zijn ook niet perfect. De vraag is wat je mag verwachten. Blijkt het maken van software inherent foutgevoelig, dan moet je daar als consument rekening mee houden. Denk aan het gedoe over dode pixels in LCD-schermen. In het begin moest je daar rekening mee houden, tegenwoordig eigenlijk niet meer.

  10. “Maar ja, dan moet je gestructureerd werken en controleren en specificeren wat je wilt, en dat valt niet voor alle programmeurs mee.”

    Zullen we het dan maar niet over de opdrachtgevers hebben?

  11. Goed artikel, ik stond er heel negatief tegen over. Maar dankzij jouw ben ik nu een stuk positiever!

    Ik word er zelf gek van dat je soms 100e euros uitgeeft aan software en dan vervolgens tot de conclusie komt dat het niet goed werkt… Ja met updates, maar sommige van die bugs zouden er niet eens in mogen zitten!

    Toen ik opzoek was naar een UML editor heb ik mijn oog laten vallen Enteprice Argitect (EA). Mooi programma, niets mis mee (gebruiksvriendelijk is een ander verhaal).

    Totdat ik een SQL Tabel wilden maken. Ik koos het typen PostgreSQL, maar misten een groot aantal opties. Zo ondersteund het geen serial date-type en worden Sequences niet ondersteund (MAX(veld)+1 gebruiken ze, WTF?!)

    Dus toen in de SQL liet genereren, maakt hij het date-type integer. SQL bestand ge-opent, integer vervangen voor serial. En met EA terug laten syncen naar UML.

    Wat denk je? Ik kan het data-type niet veranderen en programma liep vast!! Was gelukkig een trial, maar ze vragen wel meer 600 euro voor die software, schande!

    Een ander verhaal met Zend Studio for Eclipse waar ik ook de nodige worstelingen mee heb gehad. En sinds de laatste versie nu eindelijk een beetje naar behoren werkt.

    En als klap op de vuurpijl, Windows 🙂 Maar dat is algemeen bekend.

  12. Ik kan me de frustratie van (mede)gebruikers van buggy software voorstellen, maar vind als leverancier dat er in deze discussie toch aan een paar belangrijke punten voorbijgelopen wordt. Daaronder deze:

    • Wanneer het om standaardsoftware gaat, wordt er geen ‘software geleverd’. Geleverd wordt alleen een gebruikslicentie en eventueel een drager. Je verkrijgt bv. niet het recht de software te verveelvoudigen (anders dan voor een eigen backup), te wijzigen, te exploiteren, enzovoort – je betaalt slechts voor het recht om de programmatuur te mogen gebruiken. Dat die gebruikslicentie uitstekend werkt, zal iedere leverancier je natuurlijk met alle liefde garanderen.. 0:-)

    • In die zin is software vergelijkbaar met een boek of DVD; de inhoud kan soms tegenvallen, maar je hebt het ermee te doen. Zonder al te filosofisch of romantisch te willen worden: software is een product van de geest, het heeft ‘artistieke’ aspecten en is niet alleen het product van rechtlijnige wetenschap waar velen het voor houden. Bovendien, wat de ??n een bug of ontwerpfout noemt, is soms een nuttige of zelfs noodzakelijke feature.

    • Zelfs als een programma de volkomen perfectie bereikt heeft, zullen er altijd talloze systemen zijn waarop het niet of niet goed draait door omstandigheden waar de maker geen enkele invloed op heeft. Ik kan zonder aarzeling stellen dat de meeste problemen waar gebruikers van onze producten (installed base: miljoenen) tegenaan lopen, te maken hebben met bugs, onvoorzienbare of ongedocumenteerde wijzigingen en ondoordachte ‘features’ in o.a. Windows, antivirus- en andere beveiligingssoftware, Explorer-extensies, drivers, etcetera – om nog te zwijgen over ongebruikelijke instellingen of andere omstandigheden en onoordeelkundig gebruik. Als we daar steeds aansprakelijk voor worden gesteld kunnen we dagelijks nodeloos naar de rechtbank om aan te tonen dat e.e.a. op een schoon systeem (ooit noemden we dat een “IBM-compatible P.C.”, maar zo’n toetssteen bestaat niet meer) prima werkt, maar dat onvolkomenheden bij de gebruiker roet in het eten gooien. In software zijn oorzaak en gevolg helaas zelden evident, zeker voor leken.

    • Tot slot: Is wetgeving wel zo nodig en zou het productief zijn? Het is allereerst in het commerci?le belang van producenten om goede software te leveren, en door de toegenomen concurrentie is de kwaliteit, ondanks de enorm toegenomen complexiteit en sterk gedaalde prijzen, al met sprongen vooruitgegaan. Ten tweede is het een heel transparante markt die volledig op internet ‘leeft’; google een productnaam en je krijgt een uitputtend overzicht van professionele reviews, gebruikerservaringen, problemen en oplossingen, etc. Je kunt evaluatieversies downloaden, supportforums bezoeken, met de makers corresponderen en desgewenst nagaan of er een niet-goed-geld-terug garantie geboden wordt. Mij dunkt genoeg mogelijkheden om problemen te voorkomen. Als consument van software, met tientallen betaalde applicaties, kan ik stellen dat ik nooit een miskoop heb gedaan, op een enkele keer na waarbij ik mijn huiswerk niet gedaan had en veronderstelde dat de software dingen zou kunnen doen, die het bij nader inzien niet kon. Een kwestie van verkeerde verwachtingen en te weinig onderzoek. Natuurlijk heb ik in mijn 25 computerjaren ook heel wat problemen en bugs moeten overwinnen, voor mijzelf en zeker ook voor klanten, maar dat is en blijft inherent aan computergebruik – daar zullen geen 1000 pagina’s wetgeving iets aan kunnen veranderen. Waar ik wel voor vrees, is dat wetgeving zoals deze het bestaan van met name kleine, innovatieve ontwikkelaars en hun verkopers, die onder de huidige wetgeving al nauwelijks voor aansprakelijkheid verzekerbaar zijn, practisch onmogelijk zal maken (ik voorzie talloze gefingeerde schadeclaims na iedere ontdekking van een obscure bug), en dat het zo een domper zal zetten op de vernieuwing en concurrentie die nu juist de belangrijkste krachten achter de beoogde productverbetering zijn.

  13. “Bovendien, wat de ??n een bug of ontwerpfout noemt, is soms een nuttige of zelfs noodzakelijke feature.” Ik noem een update functie die de geest geeft geen noodzakelijke feature 😉 (en nee dit was niet mijn schuld, ik heb de software schoon ge?nstalleerd. alles werkten ik deed updaten. en poef! de update functie werkt niet meer.)

    En een voor mij ‘noodzakelijke feature’ is bij Windows Vista compleet verdwenen. Vroeger kon ik instellen met welke programma in een bestand wilde openen en de bestands-icon aanpassen. Dat laatste is nu niet langer mogelijk. Ik kan hem wel instellen, maar het geld dan voor alle bestanden die ik met dat programma open. Ik stel mijn PHP en CSS bestanden zo in dat ik deze open met notepad++. Maar ik kan niet langer een appart icon per bestandstypen instellen!! Een bug? nee gewoon het verwijderen van zeer handige feature…

    Of zoals MS zou zeggen: ‘it’s a feature not a bug.’

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.