Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Open source compliancy is essentieel

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. 

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4799137). © Jaarbeurs IT Media.
?

 

Reacties

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"

@Pa Va Ke

De meeste mensen ?
in ICT bestaat 'de' niet.
Interessant artikel van je trouwens, je kunt er niet omheen.. blijkbaar ;-)

Licentievoorwaarden op waarde schatten voor de betreffende omgeving is gewoon noodzaak voor elke ICT professional.

Ik snap iets niet.

GPL eist dat als je een open source product als basis gebruikt, wijzigt en verspreidt dat je dan source code mee moet leveren. Anderen kunnen daar dan weer op verder bouwen.

Maar waarom zou je de source code moeten meeleveren als je het product alleen maar gebruikt? Die source is al beschikbaar en wel bij de bron.

Dit zou betekenen dat je nooit meer GPL software (ongewijzigd) kunt gebruiken embedded in een product als een mediaplayer of wat dan ook. Wat is dan nog de zin van open source?

Ergens mis ik iets in dit verhaal. Kan iemand dat nader uitleggen?

@brombeer

GPL eist niet dat je de source code mee hoeft te leveren maar eist dat je de source code beschikbaar stelt en het niet moeilijker maakt om te krijgen dan het is om jou executable te krijgen. Dus lever je executables van een bepaalde applicatie en zet daarna de code op bijvoorbeeld Github dan voldoe je gewoon aan de GPL licentie. Let op dit geld alleen als jou code nauw verbonden is met GPL code.

Je kunt uiteraard wel GPL software embedden in een product maar er word wel van je verwacht dat je duidelijke instructies mee leverd hoe ze aan de source van de GPL kunnen komen en hoe ze de applicaties kunnen herinstalleren. Maakt jou software gebruik van GPL libraries dan moet je jou software ook onder de GPL (of andere compatible) licentie leveren.

Voor meer duidelijkheid kun je altijd kijken of http://www.gnu.org/licenses/gpl-faq.html het beter uitlegt ;).

Channelweb Expert
André  Kamps

André Kamps
Partner, De IT-jurist. Expert van Channelweb voor het topic Management.
Hele profiel

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×