Help, mijn software is nagemaakt! Wat nu?

software-namaken

Wat nu te doen? Uw eerste gedachte is waarschijnlijk: we hebben deze software in eigen huis ontwikkeld, dus we gaan de rechter vragen onze concurrent te verbieden de namaaksoftware op de markt te brengen en hem tot schadevergoeding te veroordelen. Als eisende partij zult u dan moeten bewijzen dat de concurrent uw software heeft nagemaakt. Hoe doet u dat? Deze vraag was onderwerp van een procedure waarin de rechtbank Den Haag in juni 2014 uitspraak deed.

Voordat ik inga op deze uitspraak is het handig te weten wanneer uw concurrent eigenlijk inbreuk op uw auteursrecht maakt. Is dat pas het geval als hij gebruik maakt van een gekopieerde broncode? Of is dit ook al het geval als hij software op de markt brengt die functioneel wel erg lijkt op uw software?

Wanneer wordt het auteursrecht geschonden?

Het antwoord is simpel: als de broncode of objectcode is gekopieerd. Alleen deze kunnen namelijk tot reproductie van de software leiden en dat criterium is leidend. Daarnaast biedt de Auteurswet ook bescherming voor voorbereidend materiaal, maar daarvoor geldt dat dit tot een computerprogramma moet kunnen leiden. Denk hierbij aan het functioneel of technisch ontwerp.

De interface van software kan ook auteursrechtelijk beschermd zijn. Dit valt echter niet onder de categorie ‘software’, maar onder de categorie ‘werken van letterkunde, wetenschap of kunst’ die beschermd worden op grond van de Auteurswet. Zolang de interface maar oorspronkelijk is en het product van ‘creativiteit’ is (in de rechtspraak een “eigen intellectuele schepping van de maker” genoemd).

Het is dus onvoldoende om op basis van vergelijkbare interfaces of functionaliteiten beslag te leggen op de software van de concurrent om inbreuk op het auteursrecht vast te stellen. Maar wat dan? U heeft immers niet de beschikking over de code of ontwerpen van de concurrent om het bewijs voor de inbreuk te leveren.

Wanneer krijgt u wel inzage in de software van de concurrent?

Aan het leggen van bewijsbeslag zitten zeer veel juridische en praktische haken en ogen. Denk bijvoorbeeld aan de vertrouwelijkheid van bedrijfsgegevens van de concurrent of bestanden of programmatuur van derden die wellicht op dezelfde server draaien. Of denk aan het eisen van de medewerking van de concurrent als die wachtwoorden moet afgeven of aan decryptie moet meewerken. Punt is ook dat je na die beslaglegging de rechter ook nog toestemming moet vragen om de software te mogen onderzoeken.

Voor toewijzing van dit soort vorderingen moet er volgens de relevante rechtspraak sprake zijn van een ‘redelijk vermoeden van inbreuk’. De eiser in de eerdergenoemde zaak stelde dat dit vermoeden kan worden afgeleid uit de overeenkomende interfaces van de software van hem en van de concurrent. Zoals hiervoor aangegeven is dit niet voldoende om een inbreuk op het auteursrecht te bewijzen, maar is het misschien wel voldoende om aan bewijs te komen?

De rechtbank vond van niet. Een inbreuk op een interface is geen inbreuk op software, dus er is geen redelijk vermoeden van inbreuk. Daarom mocht de software volgens de rechtbank niet worden onderzocht.

Kortom, overeenstemmende interfaces lijken vooralsnog niet voldoende om de broncode van de concurrent te mogen onderzoeken. Er zijn echter juristen die vinden dat met een ‘redelijk vermoeden van inbreuk’ de lat te hoog ligt. Volgens hen zou een rechtmatig belang van de eiser voldoende moeten zijn.

Wanneer is er een ‘redelijk vermoeden van inbreuk’?

Om een indruk te geven van toepassing van een ‘redelijk vermoeden van inbreuk’, vindt u hieronder drie voorbeelden.

Zaak 1

Allereerst de zaak die in 2013 leidde tot de uitspraak van het Hof Den Haag waar het eerdergenoemde criterium ‘redelijk vermoeden van inbreuk’ geformuleerd werd. In die zaak bracht de concurrent software op de markt die onderdelen bevatten (codecs en plugins) die voor 100% waren gekopieerd uit de software van de eiser (internetsoftware voor streaming van beeld en geluid). De rechter achtte het aannemelijk dat met name de codecs het resultaat waren van scheppende arbeid en van creatieve keuzes en daarom auteursrechtelijk beschermde software vormden. Het feit dat deze gekopieerd waren, leverde voldoende aanwijzingen op om inzage in de beslagen gegevens toe te staan. Op die manier kon de eiser de totale omvang van de inbreuk onderzoeken.

Zaak 2

Ook in een andere zaak die in 2014 voor de rechtbank Den Haag diende, werd een verzoek tot onderzoek van een broncode toegewezen. Het ging in die zaak om zogenaamde Computer-Aided Design-programma’s. De eiser wees op de overeenstemmende functionaliteit tussen haar eigen CAD-software en die van de concurrent. Dit hoeft niets te zeggen over het kopiëren van de broncode. Echter, in dit geval zaten er een aantal fouten in de functionaliteit van de concurrerende software die ook in de functionaliteit van de software van de eiser voorkwamen. Dit was voor de rechtbank voldoende voor het aannemen van een redelijk vermoeden van inbreuk.

Zaak 3

Het laatste voorbeeld is een wat oudere uitspraak van de rechtbank Den Haag uit 2012 was de rechter wat minder streng. In die zaak, waar het ging om software voor bepaalde tankpassen, kon het redelijk vermoeden volgens de eiser afgeleid worden uit het feit dat de concurrerende software een bewerking vormde van de specificaties van de eigen software. De rechtbank stelde een redelijk vermoeden vast. Hierbij werd meegewogen dat het ging om een zeer specifiek product en dat medewerkers die bij de eiser hadden gewerkt en toegang hadden gehad tot de specificaties, naar de concurrent waren overgestapt kort voordat de concurrerende software op de markt kwam.

Conclusie

De conclusie is dat het in bezit krijgen van (mogelijk) inbreukmakende software één stap is, maar deze mogen onderzoeken een volgende stap. Hiervoor moet een ‘redelijk vermoeden van inbreuk’ aanwezig zijn. Alleen op elkaar lijkende interfaces of functionaliteiten zijn daarvoor niet voldoende. Bijkomende feiten en omstandigheden kunnen er echter tot een redelijk vermoeden van inbreuk leiden. En daarmee onderzoek mogelijk te maken.

Voor vragen over dit artikel of het ICT-recht in het algemeen, kunt u contact opnemen met Marjolijn Hoevenaars via marjolijnhoevenaars@degierstam.nl

Dit artikel verscheen eerder op onze website: www.degierstam.nl

Share this post: