Maakt linken van een GPL bibliotheek je software automatisch GPL?

Intrigerende discussie in de comments vorige week: als je programma linkt tegen een GPL open source library, is je programma dan alleen onder de GPL te verspreiden? Immers, de GPL zegt dat je afgeleide werken alleen onder de GPL mag verspreiden. En wat is er nu meer afgeleid dan een programma dat noodzakelijkerwijs een library gebruikt? Het programma wérkt niet zonder de library. Maar Europees auteursrechtelijk waag ik dat toch te betwijfelen.

De term ‘afgeleid werk’ is een tikje ongelukkig. De term komt uit het Amerikaans auteursrecht; in Europa kennen we alleen de ‘verveelvoudiging in gewijzigde vorm’, oftewel een kopie, al dan niet aangepast, van (een deel van) het werk. Dat klinkt inderdaad wat beperkter, en dat is het volgens mij ook.

In de SAS/WPL-uitspraak heeft het Hof van Justitie de grenzen getrokken van het software-auteursrecht. In die zaak beriep SAS zich op een auteursrecht voor haar programmeertaal en functionaliteit daarin, maar gedaagde WPL kreeg gelijk, zo’n auteursrecht bestaat niet.

Auteursrecht op software bestaat volgens de hoogste Europese rechter alleen op de broncode en de daarvan afgeleide uitvoerbare code. Men noemt dit de ‘uitdrukkingswijzen’ en daaronder wordt alleen datgeen verstaan dat tot “reproductie van het computerprogramma of tot het computerprogramma zelf kunnen leiden”. Je moet dus, kort gezegd, met wat er overgenomen of gebruikt is in het andere werk, het originele programma zelf althans gedeeltelijk kunnen terugvinden.

Bij het gebruik van een software library roep je in je eigen programma een functie aan, waarna de implementatie van de library wordt uitgevoerd om de betreffende functionaliteit te realiseren. In het SAS/WPL arrest ging het om functies uit een programmeertaal, maar ik zie het verschil niet met een API van een specifieke bibliotheek. In feite is de implementatie van een programmeertaal ook een library (of set libraries) die je middels een API aanroept. Wil je in C een tekst op het scherm, dan zeg je printf("Hello, world!");, waarna libc de implementatie daarvan uitvoert, en wil je bij GNU readline een regel invoer verkrijgen dan zeg je readline(my_prompt);, waarna readline de implementatie daarvan uitvoert. Dat is technisch volgens mij dus hetzelfde.

Meer algemeen, als het aanroepen van een functie van een bibliotheek zou meebrengen dat je het auteursrecht op die bibliotheek schendt, dan zou het auteursrecht dus in feite de functionaliteit beschermen die achter de functie zit. En dát is nadrukkelijk niet de bedoeling in het Europese auteursrecht.

Gelet op deze overwegingen moet worden geconstateerd dat, wat de elementen van een computerprogramma betreft (…), noch de functionaliteit van een computerprogramma, noch de programmeertaal en de indeling van gegevensbestanden die in het kader van een computerprogramma worden gebruikt teneinde de functies daarvan te benutten, een uitdrukkingswijze van dit programma vormen in de zin van [het auteursrecht].

Het opnemen van een functie-aanroep in je programma (zoals printf("Hello, world!"); of readline(my_prompt);) kan dus niet leiden tot een auteursrechtinbreuk op libc of GNU readline, omdat die functie-aanroep nog geen uitdrukkingswijze van het programma libc dan wel readline vormt. Pas als je code zou overnemen, ook in gedeelten, zou er inbreuk kunnen ontstaan.

Wat de GPL of de FSF zeggen over afgeleide werken, linken of Complete Corresponding Source doet er hierbij volstrekt niet toe: je komt pas aan terminologie uit een licentie toe als er sprake is van inbreuk. Pas dan zou de aanroeper van de software immers hoeven te zeggen “geen inbreuk, ik heb een licentie”.

Het argument uit Oracle/Google dat het maken van de API zélf creatief is, gaat hierbij niet op. In die zaak werd Google’s API-kloon van Java inbreukmakend geacht omdat Oracle creatieve arbeid had gestoken in het definiëren daarvan. Maar dat was natuurlijk ook het geval bij de SAS programmeertaal waarvoor WPL programma’s maakte. De functionaliteit, dus ook hoe de functies heten, wat ze doen en welke parameters en return values daarbij horen, is geen “uitdrukkingswijze” van het programma.

Een complete reproductie van de API zou mogelijk wél inbreuk kunnen zijn. In de SAS/WPL uitspraak stond ook de eigen handleiding van WPL ter discussie, waarin elke functie was opgenomen (maar volgens mij ook stukken tekst uit de documentatie van SAS). Dit is iets dat de rechter per geval moet onderzoeken: hoe veel is er overgenomen en hoe creatief is hetgeen overgenomen is? Mogelijk dat bij een handleiding het citaatrecht nog een verweer kan zijn, maar bij een volledige overname met als doel een interface-compatibele kloon te schrijven twijfel ik zeer of dat opgaat. Maar wellicht biedt dit dan een lichtpuntje:

In deze context moet worden gepreciseerd dat indien een derde een gedeelte van de bron- of doelcode betreffende een voor een computerprogramma gebruikte programmeertaal of indeling van gegevensbestanden zou aanschaffen en hij met behulp van deze code soortgelijke elementen in zijn eigen computerprogramma zou creëren, deze handeling mogelijkerwijs een gedeeltelijke reproductie in de zin van [het auteursrecht] zou opleveren.

Het lijkt dus echt nodig dat er ook broncodes worden overgenomen. En puur de definities van de functies voldoen niet snel aan die eis.

Wat vinden jullie? Is er een wezenlijk verschil tussen een API van een of andere bibliotheek aanroepen versus de functies uit een programmeertaal? Maakt het uit of er maar één implementatie van die API+bibliotheek is? Of zijn er andere redenen om een API-aanroep toch inbreuk op het auteursrecht te noemen?

Arnoud

40 reacties

  1. Een API is bedoeld om geimplementeerd te worden, en een API is bedoeld om op dat punt een ‘knip’ te maken tussen twee stukken software. Of die API zich dan manifesteert in de vorm van een dynamische library, statische library of een REST API is mijns inziens volstrekt irrelevant. Wil je om de GPL heen? Dan bouw je een REST API tegen de library aan en publiceer je alleen de server code. (Ok, niet echt een optie voor een readline library maar you get the point).

    De enige conclusie die je dan ook kan trekken is dat de GPL inherent volledig ongeschikt is voor libraries. Het is niet voor niets dat Linus een preambule aan de kernel license heeft toegevoegd (https://www.kernel.org/pub/linux/kernel/COPYING)

    NOTE! This copyright does not cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does not fall under the heading of “derived work”.

    WordPress en Drupal daarentegen misbruiken (naar mijn mening) de GPL om plugins en modules onder de GPL te forceren, omdat ze ‘afgeleide werken’ zouden zijn. (https://www.drupal.org/licensing/faq/#q7)

    7: If I write a module or theme, do I have to license it under the GPL? Yes. Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later.(…) The GPL on code applies to code that interacts with that code, (…)
    en https://wordpress.org/about/license/
    There is some legal grey area regarding what is considered a derivative work, but we feel strongly that plugins and themes are derivative work and thus inherit the GPL license

  2. Mogelijk dat bij een handleiding het citaatrecht nog een verweer kan zijn, maar bij een volledige overname met als doel een interface-compatibele kloon te schrijven twijfel ik zeer of dat opgaat.

    Ehh, volledige interface-compatibiliteit is toch iets goeds, dat mag toch niet bestraft worden? Hoe zit dat bijvoorbeeld met Wine, dat volledig compatible probeert te zijn met de windows API? Ik dacht dat de vraag altijd was of je code overneemt, en niet of je de zelfde interface aanbiedt.

    Ik mag hopen dat een interface per definitie geen creatief werk is, zelfs al is het dat in de praktijk soms wel. Dit omdat het gewoonweg maatschappelijk ongewenst is als een interface auteursrechtelijke bescherming zou kunnen krijgen / claimen.

  3. Wat de GPL of de FSF zeggen over afgeleide werken, linken of Complete Corresponding Source doet er hierbij volstrekt niet toe: je komt pas aan terminologie uit een licentie toe als er sprake is van inbreuk. Pas dan zou de aanroeper van de software immers hoeven te zeggen “geen inbreuk, ik heb een licentie”.

    Ik denk dat dit een belangrijk punt is. Dus, stel dat je een programma schrijft dat gebruik maakt van de API van een GPL-library, en je bent op de één of andere manier nergens gebonden aan de voorwaarden van de GPL, dan hoef je je programma ook niet onder de GPL te verspreiden.

    Alleen: het is gebruikelijk om, voor de gebruiksvriendelijkheid, alle gebruikte libraries samen met een programma te verspreiden. Je hebt niet het recht om die GPL-bibliotheek te verspreiden zonder toestemming van de auteursrechthouder, en die toestemming heb je alleen als je de voorwaarden van de GPL accepteert. Wat zou je nu kunnen doen?

    Je software verspreiden zonder de library, en verspreiding van de library aan een derde over laten. Je software-installer zou de library automatisch kunnen downloaden van de website van die derde. De gebruiker is dan de gene die de library linkt aan het programma; als de gebruiker is gebonden aan de voorwaarden van de GPL (is dit zo?) en de GPL dit verbiedt (is dit zo?), dan mag dit niet.

    Je software verspreiden samen met de library. Hier zijn verschillende varianten van. Je zou ze samen op een CD-ROM of op een website kunnen plaatsen met aparte installers, en een handleiding die zegt dat de library voorafgaande aan de software moet worden geïnstalleerd. Je zou ze als geïntegreerd pakket aan de gebruiker kunnen aanbieden, waarbij de library wel als dynamisch gelinkte library (los bestand, bijv een .DLL) wordt geïnstalleerd. Je zou ook statisch kunnen linken met library, zodat de functies van de library onderdeel worden van het executable bestand (bijv. .EXE) van het programma.

    Bij vespreiding van de library ben je gebonden aan de voorwaarden van de GPL. Volgens mij verbieden die niet verspreiding als onderdeel van een software-collectie die ook niet-GPL software bevat, dus de vraag is waar de grens ligt wanneer je het “linken” noemt. De grens moet bepaald worden op basis van de voorwaarden van de GPL, waarbij het ene uiterste (statisch linken) waarschijnlijk niet is toegestaan, en het andere uiterste (verspreiden samen met software die niets met de library te maken heeft) waarschijnlijk wel.

    1. Bij vespreiding van de library ben je gebonden aan de voorwaarden van de GPL.

      Maar alleen voor de library. En die was natuurlijk toch al eerder publiek beschikbaar dus dat maakt geen verschil. Je hoeft dus echter niet je eigen broncode beschikbaar te stellen als je een GPL library gebruikt en aanroept in die broncode.

      1. Ik dacht dat de licentie gewoon een (weliswaar eenzijdig aangeboden) overeenkomst is. Als je iets doet waar je alleen toestemming van kunt hebben middels die overeenkomst, dan word je gewoon geacht die overeenkomst geaccepteerd te hebben; je bent dan gebonden aan de voorwaarden van die overeenkomst. Als ik het goed begrijp, dan kunnen daar allerlei willekeurige voorwaarden in staan; de voorwaarden hoeven niet per sé te slaan op de verspreiding van de library. Als er in de licentie staat dat je per kopie een keer op straat het volkslied moet zingen, dan ben je daar aan gebonden.

        1. Naar Nederlands recht klopt dat. Je sluit een overeenkomst door het aanbod te aanvaarden, en als je een handeling verricht die normaliter inbreuk op auteursrecht oplevert, dan wordt dat geacht een aanvaarding te zijn. Het is onredelijk te verwachten dat je opzettelijk het auteursrecht wilde schenden, dús bedoelde je de licentie te aanvaarden.

          Hier maakt dat niet uit denk ik. Of je nu gezamenlijk verspreidt of alleen je eigen programma, je programma is geen verveelvoudiging in gewijzigde vorm van de GPL software. En als het dat niet is, dan geldt de GPL per definitie (uit de GPL zelf) niet voor je eigen programma.

          In theorie kan het. In een contract kun je opnemen “alle software die u ooit verspreidt moet GPL zijn”, ongeacht of die software ook maar één letter afgeleid is van de GPL software. De FSF ziet echter de GPL niet als overeenkomst maar als eenzijdige toestemming, wat inhoudt dat ze alleen regels mogen stellen die in verband staan met auteursrechtelijk relevante handelingen. Je een liedje laten zingen kan dus niet; verlangen dat je afgeleide werken alleen onder de GPL verspreidt, kan dan wel.

    2. en de GPL dit verbiedt (is dit zo?)

      Ik heb het even opgezocht voor de GPL v3, en dit is niet zo:

      A “covered work” means either the unmodified Program or a work based on the Program. To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. … You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.

      Ook dit:

      You are not required to accept this License in order to receive or run a copy of the Program.

      DUS: de eerste aanpak lijkt te zijn toegestaan.

    3. De gebruiker is dan de gene die de library linkt aan het programma; als de gebruiker is gebonden aan de voorwaarden van de GPL (is dit zo?) en de GPL dit verbiedt (is dit zo?), dan mag dit niet.

      In de GPL v2 staat in paragraaf 0: “Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.” Je hooft dus aan geen enkele vorowaarde van de GPLv2 te voldoen om een pragramma (of bibliotheek) uit te voeren. Er vanuitgaande dat de gebruiker de bibliotheek alleen gaat gebruiken is die dus niet gebonden aan de GPL. De GPL kan door deze constructie dan ook geen beperkingen aan de pure gebruiker opleggen.

      Als je een afgeleide werk maakt van een GPL programma, heb je dus ook alleen met de GPL te maken als je deze verspreidt. Je kan dus zonder enige beperkingen in-house GPL software combineren met niet GPL software, zolang je het eindproduct maar niet distribueerd. De GPL kan door zijn opzet dus niet verbieden dat een gebruiker jouw software download, de GPL library download en deze samen op één computer installeert en gebruikt.

      M.a.w. GPL 2 en 3 verschillen alleen in de bewoording.

    4. De grens moet bepaald worden op basis van de voorwaarden van de GPL

      Dit is wat de FSF er zelf van zegt:

      Where’s the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

      If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

      By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

      In wezen zetten we nu vraagtekens bij het vetgedrukte stukje van hun interpretatie van de GPL.

      1. Ik geloof niet dat we vraagtekens zetten bij wat de FSF zegt over wanneer twee stukken code een programma vormen. Wat we niet geloven is dat zelfs als een stuk code specifiek is ontworpen om dat samen met een tweede stuk code te doen, dat eerste stuk code daarmee een afgeleid werk van het tweede stuk code is, en het is al helemaal geen gewijzigde verveelvoudiging. Een geschreven equivalent van een schroef is auteursrechtelijk geen gewijzigde verveelvoudiging van het geschreven equivalent van een moer.

    5. Ik zeg dat ook het aanbieden als geïntegreerd pakket geen afgeleid werk oplevert. Ook niet met dynamisch linken. Met statisch linken wel, omdat je dan een kopie van de library in je eigen software hebt zitten. Bij dynamisch staat het er naast. En omdat je dan géén verveelvoudiging in gewijzigde vorm in je eigen software hebt zitten, is er geen sprake van inbreuk op het auteursrecht en daarmee per definitie geen “afgeleid werk” in de zin van de GPL.

      GPLv2:

      a “work based on the Program” means either the Program or any derivative work under copyright law
      GPLv3:
      To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

      Beiden definiëren ‘afgeleid werk’ als hetgeen de toepasselijke auteurswet als zodanig aanmerkt. En omdat een dynamische link geen dergelijk afgeleid werk oplevert, hoef ik van de GPL mijn eigen code dan niet onder de GPL te plaatsen bij verspreiden.

      1. Ik zeg dat ook het aanbieden als geïntegreerd pakket geen afgeleid werk oplevert. Ook niet met dynamisch linken. Met statisch linken wel, omdat je dan een kopie van de library in je eigen software hebt zitten.

        Het geïntegreerd pakket als geheel is wel een afgeleid werk: dat bevat wel een kopie van de library. Het aanbieden van een geïntegreerd pakket is dus een handeling waarop de voorwaarden van de GPL van toepassing zijn.

        De vraag is dan dus wat de GPL wel en niet toestaat bij een geïntegreerd werk. Dit lijkt een beetje vaag te zijn, omdat “aggegratie” met niet-GPL code wel is toegestaan, maar “linken” niet, waarbij de definitie van “linken” een beetje vaag is. Ik ben zelf ook wel benieuwd wat je (of de FSF) precies probeert te bereiken met de GPL: de vaagheid kan zijn voortgekomen uit een ideologische inconsistentie.

        Het lijkt mij logisch dat je in ieder geval probeert veilig te stellen dat iedereen de functionaliteit van de library kan blijven aanpassen en die aanpassingen verder kan blijven verspreiden en gebruiken. Dynamisch linken met niet-GPL code lijkt daarbij geen hindernis te vormen, zolang dat maar op een normale manier gebeurt. De niet-GPL code moet bijvoorbeeld niet afwijken van de officiële API, of middels een secure hash o.i.d. afdwingen dat een specifieke versie van de library wordt gebruikt. Statisch linken is wel een grote hindernis, omdat het nogal lastig is een statisch gelinkte executable te ontleden om de GPL-stukjes te identificeren en aan te passen. Zo redenerende is de LGPL een veel logischere keuze voor libraries.

        Aan de andere kant wil je ook geen loopholes maken waarbij iemand makkelijk een niet-GPL versie van een GPL-programma maakt door alle GPL-code in een aparte GPL-library mee te leveren, en een proprietary loader-applicatie met een beetje extra functionaliteit op die library bouwt. Maar dan nog: welk probleem ontstaat er dan precies? Is er wel een echte loophole?

        1. Akkoord, verkeerde terminologie van mijn kant: het programma dat de API van de GPL library aanroept, is geen afgeleid werk omdat de library er niet in zit. De library staat er naast. Is nodig, maar dát is geen auteursrechtelijk argument zo blijkt uit deze zaak.

          Mijn gedachte is en blijft dat de GPL geschreven is voor de ouderwetsche C programmeurs, en in die context is een afgeleid werk duidelijk: broncode aanpassen en/of meelinken in je programma. Ik vermoed dan dat dynamisch linken pas later aan de orde kwam en er toen een beetje snel bij gezet is in de FAQ. Ik proef altijd een moppertoon van “bijdehante figuren die niet aan GPL willen doen”. Maar ik ben (ook hier) erg cynisch, dat realiseer ik me.

          De hoofdgedachte die zowel RMS als Moglen steeds benadrukken is dat de GPL een auteursrechtlicentie is en géén contract. Derhalve moet alles dat de GPL doet, aan het auteursrecht op te hangen zijn. Vandaar dat ze “afgeleid werk” niet definiëren maar verwijzen naar de auteurswet. En daarom vind ik dat je de auteursrechtelijke interpretatie van “verveelvoudiging in gewijzigde vorm” erbij moet pakken om te zien waar je dan uitkomt.

          Het wordt gezien als een loophole omdat doel van de FSF is dat iedereen op vrije software overstapt en de GPL omarmt als enige licentie. De GPL is daarbij een middel dat je verlokt hun software te gebruiken (want die is goed en nuttig) en dat je betaalt met ‘verplicht vrijwillig meedoen’ door je code ook GPL te maken.

          1. doel van de FSF is dat iedereen op vrije software overstapt en de GPL omarmt als enige licentie

            Als dat zo was dan zou de LGPL er niet zijn. Volgens mij is het doel van de FSF ervoor te zorgen dat jouw harde werk niet zonder meer in niet-vrije software terecht komt buiten jouw wil. Je krijgt daarom de keuze om de GPL of de LGPL te gebruiken waarbij de FSF redelijk consistent zelf voor de LGPL kiest als het om bibliotheken gaat.

            1. De FSF ziet de LGPL als een zwaktebod:

              By releasing libraries that are limited to free software only, we can help each other’s free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition.

        2. Dynamisch linken met niet-GPL code lijkt daarbij geen hindernis te vormen, zolang dat maar op een normale manier gebeurt.

          Volgens mij ook niet, maar volgens FSF en Debian zealoten wel: Het bekendste voorbeeld is incompatibiliteit met de OpenSSL library, waarbij programma’s die daar vanaf hangen (zoals Courier, of netatalk) niet gedistribueerd mogen worden.

          Allebei afzonderlijk downloaden, en daarna op je eigen computer compileren mag wel. Ik ben wel benieuwd hoe dat zit met package managers zoals MacPorts of HomeBrew, waarbij je op je eigen laptop de boel compileert. Dat zal wel legaal zijn.

    6. Dit was ik met jou eens, dus heb ik even nagevraagd bij de FSF hoe dit nou precies zit. Daar kreeg ik het volgende antwoord:

      Asking the recipient to do the linking for you isn’t a loophole in the GNU GPL. If you are interested, have a look at this interesting thread between Richard Stallman and the then maintainer of CLISP in which Dr. Stallman recalls a similar question which arose when Steve Jobs wanted to distribute GCC at NeXT (the relevant part starts around line 356): http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL

      1. Interessante discussie. Ik begin het meer en meer oneens met RMS te worden.

        The result would be to negate for practical purposes the GPL’s requirement that improvements be free.
        Op een of andere manier beargumenteert RMS dat CLISP door het gebruik van readline een “improvement” maakt die hij niet vrij wil geven, maar dat slaat volgens mij echt nergens op. Daarnaast komt zijn eindargument voornamelijk neer op “als jij om de GPL heen kan, dan kunnen de slechterikken dat ook, is dat echt wat je wil?”

        De oplossing van Haible om een eigen dummy implementatie van de readline interface mee te leveren en de gebruiker de GNU readline implementatie neer te laten zetten vind ik eigenlijk vrij overtuigend. De FSF niet, maar wat als er echt 2 concurrerende (en werkende) implementaties zijn? In dit geval kon de FSF claimen dat de intentie om readline mee te leveren er was en het hele gebruikersgebeuren slechts een truuk (de gebruiker doet het niet uit eigen wil maar volgt slechts een instructie op waardoor het dus nog steeds de intentie van CLISP blijft om readline mee te leveren). Maar als er een 2e (al dan niet GPL) implementatie is van readline, welke licentie bepaalt dan? In mijn huidige opinie: geen van beide.

  4. Ik vind het een heel moeilijke kwestie. Corné heeft volgens mij de belangrijkste punten te pakken. Ik vraag me nog wel af hoe dit alles zich verhoud tot proprietaire bibliotheken. Die mag je namelijk sowieso niet verspreiden zonder toestemming, dus ook al zou je auteursrechtelijk gezien je aan proprieteire bibliotheken gelinkte software mogen verspreiden, je hebt er niks aan tenzij je ook de bibliotheek verspreid. Je zit dan vast aan Corné-optie 1, waarbij het er waarschijnlijk op neer komt dat je bij de installatie vermeld dat zus of zo software aanwezig moet zijn en je deze dus zelf moet aanschaffen en installeren. De GPL daarentegen wil niet lullig doen en zegt, soit, als jij je software ook GPL maakt dan mag je de bibliotheek ook verspreiden. Het probleem is volgens mij dat dat nou net iets is wat ze niet kunnen zeggen omdat je de bibliotheek ook los mag verspreiden. Je kunt niet zeggen: je mag X doen mits je, als je een stuk fruit eet dit een appel is, of geen fruit eet. Want dan doe je gewoon X en eet je daarna je appel. Daarnaast heb je überhaupt niks te zeggen over of ik fruit een en welk fruit dat dan is. Maar dan zeggen zij natuurlijk: graag of niet.

    Sorry voor deze kromme (en niet op auto’s gebaseerde, foei!) analogie 🙂

  5. Ik ben er niet van overtuigd dat de SAS/WPL-uitspraak op het gebruik van willekeurige libraries kan worden toegepast. Waarom niet? Omdat het in SAS/WPL niet om (het gebruik van) een library van SAS ging, maar om de functionaliteit (dus: de ideeën) die opnieuw geimplementeerd werd door WPL.

    WPL verheelt niet dat het haar bedoeling was om een groot deel van de functionaliteiten van de SAS Componenten zo veel mogelijk te emuleren.
    Als we deze situatie willen vergelijken met een GPL library, zouden we kunnen zeggen: ik bestudeer de werking van een GPL library en schrijf vervolgens een eigen versie met een andere licentie, en ik zorg dat dezelfde inputs tot dezelfde outputs leiden. In dit geval is het duidelijk (en bevestigd door SAS/WPL) dat de auteursrechthebbende van de GPL library daar niets tegenin te brengen heeft.

    Om antwoord te geven op je vraag: bij een API-aanroep wordt uiteindelijk de (binaire) code van de library een onderdeel van het programma van de aanroeper (van het perspectief van het besturingssysteem/interpreter en de eindgebruiker), zelfs al staat de library op een andere fysieke locatie in het systeem. De library-aanroep zorgt er dus voor dat de library onderdeel van het programma wordt. Vanuit dat perspectief kan een library-aanroep worden gezien als een verveelvoudiging van het oorspronkelijke werk (art. 13 Auteurswet).

    Nu begrijp ik best dat er mensen zeggen: ja, maar dat gaat alleen op als de library tegelijk met mijn programma verspreid wordt. Ik zie deze situatie echter niet anders als wanneer iemand Arnouds boek zonder diens toestemming onder de scanner legt en 312 aparte emails met elk een pagina stuurt met het idee dat de ontvanger ze samenvoegt. Men zou zich op het citaatrecht beroepen, want maar een pagina per email en het is de ontvanger die er een samenhangend geheel van maakt. Maar het idee was natuurlijk dat het gehele boek bij de ontvanger belandt. Zo zie ik het ook met de programmamaker die een library aanroept met het idee dat de uitwerking van de functionaliteit van de library uiteindelijk wordt opgenomen in zijn programma.

    1. Het klopt dat WPL een emulator bouwde voor de SAS software. WPL linkte dus niet met de SAS software maar maakte een interface-compatibele eigen implementatie van de taal. Maar ik betoog niet dat WPL hetzelfde doet als de persoon die linkt met een GPL library. Ik gebruik de argumenten die zij geven in de situatie van linken, om aan te geven dat je met linken (ook) geen auteursrecht schendt.

      Het Hof zegt namelijk kort gezegd “pas als je het programma kopieert in je eigen programma, schend je auteursrechten”. En je kopieert niets als je enkel de API/headerfile gebruikt om functionaliteit aan te roepen. Het aanroepen en gebruiken van functionaliteit is ook geen inbreuk want is geen “uitdrukkingswijze van dit programma”.

      1. Ik denk dat het verschil tussen aanroepen en kopieren een gekunsteld iets is. Het resulterende programma is identiek in alle opzichten behalve hoe het programma verspreid wordt (in twee brokken of slechts een). Ik kan me niet indenken dat dat juridisch echt een verschil maakt.

        Ik denk ook dat het woord “functionaliteit” uit SAS/WPL verkeerd wordt uitgelegd alsof daarmee “de uitwerking” wordt bedoeld. Ik denk dat de rechters in SAS/WPL met “functionaliteit” simpelweg bedoelen dat input x tot output x leidt, en niet dat er op een specifieke implementatie wordt geduid. Dit in tegenstelling tot het aanroepen van een library, waarmee je in het algemeen een specifieke uitwerking van functionaliteit uitvoert.

        1. Het resulterende programma ziet er voor de gebruiker misschien hetzelfde uit, maar het is zeker niet identiek. Wat er achter de schermen gebeurd is iets compleet anders.

          Een programma starten is simpel gezegd niets anders als het besturingssysteem opdracht geven een executable bestand in het geheugen te laden en de program counter op de eerste uit te voeren instructie te zetten. Als jij de code gekopieerd hebt of hard hebt gelinkt, dan zal de gebruikte code bij deze handeling in het geheugen worden geladen. Hij is een integraal onderdeel van jouw programma geworden.

          Staat de code in een library, dan zal het programma een lijst in het geheugen laden met bibliotheek functies die hij nodig heeft die aan een bepaalde handtekening voldoen en welke van de op het systeem aanwezige libraries hieraan voldoen. (deze lijst kan je met compiletime aanmaken of runtime. Dat laatste is wat flexibeler. Op het moment dat de functie wordt aangeroepen zal de hele bibliotheek in het geheugen worden geladen. De data wordt geprepareerd en de executie wordt over gegeven aan de bibliotheek functie. Als deze klaar is geeft deze de resultaten door aan het programma en en jouw programma draait verder met de ontvangen data. (Ik ga even voorbij aan parallele uitvoering / multi threading)

          Zoals je ziet is dit behoorlijk inefficient geheugen gebruik als je niet alle functies in een bibliotheek gebruikt. De reden dat je dit toch doet is dat meerdere programma’s de bibliotheek kunnen gebruik waardoor het toch voordeel oplevert. Dit heeft tevens tot gevolg dat op moderne computers een library over zijn eigen heap beschikt. De library draait niet in de geheugenruimte van het programma. Dit zou namelijk een joekel van een beveiligings risico opleveren, omdat ieder programma dat die bibliotheek aanroept dan in dezelfde geheugenruimte moet draaien, of een enorme inefficientie omdat ieder programma een volledige kopie van de bibliotheek in zijn eigen geheugenruimte moet laden.

          De kern van de zaak is echter dat de code nooit een onderdeel van jouw binary wordt.

          De java en .NET runtime vertroebelen dit dan weer een beetje omdat die feitelijk libraries die dezelfde versie van het platform gebruiken in dezelfde geheugenruimte kunnen draaien op de PC. Het platform zelf zorgt hier voor de scheiding. Daarom heet het ook een java virtual machine.

          1. De kern van de zaak is echter dat de code nooit een onderdeel van jouw binary wordt.

            Niet van jouw binary, maar wel van jouw programma.

            Wat er achter de schermen gebeurt is in feite dat het besturingssysteem het programma anders behandelt; de controle over de uitwerking van het programma wordt immers tijdelijk overgenomen door de library. Noch de programmamaker noch de eindgebruiker merken ooit enig verschil.

            1. Wat is volgens jouw het verschil tussen een library in het geheugen laden en de code uitvoeren en een executable op de achtergrond aanroepen om iets voor elkaar te krijgen wat je gebruikt in jouw programma?

              Veel CD rippers roepen (vanwege octrooien) externe executables aan om muziek om te zetten in mp3. Zonder deze executables kan je geen mp3’s maken, is de ripper een afgeleide van de mp3converter?

              Strip de mp3 converter van alle logica om op te starten die je in een executable nodig hebt en neem alleen de code voor de conversie en roep deze aan door uitvoer direct bij de conversie functie te beginnen. Is het nu wel een afgeleid werk? Want dis is feitelijk het verschil tusssen een library functie en een uitvoerbaar programma.

              Maar dit zijn alleen maar voorbeelden om aan tegeven hoe krom jouw standpunt is. Het auteursrecht is na SAS/WPL duidelijk, als in jouw werk geen (deel van het) werk van de ander is opgenomen is het geen inbreuk. En een library is niet opgenomen in het werk wat jij verspreid, dus pleeg je geen inbreuk.

              Zelfs al zou je zeggen tot de conculsie komen dat het een afgeleid werk is, dat is een amerikaans begrip wat geen betekenis heeft in het Europese auteursrecht. Niet ieder afgeleid werk is een verveelvoudiging in gewijzigde vorm. Iedere verveelvoudiging in gewijzigde vorm lijkt mij wel een afgeleid werk.

              De logica is waterdicht: Als jij in jouw programma geen code van een ander opneemt, dan verveelvoudig jij die nooit. Noch in gewijzigde, noch in ongewijzigde vorm. Dus maak je nooit inbreuk. Het uitvoeren/gebruiken van software is expliciet in de wet genoemd als niet zijn een verveelvoudiging die onder het auteursrecht valt en levert dus ook geen inbreuk op.

              Het standpunt van de FSF in hun FAQ (niet de licentie!) over wat een afgeleid werk is houdt in europa geen stand.

              1. Jouw redenering leidt tot de onvermijdelijke conclusie dat als jij een programmeertaal met compiler/interpreter maakt en je deze uitbrengt op een besturingssyteem dit een afgeleide is van het besturingssysteem.

                Of in ieder geval dat je toestemming moet hebben applicaties voor hun platform openbaar te maken. Wat je nog niet hebt uitgelegd is waarom dit problematisch zou zijn.

                1. Omdat degene die de laagste software laag maakt volledige controle heeft. Je kan bij Sony en de PS3 zien wat er gebeurt als die laagste laag ingebakken is in de hardware. Eigendom wordt nietszeggend en je bent overgeleverd aan de grillen van een partij die maar één belang heeft, jouw zoveel mogelijk geld afhandig maken.

                  Dus ja dat is een groot probleem en het is tevens een probleem omdat het auteurs rechten zou geven die nooit bedoeld en nooit voorzien waren.

                  Sony had bij de PS3 nog de DMCA/EUCD nodig om volledige controle voor de komende 70 jaar te houden. Als jouw redenatie stand houdt is dat zelfs niet meer nodig en kan iedereen volstaan met de kern van het besturingssysteem hard in te bakken en noodzakelijk te maken voor gebruik.

                  1. Je lijkt er vanuit te gaan dat als er toestemming nodig is om software uit te geven voor een bepaald platform, dat de platformmaker dan de volledige controle over jouw software krijgt. Waarom dat altijd het geval zou zijn, is mij echter niet helemaal duidelijk. Maar het reflecteert toevallig wel de praktijk voor de meeste gangbare mobiele besturingssystemen, want je bent volledig overgeleverd aan de grillen van Apple, Google en co. als je apps wilt uitgeven.

              2. Veel CD rippers roepen (vanwege octrooien) externe executables aan om muziek om te zetten in mp3. Zonder deze executables kan je geen mp3’s maken, is de ripper een afgeleide van de mp3converter?

                De FSF heeft altijd gezegd dat het aanroepen van externe applicaties en bv. praten via sockets niet telt als “afgeleid werk”, maar dynamisch linken wel. Ik heb daar altijd moeite mee gehad, en ik denk dat ik nu weet waarom: alle drie die voorbeelden zijn het initiëren van functionaliteit.

                Ik zie principieel geen verschil tussen het aanroepen van een programma dat functie X uitvoert en het doen van een system call die X realiseert. Sterker nog in de Unix omgeving is zo’n programma vaak niet meer dan een wrapper rond die functie, met wat toeters en bellen die je via command line opties uitvoert (bijvoorbeeld rm dat in feite unlink() uitvoert met wat extra frutsels op de command line).

                1. Ik zie daar ook geen verschil tussen, aangenomen dat we het hebben over ontwikkelaars die software verspreiden die externe libraries/programma’s/commando’s aanroepen volgens door de ontwikkelaar gedefinieerde parameters.

    2. SAS/WPL is inderdaad niet direct vergelijkbaar. Maar er worden een aantal stellingen gemaakt om tot een uitspraak te komen in deze zaak die wel degelijk van toepassing zijn. En deze leiden tot de conclusie dat een library aanroep geen afgeleid werk oplevert.

      Als ik het goed begrepen heb gaat het met name om het gedeelte van de redenatie: * Op functie kan je geen auteursrecht krijgen; * voor inbreuk moet je een deel van de source code of binaire code opnemen in jouw programma; * Een programmeertaal is niet auteursrechtelijk te beschermen, alleen de implementatie daarvan.

      Jij probeert te beargumenteren dat dynamisch linken tot hetgeen in de tweede bullet leidt. Alleen is dat wel zo? In jouw source code staat geen regel source uit de bibliotheek. Dien ten gevolge staat in de binary die je maakt als je dynamisch linkt ook geen binaire code die een omzetting is van die source.

      Het aanroepen van uitvoerbare code (wat een library function is) is niet gelijk aan het opnemen in jouw programma van die code, maar gebruik van die code. Gebruik van legaal verkregen code leidt niet tot inbreuk.

      Jouw redenering leidt tot de onvermijdelijke conclusie dat als jij een programmeertaal met compiler/interpreter maakt en je deze uitbrengt op een besturingssyteem dit een afgeleide is van het besturingssysteem. Voor een crosspplatform compiler als GCC: compilen voor windows: afgeleide van windows, compilen voor Linux, afgeleide van Linux, etc…

      Ieder programma geschreven met GCC is onvermijdelijk een afgeleide van GCC door gebruik van C functies die door GCC in bibliotheken zijn ondergebracht en is daarmee ook een afgeleide van het besturingssysteem.

      Is dat echt hoe jij het auteursrecht ziet?

    3. Kopiëren van library-functies van harde schijf naar RAM (toevallig gemapt in de “adress space” van een bepaald programma, zodat dat programma die functies kan aaroepen) valt volgens mij onder artikel 13a:

      Onder de verveelvoudiging van een werk van letterkunde, wetenschap of kunst wordt niet verstaan de tijdelijke reproductie die van voorbijgaande of incidentele aard is, en die een integraal en essentieel onderdeel vormt van een technisch procédé dat wordt toegepast met als enig doel a) de doorgifte in een netwerk tussen derden door een tussenpersoon of b) een rechtmatig gebruik van een werk mogelijk te maken, en die geen zelfstandige economische waarde bezit.

  6. Een Android-telefoon als geheel is ook een afgeleid werk van GPL-software: Android draait op de Linux-kernel. Zou je kunnen zeggen dat het hele ontwerp van de telefoon, inclusief de chipsets en dergelijke, is “gelinkt” aan de GPL-code, en daarom onder GPL-voorwaarden moet worden verspreid?

    Volgens mijn eerder beschreven richtlijn (niet per sé het zelfde als wat de FSF er van maakt) zou je moeten kijken of de GPL-onderdelen van de telefoon makkelijk zijn los te koppelen en makkelijk aan te passen / vervangen zijn. Kortom: een Android-telefoon zou makkelijk te rooten moeten zijn; anders moet de rest van de telefoon ook onder de GPL verspreid worden. Dat laatste zal wel onmogelijk zijn vanwege geheimhoudingsplicht voor de GSM-onderdelen van de telefoon.

  7. Het enige leuke aan dit hele debat is dat je mij zó op de kast kan krijgen: noem op een feestje “OpenSSL” en “GPL” in één zin, en mijn bloed begint spontaan te koken. Kleine issue 10 jaar geleden. Nu ik het teruglees wordt ik weer boos.

    Ik ben geen jurist, maar kan me helemaal vinden in de reactie van Elroy in de oorspronkelijke thread.

    In het kort: ik geloof geen hout van de redenatie van de FSF dat de GPL viraal is. Dat ze willen dat het viraal is snap ik: ze zijn bang dat dan iemand een wrapper (“shim”) om een library zetten en deze shim vervolgens als propietory software verder verspreiden. Ze willen zekerheid hebben dat alle ontwikkeling aan de GPL library plaatsvind, en niet aan zo’n wrapper.

    Ik geloof er echter niets van. In het geval van netatalk en OpenSSL dacht ik als leek “dat is beide open source”, dus dat kan leuk samen. Mooi niet. De OpenSSL licentie bevat de voorwaarde

    3. All advertising materials mentioning features or use of this software must display the following acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)”
    En dat is een aanvullende voorwaarde, stricter dan wat GPL voorschrijft. Dat mag niet.

    Het feit dat OpenSSL gewoon open source is doet daar niets aan af: schrijf maar je eigen library. En dat is precies wat GnuTLS en NSS gedaan hebben.

    Ik ben van mening dat als het mogelijk is om een library losstaand te distribueren, en er meerdere libraries zijn met dezelfde API, zonder dat die API auteursrechten bevat, dat het dan ook mogelijk moet zijn om een programma te verspreiden, een GPL-gelicenseerde library de verspreiden, en dan samen te gebruiken, dat er dan geen sprake is van auteursrechteninbreuk. Nog door de schrijver van het programma, nog door het distributiekanaal, nog door de gebruiker.

    Maar goed, destijds was de mededeling: statisch linken mag niet, dynamisch linken mag niet, en de FSF heeft zelfs geclaimd dat het distribueren van code van een applicatie die “hun” API aanroept ook inbreukmakend is, zelfs als er een andere library is met dezelfde API.

    Maar gelukkig is de wereld weer in evenwicht: tegenwoordig haat ik niet alleen de GPL vanwege hun opvattingen over virale werking van licenties, maar ook OpenSSL. In het geval van OpenSSL vanwege de slechte interface die problemen geeft (kuch Python 2.7.9 release, kuch) en aanleiding is geweest to libraries als NaCL.

    Maar goed, ik zie daar mijn collega’s al aankomen met een dwangbuis. GPL en OpenSSL, whaaah!

    1. Oeps, dat wist ik niet. Dus dit zou een probleem kunnen zijn: https://github.com/cornwarecjp/amiko-pay/blob/master/python-prototype/crypto.py

      Ik heb zelf volgens mij nog geen probleem, omdat ik OpenSSL niet meelever met mijn software, en ik dus niet gebonden ben aan de license van OpenSSL. Alleen: als ik mijn software in Debian wil krijgen, dan is er mogelijk een probleem. In de praktijk denk ik daarbij dat alleen de puristische houding van Debian een probleem zal zijn.

      1. Je programma is legaal. Alleen volgens de door jou gekozen voorwaarden (GPL) mag het niet in gedistribueerde vorm gecompileerd worden samen met OpenSSL. Wel onhandig, omdat je programma daar van af hangt.

        Om het erger te maken: jij hebt gekozen voor een “GPLv3” licentie. Dat is problematisch. Handiger zou zijn om de software aan te bieden met een “GPLv3 of hoger” licentie. Voor het geval het niet duidelijk is: het is natuurlijk volgens de FSF volstrekt niet toegestaan om software met een GPLv2 licentie te combineren met software met een GPLv3 licentie. Stel je voor. GPLv3 heeft immers aanvullende voorwaarden vergeleken met GPLv2, en dat mag natuurlijk niet!

        Ik kan wel vragen waarom je deze onhandige combinatie hebt gekozen, maar je begrijpt waarom mijn bloed destijds ging koken: Ik: “maar de upstream heeft dit nooit zo bedoeld, ze willen wel de licentie wijzigen, maar kunnen niet meer alle contributors benaderen” Debian: “mooi pech, wij gaan het niet distribueren” Ik: “maar wat moeten ze dan?” Debian: “Dan schrijf je toch een andere open source library?” Ik: “Alleen vanwege dat ene attribution/advertisement zinnetje in de licentie?”

        Mijn advies aan jou: contacteer alle auteurs, en stel voor om een minder restrictieve licentie te gebruiken. Als minimum zou ik een OpenSSL exempt (aanvullende voorwaarde) in de licentie opnemen. Daarnaast kan je er voor kijken of het mogelijk is de boel ook met GnuTLS te compileren. Destijds lukte me dat niet met netatalk, maar wie weet is het afgelopen 10 jaar verbeterd :).

        Voor mij is het een reden om GPL-software zoveel mogelijk links te laten liggen en voor mijn eigen projecten gewoon een fatsoenlijke BSD licentie te kiezen.

        Het grote voordeel hier is dat jij zo te zien auteursrecht op je software hebt, en dat je nog leeft. Dus je kan de software ook aanbieden onder aan andere licentie. Anders hadden we 70 jaar moeten wachten tot je code licentie-vrij werd. Of moeten hopen dat de FSF komende 40 jaar geen GPLv4 maakt, met incompatbiliteitsproblemen met jouw software van dien.

        PS: Iemand die na mijn bovenstaande tirade nog steeds durft te beweren dat er niets mis is met auteursrecht, is niet goed wijs. De FSF heeft een draak van een ‘copyleft’ licentie moeten maken om een beetje tegengas te geven aan de ‘copyright’. Maar blijkbaar is dat nog met zoveel ellende omgeven dat zelfs de trouwe volgers van dit blog (zoals ik en Corné) de details blijkbaar dit nog niet overzien.

        Maar goed, ik zie daar mijn collega’s dit keer met een pot kalmerende pillen aankomen, dus het komt vast goed.

        1. Mijn idee achter GPLv3-only licensing is om te beginnen met een restrictieve licentie; zolang ik de enige auteursrechthouder ben kan ik altijd nog op een liberalere licentie overstappen. De omgekeerde richting is moeilijker, omdat derden altijd rechten kunnen ontlenen uit je eerdere liberalere voorwaarden.

          Ook een optie: zolang ik de enige auteursrechthouder ben kan ik eventueel aan dual licensing doen, voor betalende partijen die de GPLv3 niet zien zitten.

          De bijdragen van anderen betreffen allemaal 1 component waarvan ik een kopie in mijn software heb opgenomen. Interessant genoeg staat er bij die component helemaal geen licentie-informatie, maar uit het feit dat het een veel gekloond Github-repository is kan je min of meer afleiden dat het open source moet zijn. Ik herinnerde me vaag dat ik dacht dat het om X11/MIT-style licensing ging, maar dat kan ik dus niet terugvinden.

          Maar goed, ik heb wat huiswerk te doen: ik overweeg nu een uitzondering voor OpenSSL toe te voegen, en ik zal eens achter de licentie-voorwaarden van die externe component aan gaan.

        2. Om het erger te maken: jij hebt gekozen voor een “GPLv3? licentie. Handiger zou zijn om de software aan te bieden met een “GPLv3 of hoger” licentie.

          Misschien een gekke vraag van mijn kant op dit punt in de discussie, maar: waar heb je dat gelezen? Ik zie overal “GPL v3 of hoger” staan.

          1. @Corné: Je hebt gelijk. In de code staat het goed. Ik had alleen de README gezien, en daar staat “Please read the file “COPYING” for licensing information.”, en omdat in COPYING alleen GPLv3 stond ging ik daar van uit.

            PS: ik hoop dat duidelijk was dat mijn -vrij negatieve- reacties niet persoonlijk aan jou gericht waren, maar aan het adres van FSF. Ik ben nogal cynisch geworden over hoe zij de lock-in van de GPL als alleen maar positief aanprijzen: “But we should not listen to these temptations [to use more liberal licenses — Freek], because we can achieve much more if we stand together. We free software developers should support one another.”, (op de LGPL pagina). Ze gaan er volledig aan voorbij dat ze zelf niet bepaald alle andere free software developers steunen. Zoals auteurs van OpenSSL of andere software die vast zitten aan 4-clause BSD-achtige licenties. Ik snap en waardeer hun idealen, maar ik vind ze niet erg eerlijk over de keerzijde daarvan.

            1. @Corné: Je hebt gelijk. In de code staat het goed. Ik had alleen de README gezien, en daar staat “Please read the file “COPYING” for licensing information.”, en omdat in COPYING alleen GPLv3 stond ging ik daar van uit.

              Dat dacht ik al. Dat is nu opgelost, en ik denk dat ik de rest nu ook heb opgelost: * mijn eigen code is nu GPL v3 of later, met OpenSSL linking uitzondering * de component die door anderen is gemaakt is LGPL v2.1 of later. Ik weet niet zeker of LGPL-code zonder linking-uitzondering geher-publiceerd mag worden als GPL-code met linking-uitzondering. Ik ben uit gegaan van de (in mijn ogen) meest veilige en conservatieve optie: ik heb expliciet gemaakt dat die andere component onder LGPL-voorwaarden beschikbaar is. Onder die voorwaarde (en een paar andere, waar ik aan voldoe) mag ik volgens de LGPL toch linken met code die een andere licentie heeft.

              PS: ik hoop dat duidelijk was dat mijn -vrij negatieve- reacties niet persoonlijk aan jou gericht waren, maar aan het adres van FSF.

              Ik voel me niet persoonlijk aangevallen. Ik zie dit als een constructieve discussie: hoewel ik er nog niet van overtuigd ben dat ik de GPL niet moet gebruiken, begrijp ik nu wel beter waarom sommigen binnen de Free Software community er een probleem mee hebben.

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.