Welk onderhoud mag je op andermans software plegen?

Mag je als derde andermans software onderhouden? Die vraag lijkt juridisch triviaal – nee – want voor onderhoud moet je de software wijzigen, en dat mag niet zonder toestemming (licentie) van de rechthebbende. Maar er is een wettelijke uitzondering voor een rechtmatig gebruiker, en in een recente rechtszaak kwam eindelijk de vraag eens langs hoe ver die uitzondering reikt. En helemaal bijzonder: het auteursrecht was ondertussen bij een derde terechtgekomen.

De leverancier van een niet nader genoemd softwarepakket ging op zeker moment failliet, waarna de auteursrechten op die software door het bedrijf Rainbow werden gekocht uit de boedel (activatransactie). De software verzorgt de afwikkeling van het totale logistieke proces van een transportonderneming. Met de software kunnen bedrijven onder andere transportopdrachten innemen, orders opmaken, factureren en ritten plannen.

Twee andere bedrijven boden al een tijdje onderhoudscontracten op die software, en werden door Rainbow aangesproken dat ze daarmee op moesten houden omdat dit in strijd zou zijn met het verkregen auteursrecht. Maar daar staat tegenover dat de wet (art. 45j Auteurswet) zegt:

Tenzij anders is overeengekomen, wordt niet als inbreuk op het auteursrecht op een werk als bedoeld in artikel 10, eerste lid, onder 12°, beschouwd de verveelvoudiging, vervaardigd door de rechtmatige verkrijger van een exemplaar van eerder genoemd werk, die noodzakelijk is voor het met dat werk beoogde gebruik. De verveelvoudiging, als bedoeld in de eerste zin, die geschiedt in het kader van het laden, het in beeld brengen of het verbeteren van fouten, kan niet bij overeenkomst worden verboden.

Wie ooit rechtmatig de licentie kocht bij het inmiddels failliete bedrijf, is een “rechtmatige verkrijger” in de zin van dit artikel. En die mag dan ook het onderhoud uitbesteden. Daarmee zou het handelen van de gedaagden dus legaal zijn.

Complicatie is dus echter dat de werkzaamheden “noodzakelijk” moeten zijn en wel “voor het beoogde gebruik”. En dat is bij deze software lastig, omdat nergens op papier vastgelegd was wat nu precies het beoogde gebruik was. Dit moet nu in een nieuwe zitting apart worden behandeld. En dat kan nog een kluif worden, omdat eigenlijk niemand weet wat deze bepaling nu eigenlijk bedoelde te zeggen. Software gebruik je meestal voor een heleboel doeleinden, vaak niet voorzien bij het aankopen. Dus hoe moet je dat dan interpreteren?

Arnoud

6 reacties

  1. Beoogd lijkt mij minimaal wat in reclame uitingen van de maker vermeld staat over de software. Dit met inbegrip van e-mails rond de software en de website. Andere zaken aannemelijk maken lijkt mij lastiger.

  2. Het is de combinatie van “noodzakelijk” en “beoogd gebruik” die het een lastige afweging maakt. De eerste platitude is dat leverancier en gebruiker veelal verschillen van mening over wat het beoogde gebruik is, met name waar het over de details gaat. Geldt hier de (redelijke) mening van de leverancier of de (redelijke) mening van de gebruiker? Iets meer concreet, mag de gebruiker van de software de software (laten) aanpassen om het op zijn specifieke bedrijfsprocessen aan te laten sluiten of moet de gebruiker zijn bedrijfsprocessen aanpassen aan de ideeën van de softwaremaker?

    Laten we even aannemen dat de gebruiker wijzigingen mag (laten) aanbrengen om de software aan zijn bedrijfsproces aan te passen, moeten we “noodzakelijk” dan interpreteren als “minimaal” of “een redelijke manier om de benodigde functionaliteit aan te brengen”? Het wordt interessant om deze rechtszaak te volgen.

    1. Ligt het door het gebrek aan documentatie niet aan de leverancier dat er geen beoogd gebruik is? De gebruiker verzint altijd wel hoe hij het kan gebruiken. Het zou me niet verbazen als er gewoon wordt vastgesteld hoe de gebruiker het nu gebruikt, en dat onderhoud dan alleen die functionaliteit mag behouden en niet mag uitbreiden of andere functionaliteit mag toevoegen. Als er functionaliteit is die aantoonbaar niet in het origineel zat, zou je dat nog kunnen schrappen.

      1. De term “beoogd gebruik” kun je vanuit klant-perspectief vertalen met “gewenst gebruik”. Als de klant A wil kunnen en dat ligt op het vlak van wat de applicatie ondersteunt, dan kun je beargumenteren dat de klant A mag implementeren in de applicatie.

  3. Staat er in de wetsbepaling niet gewoon dat je mag back-uppen ten behoeve van de continuïteit van het gebruik? En blijven “fouten” die daarmee hersteld kunnen worden dan niet beperkt tot herstel van de onderliggende bestanden of ingestelde parameters die na een incident verloren zijn gegaan? En is het feit dat kopieën van de broncode buiten de boedel zijn geraakt niet sowieso onrechtmatig? Tot de door gebruikers verkregen licenties hoort normaal gesproken alleen een versie in door een computer leesbare taal.

  4. In de Memorie van Toelichting lees ik:

    In de aan de richtlijn voorafgaande overwegingen wordt gesteld dat een beperkte uitzondering moet worden gemaakt op de exclusieve rechten van de auteur teneinde de reproduktie toe te laten die technisch noodzakelijk is voor het gebruik van dat programma door de rechtmatige verkrijger.
    en
    Verveelvoudigingen die ertoe strekken fouten die in de programmatuur zijn geslopen te verbeteren vallen onder deze uitzondering. Deze verveelvoudigingen dienen ertoe de rechtmatige gebruiker in staat te stellen om de programmatuur operationeel te houden.
    Lijkt erop dat het artikel bedoeld is om te zorgen dat de programmatuur technisch kan blijven draaien. Op grond hiervan zou ik verwachten dat de wettelijke uitzondering zeer restrictief toegepast wordt.

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.