Ben ik nog aansprakelijk als ik het IE op mijn software overdraag?

software-disc-cd-dvd-dragerEen lezer vroeg me:

Voor een klant heb ik maatwerksoftware ontwikkeld. Zij willen nu het intellectueel eigendom daarop verkrijgen. Op zich prima, alleen wil ik dan geen aansprakelijkheid meer voor fouten. Ik heb er dan immers geen controle meer over. Daar reageerden ze heel verbaasd op. Maar dit is toch geen gekke vraag?

Nee, een gekke vraag is dit niet. Maar ik kan me de verbazing ook wel weer een beetje voorstellen.

Aansprakelijkheid en intellectueel eigendom staan in principe los van elkaar. Aansprakelijk ben je als je een fout maakt in de opdracht, en dat heeft niets te maken met wie eigenaar wordt van de auteursrechten op het resultaat.

De verwarring hier gaat volgens mij over fouten die de opdrachtgever aanbrengt nadat de software klaar is. Wie het auteursrecht verwerft, mag ook zelf gaan knutselen in het geleverde. Maar het is natuurlijk evident dat je de leverancier niet aansprakelijk kunt houden voor je eigen fouten. Dit heeft niets te maken met eigendom op het werk. Als ik een huis laat bouwen, is de aannemer aansprakelijk voor fouten terwijl ik er eigenaar van ben. Hetzelfde gebeurt bij auteursrechten.

Het lijkt me wel verstandig dit even uit te werken in het contract, om bewijsproblematiek te verkleinen. Je zegt dan bijvoorbeeld dat iets alleen een fout is als het ook zit in de code zoals overgedragen. Je hebt dan een manier nodig om vast te leggen exact welke code dat is. Denk aan een hash, een lijst bestandsnamen met datum en grootte of het nummer van een github-repository.

Arnoud

8 reacties

  1. Een secure hash van een archief-bestand (zip-bestand, disk image o.i.d.) met daarin de opgeleverde software lijkt me een betrouwbare manier om vast te leggen welke software je hebt opgeleverd. Zorg er wel voor dat je zelf een kopie houdt van de opgeleverde software, vanwaaruit je de hash kunt reproduceren. Dan kan je altijd achteraf, zonder afhankelijk te zijn van de opdrachtgever, inhoudelijk uitzoeken of een fout wel/niet al in de opgeleverde versie zat.

    Het lijkt me dat het gehaste bestand dan wel de broncode moet bevatten. Sowieso lijkt het erop dat de opdrachtgever met de broncode verder wil (dus moet je de broncode opleveren), maar de broncode is ook nodig om (relatief makkelijk) te demonstreren of een fout wel/niet in de opgeleverde software zit.

  2. Het lijkt me vanzelfsprekend dat je niet aansprakelijk bent voor gevolgen van aanpassingen aan de software die de opdrachtgever later zelf doet, maar is het niet mogelijk om contractueel vast te leggen dat je ook niet aansprakelijk bent voor gevolgen van de software die je wel zelf hebt opgeleverd? Het overdragen van die aansprakelijkheid lijkt me geen vanzelfsprekendheid, maar dat is het overdragen van auteursrecht ook niet. Je zou het toch als uitruil-punt op de onderhandelingstafel kunnen brengen? Of zitten er juridische haken en ogen aan het afwijzen van je eigen aansprakelijkheid?

    1. Ik mag hopen dat je contractueel kunt vastleggen dat de ontwikkelaar van [software|product] niet aansprakelijk is voor de gevolgen daarvan op het moment dat de opdrachtgever vrij is in hoe [het product|de software] gebruikt wordt.

      Als ik hamers verkoop mag de klant verwachten dat je ermee kunt timmeren. Niet dat ze geschikt zijn als breekijzer. Als ik een complexe machine ontwikkel voor een stroopwafelfabriek, accepteer ik geen aansprakelijkheid voor de gevolgen bij gebruik van die machine in een medische toepassing. En als ik een app (software!) ontwikkel om kleuren te tonen op een mobieltje, dan wil ik niet aansprakelijk zijn als de klant het gebruikt voor lichttherapie.

  3. Het probleem is dat er nu fouten in de software kunnen zitten die geen problemen opleveren.

    Functie A doet X Functie B roept functie A aan. Alles gaat goed.

    Klant schrijft nieuwe code die functie X nodig heeft. Functie C roept functie A aan. Functie C genereert een randgeval waarin functie A niet X doet, omdat dit nooit onderkent is als een mogelijkheid.

    Wie is aansprakelijk de schrijver van Functie A? Daar zit immers de fout, die zegt X te doen, maar doet dat niet altijd.

    En dit is geen gezocht voorbeeld, ik heb dat al heel vaak zien gebeuren. Als een ander de ontwikkeling overneemt prima, maar dan ook de verantwoordelijkheid voor dit soort fouten.

    1. Vanuit de juridische kant bekeken: Wat is er tussen opdrachtgever en ontwikkelaar afgesproken? Levert de ontwikkelaar een applicatie, dan moet functie A het correct doen in de context van de geleverde applicatie (en moet de opdrachtgever de problemen zelf oplossen.) Is afgesproken dat de ontwikkelaar een bibliotheek (met gespecificeerde API) oplevert, dan hoort A zich aan de gedocumenteerde interface te houden en kan de ontwikkelaar aangesproken worden op de fout.

      Wat je bij maatwerk heel vaak ziet is dat er een “acceptatie” wordt afgesproken (wanneer de software als “goed genoeg” is getest) met daarna een garantie-periode, waarbij de ontwikkelaar de fouten die in de garantie-periode gevonden worden gratis oplost. Dit voorkomt dat een ontwikkelaar jarenlang lastig gevallen wordt om fouten te verhelpen.

    2. Inderdaad en ik heb het gevoel dat velen de zaak onderschatten. Hoe goed mensen hun best ook gedaan hebben en hoeveel er ook getest is, in software van enige grootte zitten in de huidige praktijk altijd fouten (e.g. ook: een functie is niet 100% consistent met zijn beschrijving, fouten worden pas zichtbaar bij gebruik van snellere of langzamere hardware of bij een upgrade naar een compiler die wel correct is, iemand heeft een stukje code zonder licentie of test hergebruikt, etc, etc.).

      De koper van jouw auteursrecht ziet verder wellicht kansen om de software veel breder te gaan gebruiken dan nu het geval is en de kans op ongewenste gevolgen en de impact daarvan kan daarmee heel hoog worden. Het risico bij software is m.i. ordes hoger dan bij een boek, liedje of filmpje. Het lijkt me zeer wenselijk dat je je daar als verkoper goed tegen kunt wapenen, en je aansprakelijkheid kunt inperken.

      Zou je in het contract bijvoorbeeld een of meer van volgende kunnen opnemen: 1. dat te verwachten is dat er (vele of significante) fouten in de levering kunnen zitten 2. dat koper bij verder gebruik een aantal extra stappen moet doorlopen (uitgebreide verificatie- en validatie-instructies o.i.d.; bijv. dat koper periodiek moet evalueren of de software in huidige context nog voldoende veilig is en aan zijn doel voldoet). 3. dat koper binnen x tijd een uitgebreide check moet doen op werking en consistentie van de levering en verkoper gelegenheid moet geven die te herstellen (misschien kun je fouten toevoegen om helder te krijgen hoe goed dit is gedaan) 4. dat koper de bron-code niet publiek mag maken 5. dat bij overtreding van zulke punten de aansprakelijkheid bij de koper ligt? 6. iets anders?

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.