21 januari 2016
Artikel, Nieuws

Software & intellectueel eigendom

Veel softwareontwikkelaars vragen zich af of hun software te beschermen is en zo ja, hoe. Helaas is hier niet altijd een eenduidig antwoord op te geven. Vandaar dat wij de meest voorkomende intellectuele eigendomskwesties met betrekking tot software in een serie artikelen zullen behandelen. In dit eerste, inleidende artikel worden enkele veelgehoorde stellingen gewogen en op waarheid getoetst. In de komende maanden zullen de belangrijkste onderwerpen verder worden uitgediept.

Uitspraak 1: "Software is niet te octrooieren"
Beoordeling: niet waar

In artikel 52 van het Europees Octrooiverdrag (EOV) staat weliswaar - in de lijst van wat er uitdrukkelijk níet als uitvinding beschouwd wordt - zwart op wit: stelsels, regels en methoden voor het verrichten van geestelijke arbeid, voor spelen of voor de bedrijfsvoering, alsmede computerprogramma’s. Een Europese richtlijn voor het eventueel wel kunnen bieden van octrooibescherming aan computerprogramma’s werd voorgesteld, maar in juli 2005 met een overweldigende meerderheid (648 tegen 14) afgewezen.

Toch kan het verstandig zijn om naar aanleiding hiervan de handdoek niet direct in de ring te gooien. De rechtspraak van het Europees Octrooibureau (EOB) heeft namelijk enige nuancering gebracht: een computerprogramma is niet als zodanig te octrooieren, maar een uitvinding mag best vertrouwen op een computerprogramma, als er maar sprake is van een zogenaamd "further technical effect". Kort gezegd, moet er sprake zijn van een ingrijpen op de fysieke omgeving. Wat dit precies inhoudt, zal in een vervolgartikel nader worden uitgelegd. Een voorbeeld kan zijn dat er een sensorinput wordt omgezet in een machineoperatie aan de hand van een computerprogramma.

Uitspraak 2: "In de VS kan je octrooi krijgen op dingen zoals dubbelklikken"
Beoordeling: niet waar

In de Verenigde Staten gelden andere regels voor wat er wel en niet te octrooieren is. Het octrooieren van handelspraktijken mag bijvoorbeeld en ook het octrooieren van "software als zodanig" is er niet uitgesloten. In het verleden was het dan ook mogelijk om in de VS software te octrooieren die in Europa niet geoctrooieerd kon worden. Dit leidde in de VS tot een aantal rechtszaken over "uitvindingen" die door menigeen als triviaal worden beschouwd.

De situatie in de VS met betrekking tot octrooien op software is echter aan het veranderen. In 2014 wees de Supreme Court het zogenaamde Alice-arrest, waarbij het er op neer komt dat een softwareprogramma méér moet behelzen dan de implementatie van een abstract idee om octrooiwaardig te zijn. Wat dit arrest uiteindelijk in de praktijk betekent, zal nog moeten blijken. De uitspraak heeft echter nu al tot gevolg dat het moeilijker is geworden om in de VS nog octrooi op software te krijgen.

Uitspraak 3: "Er zit auteursrecht op software"
Beoordeling: waar

Het mooie van auteursrecht/copyright is dat je er - in tegenstelling tot veel andere IP-rechten - niets voor hoeft te doen: auteursrecht heb je automatisch vanaf het moment dat je iets de wereld in brengt. Auteursrecht is echter beperkt in die zin dat het niet het idee achter software beschermt, maar alleen de specifieke uitvoeringsvorm. De broncode dus, maar ook het design - mits er voldaan is aan de voorwaarden voor het in aanmerking komen voor auteursrecht. Namelijk dat het een eigen oorspronkelijk karakter heeft en het persoonlijk stempel van de maker draagt.

Dit betekent dat de bescherming weliswaar automatisch verkregen wordt, maar deze is wel redelijk beperkt. Immers, als een derde partij de software namaakt door met nieuwe code functioneel (nagenoeg) hetzelfde te doen, wordt het moeilijk om inbreuk op het auteursrecht aan te tonen. Aan de andere kant kan wel een beroep op het auteursrecht worden gedaan op het moment dat iemand de broncode zonder toestemming kopieert.

Uitspraak 4: "Het beste is om je broncode geheim te houden"
Beoordeling: soms waar

Als je je broncode geheim houdt, wordt het voor derden lastiger om je programma na te maken. In tegenstelling tot uitvindingen in veel andere technologiedomeinen, kan de broncode ook daadwerkelijk redelijk goed geheim worden gehouden. Geheimhouding brengt echter ook risico’s met zich mee. Het zou bijvoorbeeld kunnen dat een ander op hetzelfde idee komt. Deze kan dan - als het een te octrooieren uitvinding betreft - zijn idee octrooieren, waardoor het zelfs kan gebeuren dat jouw software inbreuk maakt op het octrooi van deze derde.

Toch heeft geheimhouding zeker bij ingewikkelde algoritmes voordelen. Een goede strategie is (mits het kan) de combinatie van octrooien en het geheimhouden van de precieze broncode. Zo doet Google het bijvoorbeeld. Er zit octrooi op een aantal ideeën die in hun zoekalgoritme verwerkt zijn, onder andere PageRank. De broncode voor het algoritme, met al zijn verfijningen en tweaks, is echter een goed bewaard geheim. Als een dergelijk bedrijfsgeheim behouden blijft, is de bescherming met geheimhouding haast absoluut en in tegenstelling tot een octrooi niet in tijd beperkt. Als er iemand uit de school klapt, heb je echter wel een probleem. Waarbij nog meespeelt dat bescherming van bedrijfsgeheimen in Europa minder grondig in de wet is vastgelegd dan in de Verenigde Staten.

Uitspraak 5: "Iedereen kan mijn software gewoon jatten"
Beoordeling: niet waar

Zoals hierboven besproken zijn er allerlei manieren om je software te beschermen. Naast octrooien en auteursrecht zijn er nog een aantal andere manieren om (gedeeltes van) je software (product of dienst)te beschermen. Zo is de naam waaronder je een onderneming drijft, beschermd door de Handelsnaamwet. De merknaam en het logo van je programma kunnen worden beschermd met het merkenrecht. Er zijn genoeg partijen die Photoshop™ nabootsen, maar niemand mag de naam Photoshop gebruiken. Met modelbescherming kan je tot op zekere hoogte ook beschermen hoe het design van je programma eruit ziet. Daarnaast is het de moeite waard om in gedachten te houden dat een concurrent, die bereid is om tijd en moeite in het nabootsen van een stukje code te steken, wellicht ook bereid is om in plaats daarvan een licentie te nemen. Dat kost immers minder tijd, is in sommige gevallen zelfs goedkoper en kan compatibiliteitsproblemen voorkomen.

Uitnodiging: Stuur je vraag ter beantwoording in

In de komende maanden zullen de belangrijkste onderwerpen in vervolgartikelen verder worden uitgediept. Ook kijken we naar de risico’s en uitdagingen die het ondernemen met software met zich meebrengen. Heb je zelf een vraag over software en intellectueel eigendom? Laat het de redactie dan weten via pr@arnold-siedsma.nl en we proberen je vraag in een van de volgende artikelen te beantwoorden.

Terug