Regelmatig wordt er in verschillende media aandacht geschonken aan het (toenemend) gebruik van open source software. Uit de praktijk blijkt vaak ook, dat men onvoldoende op de hoogte is van de juridische status van open source software. Handel in software is een handel in rechten. Dat geldt zeker ook voor open source software! Het feit dat er vaak geen kosten aan verbonden zijn, wil nog niet zeggen dat er geen verplichtingen mee gemoeid zijn
Op 14 juni 2013 heeft de Duitse rechter een belangrijke uitspraak gedaan voor de open source praktijk in de zaak Welte/Fantec.
In de zaak is Welte een open source ontwikkelaar van en auteursrechthebbende op ‘netfilter/iptables’. Deze software wordt verstrekt onder GPLv2 licentievoorwaarden. Deze licentievoorwaarden bepalen onder meer, dat het gebruik, het verspreiden en het kopiëren van de software toegestaan is. De GPLv2 licentievoorwaarden stellen echter wel de eis, dat de licentienemer verplicht is om dezelfde licentievoorwaarden te verbinden aan de verdere distributie van de in licentie gegeven software, wat tevens geldt voor kopieën en wijzigingen aan deze software. Voorts verplichten deze licentievoorwaarden dat de broncode beschikbaar moet zijn voor de volgende licentienemer.
De open source software van Welte is verwerkt in een product (mediaspeler) van het bedrijf Fantec. Fantec maakt namelijk gebruik van firmware van een Chinese leverancier, waarin de “iptables” – software van Welte is verwerkt. De broncode wordt echter niet conform de GPLv2 voorwaarden beschikbaar gesteld.
De rechter oordeelt dat er sprake is van schending van de licentievoorwaarden. Hierbij geeft de rechter aan, dat Fantec een eigen verantwoordelijkheid heeft ten opzichte van het gebruik van open source componenten en zich dus niet kan verschuilen achter een tussenpartij (de Chinese leverancier). De licentienemer is zelf verantwoordelijk voor eventuele schendingen van intellectuele eigendomsrechten, ook indien de leverancier hiervoor instaat.
Dezelfde Welte heeft in 2004 overigens het bedrijf TomTom succesvol aangesproken op het feit, dat TomTom niet conform de GPL-licentievoorwaarden handelde.
Uit deze zaken blijkt het belang van het actief controleren van open source compliancy voor zowel leveranciers als licentienemers.
Ook voor software escrow is open source compliancy essentieel. De Arbit-voorwaarden van de overheid bepalen bijvoorbeeld, dat leveranciers verplicht zijn om te voorzien in een escrow-regeling, ook in geval de software open source componenten bevat. Voor het in depot nemen van software is het noodzakelijk om te beoordelen of de software open source componenten bevat om mogelijke acties van auteursrechthebbenden, zoals in de praktijk gebeurt, en daarmee eventuele frustratie van afgifterechten te voorkomen.
Tja Andre,
De bekende voorbeelden die je noemt zijn iid nogal voor de hand liggend.
Akkoord gaan met een licentie om er vervolgens niet mee akkoord te gaan zoals een met name een aantal Duitse bedrijven onder het motto ‘ik hoef mij niet aan die licentie te houden’ is zoiets als ik koop een Windows licentie en verkoop die meerdere malen verder omdat ik vind dat meneer Gates al rijk genoeg is. Niet echt een degelijke onderbouwing.
Wel is het tegenwoordig zo dat je als ITer haast jurist moet zijn om nog iets van die hele licentiebrei te begrijpen.
Het is inderdaad een onderwerp dat door velen over het hoofd gezien wordt.
Ontwikkelaars plukken iets van het internet wat handig is, en stoppen dat in een product zonder zich te bekommeren om licenties. Immers, het is toch open source, niet dan?
Bewustzijn creëren bij je medewerkers en integratoren is een stap in de goede richting, maar beter nog zou je een streng control board met o.a. IT-Juristen erin hebben die bepaalt welke software er gebruikt kan/mag worden onder welke voorwaarden.
Door ontwikkelaars wordt dit echter ook weer vaak gezien als beperking in de creativiteit…. totdat ze (werkgever) de rekening gepresenteerd kijgen
Allemaal zwartkijkers.
Het principe is eenvoudig.
GPL-2 software mag je gebruiken op zoveel machines als je wilt.
Kopieren is toegestaan.
Veranderen is toegestaan, je mag er mee doen wat je wilt zolang je het zelf gebruikt.
Wanner je de software wilt verspreiden ben je verplicht dat te doen met de bronkode erbij.
Heb je wijzigingen aangebracht die je wilt verspreiden, dan ben je verplicht de bronkode van je wijzigingen vrij te geven, ook onder de gpl-2.
Wanneer je een stukje gpl-software inbouwt in een commercieel produkt ga je risiko’s nemen, dan heb je een jurist nodig.
Genoemde firma’s bouwden gpl-software in hun commercieel produkt zonder hun kode vrij te geven, dat mag niet en is ook nog immoreel.
@ PaVaKe,
Goede toevoegingen. Alleen is een it-jurist vaak niet genoeg. Een goede onafhankelijke securityspecialist is geen overbodige luxe.
Typisch weer voor een jurist om het moeilijker voor te stellen dan het lijkt. De intentie van de GPL is juist om innovatie met elkaar te delen door code vrij te geven. Je hoeft geen jurist te zijn om dat principe te snappen. In het geval van GPL is het is iets strenger en moet je bij verspreiding van software ook veranderde broncode erbij leveren. Dat geldt niet voor alle types open-source licenties overigens.
Dat maakt het juist makkelijker om aan de escrow voorwaarde te voldoen want als partij ben je dan altijd in bezit van de orginele broncode en kan een ieder hier onderhoud op plegen. En dus ook bij failliesementen gaat die vlag op.
En wat gebruik van software betreft lijkt het nogal raar om te impliceren dat open-source software anders behandeld zou moeten worden als closed-source software. Bij beiden moet je goed nagaan welke randvoorwaarden aan het gebruik zitten. En desnoods er samen met een jurist naar te kijken.
Voor escrow lijkt me dit allemaal geen probleem. Geen enkele open source licentie verbiedt het maken van een backup door een derde die later door een ander weer kan worden gelezen, wat escrow in feite is. Mocht het ooit nodig zijn de source uit escrow te halen dan gelden nog steeds de open source licenties.
@Jan van Leeuwen: een klein ding: de standaard formulering in GPL v2 is dat je aangepaste software onder de GPL v2 OF HOGER dient uit te leveren. Dat kan van belang zijn omdat dat dus ook GPL v3 kan zijn, die enkele trucs tegen het installeren van zelf gecompileerde software via gesloten bootloaders e.d. manier verbieden (in dat geval dient men ook de sleutels die daarvoor nodig zijn vrij te geven). Alleen in de Linux kernel is die “of hoger” expliciet uit de licentie gehaald.
@Ruud Mulder
waarom een security-specialist?
@Johan:
“En wat gebruik van software betreft lijkt het nogal raar om te impliceren dat open-source software anders behandeld zou moeten worden als closed-source software.”
Klopt … zou moeten.
De praktijk wijst echter anders uit, zoals ik al aangaf in een eerdere reactie. Een ontwikkelaar kan makkelijk open source software downloaden en gebruiken, zeker als deze gratis is.
Om commerciële software te gebruiken moet hij een heel ander traject door om dit te kunnen gebruiken.
Dit kan een keerzijde zijn van de laagdrempeligheid van het gebruik van open source.
@Pa Va Ke
Even het onderscheid maken tussen commercieel en closed-source graag. Er zijn zat open-source producten waarbij een commerciële licentie voor commercieel verbruik wordt geëist.
Dit geldt overigens voor het gebruik van auteursrechtelijk beschermde werken in het algemeen. Een licentie is dan ook een vrijwaring voor het gebruik ervan onder bepaalde voorwaarden.
@Peter … wat bedoel je met onderscheid maken tussen commercieel en closed source in je reactie?
Wat ik probeer aan te geven is dat het toevoegen van (eventueel) gratis open source software aan een product heel eenvoudig door een ontwikkelaar gedaan kan worden. Wil hij een commercieel pakket toevoegen aan een product, dan krijgt hij doorgaans te maken met de inkooporganisatie van zijn bedrijf, en wordt er langs die as wellicht al kritisch(er) gekeken naar bijbehorende licentievoorwaarden.
De meeste mensen, zo ook ontwikkelaars, lezen de licentievoorwaarden niet eens (wie kent ‘m niet: “enter, enter, enter en je bent er”