Wanneer je software ontwikkelt, wil je niet dat anderen met het resultaat van jouw arbeid aan de haal gaan. Gelukkig hoeft dat ook niet. Het software-auteursrecht schiet je vaak te hulp.
Wel moet de softwarecode daarvoor aan bepaalde vereisten voldoen. De belangrijkste twee zijn:
Als de software aan deze eisen voldoet, ontstaat het (software-)auteursrecht automatisch. Je hoeft het dus niet ergens te laten registreren of deponeren — al kan goede documentatie uiteraard wel belangrijk zijn om je bewijspositie te versterken, mocht dat ooit nodig zijn.
Het is vaak niet moeilijk om aan deze eerste voorwaarde te voldoen. Wanneer je eigen softwarecode schrijft, zal deze doorgaans ook de vereiste ‘originaliteit’ bezitten. Niet-juristen schrikken nogal eens van de zware woorden waarmee dit criterium wordt ingevuld. Zo lijkt ‘originaliteit’ te suggereren dat de software in kwestie heel bijzonder of afwijkend moet zijn.
Dat is niet het geval. Hetzelfde geldt voor allerlei andere gewichtige termen die in dit verband opduiken, zoals ‘een eigen oorspronkelijk karakter’, ‘persoonlijk stempel van de maker’ en ‘eigen intellectuele schepping’. Kort gezegd komt het erop neer dat je zelf iets moet creëren en niet een bestaand werk (met kleine wijzigingen) overneemt. Om dit concreet te maken, kunnen we onderstaande tekening als uitgangspunt nemen.
De meeste mensen zullen dit geen originele tekening vinden. Het is een kinderlijke weergave van een konijn die je zo op de achterkant van een kassabon zou kunnen krabbelen. Maar de combinatie van specifieke elementen (zoals: de ring om de ogen, de streep over de rug, de oranje vacht, de dubbele contouren, enzovoorts) zorgen ervoor dat het wel degelijk beschermd is. Je kunt een konijn namelijk ook op talloze andere manieren weergeven, denk aan Nijntje, Bugs Bunny of Stampertje. Ten opzichte van die andere varianten heeft dit konijn een ‘eigen oorspronkelijk karakter’.
Hetzelfde geldt voor software. Wanneer je een code op je eigen manier opschrijft, zal het al snel ‘origineel’ zijn, in de zin dat het een ‘eigen creatie’ is. Wel is het belangrijk dat de code al afgerond is of in de afrondende fase zit. Dat brengt ons op de tweede voorwaarde: de code moet voldoende geconcretiseerd of uitgewerkt zijn.
Het auteursrecht (en ook het software-auteursrecht) beschermt alleen concrete uitwerkingen en niet de achterliggende ideeën. Walt Disney kan daarom anderen niet verbieden om — in het algemeen — stripverhalen rondom een eend-achtig personage te maken. Dit wordt anders wanneer de concrete uitwerking van zo’n personage kenmerkende gelijkenissen met Donald Duck vertoont. Kortom: algemene ideeën zijn vrij maar de specifieke vorm waarin je zo’n idee giet, kan wél gedekt worden door het auteursrecht.
Wanneer het over software gaat, geldt hetzelfde: het concept achter een computerprogramma wordt niet door het software-auteursrecht beschermd. Pas als dit idee op ‘papier’ wordt gezet, kunnen er rechten gaan ontstaan. Daarbij is het overigens niet noodzakelijk dat dit meteen gebeurt in een programmeertaal, zoals Java of Python. Ook in de ‘voorbereidende fase’ kan er al sprake zijn van bescherming.
Straks zal dit verder worden besproken aan de hand van een voorbeeld, maar eerst volgt hieronder een schematische weergave van de stappen die aan de orde zullen komen:
Stel: je hebt een softwarefunctionaliteit geschreven die een horizontaal patroon van een verticaal patroon kan onderscheiden. Ter illustratie:
Het principe achter een dergelijk computerprogramma zou je op de volgende manier in menselijke taal (dat wil zeggen: niet-computertaal) kunnen omschrijven:
Omschrijving in menselijke taal (stap 1)
Bereken over alle pixels in de afbeelding het gemiddelde absolute verschil in horizontale en verticale richting. Als dit gemiddelde absolute horizontale verschil een waarde oplevert die meer dan x-maal zo groot is als het gemiddelde absolute verticale verschil (bijvoorbeeld meer dan 2), ga dan uit van een verticaal patroon. En, in de omgekeerde situatie, van een horizontaal patroon. Als geen van beide het geval is, ga dan uit van noch een horizontaal noch een verticaal patroon.
De uitwerking van het idee in een concrete vorm komt nu al dichterbij. Maar toch is dit nog te algemeen om software-auteursrecht te kunnen claimen. Daarvoor is namelijk van belang dat de omschrijving zo gestructureerd en schematisch is, dat er bijna geen keuzevrijheid meer bestaat bij het uitprogrammeren. Dit is het geval wanneer er een ondubbelzinnig stappenplan wordt opgesteld, bijvoorbeeld:
Stappenplan (stap 2)
1. Maak een tensor T(i,j,k) aan met de kleurwaarden van de afbeelding (i lopend van 1 tot breedte, j van 1 tot hoogte, en k van 1 tot aantal kleurkanalen).
2. Maak G_hor(i,j,k) gelijk aan abs(T(i+1,j,k)-T(i,j,k)) (i lopend van 1 tot breedte-1, j van 1 tot hoogte, en k van 1 tot aantal kleurkanalen).
3. Maak G_ver(i,j,k) gelijk aan abs(T(i,j+1,k)-T(i,j,k)) (i lopend van 1 tot breedte, j van 1 tot hoogte-1, en k van 1 tot aantal kleurkanalen).
4. Maak G_hor_mean gelijk aan de gemiddelde waarde van G_hor(i,j,k) (d.w.z. de totale som gedeeld door (hoogte-1)*hoogte*kanalen).
5. Maak G_ver_mean gelijk aan de gemiddelde waarde van G_ver(i,j,k) (d.w.z. de totale som gedeeld door breedte*(hoogte-1)*kanalen).
6. Als G_ver_mean > 2*G_hor_mean, toon ‘horizontaal patroon’.
7. Als G_hor_mean > 2*G_ver_mean, toon ‘verticaal patroon’.
8. Als condities in (6) en (7) zich beide niet voordoen, toon ‘noch horizontaal noch verticaal patroon’.
Op dit punt kan de software-in-wording al auteursrechtelijk beschermd zijn als ‘voorbereidend materiaal’. De juridische eis die in dit verband vaak wordt genoemd, is dat het materiaal ‘tot (reproductie) van het computerprogramma kan leiden’. Met andere woorden: je moet precies aangeven hoe je van A naar B naar C gaat, zonder nog ruimte te laten voor creatieve keuzes tijdens het programmeerproces.
Dit stappenplan kan ook uitgewerkt zijn als een stroomdiagram. Ook zo’n stroomdiagram is beschermd voorbereidend materiaal, uiteraard op voorwaarde dat het voldoende precies is.
Tenslotte is er de stap van het uiteindelijk programmeren — misschien is dit zelfs de enige stap die daadwerkelijk genomen wordt. Voor de concrete uitwerking kiezen we in dit voorbeeld voor de programmeertaal Python (versie 3):
Uitwerking in broncode (stap 3)
import PIL, numpy
T =numpy.array(PIL.Image.open(‘/path/to/image’)).astype(‘float’)
G_hor = abs(T[:,1:]-T[:,:-1])
G_ver = abs(T[1:,:]-T[:-1,:])
G_hor_mean = G_hor.mean()
G_ver_mean = G_ver.mean()
if G_ver_mean > 2*G_hor_mean:
print(‘horizontal pattern’)
elif G_hor_mean > 2*G_ver_mean:
print(‘vertical pattern’)
else:
print(‘neither horizontal nor vertical pattern’)
Op dit moment is er sprake van werkelijke softwarecode. Als dit ook nog een eigen creatie is (en dus niet ontleend is aan een ander, zie de vorige voorwaarde) dan is er duidelijk een beschermd werk tot stand gekomen. In het geval van gecompileerde programmeertalen, zoals bijvoorbeeld C++, wordt de broncode omgezet in machinecode (objectcode) die door de computer kan worden uitgevoerd. Deze code vormt een eventuele vierde stap en valt volledig binnen de bescherming van het software-auteursrecht.
Overigens is softwarecode in de praktijk vaak een stuk langer dan in dit voorbeeld. Of inbreuk kan worden vastgesteld, hangt in zulke gevallen ook af van de hoeveelheid overlap. Vergelijk dit bijvoorbeeld met bladmuziek: wanneer enkele akkoorden overeenkomen, is er doorgaans geen sprake van inbreuk. Maar het kopiëren van een gehele melodie zal vaak wél inbreuk opleveren.
Naast het (software-)auteursrecht bestaat soms ook de mogelijkheid om software octrooirechtelijk te beschermen (een octrooi is de juridische benaming voor een ‘patent’). Hier komt wel veel meer bij kijken. Dit zijn de belangrijkste hobbels en bezwaren:
Technische functie
Octrooien zijn tijdelijke monopolies op uitvindingen. De klassieke voorbeelden van octrooieerbare uitvindingen zijn apparaten of werkwijzen die een concrete technische functie vervullen. Een batterij geeft energie, een medicijn heeft een farmaceutische werking en een werkwijze om data te verzenden kan gebruikt worden om te communiceren. Omdat softwarecode minder tastbaar is, werd octrooibescherming lange tijd niet mogelijk geacht. Daarin is inmiddels verandering gekomen, maar het vereiste van een technische functie blijft wel een belangrijk criterium: de software in kwestie moet werkelijk een technisch resultaat opleveren, net als hardware, want anders valt het buiten de grenzen van het octrooirecht.
Nieuw en inventief
Twee belangrijke vereisten binnen het octrooirecht zijn nieuwheid en inventiviteit. Dat wil zeggen dat de software, om voor bescherming in aanmerking te komen, ten eerste nog niet ‘tot de bekende stand van de techniek’ mag behoren. Het mag dus nog niet ergens ter wereld al bestaan. Als daaraan is voldaan, volgt meteen een nieuwe hobbel: de uitvinding moet niet alleen nieuw zijn, het is ook vereist dat die niet voor de hand lag. Een alledaagse aanpassing is dus onvoldoende voor octrooibescherming. Wil software voor octrooibescherming in aanmerking komen, dan zal het daarom getoetst moeten worden op (onder meer) deze vereisten. Als de octrooiverlenende instantie van mening is dat de nieuwheid of inventiviteit ontbreekt, dan wordt geen octrooi verleend. Dit kan een langgerekt proces zijn dat soms wel jaren in beslag neemt.
Kosten
In tegenstelling tot het (software-)auteursrecht, is voor octrooibescherming wél registratie vereist. Dat wil zeggen dat je een aanvraag moet indienen. Het opstellen van zo’n aanvraag is gespecialiseerd werk en daarmee ook prijzig. En vaak wordt de aanvraag niet meteen geaccepteerd door het octrooibureau waardoor er wijzigingen moeten worden aangebracht, wat het proces nog duurder maakt. Bovendien moeten er registratiekosten betaald worden en, als het octrooi verleend wordt, ook nog eens instandhoudingskosten. De totale kosten liggen daardoor vaak boven de EUR 5.000 en kunnen oplopen tot vele tienduizenden euro’s (ook afhankelijk van het aantal landen waarvoor octrooi wordt aangevraagd). Bovendien koop je daarmee geen zekerheid: het octrooi kan altijd geweigerd worden of, in een later stadium, door de rechter ongeldig worden verklaard.
En de voordelen van octrooirechtelijke bescherming?
Dit alles neemt niet weg dat een geldig octrooi een krachtig instrument kan zijn, waarmee je anderen vrijwel alle activiteiten kunt verbieden die iets met de uitvinding te maken hebben. Bovendien kan octrooibescherming wel 20 jaar duren. Wanneer je door alle hoepels bent gesprongen en de beschermde uitvinding bovendien praktische waarde blijkt te hebben, dan kan een software-octrooi een wapen met grote vuurkracht zijn. Dat ondervond ook Microsoft toen het $115 miljoen moest betalen aan het kleine Z4 Technologies na inbreuk op diens octrooi voor anti-piraterij-software (klik hier voor de uitspraak). Maar het lot van de meeste software-octrooien is helaas (of gelukkig) een stuk minder opzienbarend.
♦ Software kan auteursrechtelijk beschermd zijn
♦ Voorwaarden: (1) eigen creatie en (2) voldoende uitgewerkt
♦ Eigen creatie is geen zware eis: zolang de software niet is overgenomen van anderen, wordt hieraan al gauw voldaan
♦ Voldoende uitgewerkt: er mogen weinig of geen programmeerkeuzes meer resteren. Een concept op papier is niet beschermd als dit nog op verschillende manier kan worden uitgeprogrammeerd
♦ Broncode en doelcode (machinecode) zijn sowieso voldoende uitgewerkt
♦ Software kan ook met een octrooi (patent) worden beschermd
♦ Deze octrooi (patent)-route is ingewikkelder en duurder
♦ Een softwareoctrooi (-patent) kan in bijzondere gevallen wel een krachtig wapen zijn
Licentieovereenkomst opstellen? Dit zijn de valkuilen en aandachtspunten… Introductie: licentieovereenkomst Je besluit dat een buitenlands bedrijf onder jouw merknaam producten op de markt mag brengen.
Wordt jouw product nagemaakt? In dit blog bespreken we de juridische beschermingsmogelijkheden van het auteursrecht, modelrecht, merkenrecht, octrooirecht en de leer van de slaafse nabootsing.
Er bestaan veel misverstanden over octrooien. Is een octrooi bijvoorbeeld iets anders dan een patent? En zijn octrooien altijd duur?
