Kunnen Linux-ontwikkelaars de GPLv2 intrekken als ze het met de Code of Conduct oneens zijn?

Herrie in de Linux-tent: een nieuwe Code of Conduct in het project heeft veel ophef veroorzaakt, inclusief dreigementen dat men bijdragen aan de kernel gaat intrekken. Deze zijn door vrijwilligers ingebracht onder de GPLv2 open source licentie, maar volgens partijen die het oneens zijn met de Code is het nu mogelijk deze licentie weer in te trekken. Daarmee zou Linux en al haar afgeleide projecten – waaronder Android, dat het fundament vormt voor de meerderheid van alle smartphones en dergelijke devices – op losse schroeven komen te staan. Maar zo heet wordt die soep niet gegeten.

De herrie begon vlak nadat oprichter en eindbaas Linus Torvalds besloot zich tijdelijk terug te trekken “to take some time to learn how empathy works”. Op dat moment was er ook net een nieuwe Code of Conduct aangenomen voor het project, in lijn met vele andere open source projecten die proberen meer diversiteit aan boord te krijgen en verwijten van toxic culture het hoofd te bieden. Dat was tegen het zere been van een vocale groep ontwikkelaars, die dit zien als een aanval op de waarden van open source, met name het principe dat het gaat om de inhoud en kwaliteit, niet om vorm, afzender of wat dan ook. Ik breng het maar zo neutraal mogelijk, en wie even googelt op social justice warrior en toxic culture zal begrijpen waarom.

Een recente oproep in de vorm van een open brief gooide olie op het vuur. Deze stelde namelijk dat iedereen die het oneens was met de Code of Conduct, dit moest laten merken door zijn (of in theorie: haar) bijdragen aan Linux terug te trekken. Dit zou kunnen via de juridische figuur van rescission, in het Nederlands ontbinding geheten. Daarmee vervalt de licentie en mag de Linux kernel, maar ook Android en consorten, die code niet meer gebruiken.

Leuk bedacht, maar ik denk niet dat het stand houdt. Het concept van rescission of ontbinding is een contractuele figuur, en zeker in Amerika is altijd gesteld dat de GPLv2 geen contract is. Het lijkt me dan niet haalbaar om de ontbinding daarvan in te roepen. In Europa ligt dat anders, ik weet 99% zeker dat de GPL hier een contract is. En inderdaad kun je een contract dan ontbinden.

Voor ontbinding zijn wel argumenten nodig. Je bedenken of geen zin meer hebben in de sfeer van de club is nadrukkelijk geen argument. Dat moet je maar vooraf in het contract opnemen (contractsjuristen spreken dan van termination at will). Ontbinden onder de wet kan eigenlijk alleen bij wanprestatie, schendingen van de overeenkomst door de wederpartij, of in zeer uitzonderlijke situaties die maken dat je redelijkerwijs écht niet meer gehouden kan worden aan dat contract.

Van een wanprestatie onder de GPL lijkt me geen sprake als iemand nieuwe gedragsregels binnen het project introduceert. De software wordt nog steeds onder precies dezelfde voorwaarden aangeboden, daar verandert welke gedragsregel dan ook niets aan. Ook je beroepen op gedane beloften over sfeer en werkwijze zie ik niet als wanprestatie. De GPL gaat over de software en wat daarmee mag gebeuren – namelijk alles, mits onder de gelijk-delen clausule uit die licentie. Ik zie niet hoe je dan achteraf kunt zeggen, ik vind deze nieuwe huisregels van project Linux onaardig dus de GPL wordt geschonden.

Natuurlijk kun je er wel voor kiezen om niet meer mee te doen aan het project, maar je bestaande licentie intrekken gaat ‘m niet worden.

Arnoud

58 reacties

  1. Wat gebeurd er als laat we zeggen dat een persoon software X heeft gemaakt onder GPL en hij trekt zich terug en gaat verder met de software en noemt het nu Y (commercieel) en heeft een andere licentie. Mag de GPL groep nu nieuwe onderdelen uit Y gebruiken terwijl die nu commercieel zijn.

    1. Het komt best vaak voor dat een software beschikbaar is onder meerdere licenties, al dan niet met veranderingen in de code. Het is niet toegestaan om code die niet onder de GPL is uitgebracht, doordat de eigenaar de licentie later heeft gewijzigd, dan wel doordat de licentie van dat stukje code toegevoegd is aan de niet-GPL versie van het project, te gebruiken. IANAL, maar vrij zeker hiervan.

      1. Let wel goed op wat er precies valt onder “code die niet onder de GPL is uitgebracht” . Stel iemand brengt een programma foo-1.0 uit, onder GPL. Stel diezelfde iemand biedt op een gegeven moment foo-1.0 niet langer aan, maar brengt datzelfde programma uit als bar-1.0, onder andere voorwaarden die geen kopieën toestaan, terwijl de code gelijk is gebleven. Het downloaden en kopiëren uit foo-1.0 uit andere bron blijft dan toegestaan en is essentieel voor bijvoorbeeld Linux distributies die foo als package aanbieden vanaf hun eigen servers, het downloaden en kopiëren uit bar-1.0 is toch verboden, zelfs als het resultaat 100% identiek zou zijn.

  2. Ik geloof dat een van de argumenten was dat (in tegenstelling tot v2) in de GPLv3 specifiek staat dat je je licentie niet mag intrekken, en dat dat dus impliciet bewijst dat het onder de GPLv2 wel mag. Snijdt dat hout?

  3. Die Code of Conduct geldt toch alleen voor de personen die de code aanleveren aan kernel.org? Je kunt dus prima een organisatie hebben zonder CoC om kernelcode te ontwikkelen, zolang de uiteindelijke bijdrager zich maar aan de CoC houdt. Er zijn best veel grote organisaties die kernelcode ontwikkelen (Google, NVidia, AMD, Intel, Microsoft?) en het lijkt me niet dat je die ineens aan een of andere Code of Conduct kunt houden. Daarnaast staat het je vrij om kernelcode te publiceren zonder dit aan te leveren aan kernel.org. Linus en consorten mogen deze code onder de GPL adopteren in hun eigen code maar dat is hun keuze en dan hoef je je niet ineens aan een Code of Conduct te houden.

    Persoonlijk ben ik voorstander van de No Asshole Rule en de No Code of Conduct-Code of Conduct. Natuurlijk moet iedereen zich gewoon aan de wet houden, en dat dekt al best veel.

  4. Als de GPL een contract is, en ik code bijdraag aan een open-sourceproject dat onder de GPL publiceert (wat ik wel heb gedaan, alleen niet bij de Linux-kernel), met wie heb ik dan wanneer een contract?

    1. Dat is inderdaad ingewikkeld als er geen duidelijke partij zoals een stichting (Linux Foundation of Apache Foundation, bijvoorbeeld) zich positioneert als beheerder. Ik denk dat je dan het contract sluit met de persoon die de hoofdmaintainer is (dus bij Linux de heer Torvalds uit Finland, toen de Foundation er nog niet was), maar verdedigbaar is ook dat het met een informele vereniging is als er een groep mensen structureel samenwerkt (de zonder notariële akte opgerichte vereniging Linux).

      1. Een contract is toch aanbod en aanvaarding? Dus als je niet meer wilt meedoen, bied je niet meer aan, en komt er geen nieuwe overeenkomst tot stand met jou als ontwikkelaar van een stukje code. Dat is echter onder de GPLv2 geen probleem: eenieder met wie je wel een overeenkomst hebt mag jouw code ook weer in sublicentie geven. Volgens mijn ontstaat daardoor een soort onontwarbare kluwen of keten van licenties en sublicenties, waarbij ieder persoon dat de code aanbiedt aan een derde de formele contractspartij met die derde wordt.

        1. De GPL zegt dat iedereen die een kopie van de code krijgt, daarbij een licentie direct van jou krijgt. Er is dus geen sprake van sublicenties. Juridisch gezien geef je een blanco machtiging af, iedereen die jouw code heeft mag namens jou een GPL overeenkomst sluiten met iedereen aan wie zij die code geven. En daar zit jij dan aan vast.

          1. Zo heb ik het nooit opgevat. Volgens mij zegt de GPL dat iedereen die een kopie van mijn code krijgt, deze mag gebruiken onder de voorwaarden van de licentie. In die voorwaarden staat dat jij de code mag distribueren mits je dit onder dezelfde voorwaarden doet. Voorwaarden dus tussen jou en de ontvanger.

            You must cause any work that you distribute or publish [..] to be licensed as a whole at no charge to all third parties under the terms of this License.
            Verbatim kopieën hebben een iets andere bewoording waardoor ik niet durf te zeggen of er daardoor een nieuwe overeenkomst ontstaat of niet:
            You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you [..] keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
            Netto maakt het niet heel veel uit omdat die voorwaarden hetzelfde zijn. Maar als je de broncode opvraagt aan de partij van wie je een gecompileerde versie gekregen hebt, is het toch handig om dat bij de distributeur van de binary te doen, aangezien alleen zij weten of het een aangepaste versie is of een verbatim kopie.

            1. Ik baseer me op artikel 6:

              Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.
              Vanwege dat “receives a license from the original licensor” lees ik het dus als géén sublicentie, want dat is niet from the original licensor.

              De eerste tekst die jij citeert, gaat over jouw afgeleide werk. Daar moet jij natuurlijk de licentie op geven, want daar heb jij de auteursrechten op.

              Je tweede tekst zegt dat je de GPL voorwaarden moet laten staan. Ik haal daar niet uit dat jij een sublicentie verleent op andermans code.

              1. Ah ja, dat is klare taal inderdaad. Dus als partij C code ontvangt van partij B, die de code van A heeft ontvangen en aangepast, dan heeft partij C een contract met zowel B (voor de aanpassingen) als A (voor de oorspronkelijke code)?

                Kan een ingewikkeld web van licenties worden voor de eindgebruiker…

      1. De vraag is of ik degene ben die die toestemming geeft, en aan wie ik die geef.

        Ik zie meer in Arnouds standpunt, dat ik mijn code heb afgegeven aan het project (dat wil zeggen, de hoofdbetrokkene of de informele vereniging van betrokkenen), en dat zij het zijn die de code aan anderen in licentie hebben gegeven. (Het lijkt me overigens ondoenlijk om in het algemeen te bepalen wanneer er van zo’n vereniging sprake is en wie daar wanneer toe behoort.)

        Maar wie zijn die anderen? Misschien wel niet de eindgebruiker. Misschien zijn het wel distributeurs of herverpakkers van de code.

        Neem bijvoorbeeld deze wijziging. Ik heb die ooit gemaakt en naar de mailing list van het project gemaild; na bespreking daar hebben de beheerders van het project besloten om de wijziging, misschien licht aangepast, in de code base van het project op te nemen. Daarmee werd mijn code openbaar; die openbaarmaking heb ik dus niet zelf gedaan. Na 18 jaar is deze code nog steeds terug te vinden, zij het op een andere plaats en met allerlei verdere wijzigingen.. Wie gebruikt deze code? Het overgrote merendeel van de gebruikers zijn spelers van het spel Freeciv, van wie 99% nooit broncode heeft gezien en zich nooit heeft afgevraagd door wie die onder welke licentie is uitgegeven. Nee, wat ze doen is bijvoorbeeld in hun Ubuntu-distributie Freeciv – installeren aanklikken en dan het spel starten. Gaan ze daarmee een overeenkomst aan met mij voor het mogen gebruiken van mijn code? Ik vind dat heel erg onwaarschijnlijk. Ik denk dat ze een overeenkomst aangaan met Ubuntu voor het mogen gebruiken van Freeciv, dat Ubuntu (dat op Debian is gebaseerd), een overeenkomst is aangegaan met Debian voor het mogen gebruiken van Freeciv, dat Debian een overeenkomst is aangegaan met het Freeciv-project voor het mogen gebruiken van Freeciv, dat die informele vereniging (waar ik toe behoor of behoorde) Debian en alle andere gebruikers van de Freeciv-code daartoe toestemming heeeft gegeven, en dat ik zelf die informele vereniging toestemming heb gegeven om mijn code zo als onderdeel van hun werk te verspreiden. Je ziet dat, denk ik (maar ik geef mijn mening graag voor iemand met juridische kennis van zaken), als je je afvraagt wat ik kan doen als ik mijn toestemming voor het gebruiken van dit stukje code zou willen intrekken. Ik kan dat de eindgebruiker, of Ubuntu, of Debian, helemaal niet vragen! Ik moet bij de mensen van het Freeciv-project zijn. Dat maakt het niet meer dan logisch dat het ook die mensen zijn die ik in de eerste plaats toestemming voor het gebruik van mijn code heb gegeven.

        1. Ik heb naar een paar praatjes van Eben Moglen (samen met RMS de auteur van de eerste GPL versies) geluisterd en die zegt dat je voor het verspreiden van software een licentie nodig hebt; samen met de tekst van de GPL betekent dat dat zowel Debian als Ubuntu jouw licentie geaccepteerd hebben op het moment dat ze Freeciv aanboden. (In een pakket van GPL-licenties voor alle bijdragen aan Freeciv.)

          Dat de licentie namens de auteur verstrekt wordt is ook een feature, het betekent dat een tussenpartij niet zomaar een licentie kan intrekken als zij het niet eens is moet hoe de ontvanger de software gebruikt; alleen de originele auteurs hebben het recht. (In de praktijk zullen de kernontwerpers van een project voldoende code hebben geleverd om, in theorie, gezamenlijk het project van de markt te kunnen halen, maar de praktijk is lastig.)

          Een andere reden om de licentie direct van de auteur te laten komen is dat er internationaal niet een lijn is in welke rechtshandelingen een informele vereniging mag plegen… Een licentie verlenen is een rechtshandeling.

          1. Ik denk dus dat niet 1 auteur tegenover gebruikers de toestemming voor de verspreiding van zijn/haar code kan intrekken, als die code is vervlochten in een gezamenlijk werk. waarvan je kunt zeggen dat het door een vereniging of een publicist verspreid wordt die niet die auteur zelf is. De auteur heeft dan die toestemming namelijk niet zelf gegeven, dat heeft die vereniging of publicist dan gedaan. Wat die auteur wel kan doen is zijn/haar bijdrage terugtrekken uit dat geheel (de publicist of vereniging moeten dan de code van de auteur inderdaad uit het werk verwijderen), maar dat is dan een handeling van de auteur tegenover de vereniging of publicist, niet tegenover de eindgebruiker. Bovendien is het effect dan beperkt tot toekomstige verspreiding: ik denk niet dat je retroactief van mensen kunt vragen om software met code van jou erin te verwijderen op het moment dat jij je toestemming voor het gebruik intrekt.

            Ik verwacht dat het zo werkt voor bijvoorbeeld mijn bijdragen aan Freeciv. Of het voor bijdragen aan de Linuxkernel zo werkt, weet ik niet.

  5. Zou je niet verdere verspreiding van de software kunnen proberen te voorkomen op basis van art. 3:37 lid 5 BW? Er vanuit gaande dat je de licentie niet kunt intrekken, kun je iedereen die de software al ontvangen heeft, niet verbieden die software te gebruiken en verder te verspreiden. Maar je zou iedereen die de software nog niet ontvangen heeft, kunnen vertellen dat je bijdrages niet langer beschikbaar zijn onder de GPL licentie. Dan mogen die de software dus niet gaan gebruiken zodra ze die ontvangen. Dit is natuurlijk praktisch gezien wel lastig om de betreffende personen tijdig te bereiken, en te bewijzen dat je dat tijdig gedaan hebt.

    1. Dat werkt dan alleen tegen partijen die de software nog niet hebben gekregen. En ik twijfel ook wat er dan gebeurt als ze daarna van een derde toch een kopie onder GPLv2 krijgen, omdat daar immers in staat dat jij ze dan een licentie verleent. Dat zou ik dan lezen als een nieuw aanbod, juridisch een ander dus dan het aanbod dat jij daarnet had ingetrokken. Ik twijfel of je een nog niet gedaan aanbod kunt intrekken onder 3:37 lid 5 BW.

      Ik zou het zelf doen via art. 6:219 BW doen, ik trek dan het aanbod in, wat ik mag omdat niemand me gemeld heeft het te hebben aanvaard (lid 2). Probleem is dan wellicht dat het aanbod als onherroepelijk kan worden aangemerkt, waardoor het niet intrekbaar is. Het staat niet letterlijk in de GPLv2, maar gezien de aard van de licentie is het denk ik wel logisch om deze als onherroepelijk op te vatten.

  6. Hilarisch: als ik het verhaal goed begrijp is er een groep ontwikkelaars die klagen dat het om de inhoud en niet de vorm gaat, en vervolgens dreigen de inhoud terug te trekken omdat ze het niet met de vorm eens zijn.

    Ik twijfel of ik hier hard om moet lachen of vooral vermoeid moet hoofschudden.

    1. Ik moest vooral triest hoofdschudden. Die Code of Conduct zegt in feite niet meer dan dat je normaal met elkaar om moet gaan en daar vallen ze over? Zijn het dan zulke contact gestoorde wereldvreemde einzelgängers dat ze daar over vallen. Misschien moeten ze dan maar opzouten, wel zo prettig voor de minder contact gestoorde devs.

      1. Gezien Arnouts referentie naar “social justice warrior” heb ik zo’n vermoeden dat er gamergate-achtig gedrag achter schuil gaat. Zo zielig zijn sommige mensen helaas. Ze zijn in de minderheid, gelukkig.

      2. Heej, dit is nu al een overtreding van de Code of Conduct. Zo gaan we niet met elkaar om! Iemand/een groep contactgestoord noemen is een belediging en kleinering.

        Als je naam nu: “Elroy, bijdrager aan de Linux kernel | elroy@linux.org” was geweest, dan is dit mogelijk een directe overtreding van de Linux kernel CoC en willen we dat — als eensgezinde open source community — je stopt met bijdragen totdat je geleerd hebt normaal met elkaar om te gaan.

        [Within Scope] Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

        En ja: Heel veel open source software is geschreven door contact-gestoorde wereldvreemde eenzame autisten. Waar is je empathie voor deze mensen? Dezelfde skills die ze goed maakt in gedetailleerd programmeren, maakt ze “anders”/”divers” op dingen als een Code of Conduct (ze zien het als een regelboek voor een Dungeons and Dragons spel, waar fouten in kunnen zitten, en die inconsistent kunnen zijn).

        Wel bescherming voor dikke homofielen, maar niet voor witte autisten? Willekeur.

        1. Zelf ken ik toxicity niet van dit soort projecten (want ik doe er niet aan mee/heb niets bijgedragen) maar ken het zelf uit het gamen. Toxicity bestaat en is meer dan “homofielen moet je accepteren, dus autisten ook”. Natuurlijk zitten er mensen tussen die ernstig autistisch zijn en het moeilijk vinden om te gaan met allerlei mensen die niet exact zijn zoals ze verwachten. Echter blijkt het ook dat, net als bijvoorbeeld bij cv’s, code soms lager wordt gewaardeerd op basis van de naam van de contributor. Communities kunnen allerlei negatieve eigenschappen hebben, zoals een mannencultuur of white supremacy.

          Ik denk dat het goed mogelijk moet zijn, zelfs voor de mensen met de ergste contactstoornissen, om in ieder geval hun best te doen anderen met respect te behandelen. Er zullen dan vast een aantal overblijven die zich daar niet toe kunnen zetten, maar dat moet de uitzondering zijn, en niet de regel.

          Bovendien is mijn ervaring dat groepen waarin het “normaal” is om op een bepaalde manier met elkaar om te gaan en over anderen te praten, ook dat soort gedrag normaliseert. Het goede aan het internet is dat het makkelijker is om soortgelijke mensen te vinden, wat prettig is als je bijzondere interesses hebt in een kleine gemeenschap, maar dat kan helaas ook doorslaan. Je kunt ook gelijkgestemden vinden over ernstige en onwenselijke zaken.

          Ik vind het niet zo gek dat Linux, en andere open-source projecten, niet gemaakt willen zijn door mensen met kwalijke meningen of in een giftige sfeer. Ook loop je het risico veel toevoegingen mis te lopen doordat mensen niet worden geaccepteerd door deze giftige groep. Dan de giftige elementen er maar uit.

          1. Ik vind het niet zo gek dat Linux, en andere open-source projecten, niet gemaakt willen zijn door mensen met kwalijke meningen of in een giftige sfeer.

            Maar zie je nu niet wat je doet? ‘Kwalijke meningen’ is natuurlijk hardstikke subjectief, en ook nog eens niet constant over de tijd.

            En de giftige sfeer: Die bestaat vooral buiten of aan de rand van het inhoudelijke project. Die uitingen blijven toch wel gedaan worden, als het niet aan de rand van het project is, dan wel erbuiten. Dus je lost er niets mee op, Linux zijnde, alleen je eigen stoepje schoonvegen voor imagoredenen.

            1. Natuurlijk is dat subjectief. Het is immers iets maatschappelijks, iets juridisch. Alle juridische termen zijn subjectief – wanneer is een uiting smadelijk, wanneer is een gegeven een gevoelig persoonsgegeven? Dat is dus geen argument bij de vraag of iets maatschappelijk aanvaardbaar is.

              Al decennia, zo niet eeuwen, werken allerlei bedrijven en instanties met vage normen. “Geen onfatsoenlijk taalgebruik” of “Gepaste kleding verplicht”. Wat gepast is, verschuift behoorlijk over de tijd. Wat nu prima is in de Baja Beach Club, zou in de jaren vijftig in jongerensoos Het Uitspansel tot volkswoede hebben geleid. Ik zie werkelijk niet wat het probleem is met die verschuiving of tijdsgebondenheid.

              1. Daarom zei cg ook ‘hardstikke[sic] subjectief’ (het is ‘hartstikke’). Er is een verschil tussen subjectief in de ogen van een enkel persoon (“ik vind blauwe kleding beledigend”) en subjectief in de ogen van de huidige maatschappij (“we vinden hitlersnorren beledigend”), en alles daartussen (subculturen, en dergelijke). Juridische termen zijn als het goed is zo objectief mogelijk, en zo niet, subjectief overeenstemmend met een zo groot mogelijke groep mensen.

              2. Dat het subjectief is, is ook niet het grote probleem. Dat is ook niet de kern van mijn argument.

                De kern van mijn argument is dat een open source project een technisch langlopend samenwerkingsverband is van mensen die vrijwillig tijdelijk meewerken en vrijwillig meer of minder werk aanleveren.

                Er is geen overkoepelende autoriteit die iets te eisen, of te willen ( in de zin van niet gemaakt willen zijn door mensen met bepaalde meningen of bepaald gedrag) heeft.

                De gemeenschap kan alleen technische voorwaarden stellen op basis waarvan iemand mag meewerken aan het project. De kern van mijn argument is dat subjectieve voorwaarden niet compatibel zijn met technische voorwaarden.

                1. Er is geen overkoepelende autoriteit die iets te eisen, of te willen ( in de zin van niet gemaakt willen zijn door mensen met bepaalde meningen of bepaald gedrag) heeft.

                  Dat klopt niet. Linus heeft altijd het laatste woord. En dat geldt voor alle open projecten: uiteindelijk is er altijd een persoon die het voor het zeggen heeft.

                  Natuurlijk staat het een ieder vrij een eigen project te beginnen op basis van de code van het oude project. Dan kan die persoon zelf regels stellen.

                  Mochten we er even vanuitgaan dat er geen autoriteit is, zoals je betoogt, dan heeft het stellen van gedragsregels geen effect. Dan hoeven we er dus niet verder over te praten.

                2. De gemeenschap kan alleen technische voorwaarden stellen op basis waarvan iemand mag meewerken aan het project.
                  Daar ben ik het niet mee eens. Om in een project goede software te kunnen maken is communicatie (en ook overeenstemming) tussen de verschillende ontwikkelaars nodig. Linus stelt (heel terecht) niet alleen de eis dat een bijdrage aan de kernel nu werkt, maar vraagt ook om een commitment om de bijgedragen code te ondersteunen en (voor de toekomst) bugs te fixen.

                  Ja, er zijn vanuit project-management-oogpunt redenen om meer eisen te stellen dan dat de code technisch werkt… Aan de juridische kant is er de kwestie dat de licentie van de bijdrage moet passen met de licentie van het project.

                  1. Je kunt moeilijk zonder beheerder/coordinator. Die is een noodzakelijk kwaad.

                    Het kritieke discussiepunt is of je een beheerder hebt die alleen minimaal noodzakelijke doet om het project technisch te laten slagen, of dat die meer doet, namelijk het project commercieel succesvol maken of zoeken naar maatschappelijk draagvlak, en het daarom onwenselijk vindt dat mensen met een ‘rare’ mening zich met het project identificeren.

                    En dan is het maar helemaal een kwestie van mening wat voor soort beheerder dat je vindt dat er moet zijn.

                    1. Er is een zekere discrepantie tussen het historische optreden van Linus (lees maar eens een van zijn befaamde scheldkannonades) en de nieuwe gedragscode. Dat geeft me het vermoeden dat die code ook niet aansluit op de bestaande projectcultuur en dat daar de kern van het probleem ligt.

          2. De bijdrage van Hans Reiser is indertijd echter niet teruggetrokken uit Linux. Terwijl hij toch veroordeeld is vanwege een moord. En het ReiserFS systeem heb ik ook na die veroordeling nog jaren gebruikt zonder enige gewetenswroeging.

          3. Het is vrijwel onmogelijk om politiek uit deze discussie te laten, en dat maakt discusseren lastiger. Ik heb zelf het gevoel dat het internet meer naar “social network” gaat neigen. De tendens is dus om “open source code” als “social source code” te gaan zien: Iedereen moet kunnen bijdragen aan het project zonder getriggered te worden, we zijn nu Post-Meritocratie (van dezelfde auteur als de CoC: https://postmeritocracy.org/nl/ ).

            Open source is beide communistisch, maar ook kapitalistisch: Projecten werken als ze waarde hebben, of ze werken niet. Het is een open markt van ideeen, die bestaat uit waarde en kunst, ongeacht het gedrag of opinies van de makers. Ik geloof dat een markt rationeel is ten opzichte van winst en waarde: ze vindt snel (en zonder hulp van CoC’s) een dichtbij-optimale oplossing. Ik geloof ook dat een markt irrationeel is ten opzichte van normen en waarden: ze heeft een Bijbel of CoC’s of regulatie nodig voor optimale sociale cohesie en eerlijkheid/gelijke behandeling. Het gaat er dan om wat je belangrijker vind: De beste en meest gevarieerde open source code toegankelijk voor jou? Of vriendelijke en eerlijke open source code toegankelijk voor iedereen? Als je gaat voor harde winst, realiseer dan dat er flink wat zieltjes gekwetst gaan worden. Als je gaat voor een meer inclusieve social source community, realiseer dan dat dit soort CoC’s ten koste gaat van de winst (hoeveel slechter % is Linux nu Linus bij de psycholoog zit?). Vrije markt of eerlijke deelname?

            Op social media is het veel gemakkelijker om positief te staan tegenover immigranten (het slechtste wat je kan gebeuren is als naief bestempeld te worden), dan negatief te staan tegenover immigranten (je zou een Nazi zijn). Nazies zijn giftig. Naieve mensen zijn post-meritocratie. Beide meningen zijn volkomen democratisch en legitiem. Een ieder vindt de andere mening kwalijk. Speltheorie geeft dus aan dat de negatieven hier het onderspit zullen delven.

            De uitspattingen van Linus zijn misschien 0.001% van alle posts en emails (hij verstuurd er duizenden per jaar). Soms wordt hij boos en kan hij geen andere woorden vinden dan: “je bent een domme debiel en moet je bek houden”. Dit is voor mij herkenbaar als het gaat om dingen waar ik veel om geef. Ik kan daar dan echt op moment niets aan doen. Daarop aangevallen worden voelt als aangevallen worden op iets dat je niet kan veranderen (dikheid door ziekte, huidskleur, lage intelligentie).

            Communities kunnen allerlei negatieve eigenschappen hebben, zoals een mannencultuur of white supremacy.

            Ik ga hier voor vrije markt en niet voor eerlijke deelname. Communities mogen, zonder prescriptie, zich vormen en een vrouwencultuur (vrouwendispuut) of black power cultuur vieren. Voel je je daar niet thuis, organiseer dan je eigen feestje (liefst waar mensen die zich ook nergens thuis voelen welkom zijn).

            Ik vind het niet zo gek dat Linux, en andere open-source projecten, niet gemaakt willen zijn door mensen met kwalijke meningen

            Ik ga hier voor vrije markt en niet voor eerlijke deelname, tenminste eerlijke deelname voor iedereen, ook mensen met kwalijke meningen. Het probleem (voor mij om op te lossen) is dan bij de persoon die zich niet welkom voelt in de community, omdat er deelnemers zijn met ogenschijnlijk kwalijke meningen, en niet dat de community mensen met kwalijke meningen laat deelnemen. Code heeft geen politieke kleur en staat los van kwalijke meningen. Dat is het meest inclusief. Als potentiele deelnemers dan ook nog een schild vormen tegen voor hun abjecte meningen, dan is het probleem zo goed als opgelost.

            1. Thorvald, Je hebt een mooie gebalanceerde analyse gebracht.

              Communities zijn vrij. Het zijn geen formele organisaties die zich aan wetten moeten houden (zoals: iedereen mag lid worden, en we zullen ons best doen dat iedereen zich welkom voelt), maar informele structuren van gelijkgezinden.

              Zodra iemand de macht heeft om een CoC op te leggen is het eigenlijk geen community meer, maar een formele organisatie (misschien nog steeds met een groot community-aspect).

              In het Linux verhaal denk ik dat je de code, en de bijbehorende community, als losstaand van elkaar moet zien: In het Linux verhaal is het de bedoeling een zo goed mogelijk OS neer te zetten. (wat goed is, daar kun je over twisten, daarom zijn er ook zoveel forks). Dat daar een community omheen ontstaat, waar sommige mensen zich prettig in voelen, is een bijeffect.

              Ik denk dat het een fundamentele fout is om een community, die niet gereguleerd wil worden, en per definitie niet gereguleerd kan worden, te willen reguleren.

              Linus kan natuurlijk code weigeren van mensen die niet aan door hem gestelde voorwaarden voldoen (of dat verstandig is, of eerlijk, is een andere zaak). Maar hij kan geen mensen uit een community schoppen, mensen bepalen zelf met wie ze een community vormen.

              Neem als voorbeeld deze blog. Arnoud zou mij kunnen bannen. Maar dat zou nog niet meteen betekenen dat ik uit de community van regelmatige reageerders verwijderd wordt. We kunnen immers gemakkelijk op een andere plek gaan reageren.

              Maar als de andere leden van de community besluiten dat niet te doen en hier te blijven, is het niet Arnoud die mij uit de community geschopt heeft (hij heeft mij immers alleen van zijn blog geschopt), maar de community die mij eruit geschopt heeft (die heeft immers laten blijken dat ze het niet heel veel kan schelen of ik er nog bij zit of niet).

              Zo is het met Linus ook. Er is een verschil tussen Linus de baas van Linux, en Linus de informele leider van een community. Als baas van Linus mag hij een CoC maken en afdwingen, als informeel leider van de community niet.

              Maar hij doet het toch, en dus zal de comminity zich splitsen in volgers en afhakers. Ik denk dat de tegenstanders vooral een emotionel reactie daartegen hebben. De bestaande community waarin zij een hoge status hebben wordt kleiner, en natuurlijk vinden ze dat niet fijn.

              1. Communities bewegen zich in het schemergebied van rationeel en superrationeel tov winst en waarde: Spellen, zoals het gevangenendilemma en de altruistische benefactor tonen aan dat de meeste winst behaald kan worden, door het spel “als 1 persoon” te spelen. Echter, zodra een individuele deelnemer zich kan verrijken, ten koste van andere deelnemers, dan is dit in zijn/haar aard dit te doen. Communities maken samenwerken een valide strategie zolang de community vertrouwd kan worden en sterke samenhang vertoond (een CoC kan hier idealiter aan bijdragen, maar ook reeele schade doen). Als een communitie superrationeel was, dan zou het werken aan meer diversiteit (minder samenhang), omdat dan de output van het project in aggregaat beter is (diversiteit verhoogd de accuraatheid, omdat het met andere ogen naar bugs en bruikbaarheid kijkt). Maar dit is een lastige investering die pas in enkele jaren dividend zou kunnen tonen. De huidig behaalde winst is dus slechts een lager percentage van de mogelijke ideale winst.

                Communities bewegen zich in het schemergebied van irrationeel en superirrationeel tov normen en waarden: Het is niet zo dat communities het specifiek op minderheden of vrouwen gemunt hebben, het is gewoon zo dat het gemakkelijker werkt (minder energie vergt voor eenzelfde resultaat). Het voelt echter wel zo. Zelfde is het met de zondebokken van de communities. Die worden niet superirrationeel gekozen. Dit is slechts een toegankelijke deksel (globalisten, immigranten) die op het potje (community) past. Het is zeldzaam dat een communitie het potje maakt voor 1 specifiek dekseltje. Het voelt echter wel zo.

  7. Alhier het werkzame deel van de code of conduct:

    Examples of unacceptable behavior by participants include:

    • The use of sexualized language or imagery and unwelcome sexual attention or advances
    • Trolling, insulting/derogatory comments, and personal or political attacks
    • Public or private harassment
    • Publishing others’ private information, such as a physical or electronic address, without explicit permission
    • Other conduct which could reasonably be considered inappropriate in a professional setting

    Je aan zulke regels moeten houden is inderdaad verschrikkelijk. Wat hebben wij mannen het anno 2018 toch moeilijk! Niemand lastig vallen, elkaar netjes behandelen, bah!

    Full disclosure: ondergetekende heeft bijdragen in de kernel.

    1. Van mensen die over zulke regels moeilijk doen, krijg ik als vrouwelijke dev altijd de kriebels. De meeste mannen zijn prima mensen, maar je weet nooit of die éne vreemdeling niet bij het “foute” groepje hoort, waardoor je sneller gespannen en alert bent. Het is dan fijn om te lezen dat er genoeg mannen zijn die geen moeite hebben met zulke regels, dat steekt weer een hart onder de riem. En dan besef ik weer dat de minkukels toch echt een kleine minderheid zijn.

      1. Het is niet zozeer dat ik het met de inhoud van dit soort regels oneens ben, integendeel, ik vind deze regels zo voor de hand liggend dat het kinderachtig voelt om ze überhaupt in een documentje te stoppen en mensen dit te laten ondertekenen.

        Ik zou het zeer irritant vinden als elke keer dat ik bij het bedrijf waar ik werk naar binnen loop, de portier tegen me zegt: “niet tegen de muren plassen, hè!” (of erger, dat dit vastgelegd wordt in een sociaal contract). Dat je geen klootzak moet zijn is logisch, en het theater om dit vast te leggen is volgens mij niet effectief (en geeft misschien wel een vals gevoel van dat het hier wel goed zal wezen). Besteedt liever die energie aan het aanpakken van de mensen die zich misdragen. Deze mensen weten ook zonder sociaal contract wel dat wat ze doen niet door de beugel kan.

        De mensen die hier moeilijk over doen, doen dat waarschijnlijk niet omdat ze zich willen misdragen. Tenminste, dat denk ik…

        Edit: de mensen die hun code willen terugtrekken zijn natuurlijk wel echte zeikerds. Dan ben je gewoon moeilijk aan het doen om het moeilijk doen.

        1. Ik denk dat zulke regels een zekere symbolische waarde hebben. Om te zeggen dat als je eventueel dacht dat het hier een soort Walhalla was voor dit soort gedrag (als degene die zulk gedrag vertoont), dat het toch echt niet zo is.

          Bovendien lijkt me zo’n CoC niet hetzelfde een portier die tegen je roept dat je niet tegen de muren mag zeiken, maar meer dat het in de huisregels staat die je tekent bij je contract, omdat er een groepje is die het normaal vond om tegen de muur te zeiken. Meestal zie je ook in huisregels een paar regels die specifiek lijken te zijn om vroeger gedrag af te kaarten.

          Bovendien lijkt het me altijd wel handig, zeker met dingen op het internet, om dit soort regels op te schrijven zodat je ergens hebt om naar te wijzen als je iemand wil aanpakken. Het gaat om veel verschillende landen met veel verschillende mate van bescherming voor verschillende bevolkingsgroepen, en zo heb je gewoon een set normale regels.

          1. om dit soort regels op te schrijven zodat je ergens hebt om naar te wijzen als je iemand wil aanpakken
            Maar daar schuilt ook weer een gevaar, namelijk dat de regels subjectief of met een agenda in het hoofd kunnen worden toegepast. Dat klinkt een beetje paranoïde, maar bij wetten is het hetzelfde. Als iedereen wel ergens in overtreding van is, dan krijgt de handhaver ineens de macht om mensen al dan niet aan te pakken. Boorbeeld: A flirt met B, en B vindt dat leuk. So far, so good. C flirt met B, en B vindt dat niet leuk, klaagt met de CoC in de hand bij de directie waarop C op het matje geroepen wordt. Zonder de CoC kan de directie het misschien sussen, maar nu zwart op wit te lezen dat er een regel is voor dit soort dingen, kan dat minder makkelijk.

            Ik ben niet 100% tegen huisregels, maar er schuilen gevaren in die goed doorgedacht moeten worden voordat je maar een pak regels op papier smijt. En je moet het alleen doen als er een realistisch probleem is dat je wilt oplossen en niet omdat het beter oogt voor je bedrijf of stichting of whatever.

            1. Het gaat er in zo’n geval vooral om wie je inhuurt om de regels te handhaven, en hoe je je interne richtlijnen omschrijft. Het voordeel in dit soort projecten is dat het moeilijk is om mensen in een dictatuur te vangen. Dan zetten ze gewoon wat anders op.

              Gezien het is opgezet om toxicity tegen te gaan, zal het niet gauw worden ingezet om toxicity te versterken (wat technisch gezien wel zou kunnen, door met interpretatie te vogelen en niet altijd toe te passen). De aanpak geeft ook een zekere precedentwerking, waardoor mensen de handhavers kunnen aanspreken op verschillen in toepassing.

              Wat flirten betreft: Daar mag misschien sowieso wel een rem op. Ik vermoed dat flirten, zolang daar geen grensoverschrijdend gedrag bij zit, geen probleem is. Op het moment dat B hun grens aangeeft bij C, dient C zich daaraan te houden, zelfs als die grens voor A anders ligt. Als C toch over die grens gaat, kunnen ze daar wat mee. En zelfs met huisregels zal dit in eerste instantie sussend zijn, tenzij het te heftig is.

              Tegelijkertijd zijn er landen waarin vrouwen toch echt als minderwaardig worden beschouwd, of homo’s verboden zijn, en dan kun je naar de regels wijzen dat het best kan dat het in jouw land mag, maar niet in dit project.

      2. Ik ben geen developer en heb al helemaal niet aan de kernel bijgedragen, maar je moet het misschien toch iets anders zien, werkbij.

        In interacties met anderen kunnen sommigen gewoon bot zijn, onbeschoft. Hufters kortom. Dat kan kwaadwillendheid zijn, maar het kan ook gewoon duiden op onvoldoende sociale vaardigheden, wat ze zelf misschien ook wel jammer vinden.

        Daar is niet veel aan te doen, zo zijn ze gewoon. Mogen ze dan geen code meer bijdragen, omdat ze hufters zijn, of per ongeluk sociale fouten maken? Mag een brandweerman die geen donder uitvoert in het huishouden maar verwacht dat zijn vrouw hem zijn biertje brengt, jouw huis niet meer blussen omdat hij een hufter is?

        Kortom, ik vind dat mensen een recht hebben om onbeschofte hufters te zijn. De consequentie, namelijk dat ze sociaal gemeden worden, dragen ze zelf.

        Ik zou liever hebben dat ze het niet zijn, maar om nu een code of conduct te maken voor vrijwilligers die een technisch product aanleveren en zich soms minder, of niet, aan algemeen geaccepteerde omgangsvormen houden gaat me een beetje ver.

        Algemene geaccepteerde omgangvormen zijn ook niet universeel maar cultuur-afhankelijk, en zijn natuurlijk ook een manier van een meerderheid om zijn wil op te leggen aan een minderheid.

        Live and let live, zou ik zeggen, en ja, daar hoort wel eens een sociaal ongemakkelijke situatie bij. Het alternatief is een soort gedachtenpolitie, en daar worden we ook niet gelukkig van.

        Sociaal gewenst gedrag kun je niet afdwingen (behalve als je echt controle hebt: werkgever/werknemer bijvoorbeeld).

        Bovendien, ik denk ook dat de tegenstanders hun code-bijdragen als regelatief losstaand van hun sociale gedrag beschouwen, en ook daar valt wel wat voor te zeggen.

      3. De meeste mannen zijn prima mensen, maar je weet nooit of die éne vreemdeling niet bij het “foute” groepje hoort, waardoor je sneller gespannen en alert bent. Het is dan fijn om te lezen dat er genoeg mannen zijn die geen moeite hebben met zulke regels, dat steekt weer een hart onder de riem. En dan besef ik weer dat de minkukels toch echt een kleine minderheid zijn.

        Om te laten zien hoe fout deze reactie is, zal ik het woord ‘mannen’ door ‘moslims’ vervangen. Let op dat dit dus absoluut niet mijn mening is, maar alleen een manier om te laten zien dat deze reactie erg fout is:

        De meeste moslims zijn prima mensen, maar je weet nooit of die éne vreemdeling niet bij het “foute” groepje hoort, waardoor je sneller gespannen en alert bent. Het is dan fijn om te lezen dat er genoeg moslims zijn die geen moeite hebben met zulke regels, dat steekt weer een hart onder de riem. En dan besef ik weer dat de minkukels toch echt een kleine minderheid zijn.

        Fout he? Dacht ik ook ja.

        1. De meeste mensen zijn prima mensen, maar je weet nooit of die éne enkeling niet bij het “foute” groepje hoort, waardoor je sneller gespannen en alert bent. Het is dan fijn om te lezen dat er genoeg mensen zijn die geen moeite hebben met zulke regels, dat steekt weer een hart onder de riem. En dan besef ik weer dat de minkukels toch echt een kleine minderheid zijn.

          Zo beter?

  8. Ook opensource projecten in beheer waar deze Code of Conduct aan is toegevoegd, en ik voel me er niet prettig bij.

    Ik heb het idee dat deze CoC in strijd is met de open source licentie die reeds eerder was toegevoegd. “Je bent vrij om te doen met deze software wat je wil”, behalve als je bijdraagt aan de code en dan op social media (met de naam van het project in je profiel) nare politiek-incorrecte dingen zegt. Dan ben je in strijd met de CoC.

    Deze CoC is zelf een “politieke aanval” (identiteitspolitiek), omdat veel linkse mensen een politiek-rechtse mening als beledigend opvatten (als hoofdbijdrager van de software financieel bijdragen aan de PVV of FvD? Je zou uit je eigen project gewerkt kunnen worden).

    Nu is dit niet de grond waarop ik wil sterven, en de bedoeling achter mening CoC is goed. Maar het micromanagement van moraal is heel erg eng, het is politiek gemotiveerd, overbodig (niemand gaat iemand op een pull request zitten uitschelden voor dikke lelijkerd), en in strijd met vrije software ontwikkeling/licenties: Je mag alles met de software doen — zelfs al ben je vocaal rechts, haat je lelijke dikkerds, geloof je in Evil, en is je emotionele IQ te laag om altijd maar met een glimlach slechte code de deur te wijzen.

    Plak de CoC achter de licentie en het klopt gewoon niet. Houdt de CoC buiten de licentie, en handhaving wordt een politiek spel waar mensen je Twitter-feed tot in 2012 gaan nalopen, of je dronken gedrag op een feestje na een conferentie in de scope van de CoC sleuren.

    1. De code gaat alleen over het project (eventueel informele vereniging). De GPL geeft recht op de source code, recht om die te wijzigen en recht om dat te verspreiden. Wat het niet doet is anderen dwingen om jouw code te accepteren in hun samenwerking. Het dwingt ze ook niet om naar je te luisteren of je op de mailing lijst (of andere fora) te dulden. Dit ongeacht of ze de cofe slecht vinden, je een hufter bent (of de mensen in het project) of dat je gewoon ruzie hebt. Zelfs als het ze niet kan boeien heb je dat voor lief te nemen.

      1. De CoC heeft een zeer brede scope: dingen die je op Twitter zegt (als hoedanigheid van bijdrager aan open source code project) vallen in de scope.

        Ik plak een open source licentie op mijn projecten, omdat ik wil dat die open source zijn. Iemand’s bijdrage weigeren, omdat deze op Twitter — nogal lomp — voor een strenger immigratiebeleid pleit, is niet mijn idee van open source. Misschien moet er een nieuwe licentie komen die ook “code bijdragen” vrijstelt van politieke willekeur.

        In ieder geval kun je niet de http://www.wtfpl.net/ licentie toevoegen aan een project wat reeds deze CoC heeft (en vice versa). De WTFPL licentie gebruikt namelijk gesexualiseerde/grove taal.

    2. Je haalt hier van alles door elkaar (helaas typisch voor het boze witte mannetjes-complex). Handel je in strijd met de code of conduct, mag je nog gewoon Linux gebruiken. De code of conduct zelf wordt geen onderdeel van de GPL.

      1. De Code of Conduct is wel degelijk onderdeel van de GPL, want het is een document dat deel uitmaakt van de broncode.

        En mij een slachtoffer van boze witte mannetjes-complex noemen is een overtreding van de Code of Conduct. Probeer meer inclusieve taal te gebruiken! (of registreer je Tourettes aandoening als handicap en je krijgt van mij vrijstelling voor je onveranderbare gedrag)

        1. Dat is natuurlijk complete onzin. In elk source-bestand van Linux staat bovenaan precies beschreven wat de licentie van die code is. Wat er elders in de tree gebeurt is daarop niet van invloed. Overigens kan een derde de licentie van jouw code niet zonder meer veranderen, zelfs als men dat zou willen.

  9. gaat ‘m niet worden.

    Veel software waaronder Word zet dat kommaatje inderdaad automatisch verkeerd, maar hij moet andersom, ’m, net als bij ’s avonds en ’s-Hertogenbosch. Voor wie Windows gebruikt met de US-international toetsenbordindeling: rechter-Alt-), niet idem (.

    (Nu benieuwd of de blogsoftware dit bericht laat staan zoals getikt.)

    Edit: gelukkig, is goed gegaan.

Geef een reactie

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