Juridische vraag: Wat mag je met opensource?
Heb jij een uitdagende vraag over beveiliging, recht en privacy, stel hem 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 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: Bij de discussie naar aanleiding van mijn antwoord over auteursrecht op software kwam naar voren dat er nog veel onduidelijkheid over open source (OSS)-licenties is. Daar ga ik deze keer wat uitgebreider op in.
Antwoord: Open source licenties zijn juridisch gezien niet anders dan andere licenties. Je krijgt toestemming om de software te kopiëren, te verspreiden en aan te passen maar daar zitten wel voorwaarden aan. Die voorwaarden zijn zelf wel nogal anders dan traditionele ("gesloten") licenties, en dat is waar veel van de misverstanden over open source vandaan komen.
Het meest gehoorde misverstand is dat open source niet commercieel gebruikt zou mogen worden. Dit komt volgens mij omdat "commercieel" twee betekenissen heeft: (1) geld verdienen en (2) royalties verdienen. Het is zonder meer toegestaan om open source te verkopen of verhuren, en al het geld dat je daarmee verdient, mag je zelf houden. Je mag zelf je prijs bepalen, het hoeft niet beperkt te zijn tot de kosten van de drager waar de software op staat. Ik brand graag een CD met willekeurig welke open source voor je, maar dat kost je wel 995 euro per CD. Volstrekt legaal.
Wat ik echter niet mag doen, is de broncode van die open source geheim houden. Tenminste, in geval van de GPL en vergelijkbare licenties. Er zijn liberalere open source licenties, zoals de BSD, MIT en Apache licenties waarbij dat wel mag. Dit is iets waar bedrijven in het verleden wel over struikelden. Zij pasten GPL software aan en verkochten dat in binary-only vorm. Vervolgens kregen ze Stallman en consorten op hun dak, die eisten dat de broncode vrijgegeven werd onder GPL. "Zo kan ik geen zaken doen!" was de reactie, en het misverstand "open source is niet commercieel bruikbaar" was geboren.
Als je verwacht geld te verdienen per kopie, dan is open source inderdaad niet handig om te gebruiken. Iedereen mag open source kopiëren en verspreiden, dus ook jouw klanten. Als je pech hebt, verkoop je je software dus maar één keer en downloadt iedereen het vervolgens gratis van die klant. Zoek dus maar beter een bedrijfsmodel waarbij het niet erg is dat de open source in je product of oplossing door iedereen gratis wordt weggegeven. Op uurtje-factuurtje basis de software installeren of wijzigen bijvoorbeeld, of een bedrijf trainen in het gebruik.
Verder, ik noemde het al even, bepalen veel open source licenties dat je gewijzigde of uitgebreide versies alleen onder diezelfde licentie mag verspreiden. Er is geen plicht om wijzigingen vrij te geven, maar als je ervoor kiest om bv. GPL-software in gewijzigde vorm te verspreiden, dan moet de broncode van je gewijzigde versie erbij en die moet onder de GPL geplaatst zijn. Ook dat is voor sommige bedrijven een probleem: zij willen als enige die gewijzigde versie leveren omdat dat ze een uniek voordeel levert. Tsja, dat gaat dus niet gebeuren.
De GPL legt deze bepalingen ook op aan "afgeleide werken", een begrip waarvan nog steeds niet duidelijk is wat het nu precies inhoudt. Het is meer dan "gewijzigde versies" maar minder dan "alle software op dezelfde CD".
Maar let wel: de bepaling geldt alleen bij verspreiding van de software. Wie binnen zijn bedrijf GPL software inzet, heeft niets te maken met deze bepaling. Een bedrijf mag dus GPL software aanpassen en uitbreiden en gebruiken zo veel ze wil, zonder te hoeven betalen aan wie dan ook en zonder verplicht te zijn ook maar een puntkomma vrij te geven. Het is wel netjes en vaak ook verstandig om te doen: zo hoef je niet bij elke nieuwe versie weer al je wijzigingen door te voeren.
En ja, dit geldt ook voor SaaS-oplossingen en andere webapplicaties. Die worden niet verspreid in de zin van de GPL (of andere open source licenties, met uitzondering van de Affero GPL) en dus hoef je je op open source gebouwde SaaS-oplossing of webapplicatie niet vrij te geven.
Hoe gebruiken jullie open source in je bedrijf of dienstverlening?
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".
De 'Software' waar je op doelt is bij gebruik eigendom van de zaak. Dat houdt in essentie in, dat zij bepalen OF de software mag worden gekopieerd/vrijgegeven. Wanneer ze er dus voor kiezen om dat niet te doen, is het niet aan de medewerker om dat alsnog zelf te doen. Ook als hij de schrijver van de software is. Om als medewerker eigendomsrechten op de software te hebben (en dus feitelijk de licentie te bepalen) zal die medewerker daar apart voor moeten onderhandelen met het bedrijf.
Je krijgt alleen rechten wanneer je legaal een kopie van GPL software weet te bemachtigen. Die medewerker kan dat niet persoonlijk voor elkaar krijgen. Als hij een kopie thuis blijkt te hebben liggen en zijn ex-manager zegt "ach, hou maar", dan wordt het interessant.
Omdat je door de aanschaf van open source geen eigenaar van de (bron)code bent geworden en/of het copyright kan je die ook niet weer exclusief doorverkopen. Aanpassen en verder verspreiden is mooi en omdat je verder bouwt op je voorgangers werk is het dus ook logisch zelf je aanpassingen en verbeteringen door te geven.
De simpele uitleg, die werkt voor mensen die er nooit bij stil hebben gestaan of er nooit mee te maken hebben gehad.
Meer uitleg (vooral USA) zoals altijd bij Groklaw van ons Pamela ;)
http://www.groklaw.net/article.php?story=20031231092027900
Zelf gebruik ik voor mijn bedrijf vooral op de server open-source software.
Ubuntu, Apache, PostgreSQL, PHP, Postfix, PureFTPd, ClamAV, amavis-new, Perl, en zo kan ik nog wel even door gaan :)
Helaas op kantoor iets minder, maar daar ben ik wel mee bezig.
Met LGPL kunnen libraries ook worden gebruikt in niet GPL software. Bij GPL kan dat niet.
Zo kun je wel gcc (GPL) gebruiken om een programma te compileren, want gcc gebruik je daarna niet meer, maar je mag geen GPL libraries linken in niet-GPL software.
GPL is een virus: het besmet andere software met de beperkende licentie. Daarom is het voor commerciele ontwikkelaars noodzakelijk GPL libraries te vermijden.
Zie http://www.gnu.org/licenses/lgpl.html
De term "free" (vrij) is misplaatst, GPL software is niet "free", integendeel. De BSD licentie is wel vrij te gebruiken.
De 'Software' waar je op doelt is bij gebruik eigendom van de zaak. Dat houdt in essentie in, dat zij bepalen OF de software mag worden gekopieerd/vrijgegeven. Wanneer ze er dus voor kiezen om dat niet te doen, is het niet aan de medewerker om dat alsnog zelf te doen. Ook als hij de schrijver van de software is. Om als medewerker eigendomsrechten op de software te hebben (en dus feitelijk de licentie te bepalen) zal die medewerker daar apart voor moeten onderhandelen met het bedrijf.
Ja , ok maar als die ontslagen medewerker met de code naar een ander bedrijf gaat, is er geen enkel controle middel om uit te maken als de ontslagen programmeur dezelfde code - ontwikkelt op kosten van zijn oud bedrijf - gebruikt?
Ja , ok maar als die ontslagen medewerker met de code naar een ander bedrijf gaat, is er geen enkel controle middel om uit te maken als de ontslagen programmeur dezelfde code - ontwikkelt op kosten van zijn oud bedrijf - gebruikt?
Dit is inderdaad zo. Er is voor zover ik weet een gerechtelijke uitspraak (VS, maar toch) die het mogelijk maakt voor de originele programmeur om zijn werk re re-creeeren. Het is namelijk door de rechter bepaald, dat het niet mogelijk is om een programmeur zijn originele werk te laten 'vergeten' (D'oH!)
Er zijn echter wel degelijk mogelijkheden om aan te kunnen tonen of de software (de gebruikte algoritmes en Program Logic) inderdaad opnieuw zijn geprogrammeerd, of dat uitgegaan is van de oudere sourcecode. Aangezien de originele eigenaar (het genoemde bedrijf) de source niet vrijgegeven heeft, MOET deze dus gestolen zijn. En ja.. er is dan sprake van diefstal, ook al is de source een aangepaste versie van iets wat van origine GPL op internet te krijgen is. De code-fork in kwestie is dat namelijk niet. Die wordt pas weer GPL als ie vrijgegeven wordt.
GPL is een virus: het besmet andere software met de beperkende licentie. Daarom is het voor commerciele ontwikkelaars noodzakelijk GPL libraries te vermijden.
De term virus impliceert dat de getroffene geen keuze heeft, en is daarom zeer misplaatst. Ik geef ook meer van mijn code BSD dan GPL, maar om het nou een virus te noemen gaat toch echt te ver.
De term "free" (vrij) is misplaatst, GPL software is niet "free", integendeel. De BSD licentie is wel vrij te gebruiken.
Integen-tegendeel. De free slaat niet op de ontwikkelaar, maar op de ontvanger van de software. Bij GPL is die ook vrij om met de code te doen wat hij of zij wil, met als enige beperking dat er geen verdere restricties komen bij diegenen aan wie het daarna weer verspreid wordt. Bij BSD is alleen de *eerste* ontvanger dat. Als die besluit zijn aanpassingen ineens te sluiten, dan hebben de ontvangers daarvan helemaal niets meer kwa rechten op de source.
Integen-tegendeel. De free slaat niet op de ontwikkelaar, maar op de ontvanger van de software. Bij GPL is die ook vrij om met de code te doen wat hij of zij wil, met als enige beperking dat er geen verdere restricties komen bij diegenen aan wie het daarna weer verspreid wordt.
Dat laatste heet besmetten en dat is wat een virus ook doet. Jij bent een GPL believer. Geeft niet, zolang je dat zelf ook beseft en dat niet iedereen jouw geloof aanhangt.
Omdat je door de aanschaf van open source geen eigenaar van de (bron)code bent geworden en/of het copyright kan je die ook niet weer exclusief doorverkopen. Aanpassen en verder verspreiden is mooi en omdat je verder bouwt op je voorgangers werk is het dus ook logisch zelf je aanpassingen en verbeteringen door te geven.
De simpele uitleg, die werkt voor mensen die er nooit bij stil hebben gestaan of er nooit mee te maken hebben gehad.
Meer uitleg (vooral USA) zoals altijd bij Groklaw van ons Pamela ;)
http://www.groklaw.net/article.php?story=20031231092027900
Dat kunnen ze dus al jaren met de broncode van Windows. Leuk dat ze dat nu ook bij open source doen. ;-)
Integen-tegendeel. De free slaat niet op de ontwikkelaar, maar op de ontvanger van de software. Bij GPL is die ook vrij om met de code te doen wat hij of zij wil, met als enige beperking dat er geen verdere restricties komen bij diegenen aan wie het daarna weer verspreid wordt.
Dat laatste heet besmetten en dat is wat een virus ook doet. Jij bent een GPL believer. Geeft niet, zolang je dat zelf ook beseft en dat niet iedereen jouw geloof aanhangt.
Nee dat is niet besmetten. Ik ben in die zin een believer dat ik geen problemen met de licentievorm heb. Als anderen heb liever niet gebruiken snap ik dat best, en afhankelijk van de reden van het ontwikkelen van de software kan ik zelf ook genoeg redenen bedenken om voor een andere te kiezen. Maar spreken over 'virus' en 'besmetten' is je eigen oordeel over de licentievorm toevoegen aan het benoemen ervan, en bevordert de discussie niet.
Nee dat is niet besmetten. Ik ben in die zin een believer dat ik geen problemen met de licentievorm heb. Als anderen heb liever niet gebruiken snap ik dat best, en afhankelijk van de reden van het ontwikkelen van de software kan ik zelf ook genoeg redenen bedenken om voor een andere te kiezen. Maar spreken over 'virus' en 'besmetten' is je eigen oordeel over de licentievorm toevoegen aan het benoemen ervan, en bevordert de discussie niet.
Een virus besmet cellen met zichzelf, een GPL licentie besmet andere software met die licentie. Deze parallel berust volledig op feiten (waarnemingen/constateringen) en niet op meningen. Deze licentie infectie strategie is een duidelijk nadeel ten opzicht van bijvoorbeeld de BSD licentie en het is ook duidelijk dat de infectie de bedoeling is van GPL.
Je verwart de emotionele lading die je zelf hangt aan de termen virus en besmetten met de feitelijke waarneming dat GPL zich in bepaalde essentiële opzichten als een virus gedraagt.
Een virus besmet cellen met zichzelf, een GPL licentie besmet andere software met die licentie. Deze parallel berust volledig op feiten (waarnemingen/constateringen) en niet op meningen. Deze licentie infectie strategie is een duidelijk nadeel ten opzicht van bijvoorbeeld de BSD licentie en het is ook duidelijk dat de infectie de bedoeling is van GPL.
Of de licentiestrategie die jij infectie noemt een nadeel is, hangt in dit geval puur af van de vraag 'voor wie'. Voor iemand die er graag mee aan de haal wil gaan, en het wil gebruiken om vervolgens gesloten door te verkopen, ja. Dan is het een nadeel. Voor de developer die niet wil dat zijn uitbreidingen, of uberhaupt zijn software, door andere bedrijven alsnog later gesloten wordt kan het juist een voordeel zijn.
Je verwart de emotionele lading die je zelf hangt aan de termen virus en besmetten met de feitelijke waarneming dat GPL zich in bepaalde essentiële opzichten als een virus gedraagt.
Nogmaals, de woorden virus en besmetting, en inmiddels ook infectie, impliceren dat er geen keuze is. Dat de GPL je als het ware bespringt en al jouw andere software ineens converteert naar iets dat jij niet wil. Dat is onzin. Je kunt de voorwaarden van de GPL niet willen voor de uitbreidingen die jij erbij maakt. Maar dan heb je zelf de keuze om de GPL software niet als basis te gebruiken (of geen GPL in de kern te stoppen). Dan kies je dus voor een oplossing in BSD, of je schrijft zelf iets, of je koopt iets in. Nergens heb je niet zelf de keuze, en dus kun je niet spreken van viraal of besmetting.
Hoe vaker ik deze zin lees des te minder ik er van snap. Ben ik nu zo dom of u zo slim?
Hoe vaker ik deze zin lees des te minder ik er van snap. Ben ik nu zo dom of u zo slim?
Dat is vrij eenvoudig: Een dubbele ontkenning is in onze taal nog steeds een bevestiging: Nergens ... niet, ofwel:
Overal heb je zelf de keuze en dus kun je niet spreken van viraal of besmetting.
Hoe vaker ik deze zin lees des te minder ik er van snap. Ben ik nu zo dom of u zo slim?
Dat is vrij eenvoudig: Een dubbele ontkenning is in onze taal nog steeds een bevestiging: Nergens ... niet, ofwel:
Overal heb je zelf de keuze en dus kun je niet spreken van viraal of besmetting.
Dus als men inbreekt bij je provider en een virus installeert op al zijn klanten ben je net als alle andere klanten niet besmet, want had je een andere provider moeten kiezen???
Software die alleen geinstalleerd wordt als een klant van een provider het zelf doet noemt men doorgaans geen virus. Men noemt een stuk software een virus als het zichzelf ongevraagd bij anderen installeert. Als iemand zonder jouw medeweten of toestemming bij jou een stuk software installeert kan het al dan niet een virus zijn.
Als je jouw vergelijking op licenties toe zou passen zou de GPL zich zonder medeweten, of zonder toestemming, uit zichzelf bij een project naar binnen werken. Je hebt dus een project met een berg code met licentie Y, en zonder dat jij iets doet wordt alles ineens omgezet naar GPL. Zo krachtig is zelfs de GPL niet.
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.
