Hoe verdeel je de eigendom van versgemaakte software?

| AE 6521 | Auteursrecht, Software | 11 reacties

software-code-binary-bits-bytesRegelmatig krijg ik vragen van softwareontwikkelaars en hun klanten over hoe om te gaan met het intellectueel eigendom op software die gemaakt is voor die klant. Hoe ga je daar nu mee om, hoe verdeel je die rechten op een manier waar beide partijen tevreden mee zijn.

Hoofdregel uit het auteursrecht is dat de partij die het werk maakt, de rechten daarop heeft. Huur je dus iemand in (een bedrijf of een freelancer), dan heeft deze de rechten. Niet de opdrachtgever. Ook niet als deze alle uren betaalt en/of als de software heel specifiek voor zijn situatie is ontwikkeld.

Wil je als opdrachtgever de rechten, dan moet je dat afspreken in de offerte. Achteraf opeisen kan ook, maar je staat dan een stuk zwakker. De ontwikkelaar hoeft dan niet akkoord te gaan met overdracht, dat was immers niet afgesproken. En iets verkrijgen dat niet afgegeven hoeft te worden, is onderhandelingstechnisch een lastige. Plus, wat moet dat kosten?

Een gebruikelijk compromis is maatwerk eigendom klant maken en het standaarddeel eigendom leverancier laten blijven. Zo kunnen zij door met het maatwerk, en kan de leverancier door met het standaardproduct naar andere klanten. Dit kan worden aangevuld met een verbod voor de leverancier om exact/vrijwel hetzelfde op te leveren voor een concurrent.

Nadeel voor de klant (en voordeel voor de leverancier) hiervan is dat de leverancier nu altijd nodig blijft om onderhoud aan de standaardsoftware te doen. Dat kan een leuke inkomstenbron zijn voor die leverancier, maar veel frustratie opleveren bij de klant. Zeker als de standardsoftware wordt uitgefaseerd of de ontwikkelaar gewoon geen zin meer heeft.

Van de ontwikkelaar eisen dat hij de rechten op de standaardsoftware afstaat, is niet redelijk. Hij maakte die immers om bij meerdere klanten in te zetten, en die optie wordt nu geblokkeerd.

Een alternatief kan zijn om te eisen dat de ontwikkelaar alleen werkt met open source. Daarvan is immers niet echt een eigenaar aan te wijzen, en bovendien heeft de klant dan altijd genoeg gebruiksrechten om er zelf mee te kunnen werken. Hij is dan leveranciersonafhankelijk. Maar lang niet iedere ontwikkelaar kan of wil werken met open source van derden.

Sommige juristen stellen dat je zou kunnen zeggen dat het totaalpakket eigendom van de klant kan worden, zonder dat de leverancier daarmee de onderliggende rechten verliest. Vergelijk dat iemand foto’s levert voor in een boek: de rechten op de foto blijven van de fotograaf maar het auteursrecht op het boek is van de uitgever daarvan. De uitgever mag het boek dan herpubliceren in bewerkte vorm zonder aparte toestemming van de fotograaf. Die analogie gaat echter niet helemaal op, want foto’s hoeven in een boek zelden aangepast te worden en bij standaardsoftware (zoals een CMS of framework) moet dat juist wél kunnen. Misschien als je zegt, het gaat hier om de ‘foto’ zoals aangepast voor maatwerkproduct X van klant Y. Een standaardpakket zal altijd iets moeten worden aangepast voordat het werkt bij klant Y.

Hoe dan ook, maak alsjeblieft vóóraf afspraken. En vraag door als klant: menig ontwikkelaar denkt dat als je zegt “je wordt eigenaar van de software” de klant daarbij begrijpt “behalve natuurlijk het framweork/cms dat ik erbij krijg, dat spreekt voor zich”.

Arnoud

Deel dit artikel

  1. De klant hoeft geen auteursrecht op het maatwerk te ontvangen, maar ik kan begrijpen dat hij heel graag een licentie (plus technische middelen) wil voor gebruik van en het maken van aanpassingen aan het gehele geleverde werk. Met een brede licentie waar het recht tot verspreiden en sub-licenseren expliciet bij de leverancier blijft, bereik je dat beide partijen krijgen wat ze nodig hebben.

  2. Open source software is nog steeds door iemand gemaakt, dus er is nog steeds sprake van autersrecht op de gemaakte software. Meestal is het zo dat er wel toestemming (een open source licentie) wordt gegeven voor het gebruik, aanpassen en verspreiden van de software. Door die licentie heeft de klant wel voldoende rechten om er mee te werken, maar de auteur van de betreffende code is nog steeds de eigenaar.

  3. Hoe zit het als een ontwikkelaar een standaard-product op de markt zet en een klant speciaal extra maatwerk biedt. Maar na 5 jaar besluit de ontwikkelaar over te stappen op andere ontwikkel-technieken en herschrijft hij het standaardproduct waardoor het extra maatwerk niet op het nieuwe product zal werken. Als vervolgens geen onderhoud meer plaatsvindt op het oude product dan zal de klant met zijn maatwerk weer fors moeten investeren om nieuw maatwerk te krijgen. Het lijkt mij dan ook belangrijk dat er afspraken worden gemaakt in geval van maatwerk bovenop een standaard-product. Ik denk dan b.v. aan de optie om de broncode van het standaardproduct te koop te bieden aan een andere partij die er dan alsnog mee verder kan gaan.

    • Iedere optie waarbij de rechten op maatwerk software bij de leverancier blijven liggen is een risico in Nederland, omdat bij failissement niets is af te dekken. Je kan wel een ‘eeuwig’ durende licentie op de source bedingen, maar de curator trekt die zonder met zijn ogen te knipperen in en stuurt je een rekening.

      Als de software bedrijfskritisch is en maatwerk, moet je gewoon de rechten hebben als je zekerheid wil.

      Waar dit natuurlijk fout gaat is dat iedere ontwikkelaar die je inhuurt een toolkit met wat standaard functies zal hebben. En die wil hij ook bij volgende opdrachten nog kunnen gebruiken. Is het mogelijk om het auteursrecht op beider naam te zetten of kan geen van beide dan nog zelfstandig beslissen? Of misschien de auteursrechten in een stichting onderbrengen die lcenties geeft aan beide partijen. Dan ben je bij faillisement in ieder geval gedekt lijkt mij. Zolang 1 van de partijen de stichting blijft financieren en de licentie overeenkomst met de stichting is.

  4. Niet geheel direct een reactie op een artikel, maar wel in aansluiting hierop: hoe is software toch ooit in zijn geheel onder het auteursrecht terecht gekomen? Dat de gebruikersinterface/look-and-feel onder het auteursrecht valt, vind ik logisch en ook de uitvoer van een computerprogramma kan een auteursrechtelijk beschermd werk opleveren, mits daar voldoende menselijke creatieve input bij komt kijken. Maar de code zelf is voor mijn gevoel een ingenieursding, niet het soort creatieve arbeid waarvoor het auteursrecht geldt. Een architect heeft toch ook alleen auteursrecht op het ontwerp van zijn gebouw en niet op de constructie?

    Misschien heeft iemand een link naar een artikel waarin de geschiedenis hiervan en de redenatie erachter wordt uitgelegd?

  5. Maar lang niet iedere ontwikkelaar kan of wil werken met open source van derden.

    Dat kan ik me wel voorstellen: de kwaliteit van broncode kan heel sterk variëren, en verder voortborduren op slecht geschreven software is erg vervelend en lastig, en je kunt ook nog eens de schuld krijgen van problemen die daaruit volgen.

    Misschien wil je al tijdens het ontwikkelingsproces een peer review van de code hebben? Dan zouden de reviewende partijen direct kunnen aangeven of ze de code in de toekomst zouden willen ondersteunen. Aan de andere kant: je wilt natuurlijk absoluut geen “design by committee”, dus reviews moeten continu gefocust zijn op eenvoud, en niet op features. Lastig, lastig…

  6. Dit is een verhaal wat herkenbaar is en afgelopen week ook weer bij ons speelde.

    Het komt vaak voor dat een klant het idee heeft bij maatwerk (aangezien hij / zij er vaak flink voor betaalt), de software ook eigendom wordt (“het is toch voor mij gemaakt”). Strikt genomen is dat natuurlijk onhandig als je componenten en code over meerdere projecten wilt gebruiken en hierover het eigendom overhevelt naar de klant. Daarnaast kun je die claim niet maken op Open Source software. Als je vervolgens uitlegt dat de software exclusief voor de klant is, maar je de mogelijkheid wilt hebben om alle componenten naar eigen inzicht op andere projecten ook in te zetten, is dit over het algemeen geen probleem. Alleen blijft dit voor veel klanten toch een punt van veel discussie in het offertetraject. Ik ben bang dat dit altijd een puntje van uitleg zal blijven (zeker bij de klanten die iets minder gevoel voor software hebben).

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS