Maakt die Google/Oracle-uitspraak de GPL krachteloos?

gpl-sans-plombeJe kunt je mooie GPL vaarwel kussen, las ik bij Ars Technica vorige week. Die Google/Oracle uitspraak die een API fair use verklaarde, gaat namelijk de GPL en consorten onderuit schoffelen. Oké, het was de advocaat van Oracle die dat schreef, maar er zit een argumentatie bij. Dus laten we die eens nader bekijken.

In het kort is het een typisch “de wereld stort in want ik kreeg ongelijk”-verhaal dat te reduceren is tot deze quote:

While we don’t know what ultimately swayed the jury, Google’s narrative boiled down to this: because the Java APIs have been open, any use of them was justified and all licensing restrictions should be disregarded. In other words, if you offer your software on an open and free basis, any use is fair use.

Volgens mij slaat advocate Hurst hier de plank stevig mis, want er is nogal een verschil tussen een API hergebruiken met je eigen code en het hergebruiken van code. En dát is waar de GPL voor geschreven is: copypasten van code, of het linken/combineren van die code in je eigen software. Bij dergelijke handelingen heb ik weinig twijfel dat sprake is van een auteursrechtelijk relevante handeling.

Inderdaad, als iemand een GPL header file of API zou hebben en jij zou een eigen implementatie daarvan schrijven, dan zou je waarschijnlijk in Amerika onder fair use daarmee vrij lopen zodat de GPL niet op jou van toepassing zou zijn. Maar is dat vervelend? Volgens mij is dat een behoorlijk uitzonderlijke situatie en zeker niet de normale wijze van hergebruiken van iemands GPL werk.

Dus nee, hier wordt uit de nek gekletst.

Arnoud

33 reacties

    1. Het gebruiken van een library is iets anders dan het gebruiken van de API van die library. Je kunt namelijk een tweede library maken, die geen regel code bevat van de eerste library, maar wel precies de zelfde API heeft. In de VS zou dat nu als “fair use” gelden, maar het was al langer gebruikelijk dat dit niet als auteursrechtenschending wordt gezien.

      Het verschil tussen GPL en LGPL wordt pas relevant als je niet alleen de zelfde API gebruikt, maar ook de zelfde implementatie van de library, dus als je echt code kopieert. Dan pleeg je potentieel auteursrechteninbreuk, en worden de licentievoorwaarden relevant. De LGPL staat dit expliciet toe, onder bepaalde voorwaarden: o.a. wijzigingen in de library zelf moet je ook weer (L)GPL voorwaarden geven.

      De GPL staat het niet toe om een gecombineerd werk te publiceren dat ook niet-GPL code bevat. Veel mensen zien de combinatie van executable + library als een gecombineerd werk, omdat de FSF over het algemeen “linken” ziet als de stap die een gecombineerd werk maakt, zelfs als de library als apart bestand (DLL o.i.d.) wordt geleverd. Ik denk dat dit nog een beetje een zwak punt van de GPL is, dat in de praktijk in rechtszaken getoetst zou moeten worden.

      1. Dat dynamisch linken hebben we eerder een discussie over gehad hoe dat onder het nederlandse auteursrecht zou zijn. Ik ben er van overtuigd dat het onder het Nederlandse auteursrecht niet stand houdt.

        En onder het Amerikaanse auteursrecht zou het geen stand meer m0eten houden na deze uitspraak. Immers als de API gebruiken voor een herimplementatie fair use is dan kan je een compatible herimplementatie maken (naast API ook ABI compatible maken). Als je jouw programma linkt tegen die non-GPL DLL dan kan die daarna door de originele GPL DLL vervangen. Hoe kan je volhouden dat iets een derived work is als je drop-in replacement bibliotheken hebt?

        1. Dat geldt alleen als je een niet-GPL herimplementatie hebt. Meestal heb je die niet, en is het ook nog eens veel werk om die te maken. En als je die wel hebt, waarom zou je dan nog de GPL-versie gebruiken?

          Het wordt misschien interessant als er een GPL- en een niet-GPL-versie is met de zelfde API, maar de GPL-versie significant beter is. Je hebt dan een reden om de GPL-versie mee te leveren. Zou dat dan mogen, met als argument dat het geem combined work is omdat er ook die niet-GPL versie is die als drop-in replacement gebruikt kan worden?

          In het extreme geval is die niet-GPL-versie een stub: een bijna lege library, die niets anders doet dan de API leveren die de executable nodig heeft, zonder zinvolle implementatie. Dan faalt de “giecheltoets” al snel.

          1. Ik zie niet hoe het daadwerkelijk bestaan van een niet GPL implementatie iets aan de conclusie veranderd dat een bibliotheek die je runtime door een andere kan vervangen (of die vervanger er nu is of niet) geen onderdeel van het werk is. Het feit dat het kan betekent al dat het een op zich staand werk is.

          2. Ik denk ook niet dat het argument moet zijn, er is een niet-GPL implementatie dús is het geen afgeleid werk. Voor mij is het fundamenteler: het is geen inbreukmakende handeling om code te schrijven die een API aanroept of headers importeert. Dat is immers slechts aanroepen van functionaliteit en daarop rust geen auteursrecht. Geen inbreuk, dus geen discussie over wat de licentie ervan vindt. Dit mag gewoon, net als citeren of parodiëren.

            En ja, daarmee is ook gewoon klassiek dynamisch linken met GPL code geen inbreuk.

            1. En ja, daarmee is ook gewoon klassiek dynamisch linken met GPL code geen inbreuk.

              Ik ben het op zich met je eens dat deze interpretatie juist is. De licentie is echter ook een (soort, niet helemaal) contract, dat rechten geeft onder voorwaarden. Zonder de licentie kan de GPL library helemaal niet gebruikt worden zonder inbreuk te plegen. Het linken vanuit niet-GPL code is dan geen directe inbreuk op het auteursrecht, maar wel een contractbreuk die volgens de GPL het gebruiksrecht ondermijnt (waardoor het gebruik van de library niet meer onder de licentie valt).

              De clausule is vooral belangrijk in gevallen van grote “proprietary” software bedrijven die bang zijn dat ze hun eigen software onder GPL moeten vrijgeven als ze “per ongeluk” (programmeurs zijn zeer slordig met licenties) GPL bibliotheken gebruiken in een gedeelte van de software. De verhouding tussen eigen en GPL code is vaak sterk uit balans (veel meer eigen code) en over het algemeen zijn de uitkomsten van dit soort zaken zo dat de eigen code niet onder GPL wordt vrijgegeven, maar het maakt veel bedrijven (en hun juristen) wel bang.

              1. Het klopt dat de GPL een contract is (hoewel de opstellers ervan daar anders over denken, maar naar Amerikaans recht). Echter, dat contract blijft binnen de lijntjes van het auteursrecht en zegt in feite “als je iets doet dat normaal inbreuk is, dan mag dat alleen conform onze voorwaarden”. Omdat linken geen inbreuk is, doe ik dus niets waarvoor ik me aan de licentie moet conformeren.

                Ik zou ook kunnen zeggen: ik download en inspecteer de software, dat is legaal onder de Auteurswet (art. 45k en m) en dus ook geen inbreuk. Ik heb een wettelijk gebruiksrecht. Daarmee achterhaal ik de API of functieheaders geheel legaal en zonder aan het contract gebonden te zijn. Vervolgens roep ik deze aan, wat dus mag omdat linken geen inbreuk is. Nergens doe ik dan iets dat normaal inbreuk zou zijn, dus nergens doe ik iets waarvoor ik aan de GPL gebonden moet zijn. Dus heb ik met de GPL niets te maken.

            2. Natuurlijk is het inbreuk, alleen wordt die gemaakt door het programma te draaien! Op dat moment worden de onderdelen immers wel samengevoegd.

              Het juridisch excuus komt daarmee neer op “ja maar de klant drukt op de knop, ze hadden dat ook niet kunnen doen. tja, de software is misschien nutteloos zonder een druk op die knop, dus waarom zouden zij het dan afnemen? dat weten wij ook niet, wij doen wat de klant vraagt, maar wij plegen geen inbreuk, dat moet de klant helemaal zelf weten.”.

              En, Arnoud, kom je daarmee weg bij de rechter? 🙂

              1. Daar kom je mee weg ja. Je mag namelijk gerust GPL en non-GPL combineren, zolang je die combinatie maar niet verspreid, want als je dat doet moet het onder de GPL.

                Dus los van de discussie of dynamisch linken wel of niet leidt tot een afgeleid werk en dus een auteursrechtelijke handeling mag die eindgebruiker combineren tot hij erbij neervalt.

                1. En de eis dat de combinatie onder GPL verspreid moet worden is voor mij de reden om GPL code van derden in eigen projecten te gebruiken. Dat lijkt mij ook niet gelijk de bedoeling van opensource.

                2. Als dat zo is, is de ‘niet statisch linken’-bepaling uit de GPL dus nutteloos. ‘Dynamisch linken’ klinkt leuk, maar is in feite niets meer dan het uitstellen van het gewone, ‘statische’ linken, tot op het moment dat het nodig is voor het draaien van het programma. Misschien is mijn voorbeeld dan ook niet helemaal juist: het is meer als een valluik: de opdracht wordt al door de leverancier gegeven, de klant heeft alleen inspraak wat betreft het tijdstip, en vaak dat nog niet eens.

                  En dan koment we nog bij vragen waar zelfs techneuten het niet over eens zijn: is een Makefile misschien ook een programma? En wat is ‘linken’ in werelden van programmas die elkaar uitvoeren en daarbij ook gegevens uitwisselen? Is het openen van een netwerkverbinding misschien al linken in bredere zin? Of een gezamenlijk bestand? Een pijp, een socket? Al zijn dat natuurlijk geen juridische argumenten…

                  Mocht de GPL al in 1960 bedacht zijn, dan was-ie al belegen geweest.

                  Bah, een soort anti-GPL rant. Dat was helemaal niet de bedoeling (al ben ik van de blauwe knoop^W^W^Whet publieke domein…).

                  1. Effectief is bij statisch linken de gpl code onderdeel van de binary die je verspreid. Je kan dan jouw werk niet meer separaat van het GPL werk verspreiden. Het is ook niet meer te vervangen door een andere compatibile implementatie.

                    Als je dynamisch linkt kan je de software en de library apart distribueren. De eindgebruiker kan een andere compatible library gebruiken, zolang die zich maar hetzelfde presenteert.

                3. Dat weet ik toch niet zo zeker. Als je puur een stuk GPL software verspreid naast je eigen software, dan valt jouw software niet direct onder de GPL. Alleen als je ook daadwerkelijk code overneemt.

                  Het lijkt me sterk dat je door het opnemen van een library ineens aan de GPL vast zit. Zeker als het gebruik van een API nu we mag.

                  En ja, je bent dan wel verplicht om de broncode van die library beschikbaar te maken, want GPL.

              2. “Samenvoegen” is geen juridische term. “Verveelvoudiging in gewijzigde vorm” (Europa) of “afgeleid werk” (US) zijn de criteria. Ik zie niet hoe ik de bibliotheek in gewijzigde vorm kopieer door hem aan te roepen. Ik gebruik hem gewoon. Daarom vind ik dat geen inbreuk.

                Dit nog los van het feit dat de GPL zegt dat “the act of running” altijd toegestaan is. Dus zelfs als linken een inbreuk is, dan is die inbreuk toegestaan onder het licentiecontract.

                1. Wat er in feite gebeurt bij klassiek dynamisch linken:

                  1. De gebruiker (direct of indirect) geeft de computer de opdracht om een programma uit te voeren;
                  2. De computer is zo geprogrammeerd dat ze eerst kijkt of het programma compleet is: als het niet compleet is roept ze eerst de linker aan om het programma te completeren;
                  3. Het programma wordt uitgevoerd.

                  Daarbij kan ik misschien beter opmerken dat, voor de opkomst van dynamische linkers, het nog wel eens gebeurde dat een wrapper de statische linker aanriep, om het resultaat uit te voeren.

                  Dit is misschien haarkloverij, maar dat zijn toch echt aparte stappen. Het complete resultaat kan bijv. ook worden gedumpt en later weer worden ingelezen. Of naar een andere partij gestuurd. In feite is dat wat er gebeurt na ‘gewoon, statisch’ linken. Daarom spreekt men ook wel over een ‘executable image’ i.p.v. ‘program’.

                  De grote uitzondering zijn ‘loadable modules’. Daarbij draait het programma doorgaans al, om alsnog (of opnieuw!) de dynamische linker aan te roepen om de module in zichzelf te integreren. Maar ook daar is het linken een aparte, expliciete stap.

                  Wat onder “running” valt, is dus nog maar zeer de vraag. Bovendien is het niet de bibliotheek die gewijzigd wordt, maar het programma!

                  Ik weet dat dit soort technische argumenten niet erg recht-compatibel zijn. De vraag is dus eigenlijk: zijn de bepalingen in de GPL dat wel? Ze leunen immers op technische termen die, zoals je ziet, nogal voor uitleg vatbaar zijn.

              3. En, Arnoud, kom je daarmee weg bij de rechter?

                Nee, dat is (op zijn minst) het aanzetten tot een onrechtmatige daad (of zelfs criminele daad – in de praktijk is het meeste auteursrecht niet binnen het strafrecht). Het aanzetten tot een onrechtmatige daad is zelf ook onrechtmatig.

                Overigens lijkt dit heel erg op de NVidia truuk voor de kerneldrivers. Alleen is het daar de gebruiker die het compileren en linken doet zodat twee incompatible (qua licentie) stukken code gecombineerd worden. Deze praktijk is juridisch dubieus, maar wordt inmiddels al zo lang gebruikt (met medeweten van kernelontwikkelaars) dat klagen waarschijnlijk weinig kans heeft.

            3. En ja, daarmee is ook gewoon klassiek dynamisch linken met GPL code geen inbreuk.

              Waar list dan de grens?

              Als je wel dynamisch linkt, maar software + DLL samen op het zelfde medium distribueert, is dat dan wel een inbreuk? Om legaal een kopie van de DLL te distribueren moet je toch akkoord zijn gegaan met de GPL?

              En wat als je een firmware blob levert waarin een filesystem zit waar de library als DLL in staat? Of is dat effectief net zoiets als statisch linken, omdat de gebruiker de DLL praktisch niet los kan gebruiken en/of upgraden/vervangen?

        2. Hoe kan je volhouden dat iets een derived work is als je drop-in replacement bibliotheken hebt?

          Door te argumenteren dat de API headers ook auteursrechtelijk beschermd zijn, en door die te gebruiken, je een afgeleid werk hebt.

          Dat is althans de redenering van de FSF. Ikzelf vind dit erg discutabel, en ben eigenlijk wel een beetje blij dat de rechter in America hier niet in mee lijkt te gaan, en dit gebruik al fair-use lijkt te bestempelen. Nu nog een Europese rechter vinden die de auteursrechtelijk bescherming van tafel veegt. Dat hiermee de GPL tot een LGPL gereduceerd wordt: ik lig er niet wakker van.

          (De incompatibiliteit die de GPL geeft is mijn persoonlijke ergernis. Je mag niet eens de Linux kernel code (GPLv2-only) combineren met een GPLv3-of-hoger library. Grrrrr.)

          1. in de VS is gebruik van de API nu in principe Fair Use (moet je wel het geld hebben om een rechtzaak te voeren indien nodig) en in de EU uberhaupt uitgesloten van auteursrecht sind een uitspraak vaan het europees hof (uit 2012 als ik me niet vergis).

    2. De LGPL is er volgens mij gekomen in een tijd dat API’s nog niet echt een ding waren. De tekst maakt onderscheid naar statisch en dynamisch linken (met primair dus C-code voor ogen, logisch gezien het GNU project en haar platform) en wilde verduidelijken hoe je kon linken met gesloten software.

      De term API vind ik lastig te plaatsen binnen de (L)GPL. Maar ik ben geneigd te zeggen dat als je een GPL programma omwerkt tot een hosted service die via een netwerk API aan te roepen is, de aanroepende programma’s geen afgeleide werken daarvan zijn. Dit is al langer een discussiepunt, elke keer als er een nieuwe communicatietechniek is (RPC, Corba, sockets) dan verzinnen mensen dat je daarmee zo’n shim kunt bouwen om om de GPL heen te komen.

      1. APIs waren zeker wel een ding, alleen toentertijd bestond een API vooral uit de inhoud van een C header file. Tegenwoordig wordt de term API veel breder gebruikt, en misschien nog wel vaker voor RPC-achtige constructies over het internet dan voor ouderwetse APIs.

        Je kunt je afvragen of de GPL nog wel het juiste middel is voor wat men probeert te bereiken. Voor zover ik weet is de GPL tot stand gekomen na slechte ervaringen met de TeX-software, die onder een permissive license werd verspreid. Daar werden vervolgens allerlei proprietary klonen van gemaakt, die allemaal onderling incompatible uitbreidingen kregen. De bedoeling van de GPL moet dus zijn geweest om er voor te zorgen dat uitbreidingen van derden altijd weer gemerged kunnen worden in het hoofd-project.

        Zo bezien zou je zeggen dat, voor software die een duidelijke API aanbiedt, een LGPL-achtige constructie veel logischer is; dan maakt het ook niet zo veel meer uit of die API nou alleen via linken of als RPC wordt aangeboden. De enige reden om dan nog GPL te gebruiken is om de “four freedoms” van free software uit te breiden naar de API-aanroepende software. Dat je mogelijkheden daartoe beperkt zijn is misschien niet eens zo heel erg; het maakt de GPL nog niet compleet nutteloos. Het is uiteindelijk beter als we die four freedoms in de wet opnemen, maar dat betekent wel dat het auteursrecht afgeschaft moet worden (“Freedom 2: The freedom to redistribute and make copies so you can help your neighbor.”).

        1. “De bedoeling van de GPL moet dus zijn geweest om er voor te zorgen dat uitbreidingen van derden altijd weer gemerged kunnen worden in het hoofd-project.”

          Dat is zeker in lijn met hun filosofie: “when in doubt, add new features”.

          En dan was er nog de tijd dat het hele idee van auteursrecht op software op de lachtspieren werkte. Immers, het zijn maar algorithmes, die kan iedereen met een half brein toch verzinnen? En we hebben toch ook geen auteursrecht op algorithmes in de wiskunde? Wat is dit nu weer voor onzin, haha?!

          1. Volgens mij was de discussie meer “software, dat is techniek, hoezo moet dat in het creatievelingenrecht komen? gewoon het patentsysteem net als bij hardware”. Dat had dan alleen weer het nadeel dat 90% van alle software niet beschermd is, omdat 90% van de innovaties daarin te triviaal voor patenten was. Volgens mij is er uiteindelijk gekozen voor copyright omdat dat het makkelijkste systeem is: je krijgt het automatisch en er is een hele lage toets voor de benodigde creativiteit.

            Nadeel van auteursrecht is dan weer dat je alleen je concrete code beschermd hebt, en niet het achterliggende idee of algoritme. Daar zijn patenten voor. En het is mijn stellige overtuiging dat deze beperking uiteindelijk leidde tot de opkomst van softwarepatenten. Ik citeer:

            In Apple v. Microsoft (1994) kreeg Apple te horen dat zij geen auteursrecht kon claimen op concepten als titelbalken op vensters, iconen voor bestanden en mappen of een prullenbak voor zaken die verwijderd moesten worden. Kort daarna werd in Lotus v. Borland (1996) bepaald dat de look-en-feel van een spreadsheetprogramma eveneens niet auteursrechtelijk beschermd kon worden. Hiermee waren de mogelijkheden flink beperkt voor bedrijven om middels auteursrecht imitatie van hun software tegen te gaan. Het lijkt erop dat deze bedrijven vervolgens op zoek gingen naar alternatieven en uitkwamen bij het octrooirecht, hetgeen mede zou verklaren waarom het octrooieren van software sterk toenam in die tijd. (20).

            Ook de rechtszaak van Stac Electronics tegen Microsoft speelde een rol. Microsoft verloor stevig omdat de makers van Stacker patent hadden op hun verdubbel-je-harddisk technologie, die Microsoft schond met hun Doublespace. Ik heb diverse bronnen gelezen die zeggen dat MS dergelijke dingen vaker deed: iemands software goed bestuderen en het dan zelf opnieuw bouwen. Dat mag onder het auteursrecht, maar het is patentschending. Als je het aantal Microsoft-patenten voor en na de Stac-zaak turft, dan zie je een gróte sprong na dat vonnis:

            1. Ik beschreef het vanuit het programmeursoogpunt. Vanuit juridisch oogpunt heb jij waarschijnlijk gelijk.

              Overigens meen ik ook een beetje vanuit het bedrijfsoogpunt te kunnen spreken: voor lange tijd was het klonen van hardware een dure en omslachtige zaak. En wat had je aan de software (die toen nog niet zo flexibel was), als de aanpassingen die jij nodig had er niet in zaten? Daar kwam de klant toch voor? Een oplossing op maat?

            2. Slechte grafiek. Je wijst 1994 aan als belangrijk moment, maar de ontwikkelingen van voor 1994 zijn niet uit te lezen, want te laag. Zou je verticaal een logaritmische as willen gebruiken?

                1. De grafiek die je hier laat zien laat de mogelijkheid open dat er in de hele periode van 1986 tot 1998 een exponentiële groei was, en dat 1994 dus helemaal geen bijzonder jaar was. Die exponentiële groei kan gewoon verklaard worden uit de groei van Microsoft als bedrijf: meer werknemers + meer geld voor onderzoek = meer patenten.

                  Met een logaritmische as moet je goed kunnen zien of dat het geval was. Als jij gelijk hebt, dan moet er met een logaritmische as een duidelijke knik naar boven zitten bij 1994. Als ik gelijk heb, dan is de exponentiële groei een doorgaande lijn zonder duidelijke trendbreuk bij 1994.

                  Daarnaast: er is een trendbreuk die wel zichtbaar is in de grafiek: dat de groei rond 1998 (tijdelijk) stopt. 1998 zit vrij dicht bij de door jou genoemde 1994 + 3 jaar. Dat is toch precies het omgekeerde van wat jij zou verwachten?

  1. Inderdaad, als iemand een GPL header file of API zou hebben en jij zou een eigen implementatie daarvan schrijven, dan zou je waarschijnlijk in Amerika onder fair use daarmee vrij lopen zodat de GPL niet op jou van toepassing zou zijn. Maar is dat vervelend? Volgens mij is dat een behoorlijk uitzonderlijke situatie en zeker niet de normale wijze van hergebruiken van iemands GPL werk.

    Als ik even heel onnozel doe, zeg ik nu: doel bereikt, API in gebruik en code vrij beschikbaar. Helaas ben ik niet onnozel (toch?) en dus zie ik ook wel dat als mijn code ineens niet meer onder mijn GPL valt, dat dan voor mij de zekerheden wegvallen: dat wijzigingen worden vrijgegeven, dat gebruikers van de code dezelfde rechten hebben als de auteur, etc.

    Maar ik ben het eens met Arnoud: dit klinkt als een typisch “de wereld stort in want ik kreeg ongelijk”-verhaal.

  2. Hoe erg zou het in de praktijk zijn als de advocaat van Oracle wel gelijk zou hebben? Zal er opeens op grote schaal gebruik/misbruik plaats vinden van al die code die opeens helemaal vrij is? Misschien dat een paar fabrikanten van el-cheapo routers en dergelijke stoppen met het vrijgeven van de sources (als ze die echt hebben aangepast), maar dat lijkt me nu waar alleen fundamentalisten zich druk om zullen maken.

    1. … maar dat lijkt me nu waar alleen fundamentalisten zich druk om zullen maken.

      Daat zit ‘m nou net het probleem: als die “fundamentalisten” er zich niet druk om maken, dan heb je dus nooit de mogelijkheid om de firmware van je routertje te vervangen door OpenWRT of iets dergelijks. Daarom wordt er door de goede GPL enforcers gewerkt. (Daarnaast heb je er ook nog die het helaas voor geldelijk gewin doen)…

  3. want er is nogal een verschil tussen een API hergebruiken met je eigen code en het hergebruiken van code

    Natuurlijk zijn er een aantal grote verschillen, maar principieel is het m.i. gelijkwaardig: je maakt gebruik van (verveelvoudigd) iemands creatieve werk. In beide gevallen kunnen situaties ontstaan dat de auteursrechthebbende zijn rechten kan misbruiken (wat mij betreft geldt dat voor iedere vorm van auteursrecht dat we momenteel kennen). Fair use kan misbruik dan inperken.

    Ik vraag me nog wel af hoever het vonnis nu strekt: er wordt hierboven af en toe gesuggeerd dat iedere open source api of zelfs iedere api nu volledig vrij is om te hergebruiken, maar ik zie nog weinig argumentatie voor die conclusies…

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.