Contractuele afspraken omtrent intellectuele eigendom en broncode zijn het vertrekpunt

Software – meer in het bijzonder, de broncode – wordt doorgaans beschermd door het auteursrecht. De broncode is de leesbare tekst die door de programmeur in een programmeertaal is geschreven. Ten aanzien van de broncode heeft de rechthebbende een exclusief recht (het auteursrecht). De rechthebbende is in beginsel de ‘maker’ (de programmeur) van de software. Auteursrechten kunnen naar Nederlands recht enkel schriftelijk worden overgedragen. Dus als het gaat om specifiek voor een organisatie ontwikkelde software (maatwerksoftware), dan is van belang dat de opdrachtgever de overdracht van intellectuele eigendomsrechten ten aanzien van de software (meer in het bijzonder, de broncode) schriftelijk overeenkomt met de ontwikkelaar.

Maar dit is niet het enige aandachtpunt in software ontwikkelingsovereenkomsten. Zo bestaat ook maatwerksoftware in 9 van de 10 gevallen mede uit reeds bestaande, door derden geschreven, broncode (third party software). Veelal gaat het dan om open source software. Het is een misvatting dat ‘open source’ betekent dat je daarmee kan doen en laten wat je wil. Ook ten aanzien van open source beschikbare broncode kunnen (licentie)voorwaarden gelden. Het schenden van die licentievoorwaarden houdt gewoon een inbreuk op de intellectuele eigendomsrechten in. Van belang is dan ook dat een opdrachtovereenkomst tot ontwikkeling van software duidelijk maakt óf het gebruik van (open source) software van derden is toegestaan. Als dat het geval is, moet de software ontwikkelaar, en later de opdrachtgever als gebruiker van de software, binnen de kaders van de (open source) licentie handelen.

Tip 1: Leg de afspraken over de overdracht, of licentie (het gebruiksrecht) met betrekking tot, de intellectuele eigendomsrechten van de software vooraf schriftelijk vast.

Tip 2: Leg bij de ontwikkeling van de software ook vast of gebruik kan worden gemaakt van (open source) third party software, en zo ja, onder welke voorwaarden.

Het belang van documentatie

Tegenwoordig verloopt veel softwareontwikkeling via het zogenaamde Agile-principe. Agile houdt in dat de software wordt ontwikkeld in opeenvolgende, korte periodes (ook wel ‘iteraties’ of ‘sprints’ genoemd). Aan het eind van iedere iteratie, die aanvangt met planning, analyse en ontwerp, wordt de software getest en beoordeeld.

Bij agile ontwikkeling ligt de nadruk op directe communicatie en persoonlijk contact in plaats van geschreven verslaglegging. Omdat het beschrijven van hoe de software is opgebouwd, en het verwerken van wijzigingen achteraf een tijdrovend proces is, wordt het opstellen van de documentatie nog wel eens vergeten. Of de documentatie is onvolledig. Dat hoeft niet direct een probleem te zijn, want deze kennis zit natuurlijk ook ‘in de hoofden van de programmeurs’. Maar wat nu als je wilt overstappen naar een andere software programmeur? Dan is het toch van belang om ergens op te kunnen terugvallen, zoals een degelijke documentatie.

Tip 3: Spreek vooraf af aan welke voorwaarden de documentatie moet voldoen en/of blijf tijdens het ontwikkelproces actief de softwareontwikkeling monitoren waarbij eventueel meerdere mensen kennis opdoen van hoe de software in elkaar zit.

Het vendor lock-in risico

Meestal gaat men bij software ontwikkeling voortvarend en enthousiast aan de slag met programmeren. Nadat de ontwikkelde maatwerksoftware klaar is, betekent dit echter niet dat ook de samenwerking met de ontwikkelaar ophoudt. Het computerprogramma moet namelijk onderhouden worden waarbij logische fouten (‘bugs’) worden verwijderd en verbeteringen (‘updates’ en ‘releases’) worden doorgevoerd.

Zonder onderhoud is software veelal snel onbruikbaar. Wanneer de opdrachtgever niet in het bezit is van de broncode (en de volledige documentatie) kan hij de software niet zelf of door een ander (laten) onderhouden. Daarmee zou hij dus afhankelijk worden van de oorspronkelijke software ontwikkelaar. Dit is een onwenselijke situatie, zeker als bijvoorbeeld blijkt dat de software ontwikkelaar failliet is, of als de relatie met de ontwikkelaar om een andere reden stukloopt.

Dit voorbeeld wijst ons op het belang van de vraag of de auteursrechthebbende (lees: de opdrachtgever) noodzakelijkerwijs over de broncode moet kunnen beschikken en afgifte kan vorderen bij de softwareontwikkelaar (dan wel de curator)?

De Nederlandse rechter heeft zich in het verleden al eens gebogen over deze vraag en geoordeeld dat het onderscheid standaard-/maatwerksoftware bepalend is voor het recht op afgifte van de broncode. Daar waar het gaat om maatwerksoftware die niet elders inzetbaar is, zal de leverancier van de programmatuur (dan wel diens curator bij faillissement) de opdrachtgever toegang tot de broncode moeten verschaffen.

Van belang is dus dat het gaat om maatwerksoftware. Maar uit deze uitspraak volgt ook dat moet worden gekeken naar de inzetbaarheid van de software door de ontwikkelaar. De vervolgvraag was namelijk of voor afgifte van de broncode nog een redelijke vergoeding moest worden betaald aan de softwareontwikkelaar. Voor zover het gaat om standaardsoftware heeft de ontwikkelaar veelal een commercieel belang bij het achterhouden van die broncode. Hij heeft immers tijd en geld geïnvesteerd om de software te ontwikkelen en wil vermijden dat zijn software gekopieerd wordt. Bij maatwerksoftware heeft de opdrachtgever de ontwikkeling doorgaans volledig gefinancierd en is de betreffende programmatuur enkel inzetbaar voor de opdrachtgever. In dat geval behoeft in principe dus geen extra vergoeding te worden betaald aan de software ontwikkelaar.

Tip 4: wees je bewust van de aanwezigheid van een potentieel vendor lock-in risico en neem volledigheidshalve in je overeenkomst op dat de ontwikkeling en overdracht van de maatwerksoftware tevens de overdracht en levering van de broncode inhoudt.

Vormen onderhoudswerkzaamheden bij standaardsoftware auteursrechtinbreuk?

Een laatste interessante vervolgvraag is dan, of het onderhoud van standaardsoftware waarvoor je een rechtmatige licentie hebt verkregen, bij een faillissement van de softwareleverancier kan worden overgenomen door een derde.

Software (laten) wijzigen is zonder toestemming van de rechthebbende (lees: de softwareontwikkelaar bij standaardsoftware) niet toegestaan. Dat zou een inbreuk op de auteursrechten ten aanzien van de software inhouden. In artikel 45j Auteurswet is evenwel in een uitzondering voorzien voor de ‘rechtmatige verkrijger’. Een licentienemer is een rechtmatige verkrijger en zou dus het onderhoud van de software zelf of door een derde kunnen laten verrichten.

Het artikel bepaalt echter ook dat de wijziging van de software “noodzakelijk is voor het met dat werk (red. die software) beoogde gebruik”. En daarin zit een moeilijkheid. Dat constateerde ook de Rechtbank Midden-Nederland in een tussenvonnis van april 2019 in een zaak die was aangespannen door een softwareleverancier tegen een licentienemer die het onderhoud van de software had uitbesteed aan een derde. De softwareleverancier meende dat er sprake was van een inbreuk op het auteursrecht, waarbij de licentienemer een beroep op artikel 45j Aw deed. De rechtbank gaf de licentienemer de opdracht om het ‘noodzakelijkheidsvereiste’ en het ‘beoogde gebruik’ nader te duiden omdat dit nergens op schrift was vastgelegd.

Ongeveer een jaar later, op 5 maart 2020, volgt een nieuw tussenvonnis waarin de rechtbank concludeert dat de door de derde verrichte onderhoudswerkzaamheden onvoldoende noodzakelijk waren voor het beoogde gebruik. Naar de mening van de rechtbank had de licentienemer het beoogde gebruik te ruim geformuleerd en de onderhoudswerkzaamheden onvoldoende beschreven. Daarnaast was onvoldoende onderbouwd dat die handelingen technisch ‘absoluut vereist’ waren om de software te gebruiken overeenkomstig het beoogde doel. Conclusie: inbreuk op het auteursrecht van de softwareleverancier.

Tip 5: Omschrijf in de softwarelicentieovereenkomst duidelijk waar de licentie toe strekt en wat het beoogde gebruik is. Indien je het als softwareleverancier onwenselijk acht dat onderhoud aan een derde wordt uitbesteed, dan is het raadzaam dit expliciet op te nemen. In het genoemde voorbeeld had dat de softwareleverancier een weg naar de rechter mogelijk kunnen besparen.

Heeft u ook een vraag over software ontwikkeling, neem contact op met Chantal Bakermans via mail (c.bakermans@penrose.law) of bel 020-2400710.

Advocatenkantoor Penrose, Amsterdam.

Anderen zochten ook naar: