Is het legaal in je licentie barre arbeidsomstandigheden te verbieden?

| AE 11219 | 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?

| AE 11011 | 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?

| AE 10903 | 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

Opensourcewerk als nevenactiviteit in het arbeidscontract

| AE 9171 | 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… Lees verder

Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | 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?… Lees verder

Amerikaanse telecomwaakhond dwingt TP-Link open firmware toe te staan

| AE 8872 | Intellectuele rechten | 15 reacties

De 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… Lees verder

Mag een licentie je verbieden Kwaad te doen?

| AE 8555 | Intellectuele rechten | 11 reacties

Een 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… Lees verder

Hoe kan ik een opensourcemodule opnieuw implementeren?

| AE 8194 | Intellectuele rechten | 18 reacties

Een lezer vroeg me: Ik werk aan een opensourceproject dat een kloon (fork) is van een groter project. Wij krijgen bij onze nieuwste module nu het verwijt hun auteursrechten geschonden te hebben omdat de code te veel lijkt. Maar wij hebben deze echt zelf geschreven, hoewel de module wel exact hetzelfde doet. Plegen wij nu… Lees verder