Tag: Licentie

About Licentie

Subscribe Feeds

Adobe zet je ontwerp op zwart (letterlijk) als je niet bijbetaalt voor kleurinformatie, wacht wat?

Geplaatst op in Ondernemingsvrijheid, 27 reacties
stux / Pixabay

Adobe-programma’s als Photoshop, Illustrator en InDesign hebben geen standaard toegang meer tot de meeste kleuren van Pantone, tenzij gebruikers daarvoor een abonnement afnemen. Dat meldde Tweakers onlangs. Wie dat abonnement niet neemt, krijgt zwarte vlakken waar eerst nog kleuren in de Pantone-kleurcoderingen stonden. Het verraste veel mensen, want hoezo kan Pantone auteursrecht claimen op een kleur? Dat kunnen ze ook niet, maar dankzij de wonderen van de cloud kan Pantone dit toch afdwingen.

Het bedrijf Pantone is marktleider in het vaststellen van kleurcoderingen, waarmee ontwerpers op eenduidige manier kunnen aangeven welke kleur bedoeld is. Dat lost bijvoorbeeld het probleem op dat een beeldscherm iets anders toont dan een printer produceert; als het bestand “PMS 012” vermeldt dan zal iedere drukker daar hetzelfde van maken. Een nuttige functie, waar wereldwijd op ingesprongen is en waardoor Pantone nu de dominante partij is in kleurcoderingen.

Het gaat natuurlijk om technische informatie: er zitten 2161 kleuren in het systeem, en van elke kleur is de hoeveelheid cyaan, magenta, geel en zwart vastgelegd. Ook krijgt elke kleur een naam, de Kleur van het Jaar 2022 is nummer 17-3938 en heet Very Peri (“Very Peri displays a spritely, joyous attitude and dynamic presence that encourages courageous creativity and imaginative expression”, aldus de jury).

Goed, leuk, maar is dat genoeg voor een auteursrecht? Ik betwijfel het zeer. Maar als je de hele lijst van 2161 kleuren mét code en naam neemt, dan denk ik dat daar wel een auteursrecht op rust. Wil je dus die hele lijst in je printer (of ontwerpprogramma) dan zul je een licentie moeten nemen. Fair enough, maar dat zou een eenmalig bedrag moeten zijn want het is absurd dat je jaarlijks betaalt voor zo’n lijst terwijl jouw klant het apparaat koopt of de software installeert op zijn desktop en daarvoor ook eenmalig betaalt.

Maar goed, toen kwam de cloud en werd alles anders (geen MLP referentie). Beter gezegd: Toen bedacht Adobe dat het veel leuker is dat je per maand betaalt voor haar tools, in plaats van eenmalig een enórme smak geld. En een paar jaar later dacht Pantone, dat kunnen wij ook. Vandaar dus die eis om maandelijks te betalen voor dat bestandje (en de merknaam), want als iemand zelf al aangeeft dat je per maand kunt betalen dan is als leverancier maandelijks afrekenen natuurlijk net zo logisch.

Heel erg juridisch is dit dus niet, dit is vooral een voorbeeld van hoe de cloud ingezet kan worden om nieuwe bedrijfsmodellen af te dwingen. En om diezelfde reden is er dus niets aan te doen, als je cloudtools gebruikt en de prijs gaat omhoog, dan kun je of betalen of wegwezen.

Arnoud

 

Als je open source als gratis leverancier ziet, dan krijg je dus dit

Geplaatst op in Intellectuele rechten, 25 reacties

Enige ophef op Twitter: OSS-developer Daniel Stenberg kreeg een nogal bars klinkende mail van een gebruiker, die hem als “Maxx Team Partner” aanschreef en graag binnen 24 uur wilde horen hoe zijn bedrijf was ingericht op het afdekken van risico’s rondom de enorme log4j bug van onlangs. “What is the timeline for completing remediation? List the steps, including dates for each.” Eh. Als ik daar leverancier was, zou ik dit niet heel lief vinden. Maar als je enkel iets op internet had gezet?

Het enige logische antwoord is wat Stenberg ook gaf: “I’d be happy to answer all the questions as soon as we have a support contract.” De algemene tip die ik al eerder aanried: OSS drijft op de gedachte van communities. Iedereen helpt elkaar, en daar kan iedereen dus terecht. Maar bedrijven werken met contracten, om zekerheid (althans, de illusie van) te realiseren en om leveranciers bij de nekharen te kunnen grijpen als blijkt dat er iets misging. A throat to choke, extern de schuld neerleggen zeg maar.

Open source licenties zijn natuurlijk contracten, dus als je als bedrijf software van Stenberg installeert (hij maakte onder meer cURL) dan heb je een leveranciersrelatie. Zou je kunnen zeggen als rechtlijnige inkoper. Maar er is dan in het geheel geen sprake van zelfs maar enige inspanningsplicht bij Stenberg, hier is de software en als ‘ie breekt, mag je de stukjes houden. Of zelf aanpassen, zie maar. Dat is de gedachte achter open source: je kunt er zelf mee aan de slag, veel plezier verder.

Ondertussen zijn we denk ik op het punt dat dit geen groot risico meer zou moeten zijn. Veel bedrijven stoppen hun interne pipeline en producten dan ook vol met open source, en ontdekken pas de problemen als er dingen zoals log4j zich voordoen: een kwetsbaarheid in een breed gebruikt stuk software, dat eigenlijk nauwelijks onderhouden wordt omdat die ene aardige man uit Nebraska er niet zo’n zin meer in heeft.

Helaas verbaast het me toch niet dat je zo’n reactie krijgt van een bedrijf dat al jaren gratis die software gebruikt. Het is natuurlijk juridisch complete onzin, je hebt niets te eisen als je geen afspraak over dat onderwerp hebt gemaakt. En zeker waar het gaat om gratis aangeboden software waarbij nadrukkelijk geen enkele verwachting werd gewekt, is dit ook nog eens moreel niet zo netjes. Maar ik snap het wel, dat is nu eenmaal de reflex waar je mee komt als je software van derden gebruikt die lek blijkt te zijn.

Toch zou het goed zijn als organisaties wat vaker op zoek gaan naar mogelijkheden om OSS projecten te sponsoren. Niet perse als dure SLA, maar betalen voor een stuk ontwikkeling voor de toekomst of een preventieve securityscan, het zou geen gek idee zijn. Natuurlijk, daar profiteert de concurrent dan weer van, maar we hebben het hier over software die per definitie geen competitief voordeel geeft, dus of dat nou de ergste reden moet zijn?

Arnoud

Een laptop met illegale software, is die nonconform eigenlijk? Joh!

Geplaatst op in Ondernemingsvrijheid, 10 reacties
Free-Photos / Pixabay

Stel je bestelt bij een klein IT-bedrijf een tweedehands laptop met het verzoek er software voor “tekeningen voor metaalconstructies” op te zetten, zodat je als zzp’er direct kunt gaan werken. Oh ja, en het mag 150 euro kosten. Zou je dan gek opkijken als er op zeker moment claims van de rechthebbende op die software komen, mede omdat de echte versie 6000 euro kost en een phone-home functie heeft? Afgaande op dit arrest komt dat voor, met daarbij dus de vraag of er geleverd is wat er besteld was.

De discussie bij de rechter spitste zich toe op wat er nu besteld was: een laptop geschikt voor AutoCAD Solidworks, een laptop met een trial zodat je kon zien dat die software erop zou werken, een laptop met een illegale (gekraakte) full versie of een geheel legale full versie? Het bedrag van 150 euro maakt dat laatste een tikje onwaarschijnlijk, maar het idee van een trial versie is misschien zo gek gedacht nog niet. Hoewel, de Nederlandse distributeur in de mail:

De enigen die ene trialversie kunnen regelen bij [softwarebedrijf] in NL zijn: [licentiebedrijf] , [naam 1] en [naam 2]. Dit is niet bedoeld voor doorverkoop, maar om te kijken of de software aansluit bij de wensen van de potentiële  klant. (…) Daarnaast zijn wij vanuit [licentiebedrijf] niet op de hoogte dat er een trialversie door [handelsnaam appellant] is geregeld. Dit kan het beste bij [softwarebedrijf] zelf worden gecheckt.
Het [licentiebedrijf] sprak de [handelsnaam appellant] van de laptop vervolgens aan op [illegaal] gebruik, waarna werd geschikt. Dat is dan meteen de reden voor het aanspreken op nonconformiteit natuurlijk, het verhalen van het schikkingsbedrag.

Het Gerechtshof kwam tot de tussenconclusie dat de klant maar moest bewijzen wat er precies besteld was. Als dat een legale versie van Solidworks was, dan zou de leverancier tekort geschoten zijn. Echter, zou dat niet de afspraak zijn geweest, dan waren alle gevolgen voor rekening en risico van de klant. De klant kwam daarop met een getuige, een van zijn werknemers:

Tegen [de leverancier] heb ik gezegd dat ik een laptop zocht met SolidWorks. Ik heb uitdrukkelijk gezegd dat het om SolidWorks ging. [De leverancier] zou gaan kijken of hij dat voor mij kon regelen. Er is op dat moment niet specifiek gesproken over een legale of illegale versie. Er is ook niets gezegd over een trialversie, alleen dat het om SolidWorks ging. [De leverancier] zei dat hij ervoor kon zorgen. Hij zou in eerste instantie kijken of hij aan mijn wensen kon voldoen om een laptop met die software te leveren. Er is bij de aflevering van de laptop nog gesproken over SolidWorks. Hij heeft aan de keukentafel bij mijn schoonouders gedemonstreerd dat er SolidWorks op de laptop zat. Hij heeft laten zien dat het programma er op zat door het programma te openen maar niet laten zien hoe het werkte. Er is niet gesproken over de versie van SolidWorks op het moment van aflevering.
Verder was niet gesproken over de aard van de Software. De klant kende deze niet, maar de software werd aangeraden door een zakenrelatie (een tekenaar) en men had geen idee wat het moest kosten, maar kan het voor 1000 euro?

Meer bewijs was er dus niet. Het Gerechtshof trekt vervolgens zelf de conclusie dat een bedrijf dat vraagt om een laptop met zakelijke software, normaal de bedoeling heeft om daarmee te werken. Dan heb je een legale, volledige versie nodig. Als je zonder nader overleg dus dit bestelt bij een leverancier, dan moet die begrijpen dat de volledige, legaal gekochte software erop moet. Geen trials en al helemaal geen gekraakte/illegale versies.

Natuurlijk kan dat wel eens te duur zijn – de standaardlicentie is 6000 euro. Maar zoiets even uitzoeken is toch echt deel van je zorgplicht als IT-leverancier. Je moet dus even doorvragen, en het is dan prima als je zegt “dit kan niet voor jouw budget want die licentie is zes keer wat jij hebt”. Of “dit gaat niet maar ik kan de open source FreeCAD er wel op zetten”. Of “ik heb een trial erop gezet, want die software kost 6000 euro en ik weet niet of je dat wel wil”. Of “wil je even bijbetalen dan koop ik die licentie voor je”. Maar niet leveren en achteraf zeggen:

Midden September 2017 heb ik een 2e hands laptop voor jou geregeld en geleverd, met daarop de trialversie van [softwareprogramma] . (…) Vanaf begin November 2017 is het gebruik van een niet legitieme software op een IP-adres gelokaliseerd van de gebruiker van de laptop. Dit is ruim anderhalf maand later, ik weet niet wat er in de tussentijd met de laptop is gebeurt en als het daadwerkelijk om de desbetreffende laptop gaat. Ik heb de laptop sinds midden September 2017 niet meer in mijn bezit en ik ben niet verantwoordelijk voor wat er in de tussentijd op de laptop gezet is en ermee gedaan word.
Nonconforme laptop dus, en/of wanprestatie onder de overeenkomst. Dat betekent betalen. Alleen, hoe veel?

De klant had de volledige € 7.500 in rekening gebracht, en het Hof erkent dat dat nu eenmaal de schade is. Dat men voor een echte licentie ook dik 6000 euro had moeten neerleggen, is dan niet relevant: bij een correcte nakoming had de klant niets aan Solidworks of haar distributeur hoeven te betalen. (Hetzij omdat de IT-leverancier de kosten in rekening had gebracht, hetzij omdat deze magischerwijs een licentie voor 1000k had kunnen kopn, hetzij omdat de klant had gezegd “ben je betoeterd, 6000 euro, doe maar FreeCAD”.) Bijgevolg komt die volledige 7500 ook echt voor rekening van de leverancier.

Het bevestigt het beeld van die zorgplicht: niet zelf bedenken wat de klant wil (of niet), maar onderzoeken en navragen. En natuurlijk op papier zetten (al is het maar de e-mail) wat de klant heeft gezegd.

Arnoud

 

Is een contributor license agreement wel gunstig voor een OSS ontwikkelaar?

Geplaatst op in Intellectuele rechten, 19 reacties

Een lezer vroeg me:

Ik wilde een bijdrage doen aan een opensourceproject. De stichting erachter geeft echter aan dat ik daarvoor een contributor license agreement (CLA) moet tekenen. Dit omdat OSS licenties problematisch zijn in Europa vanwege morele rechten? Enig idee hoe dat zit? En welke nadelen haal ik me op de hals?
Een contributor license agreement of CLA is een contract waarbij een persoon die een bijdrage levert aan een OSS project, de beheerder van dat project bepaalde rechten geeft. Op zich is dat niet nodig: de bijdrage zal onder dezelfde licentie zijn als het project zelf, en de beheerder kan de bijdrage dus zo opnemen onder die licentie. Het grote nadeel daarvan is natuurlijk dat je dan mogelijk honderden auteursrechthebbenden in je project hebt.

Voor veel projecten is het een brug te ver om de auteursrechten op te eisen, wat de juridisch beste oplossing zou zijn voor het probleem. En daarom komt men met CLA’s: daar staat namelijk in dat men een onbeperkte licentie krijgt, en/of de mogelijkheid om de OSS licentie naar een andere om te zetten. Als het project dan bijvoorbeeld van BSD naar GPL wil switchen, dan is er toestemming op voorhand van alle bijdragenden.

Er is het theoretisch risico dat een bijdragende zich op hun zogeheten persoonlijkheidsrechten beroept. Dat kan in Europa (artikel 25 Auteurswet, bij ons) en dan kun je met name optreden tegen verminking van je software. Dit ongeacht je licentietekst, want je kunt van dat verzet geen afstand doen. Dan zou je dus zeggen, ook al had ik het open source gemaakt, déze specifieke aanpassing haalt mijn naam als auteur keihard door het slijk, ik ben daar fysiek misselijk van en ik eis dat het stopt.

In de praktijk wordt aangenomen dat dit bij open source eigenlijk niet kan, met name omdat het heel moeilijk voorstelbaar is wat zo’n aanpassing dan zou moeten zijn. (Enkel het werk gebruiken in een verwerpelijke context is niet genoeg, het moet echt om een aantasting van het werk gaan.) Maar goed, als men er anders in zit dan is dit een ingewikkelde discussie. “Iemand op een blog zegt van wel” is meestal geen sterk juridisch argument.

Dit geldt trouwens óók na overdracht auteursrecht (zie lid 1 zin 1 van artikel 25) dus het is geen argument om een CLA in plaats van een OSS licentie te gebruiken.

Voor de bijdragende is er weinig tot geen voordeel voor een CLA. Zelden staat er bijvoorbeeld een betalingsregeling in, of een ander voordeel zoals inspraak of medebeslissingsrecht. Het enige echte voordeel zou zijn dat als je niet tekent, je code niet in het project komt.

Arnoud

 

Niet noemen open source licentie is auteursrechtinbreuk

Geplaatst op in Intellectuele rechten, 6 reacties

Apollo Fintech maakte inbreuk op het auteursrecht van Jelurida door een cryptomunt aan te bieden die is gebaseerd op de ‘Nxt software’, zonder daarbij de licentie van Jelurida (de Jelurida Public License of ‘JPL’) te verstrekken, zo meldde Rechtspraak.nl onlangs (via). Leuk dat dan ‘JPL’ tussen aanhalingstekens moet als kennelijk gekke term, terwijl cryptomunt gewoon ingeburgerd is. Maar dat terzijde: vrij uniek dat er rechtszaken komen over de naleving van open source licenties. Het is hier natuurlijk weer een speciaal geval, een ruzie tussen twee groepen die werken aan dezelfde software.

De Nxt software implementeert blockchains, en de organisatie Jelurida is ooit begonnen met de Nxt software te ontwikkelen. Zij gebruikt daarbij de Jelurida Public License, een zo te lezen van de GPL afgeleide eigen licentie met een paar opmerkelijke bepalingen. Of je de JPL écht open source kan noemen is  daarom de vraag: de licentie eist een betaling in jouw eigen cryptomunt als je met die software een alternatieve blockchain maakt die niet compatibel is met de originele. Dat is niet helemaal hoe we open source normaal bedoelen, namelijk dat alles mag en je nooit hoeft te betalen. Maar dat terzijde.

Een paar jaar later kwam er de club Apollo, die haar eigen cryptomunt aanbiedt. Daarbij dreef zij op de Jelurida software, iets dat in eerste instantie ook erkend werd in de Github, maar ergens in 2019 verdween de licentievermelding en de tekst van de JPL. Onduidelijk is waarom, en in augustus 2020 kwam die vermelding ook weer terug, maar (mogelijk vanwege een breder gevoel van onvrede) toch stapte Jelurida naar de Nederlandse rechter (vanwege de forumkeuze uit de JPL).

De uitspraak heeft toch de nodige pareltjes. Zo was er meteen ruzie over of de ontwikkelaars van de Nxt software hun rechten wel aan Jelurida hadden afgestaan. Die hadden dat wel toegezegd, maar in digitaal getekende tokens en niet in officiële aktes. Dat is wel héél hypermodern (ik weet dat digitale aktes ook kunnen, maar is een token op de blockchain een akte):

Of overdracht onder een pseudoniem, in een Nxt Token, voorzien van een GPG public key en een Nxt account nummer, voldoet aan het dan geldende aktevereiste zal in dat geval ook moeten worden beoordeeld naar buitenlands recht.
Gelukkig voor Jelurida bleken er ook ouderwetse ontwikkelaars te zijn, die keurig een overdrachtscontract getekend hadden. Daarmee had men de ruimte om de claim te doen.

De volgende stap was discussie of Jelurida de licentie wel van de GPL (geldend op versie 0) mocht omzetten naar hun eigen JPL, omdat niet alle developers daarmee ingestemd zouden hebben. De kortgedingrechter veegt dat snel van tafel: te weinig bewijs dat daar rechthebbenden op tegen waren.

En dan de hamvraag: was het auteursrecht geschonden. Apollo had de software grondig herzien:

Niet in geschil is dat Apollo de Nxt Software heeft bewerkt en coderegels heeft toegevoegd bij het ontwikkelen van de Apollo Software. Jelurida heeft een rapport van 19 augustus 2020 van dr. A.K. Seewald overgelegd, waarin de code base van de Nxt public blockchain platform en de Apollo Foundation codebase met elkaar worden vergeleken. Seewald concludeert dat de Apollo Software een significant deel van de Nxt Software code bevat op bestand-, functie- en coderegelniveau. Tussen de 60% en 73% van de functies van de Nxt Software komen voor ten minste 50% overeen met functies van de Apollo Software. Driekwart van die overeenkomende functies is identiek. Van die overeenkomende functies kan 93% van de coderegels worden teruggevoerd op de core developers van de Nxt Software. Apollo stelt echter 400.000 regels aan eigen code te hebben toegevoegd en de code te hebben ge-refactored, met als resultaat dat de Apollo Software een wezenlijk ander product is dat voldoende van de Nxt Software verwijderd is om als zelfstandig werk te kunnen worden aangemerkt.
Dat laatste is geen argument: refactoring is juridisch gezien een vertaling of verfilming. Het betekent dat je het oude werk opnieuw weergeeft in een andere vorm, maar niet dat je alle brokjes creativiteit uit het origineel kwijt bent geraakt. En dat laatste is het enige argument dat je op tafel moet leggen. Iets is pas nieuw als al het oude (oké, al het creatieve oude) eruit verdwenen is.

Inbreuk dus. En in dit geval is dat een hele simpele: alleen al dat je de credit notice naar de originele licentie hebt verwijdert, maakt dat je deze schendt. En daarmee is de licentie automatisch vervallen, zij het dat het probleem natuurlijk wel in 2020 weer hersteld was. De rechtbank bepaalt dan ook (met dwangsom) dat Apollo zich netjes aan de licentie moet blijven houden, en al haar zakelijke klanten moet benaderen om ze de inbreukmakende versie te laten vernietigen. Schadevergoeding is niet aan de orde (het is een kort geding) maar wel moeten ze een kleine 40.000 euro proceskosten betalen.

Arnoud

 

Mag ik de hardcoded sleutel van een app gebruiken voor mijn eigen aanroepen?

Geplaatst op in Ondernemingsvrijheid, 36 reacties

Een lezer vroeg me:

Ik wil gebruik maken van een online tool vanuit mijn eigen software. Helaas is een zakelijke licentie op die tool veel te duur. Nu zat ik in de bijbehorende app voor consumentengebruik te kijken, en die blijkt met een hardcoded key te authenticeren. Ik kan daarmee dus perfect een aanroep simuleren, want het http verkeer is ook nog eens onversleuteld. Is dit toegestaan?

Het is in principe de bedoeling dat je aangeboden tools gebruikt zoals ze je aangereikt worden. Dat staat niet letterlijk in de wet maar volgt volgens mij uit wat juristen de redelijkheid en billijkheid noemen. Maar daar staat tegenover dat het dus niet automatisch strafbaar of onrechtmatig is als je iets anders inzet dan de aangeboden tooling.

In het geval van de vraagsteller kun je die app zien als niet meer dan een schil waarmee een server wordt aangeroepen. Ik zie het onrechtmatige niet in het zelf doen van die aanroep. In dit geval wordt er geen account van een ander gebruikt of een achterdeurtje aangeroepen. Alle apps hebben dezelfde sleutel, dus waartegen die sleutel moet beveiligen is me een raadsel.

Ook vraag je op deze manier geen informatie op waar je geen recht op had. Je had exact deze gegevens gekregen als je via de app de informatie op had gevraagd. Van computervredebreuk – ergens binnengaan waar je weet dat je niet mag zijn – kan ik dus niet spreken hier. Wellicht als je de API gaat manipuleren door extra velden te proberen, of counters gaat veranderen buiten de range die de app zelf gebruikt. Dat zou ik dus afraden.

Een complicatie bij deze vraag is dat de aanbieder zakelijke licenties onderscheidt van consumentengebruik met de app. De werkwijze van deze vraagsteller leidt ertoe dat hij onder een consumentenmantel informatie krijgt die hij zakelijk gaat inzetten. Dat zou je kunnen zien als contractbreuk: er staat vast iets in de app-licentie dat de informatie uitsluitend huishoudelijk of privé gebruikt mag worden.

Daar staat voor mij tegenover dat de vraagsteller ook met de app in de hand de informatie had kunnen verkrijgen en dan zakelijk inzetten. Daar doet die app niets tegen. Ik zie de schade niet voor de aanbieder in dat geval, dus waarom zou het dan wél schadelijk zijn als hij dat met een eigen tool doet?

Arnoud

Zullen we EULA’s in beeldschermen gewoon eens afschaffen jongens?

Geplaatst op in Ondernemingsvrijheid, 19 reacties

Via Twitter deze screenshot van een Volkswagen:

Wijzig uw privésfeerinstellingen (dat geforceerde nepnederlands alleen al) om de juiste juridische teksten te kunnen laden. Wat krijgen we nou. Ik vermóed dat men op basis van locatie andere landgebonden teksten wil tonen, want in sommige landen is het explicieter verboden om aan je navigatie te zitten tijdens het rijden dan andere, zoiets.

Als dat vermoeden klopt, dan heeft dit dus geen betekenis en mag je het negeren. Ik weet niet of dat kan, dit soort onderdelen van IT-systemen hebben de neiging in beeld te blijven tot ze zijn opgelost “want dat moet van Legal” of iets dergelijks. Maar als het kan, mijn zegen heb je.

Als het wel gaat om een juridisch bindende tekst, bijvoorbeeld een landgebonden EULA met andere regels over aansprakelijkheid of zo, dan heeft Volkswagen een probleem. Want dan zijn ze wel rijkelijk laat, de auto is al verkocht en mensen dán nog binden aan voorwaarden heeft geen enkele betekenis. Te laat.

Ook niet als mensen dan alsnog op “Akkoord” klikken. Dat argument kwam ik laatst ergens tegen – je zou dan weliswaar de voorwaarden mogen afwijzen wegens te laat, maar als jij in plaats daarvan op akkoord klikt ga je alsnog akkoord en doe je afstand van het recht ze te mogen afwijzen wegens te laat. Zoiets.

Dat zie ik niet. Dit soort systemen is ontwikkeld voor een verplicht akkoord. En in een situatie waarin je akkoord kunt vragen dit opeisen is tot daar aan toe – contractsvrijheid is in principe een ding, dus afgezien van speciale gevallen zoals de AVG is het mogelijk akkoord af te dwingen als deel van een transactie. Maar als de boel al verkocht en geleverd is dán nog eisen dat iemand op akkoord klikt, is echt onmogelijk. In juridische taal is het eenvoudigste argument dat de op rechtsgevolg gerichte wil ontbrak – men wil verder met die boordcomputer, men wil geen overeenkomst sluiten.

Arnoud

Ben ik strafbaar als ik in opdracht tijdelijk illegale software installeer?

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 7 reacties

Een lezer vroeg me:

Onze organisatie gebruikt al jaren bepaalde software onder licentie. Deze blijkt enige maanden geleden te zijn verlopen en het heractiveren duurt om onduidelijke redenen heel erg lang. Mijn manager heeft me opgedragen dan maar tijdelijk een illegale versie te installeren zodat het werk niet blokkeert, en ze gaan dat rechttrekken in de onderhandelingen. Ben ik strafbaar als ik dat doe, of kan mijn werk dan alsnog de boete van de rechthebbende op mij verhalen?

Als werknemer ben je niet privé aansprakelijk voor je handelen dat je in opdracht doet, of het moet wel héél ver buiten “gewoon je werk doen” treden. Je handelt immers als vertegenwoordiger van het bedrijf, dus wat jij doet wordt je werk aangerekend.

Als je specifiek en expliciet discussie hebt gevoerd dat de software illegaal gebruikt gaat worden, dan zie ik die grens wel in beeld komen. Ik kan me niet voorstellen dat je dan wegkomt met “ik kreeg de opdracht dus ik doe het gewoon”.

Vaak zie je dat het eerder iets is van, we hebben een tijdelijke licentie gebruik die maar, of je collega is parttime HBO docent dus we gebruiken de educatieve licentie. Daar kun je over twisten of dat legaal is maar daarbij heeft de werkgever dan het laatste woord. Dat zou hier op kunnen gaan, omdat de werkgever aangeeft dat dit een tijdelijke oplossing is die men gaat melden aan de licentiegever (en kennelijk denkt voordelig recht te kunnen breien). Ik denk dat je daar als werknemer wel in mee moet gaan.

Mijn advies zou desondanks zijn om expliciet in de mail op schrift te krijgen dat men de illegale versie wil, onder verwijzing naar het mondelinge gesprek en de gevolgen die jij ziet. Of je stuurt het door naar de bedrijfsjurist met de vraag hoe jij die licentieovereenkomst vervolgens moet sluiten.

Arnoud

Hoe ethisch verantwoord mag een opensourcelicentie zijn?

Geplaatst op in Ondernemingsvrijheid, Uitingsvrijheid, 23 reacties

Een nieuwe toevoeging aan het opensourcefirmament: de Hippocratische licentie, grofweg de MIT licentie met de toevoeging dat de software niet mag worden ingezet voor doelen die de Universele Verklaring van de Rechten van de Mens schenden. Iets preciezer: die mensen in gevaar brengt of hun well-being aantast op een wijze in strijd met de UVRM. Een nobel idee natuurlijk, maar het gaf herrie in de tent, want opensourcelicenties horen neutraal te zijn over het ‘field of endeavor’ waarvoor de software wordt ingezet. Deze eis staat ook zo vanaf het begin in de Open Source Definition. Maar is dat nog wel actueel om die eis te stellen?

De auteur van de licentie motiveert haar keuze kort gezegd als volgt:

Developers don’t want their labor being used to do harm, and the current structure of open source software strips any power from creators to prevent this from happening. We are being exploited. Human freedom is being traded for so-called “software freedom”.

Toen de Open Source Definition werd geschreven, was de kijk op de wereld heel anders. De discussie ging daar vaak over of bedrijven (commercial entities) al dan niet de software mochten gebruiken. Veel licenties van gratis beschikbare software verboden commercieel gebruik, of stelden extra eisen aan bedrijfsmatig gebruik. Voor het succes van open source zou dat onwenselijk zijn geweest, vandaar dat de Open Source Definition (en al eerder de Debian Free Software Guidelines) expliciet eiste dat de licentie neutraal was op toepassingsgebied:

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Het ‘genetic research’ voorbeeld is later toegevoegd, en laat zien hoe de discussie verschoven is. Want controverse over zakelijk gebruik van gratis beschikbaar gestelde software is er nauwelijks meer; de controverse over onethisch gebruik van software des te meer. En dan is ‘genetic research’ nog een zwak voorbeeld: wat te denken van inzet van je software voor concentratiekampen, killer robots of systemen voor manipulatie of onderdrukking van bevolkingsgroepen.

Het doet denken aan de discussie over de Do No Evil-licentie en de antibarrearbeidsomstandighedenlicentie. Hoe baken je af wat “evil” is. Deze auteur sluit aan bij een definitie die voor juristen algemeen aanvaard en redelijk duidelijk is: de definitie van mensenrechten die al sinds 1948 wijd geaccepteerd is (althans in het Westen). Dat is de klassieke juridische truc voor afbakeningen waar je niet uitkomt; kies een fraaie formulering of open norm en laat de interpretatie over aan de arme collega (of rechter) die over vijf jaar moet duiden waar je aan toe bent.

Bij die antibarrearbeidsomstandighedenlicentie zie ik ergens nog wel een juridisch sprankje hoop. Die verbiedt grofweg alleen dingen die toch al tegen de wet zijn. Het lijkt me lastig verdedigbaar dat de Open Source Definitie zo breed opgevat moet worden dat ook het field of endeavor van de illegale zaken toegelaten moet zijn. Ik weet niet hoe ik dit neutraal opschrijf, het voelt gewoon te onredelijk en onlogisch dat een licentiegever moet toelaten dat zijn licentienemers de software voor wetsovertredingen inzetten. Die dingen mogen gewoon niet. En dan is het volgens mij geen reële beperking als ik zeg “ik sta niet toe dat je mijn software daarvoor gebruikt”.

Datzelfde argument zou wat mij betreft hier opgaan. Het kan niet waar zijn dat mensen moeten toestaan dat mensenrechten worden geschonden met hun software. Daar kan ik alleen cultuurrelativistisch tegenover zetten dat het mensenrecht van de een het privilege van de ander is. Als kinderarbeid bij mij legaal is, waarom moet jouw licentie dat dan verbieden? Als de overheid iets een detentiefaciliteit noemt, terwijl anderen het een concentratiekamp noemen, mag die software daar dan voor worden ingezet of niet?

Daar kom je niet uit zonder gerechtelijke toetsing, en daar zit precies de pijn: hoe ga je hier een rechtszaak over voeren? Als je licentienemer werkelijk de wet overtreedt, dan kan hij daarop aangesproken worden. Voegt het dan wat toe dat je als licentiegever ze aanklaagt voor softwaregebruik bij kinderarbeid? En als het lokaal niet tegen de wet is om zoiets te doen, dan kom je per definitie ook nergens met een claim wegens licentieschending. Die is er dan immers niet, het is legaal. Dus ik denk dat deze bepaling vooral een signaal is om ethiek hoger op de agenda te zetten, en geen afdwingbare juridische clausule.

Arnoud