Tag: Open source

About Open source

Subscribe Feeds

Anno 2020 denken mensen nog steeds dat open source juridisch riskant is

Geplaatst op in Intellectuele rechten, 16 reacties

Via Bert Boerland op Twitter las ik:

Bijzonder lachwekkend (tot tranen toe!) stukje over #opensource (#cms-en) en licenses. Microsoft deed dit truukje (“Fear, Uncertainty and Doubt) zo’n 10 jaar geleden nog, maar is op het rechte pad. Lang geleden dat ik zo’n tenenkrommend stuk over proprietary vs OSS stuk las

Het gaat om dit artikel van geslotensourcecmsmaker Plate (“Meer met multisites”). In de wereld van contentmanagementsystemen is opensource al lang ingeburgerd dacht ik altijd, met Joomla, WordPress en Drupal als bekendste voorbeelden. Maar zo lees ik dan hier “achter het gemak van open source schuilt namelijk een schimmige wereld van licentievoorwaarden.” Ik heb even gecheckt en het artikel is niet uit 2002 en per abuis opnieuw online gezet. Dus eh, wat krijgen we nou.

Toen open source nog een nieuw verschijnsel was in het zakelijk firmament (eind jaren negentig) ontstond meteen discussie over de bijbehorende licentievoorwaarden. Die waren namelijk nogal anders dan het gebruikelijke licentiegeweld: in tegenstelling tot veel moeten betalen en beperkte rechten krijgen zonder aansprakelijkheid voor fouten, stond in opensourcelicenties dat je niet hoefde te betalen, alles mocht maar dat je (althans soms) wel mee moest doen met de opensourcegedachte. Oh en er was geen aansprakelijkheid voor fouten.

Dat “mee moeten doen” gaf de nodige bedrijven juridische zorgen, want die hadden allemaal net tien jaar geleerd dat geld verdienen met softwarelicenties verkopen het grote ding was. En dan zou je dus die software, die broncode gewoon weggeven en anderen alles laten doen daarmee zonder vergoeding? Kon niet waar zijn. De ietwat principiële opstelling van de Free Software Foundation hielp ook niet echt; nadat een stel slimmeriken de zakelijke term “open source” erop plakten en webbrowser Netscape vrijgaven onder zo’n licentie werd het iets makkelijker maar de twijfels bleven.

Die zorg over geheimhouding van je waardevolle software zien we ook meteen in dit artikel terug:

Stel je daarbij voor dat als je een opdracht hebt gegeven om aanvullend maatwerk te laten ontwikkelen op een Joomla platform, waarin een belangrijk deel van een businessproces in is verwerkt, de kans bestaat dat dit maatwerk vrijgegeven moet worden door de ontwikkelaar.

Ik noem dit altijd de IP-reflex: we hebben een stukje software dat we van onszelf zien (en dat noemen we IP) en dús moet dat waardevol zijn en dus geheim gehouden worden. Voor juristen heel normaal, je leert namelijk dat rechten van iemand zijn, en dus te beschermen. Maar de achterliggende zakelijke afweging – de onderliggende waardering – die blijft dan buiten beschouwing.

Zo ook hier: waarom is het waardevol om die businessprocesinformatie geheim te houden? Is het écht voordeliger voor het bedrijf om dat stukje software voor eeuwig in-house te houden, zelf te onderhouden en bij te werken? Wat voor superwaardevol bedrijfsproces heb je dan? Ik ben heel benieuwd.

Dit nog los van het juridische punt dat de GPL (want dat is de Joomla-licentie) helemaal niet eist dat als je maatwerk ontwikkelt, je dit vrij moet geven of terug moet leveren aan de Joomla community. De GPL zegt: wanneer jij maatwerk (voortbouwend op Joomla) levert aan een derde, dan moet die derde het maatwerk onder GPL kunnen gebruiken.

Maar in de meeste gevallen ga je een CMS helemaal niet aan derden leveren. Je installeert het CMS op je eigen server, voegt daar maatwerk aan toe en zet het ding aan. Er is dan geen situatie waarin de GPL enige eisen stelt. Wie een open source CMS inzet, hoeft zich nul zorgen te maken over het vrijgeven van enige maatwerkcode. Echt nul. Ik vind het echt kwalijk dat men anno 2020 nog steeds wat anders beweert.

Oh ja, inbreuk op rechten van derden. Dat zou zomaar kunnen, blijkt dat je Joomla in gebruik hebt en dat je de GPL schendt. Of dat je leverancier dat heeft gedaan. Dan krijg jij de claim. In theorie een probleem maar in de praktijk nog nooit voorgekomen, en ook iets waar je niet meteen een schádeclaim voor krijgt. In de opensourcegemeenschap is compliance het toverwoord: men eist dat je de licentie naleeft, maar naar de rechter voor een gebruiksverbod of schadevergoeding komt niet voor.

Een derde punt dat wordt aangedragen, is de beveiliging. Daar zou je niemand op aan kunnen spreken. En ja dat klopt, opensourcelicenties zeggen dat de makers nergens voor aansprakelijk zijn. Maar veel gesloten licenties zeggen dat ook (ik heb de Plate licentie niet gezien noch de SLA, dus ik weet niet hoe veel aansprakelijkheid zij aanvaarden voor securityfouten), dus in hoeverre dit uniek OSS aan te wrijven is?

Natuurlijk, met geslotensoftwareleveranciers kun je afspraken maken. En vooral: die kun je aansprakelijkheid en een vrijwaring opdringen, dus dan is het geregeld. Dat is de juridische mindset, wij zijn eigenlijk een soort tovenaars: zeg hoe het moet zijn, laat een handtekening zetten en bracchiabindo, we hebben het geregeld.

Ik sprak ooit een inkoper van IBM die bij leveranciers altijd vroeg om volledige aansprakelijkheid en een onbeperkte vrijwaring. Toen ik zei dat hij dat niet kreeg van mijn klant, was zijn reactie “mooi, want wie dat geeft die vertrouw ik voor geen cent”. Want leuk en aardig dat het op papier staat, maar wat is dat papier waard? Kan deze leverancier die kwaliteit leveren, heeft hij de expertise om de veiligheid echt goed op te lossen? Ja, het is hun product dus dan zullen ze het echt snappen. Precies, dat zeiden ze bij Zoom ook.

En dan de uitsmijter: “Het gebruik van closed source software maakt een organisatie minder kwetsbaar voor claims van buitenaf.” Dat is niet mijn ervaring, als je in de rechtspraak kijkt dan zie je eigenlijk alleen zaken tussen closedsourceleveranciers over inbreuk op elkaars licenties of rechten. Opensourcepartijen die procederen, dat komt gewoon niet voor.

Maar ach, leuk he weer eens terug naar hoe men vorig decennium dacht?

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

Is het legaal in je licentie barre arbeidsomstandigheden te verbieden?

Geplaatst op in Ondernemingsvrijheid, Uitingsvrijheid, 19 reacties

Een nieuw fenomeen in licentieland: de Anti 996 licentie, een variant op de opensource BSD licentie die een unieke beperking kent. De licentienemer (gebruiker van de software) mag in zijn bedrijf geen onwettige arbeidsomstandigheden toelaten. De term “996” komt uit een Chinese praktijk- van 9 tot 9 werken, 6 dagen per week – dat leidde tot een protestbeweging om arbeidsomstandigheden te verlichten. Leuke inhaker dus, wie deze software gebruikt moet zijn personeel betere arbeidsvoorwaarden geven of in ieder geval gewoon de wet naleven. Een loffelijk initiatief, maar mag dat eigenlijk wel in een opensourcelicentie?

De bepaling is simpel en effectief geformuleerd:

The [licensee] must strictly comply with all applicable laws, regulations, rules and standards of the jurisdiction relating to labor and employment where the individual is physically located or where the individual was born or naturalized; or where the legal entity is registered or is operating (whichever is stricter). In case that the jurisdiction has no such laws, regulations, rules and standards or its laws, regulations, rules and standards are unenforceable, the individual or the legal entity are required to comply with Core International Labor Standards.

De ILO dient daarbij als minimumstandaard. Deze standaard verbiedt onder meer kinderarbeid en eist dat men zich mag verenigen in vakbonden, om eens twee controversiële onderwerpen te noemen.

Papier is geduldig, dus als jij deze eis in je licentievoorwaarden wilt opnemen en je wederpartij wil dit accepteren dan is dat juridisch verder helemaal prima. De praktijk kent dit al – grotere organisaties nemen vaak in hun inkoopvoorwaarden ook eisen op omtrent maatschappelijk verantwoord ondernemen, garanties tegen kinderarbeid en afspraken over groen ondernemen.

Specifiek bij open source is het echter iets spannender. De definitie van “open source” zoals gepubliceerd door het OSI verbiedt namelijk dat opensourcelicenties onderscheid maken naar “field of endeavour”. Dat is primair bedoeld tegen zaken als commercieel gebruik verbieden of eisen dat de software niet voor massavernietigingswapens wordt ingezet. Maar je zou in theorie ook kunnen zeggen dat deze bepaling dus gebruik in sweatshops verbiedt of discrimineert tegen ondernemingen met inzet van kinderarbeid. Daarmee zou de clausule dus tegen de open source definitie zijn.

Omdat de licentie zich nadrukkelijk beperkt tot het conformeren aan de toepasselijke lokale wetgeving, heb ik daar wel wat twijfels bij. Het onderliggende argument is dan namelijk dat je niet mag discrimineren op grond van iets dat de wet overtreedt. Ik zou het nogal onredelijk vinden als dat niet mag. Ik weet dat al langer geldt dat je “not to be used for Evil” niet mag zeggen, maar ethisch kwaad vind ik wezenlijk wat anders dan wettelijk verboden. Een verboden handeling mag niet. Een kwade handeling hoort niet, maar mag wel.

Arnoud

Hoe je een bak geld verdient door gewoon de inkoopvoorwaarden te accepteren, wacht wat?

Geplaatst op in Security, 3 reacties

Corporate purchasing and policies make funding open source Literally Impossible, aldus Swift on Security, een parodiërende maar serieus te nemen securityonderzoekster. De onderliggende klacht is namelijk best reëel: als je een paar tientjes wilt vragen van een groot bedrijf om een bug in je open source project te fixen, dan is dat enorm ingewikkeld. Maar vraag je tienduizend euro voor een supportcontract waaronder je hetzelfde doet, dan is dat zo geregeld. Met dus het advies, doe dat laatste. Waarbij allerlei juristen beginnen te roepen, ja maar de inkoopvoorwaarden dan. Nou ja, die accepteer je dan dus gewoon, wat kan je gebeuren.

In de kern is het probleem de bureaucratie en overhead die je krijgt als je met een groot bedrijf zaken gaat doen. Er moeten veel punten op de i worden gezet wil zo’n organisatie overtuigd zijn dat ze met jou in zee moeten. Dat gaat vaak beter als je een serieuze belofte met langetermijntoezegging kunt doen, oftewel een supportcontract voor drie jaar met 24/7 beschikbaarheid. Dat dat wat meer kost dan het half uurtje dat ze eigenlijk wilden, is een bijzaak.

Natuurlijk zal zo’n bedrijf ook flink wat verwachten, althans op papier. Denk aan stevige aansprakelijkheid, lange betalingstermijnen, eenzijdig opzeggen en al die andere dingen waar je als leverancier op dag 1 tegen gewaarschuwd wordt. Dat moet je niet accepteren natuurlijk. Alleen: als er in de praktijk echt niet meer te verwachten is dan af en toe wat kleine vragen over dingen die je toch al deed, en de software gratis weggegeven wordt, welke aansprakelijkheden zijn praktisch gezien dan te verwachten? Vanuit dat perspectief is “teken gewoon en pak dat geld” een hele logische.

Een andere reden voor dit probleem is denk ik dat een eenmalige uitgave van een paar tientjes vaak wordt gerekend onder het kopje reiskosten/onvoorzien, en bedrijven zijn daar vaak erg huiverig over omdat de kans voor misbruik groot is. Als iedereen in het bedrijf ineens 50 euro mag geven aan een vaag figuur op internet omdat die een of ander leuk tooltje zou hebben gemaakt, waar ben je dan als multinational? (Ik ken mensen die om die reden die 50 euro dan maar privé betalen en het later verrekenen met reiskosten naar een conferentie.)

Het doet natuurlijk raar aan, blog ik een hele serie over hoe je je verweert tegen inkoopvoorwaarden en dan kom ik ineens met een advies om ze gewoon maar te accepteren. Maar soms kan dat gewoon het goede advies zijn.

Arnoud

Nu ga ik aan mezelf twijfelen, is de GPLv2 eigenlijk wel een contract?

Geplaatst op in Intellectuele rechten, 48 reacties

Heibel in de Linuxtent, blogde ik vorige week. Ontwikkelaars aan het besturingssysteem lagen in de clinch over een Code of Conduct die ongepast gedrag vastlegt, met de nodige interpretatieproblemen tot gevolg. Dat leidde tot een oproep om je GPL-licentie in te trekken en zo je stem te laten horen. Waarop ik me afvroeg, kan dat wel, een contract opzeggen in zo’n situatie? Maar nu ga ik zelfs twijfelen of er wel een contract ís.

Dat de GPL naar Europees recht een contract is, is al een hele lange aanname. De standaardlicentie komt uit de VS, en daar is de twijfel wel iets serieuzer: voor een overeenkomst is onder de common law het specifieke concept ‘consideration’ nodig, oftewel een tegenprestatie. Een schenking is dus géén overeenkomst daar, maar een eenzijdige rechtshandeling. In Europa waar de civil law geldt (zeg maar heel Europa behalve Ierland, Engeland en Wales) is het goed mogelijk een overeenkomst te hebben met maar één prestatie.

De GPL kent geen tegenprestatie, en kan daarmee dus geen contract zijn onder common law principes. In Europa is dat geen beletsel, dus kun je hier prima spreken van een GPL contract. (Bijkomstig voordeel is dat het Amerikaanse juristen irriteert zonder dat ze er wat aan kunnen doen.) Voor een contract is niet meer nodig dan een aanbod (dit mag je doen, onder deze voorwaarden) dat wordt aanvaard (lijkt me leuk, ik ga typen en verspreiden).

Hoe meer ik er echter over nadenk, hoe meer ik twijfel of dit eigenlijk wel goed gaat. Want die aanvaarding past niet goed in het systeem van de wet, dat er vanuit gaat dat je akkoord zegt tegen de aanbiedende partij. Als die aanvaarding niet daadwerkelijk aankomt, dan gaat er van alles schuiven. Het belangrijkste is dat de aanbieder dan het aanbod mag intrekken, waarmee het vervalt. Oftewel, zolang niemand jou daadwerkelijk meldt “ik aanvaard de GPL op jouw software, dank je” dan kun je gewoon roepen “licentieaanbod ingetrokken, sorry” en kan niemand meer wat met je software.

De praktijk is natuurlijk dat iedereen gewoon zoekt naar de regel “GPL” in de hoofddirectory van de software en concludeert dat het wel goed zit. Maar je moet je best wel in juridische bochten wringen om dan tot een juridisch perfecte aanvaarding te komen. Een mogelijkheid is bijvoorbeeld dat je zegt, de aanvaardingshandeling (het gebruik van de software) bereikt de aanbieder niet maar dat is de aanbieder zijn eigen probleem (art. 3:37 lid 3 BW), had hij maar meer moeten opletten wie zijn software gebruikt.

Maar wat is het dan wel? De Amerikaanse constructie is een “toestemming onder voorwaarden”, analoog aan een bordje bij je erfgrens. Wie zijn landgoed openstelt met een bordje “Vrije toegang dagelijks tussen zonsopgang en zonsondergang” sluit dan geen overeenkomst, maar verleent eenzijdig toestemming onder een voorwaarde (namelijk dat het overdag is). Zolang die voorwaarde wordt gerespecteerd, mag je er zijn. Schend je de voorwaarde of vervalt deze, dan pleeg je erfvredebreuk en moet je dus wegwezen. Vertaal je dat naar softwareland, dan krijg je toestemming onder het auteursrecht om te handelen maar zodra je de voorwaarden schendt, eindigt de toestemming en heb je een probleem.

Het mooie van deze oplossing is, het maakt niet uit of je de voorwaarden aanvaardt of niet. Negeer ze en je pleegt sowieso inbreuk. Dus je hoeft helemaal niets te zeggen tegen de rechthebbende. De toestemming is ook niet zomaar intrekbaar: gezegd is gezegd, zeker gezien de constructie in de aanhef van de GPL dat het krijgen van een kopie van de software tevens toestemming inhoudt.

Het grote nadeel is natuurlijk, het is nog nooit getest bij de rechter. En ik weet ook niet op welke plek in het Burgerlijk Wetboek ik deze constructie zou moeten duiden. Maar het past beter bij mijn rechtsgevoel anno 2018.

Arnoud

Mag je geen open source meer op Github zetten?

Geplaatst op in Intellectuele rechten, 10 reacties

Paniek in de tent: softwarehostingsite Github heeft nieuwe voorwaarden, en die botsen met veel open licenties. Dat las ik op diverse plekken. Je moet ze een brede licentie geven en afstand doen van je persoonlijkheidsrechten, en dat kan nu eenmaal niet als je open source daar neerzet. Maar volgens mij valt dat wel mee.

De pijn zou zitten in sectie D, over eigendomsrechten. Allereerst de licentie die je moet verlenen:

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub’s functionality. You may grant further rights if you adopt a license.

In gewone taal: wij als Github mogen jouw content (inclusief eventuele werken van derden daarin) gebruiken en verspreiden op onze dienst, en alle gebruikers mogen dat ook. Dit is typisch juridisch moeilijk doen: oh jee, straks zegt iemand dat wij een kopie maken van zijn software omdat hij die bij ons host, laten we maar even zeggen dat hij ons een licentie moet geven.

Maar belangrijker, ik zie er geen tegenspraak in met de opensourcelicentie die je op je werk plakt. Mensen moeten met de Github functionaliteit kunnen doen wat die functionaliteit doet. En met open source mag je alles: kopiëren, aan derden geven, importeren in je eigen project en ga zo maar door. Het is de distributie naar anderen toe waarop de voorwaarden geschreven zijn, en die anderen moeten dus gewoon zorgen dat ze de voorwaarden nakomen.

Dan de morele rechten: daar moet je inderdaad afstand van doen, iets dat van de Auteurswet mag (behalve het recht van verminking, maar hoe dat moet uitpakken bij software weet werkelijk niemand). Dat botst dan met licenties die naamsvermelding eisen, en dat is 99% van de opensourcelicenties. Maar ik zie ook dat niet als een probleem:

To the extent such an agreement is not enforceable by applicable law, you grant GitHub a nonexclusive, revocable, worldwide, royalty-free right to (1) use the Content without attribution strictly as necessary to render the Website and provide the Service; and (2) make reasonable adaptations of the Content as provided in this Section. We need these rights to allow basic functions like search to work.

Github wil met name voorkomen dat elke zoekopdracht moet zeggen “met code van Jan, Piet en Klaas”. Iets dat iedere rechter volkomen redelijk zal vinden. Zeker omdat je meteen wordt doorverwezen naar de resultaten, waar de naam van de programmeurs wel gewoon bij staat. Ik vraag me zelfs af of Github uberhaupt een licentie nodig heeft om zoekresultaten te mogen tonen, dat zie ik gewoon als citaatrecht.

Alles bij elkaar lijkt dit me dus een storm in een glas water, hoewel ik wel toegeef dat dit iets handiger had kunnen worden opgeschreven.

Arnoud

Opensourcewerk als nevenactiviteit in het arbeidscontract

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 18 reacties

Een lezer vroeg me:

Ik ga binnenkort als programmeur aan de slag bij een middelgroot bedrijf. Naast mijn werk wil ik aan allerlei open source projecten kunnen blijven werken, maar dat botst met de auteursrechtclausule uit hun contract: alles is automatisch van hen, ook als ik het in eigen tijd maak. Is daar juridisch iets aan te doen?

Het is zeer standaard om in een arbeidscontract binnen de ICT een auteursrechtclausule op te nemen. Als werkgever wil je immers zeker weten dat je de auteursrechten krijgt op wat je personeel maakt. Op zich staat dat al in de wet, maar je mag van die wettelijke regeling afwijken bijvoorbeeld door scherpere en/of bredere grenzen te trekken.

Als potentieel werknemer hoef je zo’n clausule natuurlijk niet te accepteren. Je mag hier vrij over onderhandelen. Natuurlijk loop je wel enig risico dat de werkgever dan geen zin meer in je heeft, maar ik mag hopen dat een werkgever extra enthousiast wordt van een programmeur die ook in zijn vrije tijd bezig is met zijn werk-skills aanscherpen.

Er zijn verschillende manieren om dit te doen. Vrijwel iedere werkgever gaat akkoord met “Ik mag aan nevenactiviteiten programmeren en de auteursrechten worden van mij, mits ik vooraf toestemming vraag”. Dit klinkt mooi, maar de cynische jurist zal meteen opmerken dat dit niets toezegt, want toestemming mag (binnen het redelijke) immers altijd worden geweigerd. Toevoegen “Toestemming mag alleen worden geweigerd als” met een beperkte lijst argumenten is dus wel zo verstandig. Denk aan “als de activiteit concurreert met het werk”, “als het werk gaat lijden onder het nevenwerk” of “als de nevenactiviteit gerund wordt door een concurrent/leverancier”.

Je kunt het ook generieker houden: nevenactiviteiten mogen tenzij ze concurreren of tenzij ze conflicteren met het werk. Dan is toestemming niet meer aan de orde maar moet de werknemer zelf inschatten of er een probleem kan ontstaan. In de praktijk komt het dan toch neer op een soort van toestemming, want bij twijfel gaat de werknemer natuurlijk vragen of iets mag of niet.

Vaak wordt ook gewerkt met een lijst met projecten waar men aan werkt. Dat kan, maar het onderhouden van die lijst is waar het dan vaak mis mee gaat. Maak dus dan in ieder geval een afspraak over hoe vaak die lijst wordt herzien en hoe eenzijdig de werknemer er projecten aan mag toevoegen. Is dat “ik zal nieuwe projecten mailen en ze zijn goedgekeurd tenzij men piept binnen 14 dagen” of “ik mag pas beginnen na schriftelijke goedkeuring van de directie”?

Mijn ervaring is wel dat dit soort clausules vaak discussie geven in het onderhandeltraject, en vervolgens compleet onder het tapijt verdwijnen. Ik vraag me dan ook wel eens af of het wel écht nodig is dit zo uitgebreid te regelen. Maar goed, het is altijd beter dingen vooraf te bespreken dan achteraf er ruzie over te maken.

Wat is bij jullie bedrijf het beleid over buiten het werk om aan open source te werken?

Arnoud

Mag je licentie-incompatibele dependencies meeleveren met je software?

Geplaatst op in Intellectuele rechten, 34 reacties

Een lezer vroeg me:

Bij veel opensourcepakketten heb je allerlei extra software nodig, zogeheten dependencies. Soms is deze extra software meegeleverd met het pakket, maar vaak niet. Je moet dan maar hopen dat het via de repository van je Linux-distributie beschikbaar is. Ik had vernomen dat dat soms een juridische keuze is, hoe zit dat?

Het lijkt zo logisch om, als je eigen software afhankelijk is van andermans open source, die open source mee te leveren. Het is immers gewoon toegestaan om open source software te verspreiden, dat is het hele punt van open source. Het doet dus wat raar aan dat je bepaalde open source niet mee mag leveren.

De reden dat het soms toch niet kan, zit hem in de licentievoorwaarden. Sommige opensourcelicenties (met name de GNU GPL) eisen dat zogeheten afgeleide werken alleen mogen worden gedistribueerd onder die licentie. Als de licentie van het andere werk dit niet toestaat – zogeheten licentie-incompatibiliteit – dan is het dus niet mogelijk die twee samen te verspreiden.

Wat precies een afgeleid werk is, is al decennia een lange discussie, maar goed verdedigbaar is dat gebruik van een dependency daaronder valt. Heb je een specifiek ander stuk software nodig, dan bouw je voort op dat andere stuk software en dus ben je daar een afgeleide van. Hoewel ook goed verdedigbaar is dat je dan alleen functionaliteit aanroept, en dat valt buiten het auteursrecht en dus ook buiten de licentiescope. Maar als je dus zegt dat inroepen van dependencies jouw software een afgeleid werk daarvan maakt, dan moeten de licenties van de software en de dependencies allemaal compatibel met elkaar zijn.

Het gekke is dat het wél toegestaan is – ongeacht compatibiliteit – om te melden welke dependencies er gelden en de gebruiker die zelf te laten downloaden en installeren. Dat mag je zelfs automatiseren met een handig installatiescript of package manager-functionaliteit. Opensourcelicenties zijn namelijk distributielicenties, oftewel de voorwaarden gelden pas bij distributie. Wie alleen downloadt en gebruikt, heeft dus niets te maken met compatibiliteit van eventuele licenties.

Arnoud

Amerikaanse telecomwaakhond dwingt TP-Link open firmware toe te staan

Geplaatst op in Intellectuele rechten, 15 reacties

tp-link-router-firmwareDe FCC heeft een schikking getroffen met TP-Link van 200.000 dollar omdat verschillende wifi-routers van het bedrijf de radiofrequentieregels van de VS overtraden, las ik bij Tweakers. De routers konden met hoger vermogen zenden dan toegestaan. De schikking komt met een opmerkelijke uitkomst: het bedrijf zal opensourcefirmware toestaan op haar routers, iets dat sowieso vrij zelfzaam is in routerland.

De Amerikaanse toezichthouder FCC had op zeker moment nieuwe regels opgesteld over zenden op de 5 gigahertz-band. Een routermaker mocht ook derden niet meer toestaan op die band uit te zenden. TP-Link koos er voor deze regel na te leven door gewoon het installeren van software van derden onmogelijk te maken.

De FCC fluit TP-Link nu terug: dit gaat te ver, je had er enkel voor moeten zorgen dat die software van derden netjes omgaat met de 5 GHz-band. En om een duidelijk voorbeeld te stellen, wordt er gekozen voor een schikking waarbij TP-Link expliciet het mogelijk zal maken dat derden eigen firmware op mogen gebruiken.

Een uitdaging lijkt me, want TP-Link moet nog steeds wel ervoor waken dat de zendregels niet worden overtreden. Het zendvermogen op de 2,5GHz band mag niet meer zijn dan 100mW, en firmware moet dat niet kunnen aanpassen. De vraag is dus of je wel zinnige firmware kunt maken én dat soort regels kunt bewaken.

Arnoud

Mag een licentie je verbieden Kwaad te doen?

Geplaatst op in Intellectuele rechten, 11 reacties

json-licentie-good-evilEen lezer vroeg me:

Onlangs vond ik de zogehten Do no evil-licentie. De JSON licentie zegt “The Software shall be used for Good, not Evil”. Is zoiets juridisch afdwingbaar, of wat zou de rechter hiermee doen?

De licentie voor JSON (een protocol voor data-uitwisseling in Javascript) is voor 94,9% gelijk aan de bekende simpele MIT licentie: je mag alles met de software doen wat je wilt, zolang je mij maar niet aansprakelijk houdt (en mijn naam niet weghaalt). Daar is weinig mis mee. Opensourcelicenties zijn legaal.

De unieke toevoeging dat je de software niet ten Kwade gebruikt is wel uniek. De toevoeging is politiek geïnspireerd (op George Bush’ “war on evildoers”) maar het staat in een juridisch document, dus zou het ook een juridische betekenis hebben?

De term “Kwaad” is niet echt een vakterm of algemeen bekende term (althans, de definitie). Onduidelijk dus. Bij standaardclausules (algemene voorwaarden) geldt de regel dat onduidelijke formuleringen tegen de opsteller worden gebruikt (bij ons art. 6:238 lid 2 BW). Daarnaast hebben we nog twee noodgrepen: een beding mag niet tegen de openbare orde of goede zeden zijn (art. 3:40 BW), en een beding is niet van toepassing “voor zover dit in de gegeven omstandigheden naar maatstaven van redelijkheid en billijkheid onaanvaardbaar zou zijn” (art. 6:248 BW). Die laatste komt bij algemene voorwaarden neer op “niet onredelijk bezwarend zijn” (art. 6:233 BW).

Mijn eerste gedachte naar een juridisch argument is: deze term is zo overduidelijk gekozen als politiek statement en is zó vaag en archaïsch dat niemand die serieus hoeft te nemen als juridische voorwaarde. Dat is eigenlijk nóg fundamenteler: deze zin is niet bedoeld als een juridische clausule, dus hoeft hij ook niet zo opgevat te worden. Misschien was hij wel bedoeld als juridische clausule, maar hij heeft de schijn zodanig tegen dat anderen dat niet hoeven te verwachten. De zin is dus geen clausule en je hebt er niets mee te maken.

Als je zegt, het stáát er als juridisch argument en in een licentie ook nog, dus dat moet je gewoon zien als een clausule, dan kom ik uit bij die onaanvaardbaarheid: het is onaanvaardbaar dat mensen zich in bochten moeten wringen om een politiek statement van de auteur juridisch te duiden. Daarom kan en mag hij zich niet op het beding beroepen. Of nog iets sterker: het beding is religieus geïnspireerd en het is tegen de openbare orde of goede zeden om mensen te dwingen jouw religieuze opvattingen te volgen.

Vind je dat allemaal niks, dan zit je eraan vast en kom je uit bij hoe je het beding moet uitleggen. Dan krijg je dus de vraag, wat is het Kwaad. Daar kom je niet uit volgens mij. Dan gaan we de uitleg tegen de opsteller doen: de term is lastig uit te leggen dus valt er niets onder, het verbod is inhoudsloos.

Gaat dat je te ver, dan moet je ergens een grens trekken bij welke handelingen je het Kwaad vindt. Het gaat me te ver om dat te doen bij alle zaken die tegen de wet zijn, want niet alle wettelijke verboden zijn ingegeven door morele opvattingen. Maar welke dingen vinden we dan verwerpelijk? Alle ernstige misdrijven, zeg waar meer dan vier jaar cel op staat? Alleen die waarbij uit een peiling blijkt dat men ze afschuwelijk vindt? Of moet je dan juist kijken naar de moraliteit zonder de wet? Legale maar zeer verwerpelijke zaken, kunnen we die als het Kwaad zien in een contract?

Arnoud