Juridische vraag: Welk auteursrecht zit er op software?
Heb jij een uitdagende vraag over beveiliging, recht en privacy, stel hem dan aan ICT-jurist Arnoud Engelfriet en maak kans op zijn boek "De wet op internet". Arnoud is van alle markten thuis, maar vindt vooral in technische / hacking vragen een uitdaging. De Juridische vraag is een nieuwe rubriek op Security.nl, waar wetgeving en security centraal staan. Elk kwartaal kiest Arnoud de meest creatieve vraag, die dan zijn boek zal ontvangen.
Vraag: Er is tegenwoordig erg veel source code beschikbaar en daar zijn veel verschillende licentiemodellen voor. Hierdoor ontstaat een wirwar aan concepten en wordt het allemaal heel onduidelijk. Als er geen expliciete licentie over de rechten van de source code is aangegeven, is er dan een default copyright op source code zoals onder het Nederlands auteursrecht? Is dit expliciet voor de source code of is dit algemeen auteursrecht?
Antwoord: Op software zit auteursrecht, net als op teksten, foto's, films, muziek enzovoorts. Het uitgangspunt van de Auteurswet is dat toestemming nodig is voor het gebruik, tenzij er een wettelijke uitzondering is op grond waarvan je de software toch mag gebruiken. Zo mag je citeren of een parodie op een werk maken zonder toestemming te hebben, maar dat zijn allebei geen dingen die je vaak met software doet (bij mijn weten dan). Muziek en films mag je voor eigen gebruik kopiëren (en dus ook downloaden) ongeacht de bron, maar dat recht geldt nu net niet voor software. Van software mag je wel 1 reservekopie maken, maar daarvoor moet je legaal verkrijger zijn van die software. Auteursrecht geldt overigens voor de broncode net zo hard als voor de executable, dat zijn twee kanten van dezelfde medaille.
Wel biedt de wet een bijzondere regeling voor de 'legale verkrijger' van software. Die mag hij, ongeacht de licentie, installeren en gebruiken voor het "beoogde doel" waarmee hij de software heeft verkregen (art. 45j Auteurswet).
Al dat geen noodzakelijk is voor het "beoogde doel", mag je doen met de software. De vraag is natuurlijk wel wat dat beoogde doel is en wat daarvoor noodzakelijk is. Vandaar dat de meeste mensen toch maar gewoon voor de licentie kiezen, daar staat immers precies in wat je mag en waartoe.
In veel gevallen krijg je die licentie als een EULA, een doorklikvenster met juridische mumbo-jumbo die niemand leest. Over de rechtsgeldigheid van EULA's heb ik elders al uitgebreider geschreven. Het probleem bij veel EULA's is dat je ze pas te zien krijgt nadat de koop is gesloten, en dat is wettelijk gezien simpelweg te laat. Bovendien kunnen EULA-voorwaarden vaak niet worden uitgeprint of opgeslagen, wat ook een wettelijke eis is bij algemene voorwaarden. EULA's zijn dus in veel gevallen juridisch van tafel te krijgen. Nadeel daarvan is wel dat je dan vaak ook een aantal rechten verliest. Je valt terug op het wettelijk gebruiksrecht, en dat is een stuk beperkter dan de gemiddelde Enterprise-licentie.
Heb je een goede inkoper of bedrijfsjurist, dan neem je met EULA's geen genoegen maar onderhandel je een bedrijfssspecifieke licentie. Dat kan, alleen zit je dan natuurlijk wel vast aan wat je afspreekt. En omdat je erover hebt onderhandeld, zal het niet meevallen om bij de rechter te betogen dat het zo oneerlijk geschreven is of dat je niet besefte wat je tekende.
De derde optie is open source, waar ook licenties aan vast zitten. Open source licenties zijn ook rechtsgeldig, maar je hoeft ze pas te aanvaarden als je software wilt aanpassen of verspreiden. Voor bedrijfsinterne toepassingen (de eigen website of mailserver) heb je niets te maken met die licenties. Wel even uitkijken: als je software gebruikt of verspreidt op een manier die de licentie (of het wettelijk gebruiksrecht) te buiten gaat, dan schend je het auteursrecht en daar staan zware sancties op. Hoge schadevergoedingen, een volledige proceskostenvergoeding en zelfs inbeslagname van de apparatuur met die software erop zijn allemaal mogelijk.
Arnoud Engelfriet is ICT-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. In 2008 verscheen zijn boek "De wet op internet".
Heb jij ook een vraag voor Arnoud en wil jij kans op zijn boek maken? Stuur dan je vraag naar juridischevraag@security.nl
En zo ontzettend veel licenses zijn er eigenlijk niet in de open source wereld; minder dan 10 echt veel gebruikte en ergens in de 100 'kleine' geloof ik. Bij propietary software moet je met elke leverancier aparte afspraken maken. Als je die zou gaan tellen kom je op een aantal met een boel nulletjes uit.
Desalniettemin moet je natuurlijk altijd opletten wat je aan het doen bent, en open source is zeker geen vrijbrief om maar te doen waar je zin in hebt. Als je iets van een ander gebruikt, moet je *altijd* de licentie opvragen, en bekijken hoe dat in de situatie past (if at all).
Daarnaast vond ik het een vrij oppervlakkig maar wel interessant stuk.
De gemiddelde IT’er klikt accept and next wanneer het EULA scherm wordt getoond. Ik vraag me af hoeveel Microsoft engineers ooit de EULA hebben gelezen.
Ik had het wel fijn gevonden als je iets dieper op de open source litenties was ingegaan. Ik denk dat het vaker in het daglicht gesteld moet worden.
Maar voor de rest was 1912 een goed jaar, of niet?
Leuk detail uit de FAQ:
5) Do I need a license to distribute mp3, mp3PRO or mp3surround encoded content?
Yes. A license is needed for commercial (i.e., revenue-generating) use of mp3/mp3PRO in broadcast systems (terrestrial, satellite, cable and/or other distribution channels), streaming applications (via Internet, intranets and/or other networks), other content distribution systems (pay-audio or audio-on-demand applications and the like) or for use of mp3/mp3PRO on physical media (compact discs, digital versatile discs, semiconductor chips, hard drives, memory cards and the like).
However, no license is needed for private, non-commercial activities (e.g., home-entertainment, receiving broadcasts and creating a personal music library), not generating revenue or other consideration of any kind or for entities with associated annual gross revenue less than US$ 100 000.00.
En SirDice: je verwijst naar patentlicenties, wat weer een ander onderwerp is dan auteursrechtlicenties. Met auteursrechtlicenties heb je niets te maken als je gewoon downloadt en installeert, met patentlicenties wel wanneer het gebruik bedrijfsmatig is.
Open source licenties zijn ook rechtsgeldig, maar je hoeft ze pas te aanvaarden als je software wilt aanpassen of verspreiden. Voor bedrijfsinterne toepassingen (de eigen website of mailserver) heb je niets te maken met die licenties.
Dit wijkt af van het beeld dat ik ervan heb, en dat komt hier op neer:
Je hebt wel degelijk te maken met die licenties, zonder die licenties mag je volgens de auteurswet de software namelijk helemaal niet gebruiken. Maar zolang het bij eigen gebruik blijft zullen opensourcelicenties je nooit in de weg zitten.
Aanpassen van de software is ook een recht dat opensourcelicenties je expliciet geven. Ook hier geldt dat je geen licentieproblemen zal krijgen als dit voor eigen gebruik is.
Je hebt recht om de software, al dan niet aangepast of verwerkt in een eigen product, verder te verspreiden. Nu wordt het zaak om wel goed te kijken wat de opensourcelicentie zegt, omdat de licentie je hier geen onbeperkte rechten geeft, de verdere verspreiding is aan voorwaarden gebonden die per licentie kunnen verschillen.
Het komt vreemd op me over om te stellen dat je de licenties pas hoeft te aanvaarden als je software aanpast of verspreid. Wat geeft je het recht om de software te gebruiken als je de licentie die je dat recht geeft afwijst? Zijn de rechten die een licentie je geeft wel afhankelijk van het aanvaarden of afwijzen van de licentie?
Bij dit alles ga ik ervan uit dat onder opensourcelicenties de licenties worden bedoeld die voldoen aan de Open Source Definition (http://opensource.org/docs/osd).
Klopt dit beeld een beetje?
Met de GPL, de licentie bij GNU Emacs heb je dan verder niets te maken. Sterker nog, de GPL zegt in artikel 5 dat je niet verplicht bent hem te accepteren.
Je hebt geen wettelijk recht software aan te passen of te verspreiden. Wil je dat toch doen, dan moet je je aan de licentie houden anders pleeg je inbreuk op het auteursrecht. De licentie van GNU Emacs geeft je toestemming dit te doen, maar je gewijzigde versie mag je alleen verspreiden onder de GPL.
Als je de GPL afwijst, heb je dus geen van de rechten die de GPL je geeft, maar je bent ook niet gebonden aan een van de plichten die men daarin stelt. Je dient je dan te houden aan wat je volgens de Auteurswet wel en niet mag. Is alleen een gebruiksrecht genoeg, dan kun je de GPL vrolijk negeren. Wil je Emacs wijzigen en/of verspreiden, dan dien je de GPL te aanvaarden.
(Een soort-van complicatie is dat in het Amerikaans auteursrecht het uitvoeren van software niet onder de Auteurswet valt. Alleen het kopiëren, wijzigen en verspreiden. In Amerikaanse literatuur zie je dus nogal eens discussie over mensen die 'executing' willen reguleren in een OSS licentie, wat formeel niet zou moeten kunnen. Maar in Europa is uitvoeren expliciet onder de exclusieve rechten geschoven; het wettelijk gebruiksrecht moet daar enige balans bij brengen.)
Met de GPL, de licentie bij GNU Emacs heb je dan verder niets te maken. Sterker nog, de GPL zegt in artikel 5 dat je niet verplicht bent hem te accepteren.
Je hebt geen wettelijk recht software aan te passen of te verspreiden. Wil je dat toch doen, dan moet je je aan de licentie houden anders pleeg je inbreuk op het auteursrecht. De licentie van GNU Emacs geeft je toestemming dit te doen, maar je gewijzigde versie mag je alleen verspreiden onder de GPL.
Als je de GPL afwijst, heb je dus geen van de rechten die de GPL je geeft, maar je bent ook niet gebonden aan een van de plichten die men daarin stelt. Je dient je dan te houden aan wat je volgens de Auteurswet wel en niet mag. Is alleen een gebruiksrecht genoeg, dan kun je de GPL vrolijk negeren. Wil je Emacs wijzigen en/of verspreiden, dan dien je de GPL te aanvaarden.
(Een soort-van complicatie is dat in het Amerikaans auteursrecht het uitvoeren van software niet onder de Auteurswet valt. Alleen het kopiëren, wijzigen en verspreiden. In Amerikaanse literatuur zie je dus nogal eens discussie over mensen die 'executing' willen reguleren in een OSS licentie, wat formeel niet zou moeten kunnen. Maar in Europa is uitvoeren expliciet onder de exclusieve rechten geschoven; het wettelijk gebruiksrecht moet daar enige balans bij brengen.)
Dank voor je toelichting. Veel van de discussies over dit onderwerp die je op internet aantreft worden vanuit een Amerikaans perspectief gevoerd. Het is goed om eens te horen hoe het in Nederland wordt opgevat.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
