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

Deel dit artikel

  1. Ik zie problemen in arbeidsomstandigheden in bijvoorbeeld kleding en games. Met name bij kleding zien we dat bedrijven zich verschuilen achter constructies met leveranciers en onderaannemers, waardoor “ze nooit hadden kunnen weten dat het niet goed was” en ze “goede arbeidsomstandigheden heel belangrijk vinden”. Als die producent aantoonbaar af probeert te dwingen dat de leveranciers zich aan de wet houden, en hun onderaannemers ook, dan zijn we in ieder geval een stap verder met arbeidsomstandigheden.

  2. Is ‘open source’ een wettelijk beschermde term of zo? En sowieso, als het in je licentie staat dan staat het er in, men mag hoogstens bezwaar maken tegen dat je het ‘open source’ noemt. Lijkt me erg onwenselijk dat je kunt zeggen ‘je noemt het open source en volgens een of ander instituut kunnen deze bepalingen dan niet, dus deze bepalingen zijn nietig’.

    • Open Source is geen wettelijk beschermde term. Het is een term voor software waarvan de broncode vrij inzichtelijk is, hier is een licentie aan gekoppeld. De ene licentie is wat vrijer dan de andere. De GPL eist bijvoorbeeld dat als je de broncode gebruikt voor je eigen product en deze code aanpast, jouw product ook onder de GPL licentie moet worden uitgebracht. De OpenBSD licentie is zo ongeveer de meest vrije licentie, deze staat je toe de broncdode aan te passen en op te nemen in je eigen product, zonder dat daar veel eisen tegenover staan.

      Dus iets open source noemen, kan alleen als de broncode inzichtelijk is. Wat je vervolgens wel (of niet) met die broncode mag doen, is volledig afhankelijk van welke licentie aan de code is/wordt gekoppeld. En ik deel de mening van Arnoud hier wel. Als iets van de (lokale of internationale) wet niet mag, dan mag een licentie dit best benoemen,

  3. Het is leuk dat je de OSI noemt als open source standaard maar als software ontwikkelaar kan ik die definitie gewoon naast mij neer leggen en mijn eigen voorwaarden aan de licenties op mijn code definiëren. Mijn Open Source valt dan alleen niet onder de OSI.

    Ik zou in mijn eigen licentie kunnen opnemen dat men voor gebruik van mijn code eerst eenmalig een uur op kantoor moet lopen als een kip, inclusief bijbehorend gekakel. Of dat men mij een sixpack moet toesturen. Of andere malle voorwaarden. Wie zich daar niet aan houdt heeft een probleem want dan mogen ze mijn code niet gebruiken. Wel inzien, maar niet gebruiken.

    De vergissing die veel mensen dan ook maken met Open Source is dat het je een systeem levert om bepaalde software gratis te gebruiken en zelf aan te passen. Maar dat is niet het geval. Met Open Source is het enige recht dat je krijgt de mogelijkheid om de broncode in te kijken. Voor gebruiksrechten moet je de software licentie accepteren en daarbij maakt het niet uit of de code open of closed is. Dat de OSI de definitie van Open Source probeert te veranderen vind ik dus onterecht. Dit omdat er Open Source bestaat die buiten hun definitie valt.

  4. De definitie van “open source” zoals gepubliceerd door het OSI verbiedt namelijk dat opensourcelicenties onderscheid maken naar “field of endeavour”.

    Als ik die definitie zo lees dan mag de licentie geen materieel onderscheid maken, wat in het geval van een wettelijke bepaalde beperking toch niet gebeurt? De licentie schept tenslotte geen nieuwe verplichtingen en maakt daarmee ook geen onderscheid.

    Overigens betwijfel ik of je überhaupt het schenden van de wet wel als “field of endeavor” mag bestempelen, aangezien dit per definitie buiten het rechtssysteem ligt dat de (licentie)overeenkomst garandeert. Kun je dan niet gewoon stellen dat aangezien je sowieso niet van de wet kan afwijken, dergelijk afwijken daarom ook niet per overeenkomst als “endeavor” kan beschermen?

  5. Ik heb er intellectueel toch wel een probleem mee dat er (blijkbaar) aan dit soort licenties allerlei voorwaarden kunnen en mogen hangen die redelijkerwijs met het beschikbaar stellen/gebruik van de software niets te maken hebben.

    Ik noem maar eens wat: De softwaremaker kan wel als voorwaarde stellen dat ik alleen in paarse auto’s mag rijden en dat ik die voorwaarde ook moet opleggen aan mijn leveranciers, en zij weer aan de hunne, etc.

    Ergens, vroeg of laat, gaat dat toch botsen tegen de beginselen van redelijkheid en billikheid (of heb ik dat mis?).

    • Maar ik heb er juist problemen mee dat de OSI een claim legt op een algemene term (Open Source) die al werd gebruikt voordat de OSI bestond. Over vreemde voorwaarden maak ik mij geen zorgen. Bij al te gekke voorwaarden gaat toch niemand het product gebruiken en ook een rechter zal al snel onredelijke eisen afwijzen.

      Maar het gaat meer om voorwaarden die wel redelijk zijn. Bijvoorbeeld dat een Open Source product niet voor commerciële toepassingen gebruikt mag worden. Of door de wapen-industrie. Of door Noord-Koreanen. Ik wil niet dat de OSI voor mij bepaald wat wel en niet redelijk is. Maar ondertussen kapen ze de definitie…

        • De OSI bestaat pas sinds de jaren 90. (1998 zelfs!) Ik begon met programmeren rond 1984. (Iets eerder zelfs, maar professioneel sinds 1984.) En toen bestond open source ook al. Maar dan meer als spreektaal, niet als vaste definitie. Broncode was namelijk open of closed. Je zou dan moeten zoeken in oude tijdschriften en oude Usenet berichten van voor 1997. En kijken wat Richard Stallman erover schreef tussen 1983 en 1998.

          Informatie over de term terugvinden op Internet is lastig omdat tussen de opkomst van het Internet en de oprichting van de OSI maar een paar jaar zitten en er veel informatie gewoon verdween. Google en het “Internet Archive” bestaat pas sinds 1998 en zijn daardoor niet geschikt om de nog oudere geschiedenis op te sporen. De vraag is of het letterlijk “open source” werd genoemd of dat men “openness” toepaste bij het delen van software met anderen. Je moet dan kijken of GNU deze term gebruikte in hun eerste GPL licenties en daarvoor in de BISON licenties. Ook moet je dan uitzoeken hoe lang de term FOSS al bestaat.

          Maar je krijgt eigenlijk een identieke situatie indien Stallman de term “Free Software” als een strenge definitie vastlegt en je software dus niet “Free” mag noemen als er ook maar enige beperkingen aan het gebruik ervan zitten. Maar ja, “Free” en de GPL gaan niet goed samen omdat de GPL weer beperkingen oplegt en dus niet “free” is. Dat maakt het voor de FSF weer best lastig.

          De vraag is dan ook meer of de term “open source” niet te generiek is om als handelsnaam bewaakt te kunnen worden. De OSI moet dan duidelijk dit merk als dusdanig beschermen en actie ondernemen tegen ieder open source product dat zich niet strict aan hun voorwaarden houdt. Daar is het al te laat voor, volgens mij.

          (Toch is er een voorbeeld van het gebruik van “open” voor 1998! Het OpenBSD project stamt uit 1996 en gebruikt de term Open dus al twee jaar eerder. )

          • De persoon die de term voorstelde voor software, zegt zelf deze niet te kennen in de softwarewereld voor 1998. De term was wel bekend in de inlichtingenwereld (een open bron, zoals het Kadaster, in tegenstelling tot een gesloten bron zoals een informant). Ik heb zelf behoorlijk veel gelezen over de geschiedenis van vrije software en open source en neig er naar dit verhaal te geloven.

            • Ik ken hem zelf ook niet van voor 1998. Maar ‘Open’ ergens voor zetten als het vrij beschikbaar is in de engelse taal al meer dan 100 jaar gebruikelijk. Het lijkt mij vrij ongewenst om een exclusief recht toe te kennen op een eeuwen oud taalgebruik.

              Overigens kom je dan wel in de heel kromme situatie van de Lindows uitspraken terecht. Waar de rechter in de VS bepaald dat Windows te algemeen is voor bescherming, omdat het te algemeen is (Microsoft Windows kon dan weer wel bescherming krijgen). Maar in Nederland kon Windows wel bescherming krijgen omdat we hier een andere taal spreken. Overigens is Engels in de Nederlandse ICT inmiddels zo ingeburgerd, dat waar je vroeger inderdaad nog vertaalde vaktermen zag je nu gewoon het de Engelse benaming gebruikt.

            • Het is een lastig onderwerp maar in principe kunnen we ons beperken tot de vraag of “Open Source” wel een handelsnaam kan zijn voor het vrijgeven van broncode. Of is de term te algemeen om als merk te dienen? Juridisch is dat best een interessant vraagstuk, toch? Bijna een blog-post waardig. 🙂

              Een boek genaamd “Open Source binnen bedrijf en overheid” door Jeroen Baten uit 2003 geeft wel het een en ander weer over de geschiedenis en hoe Open Source eigenlijk al heel lang in gebruik is, maar de term “Open Source” opkwam in 1998 waar voorheen de term “Free Software” werd gebruikt.

              Maar zo kwam ik bij “The Cathedral and the Bazaar” door Eric S. Raymond die dit in 1997 schreef. In de revisie van 2 februari 1998 heeft hij de term “Free software” vervangen door “open source”. Precies op het moment dat de OSI werd opgericht, wat ook logisch is omdat Raymond een der oprichters was. Dus is het zoeken naar deze term van voor februari 1998.

              Best lastig. Vandaar ook dat we eerst moeten bedenken of “Open source” wel een handelsnaam kan zijn, of dat dit een te algemene term is en dus geen bescherming geniet.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS