Management

Juridische zaken

Verwarring auteursrecht software

18 januari 2012

Goede bescherming van software begint al voordat de programmeur de eerste slag op het toetsenbord maakt. Met name bij het uit handen geven van softwareontwikkeling is voorzichtigheid geboden.

De auteurswet neemt als uitgangspunt dat de persoon die bepaalde software maakt daar ook de auteursrechthebbende van is. Als die persoon een werknemer is die in de uitoefening van zijn functie de software maakt, wordt zijn werkgever op grond van de wet aangemerkt als auteursrechthebbende. Overigens is het wel verstandig om in de arbeidsovereenkomst aandacht te besteden aan de omschrijving van de functie en de werkzaamheden want wat de werknemer daarbuiten maakt, komt niet aan zijn werkgever toe. Het is vooral opletten als er bij de ontwikkeling van software externe partijen worden ingehuurd, zoals freelancers, gedetacheerden of bedrijven. In de meeste gevallen zullen de auteursrechten namelijk op grond van de wet bij die externe partijen liggen (zie onder). En bij wie de auteursrechten in een concreet geval op grond van de wettelijke regels berusten, is vaak zeer afhankelijk van de feitelijke omstandigheden. Vooral bij complexe ontwikkeltrajecten waar meerdere personen bij betrokken zijn, kan dit leiden tot ingewikkelde eigendomsvragen. Partijen moeten het dan vaak achteraf bij de rechter uitvechten.

Dat de rechter ook wel eens een onjuiste invulling aan de feiten kan geven, bleek recentelijk uit een arrest van het Hof Arnhem (zie onder: 'Arrest Hof Arnhem'). In die zaak had een programmeur als freelancer bepaalde software gemaakt waardoor hij werd aangemerkt als ‘maker’ van die software. Omdat de programmeur met zijn opdrachtgever geen afspraken had gemaakt over het eigendom op de software, zou het hof hem als auteursrechthebbende hebben moeten aanmerken. In plaats daarvan bedeelde het hof de rechten aan zijn opdrachtgever toe. De opdrachtgever kwam er dus ten onrechte (voorlopig) goed van af.

Afspraken

Discussies over de eigendomsrechten kunnen voorkomen worden door – het liefst vooraf – onderling duidelijke afspraken te maken. Daarmee worden de wettelijke bepalingen in feite buiten werking gesteld en gelden de afspraken die partijen hebben gemaakt. Als een opdrachtgever de ontwikkeling van software uit handen wil geven aan een externe partij en als hij die software zelf vrijelijk wil gaan gebruiken, aanpassen en exploiteren, dan kan hij stappen nemen om het eigendom in eigen hand te houden (zie onder). Als een softwareontwikkelaar bereid is zijn rechten over te dragen aan een opdrachtgever, dan doet hij er goed aan de afspraken over de voorwaarden van de overdracht duidelijk op papier te zetten. Denk bijvoorbeeld aan betaling van de vergoeding als voorwaarde voor overdracht van de rechten. Het goed vastleggen van de afspraken kan een hoop juridisch getouwtrek achteraf voorkomen.

Stappenplan

Als een opdrachtgever de ontwikkeling van software uit handen wil geven aan een externe partij en als hij die software zelf vrijelijk wil gebruiken, aanpassen en exploiteren, dan kan hij stappen nemen om het eigendom in eigen hand te houden. Een kort stappenplan ziet er als volgt uit:

Stap 1: Inventariseer wat er wordt gemaakt: het functioneel en technisch ontwerp, de broncode van de software zelf, van eventuele hulpprogrammatuur, de vormgeving van de gebruikersinterfaces, de documentatie.

Stap 2: Inventariseer wie het maakt. Is dat een werknemer, een freelancer, een stagiair, een gedetacheerde of een andere bij een opdrachtnemer werkzame persoon? De vuistregel in het auteursrecht is dat de persoon die iets maakt (de ‘maker’) is aan te merken als auteursrechthebbende. Daarop is maar een paar uitzonderingen mogelijk (zie verderop: ‘Auteursrecht versus octrooirecht’).

Stap 3: Leg de afspraken vast (als de maker niet een eigen werknemer is die de software maakt in de uitoefening van zijn functie). Voorkomen is beter dan genezen. Dit kan door in een ‘akte’ door een jurist vast te laten leggen dat de intellectuele-eigendomsrechten worden overgedragen, en afstand wordt gedaan van persoonlijkheidsrechten. Daarbij is een goede geheimhoudingsclausule geen overbodige luxe.

Stap 4: Zorg voor feitelijke controle. Ook als eenmaal is afgesproken bij wie de auteursrechten op de software berusten, is het nog van belang om ervoor te zorgen dat degene die de software gaat exploiteren ook feitelijk de controle daarover krijgt. Het gaat dan uiteraard met name om de broncode van de software, maar ook gedacht kan worden aan het oorspronkelijke bestand met daarin de documentatie. Het is dus niet onverstandig om ook af te spreken dat voor de maker de verplichting wordt opgenomen om de ‘moederbestanden’ van de broncode en documentatie aan de (nieuwe) auteursrechthebbende over te dragen. Dit is inclusief eventuele updates en upgrades van de software als deze blijvend wordt doorontwikkeld door de niet-auteursrechthebbende.

Stap 5: Controleer de afspraken. Als de afspraken eenmaal op papier zijn gezet is het zaak ervoor te zorgen dat deze ook daadwerkelijk worden nagekomen. Dat betekent: nagaan of de ‘moederbestanden’ ter beschikking zijn gesteld en bij voortdurende ontwikkeling regelmatig controleren of de laatste versies van de broncode ter beschikking zijn gesteld.

Stap 6: Dwing de afspraken af. Als de contractpartijen zich niet aan de afspraken houden, dwing ze dan af, zo nodig in rechte.

Arrest Hof Arnhem

Het Hof Arnhem deed op 15 november 2011 (zie www.rechtspraak.nl) vanuit auteursrechtelijk perspectief een opvallende uitspraak.

Wat was er aan de hand? Meneer X (hierna ‘de opdrachtgever’) heeft een bedrijf dat software exploiteert. Zijn zwager, meneer Y (hierna ‘de programmeur’) heeft voor de opdrachtgever een softwareprogramma ontwikkeld. Daarna doet zich een klassiek geval voor: de opdrachtgever en programmeur krijgen ruzie en gaan uit elkaar. De software brengt kennelijk redelijk wat op en de programmeur eist zijn rechten daarop op. Ook eist hij het beheer van de software op en een verbod voor de opdrachtgever om de software aan te passen.

Waar het geschil om draait is de vraag aan wie de auteursrechten op de software toekomen. Het hof heeft eerst vastgesteld dat de software beschermd is en dat de programmeur is aan te merken als de maker daarvan. De programmeur heeft immers het technisch ontwerp gemaakt en de gebruikersinterface ontworpen en geschreven. Dat hij de software aan bepaalde wensen van de opdrachtgever heeft aangepast, verandert dat niet. Ook heeft het hof vastgesteld dat de programmeur niet in loondienst was van de opdrachtgever, maar als opdrachtnemer (freelancer) was aan te merken. De auteursrechten komen dus niet toe aan de opdrachtgever uit hoofde van werkgeverschap (artikel 7 auteurswet).

Kennelijk hebben de programmeur en opdrachtgever onderling geen afspraken gemaakt over aan wie de auteursrechten zouden toekomen. Ook heeft de opdrachtgever kennelijk niet aangevoerd dat de auteursrechten aan hem zouden moeten toekomen op een andere grond dan het gestelde werkgeverschap. Dit betekent dat de programmeur als auteursrechthebbende op de software moet worden aangemerkt. Dat zou alleen anders zijn als hij de auteursrechten in een akte aan de opdrachtgever heeft overgedragen.

Het hof stelt echter juist het tegenovergestelde vast: omdat de programmeur heeft nagelaten afspraken te maken over de eigendomsrechten mocht de opdrachtgever ervan uitgaan dat hij het ‘eigendoms- en gebruiksrecht’ van de software zou krijgen. Eigenlijk is dit de omgekeerde wereld: omdat de opdrachtgever heeft nagelaten afspraken te maken, zijn de auteursrechten niet bij de programmeur komen te liggen en had hij er ook niet van uit mogen gaan dat dat wel het geval zou zijn.

Het is overigens jammer dat het hof het ‘eigendomsrecht’ en het ‘gebruiksrecht’ van de software hier over één kam scheert. Dit zijn twee wezenlijk verschillende dingen. Het ‘eigendom’ van de software omvat de auteursrechten op de software. Daaronder valt ook de broncode. Het ‘gebruiksrecht’ is in feite de softwarelicentie: een contractueel recht dat aan een licentienemer wordt verleend om gebruik te maken van de software. Het hof had naar mijn mening in de feiten kunnen lezen dat de opdrachtgever het recht had om de software te gebruiken, en zelfs om die te exploiteren, maar niet dat hij ook het eigendomsrecht (lees: de auteursrechten) daarop had.

Resultaat: de opdrachtgever wordt aangemerkt als ‘eigenaar’ van de software en de programmeur niet. De programmeur heeft geen recht op ‘beheer van het programma’ (noch de broncode). Daardoor komt de programmeur er – onterecht – bekaaid van af.

Auteursrecht versus octrooirecht

Software kan worden beschermd door het auteursrecht als het – kort gezegd – voldoende origineel is. Bij een beetje creatief geprogrammeerde broncode is dat al snel het geval. Daarnaast kunnen softwarematige uitvindingen worden beschermd onder het octrooirecht. Dit is alleen nog niet erg goed uitgekristalliseerd in de Europese Unie.

Wie is auteursrechthebbende?
In de volgende gevallen wordt een ander dan de maker van een broncode op grond van de auteurswet aangemerkt als auteursrechthebbende van de software:

  • De werkgever van de programmeur die de software in loondienst in de uitoefening van zijn functie heeft geprogrammeerd (artikel 7 auteurswet).
  • Degene die de software heeft ontworpen en leiding geeft aan de programmeur bij de ontwikkeling van de software, zonder dat de programmeur daarbij een eigen creatieve inbreng heeft (dit zal niet vaak het geval zijn; artikel 6 auteurswet).
  • De rechtspersoon die de software openbaar maakt met het doel om het openbaar te maken, zonder daarbij de naam van de maker te vermelden en zonder dat er sprake is van een onrechtmatige daad jegens de maker (artikel 8 auteurswet).
  • Degene aan wie de maker zijn auteursrechten op de software heeft overgedragen door middel van een schriftelijk document (‘akte’; artikel 2 auteurswet).

Een ander dan de maker kan ook samen met de maker auteursrechthebbende, en zelf ook maker, zijn als:

  • Een andere programmeur (of meerdere) de software ook heeft geprogrammeerd, waarbij de inbreng niet scheidbaar is. Beide (of alle) programmeurs worden dan als auteursrechthebbenden aangemerkt.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!