Kun je als koper van een Tomtec tablet ze dwingen de Linuxbroncode vrij te geven?

Een lezer wees me op een draadje bij Gathering of Tweakers over de broncodes van de Linuxkernel in een Tomtec tablet:

als aanvulling ik ben afgelopen vrijdag in een mailwisseling met TOM-TEC er achter gekomen dat zij niet eens (willen) snappen wat gpl betekend als kernel licentie en dat zij eigenlijk hun source moeten openbaren. Hun antwoord :dat geld niet voor onze producten en nu doen we geen verdere mededelingen…. dus misschien moet iedereen in het bezit van een tomtec of xiron tablet eens gaan mailen met de vraag of ze de source van kernel mogen hebben.

De TomTec tablet draait Android, oftewel Linux. Linux valt onder de GPL, en in die opensourcelicentie staat de eis dat ontvangers van de software de broncode erbij moeten krijgen. Wie de broncode niet meteen kan of wil leveren, mag ook een schriftelijk aanbod tot nazending bijsluiten, maar je moet de broncode kunnen krijgen.

Tomtec lijkt dit niet te doen, en of het nu uit onwetendheid, koppigheid of een taalprobleem is: het is een schending van de licentie. De Linux-kernelcopyrighthouders kunnen dus Tomtec aanspreken op schending van de GPL, en op grond van hun auteursrecht al deze apparaten van de markt laten halen. Want volgens artikel 28 Auteurswet mag de rechthebbende roerende zaken (zoals tablets) die het auteursrecht schenden (Linux aan boord hebben zonder de GPL na te leven) als zijn eigendom opeisen dan wel onttrekking aan het verkeer, vernietiging of onbruikbaarmaking daarvan vorderen. Dat is nogal een paardenmiddel, en ik zie de Linuxkerneljongens ook niet snel zo’n actie starten.

Interessanter is de vraag: kun je als ontvanger iets juridisch doen om de broncode te krijgen?

De GPL is een licentie, en daarmee een contract (ja echt) tussen de auteursrechthebbenden en de verspreider, de Linuxkerneljongens en Tomtec dus in dit geval. (Of de Bart Smit? Die is immers de directe leverancier van de koper van het apparaat.) De ontvanger van de code is geen partij bij dit contract. Wanneer hij de code heeft ontvangen, geldt voor hem dit 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.

De ontvanger sluit dus op dat moment een eigen contract met de rechthebbende, en kan op die grond de software gebruiken, aanpassen en/of verspreiden. Maar dat contract staat los van het contract dat zijn toeleverancier heeft met de auteursrechthebbende.

We hebben in Nederland een regel over “derde-begunstigden”: mensen die geen partij zijn bij een contract maar er wel profijt van trekken. Artikel 6:253 BW zegt daarover:

Een overeenkomst schept voor een derde het recht een prestatie van een der partijen te vorderen of op andere wijze jegens een van hen een beroep op de overeenkomst te doen, indien de overeenkomst een beding van die strekking inhoudt en de derde dit beding aanvaardt.

Professor Hijma noemt het voorbeeld van de koper die TNT Post kan aanspreken op levering, hoewel TNT Post formeel alleen een contract met de verkoper heeft. De koper is een derde, maar omdat de contractuele afspraak tot levering hem raakt, kan hij er een beroep op doen. Wel moet de koper dan formeel eerst tegen de post zeggen dat hij zich wil beroepen op dit beding.

De ontvanger van de Tomtec tablet is de derde in de zin van dit wetsartikel. En er stáát in de GPL een verplichting voor een der partijen om een prestatie te leveren naar de derde toe, namelijk het (na)leveren van de broncode. Dus als de ontvanger nu tegen zijn leverancier zegt “ik accepteer bij deze de GPL zoals van toepassing op de Linuxkernel in uw apparaat en ik sommeer bij deze meteen uw nakoming van artikel 3 GPL” dan wordt de ontvanger daarmee partij bij de overeenkomst (de GPL)

De ontvanger kan vervolgens naar de rechter om die nakoming af te dwingen, graag op straffe van een dwangsom zodat het ook echt gebeurt. Maar de ontvanger kan géén auteursrechtelijke bevoegdheden uitoefenen, hij heeft uitsluitend en alleen contractuele rechten richting de leverancier.

Arnoud

61 reacties

  1. Maar als TOM-TEC van mening is dat er geen contract is tussen hun en de Linuxkerneljongens, kun je dus ook geen beroep doen op het derde-begunstigden artikel?

    edit: Ik bedoel dus dat de GPL niet van toepasing is omdat TOM-TEC die niet heeft aanvaard. Dan blijft een auteursrechtenschending over. En heb je dan als koper ook een probleem?

  2. Ah zo. Ja, inderdaad, als Tom-Tec zegt “hoe bedoelt u GPL, wij hebben niets aanvaard wij vinden auteursrecht ongrondwettig” of iets dergelijks dan kun je als verkrijger niets. Er is geen overeenkomst dus een derde kan daar geen begunstigde van zijn. Je kunt dan alleen de rechthebbenden contacteren die dan een auteursrechtinbreukzaak moeten beginnen.

  3. ???hoe bedoelt u GPL, wij hebben niets aanvaard” … hoe werkt dat? Want als dat kan, kan ik dat dan ook doen? Bijvoorbeekd met Microsoft-licenties? Dus: wel de software gebruiken, en verspreiden, maar niet de licentie aanvaarden?

  4. Ik heb trouwens ooit ergens een handleiding geleden hoe om te gaan met GPL Violations. Ik kan hem helaas niet meer vinden (geschreven door die langharige OSS-man?), maar de opvallende dingen vond ik:

    • het was een handleiding voor alle partijen, dus ook voor leveranciers die al dan niet de GPL schonden, met heldere instructies hoe te handelen
    • instructie aan melders / gebruikers: ga er niet gelijk vol in; grote kans dat het een misverstand is en dat als je de tijd neemt dat de leverancier zich dan wel netjes gaat gedragen.
  5. @hAl, 3: Iemand die alleen maar kopieën verkoopt, hoeft zelf geen auteursrechtlicentie te hebben, hij maakt zelf geen kopieën. Aan de andere kant is de verkoper wel verantwoordelijk voor een conform product en je zou hem kunnen aanspreken op de auteursrechtelijke verplichting van zijn leverancier.

    @Eva, 4: Het verspreiden van software is voorbehouden aan “de auteur”. Volgens de letter van de Nederlandse auteurswet heb jij het recht om “een legaal verkregen kopie” van de software te gebruiken (op je eigen computer) en mag je extra voorwaarden die Microsoft je bij installatie wil opleggen terzijde leggen. Zeker als de verkoper weigert je je geld terug te geven.

  6. Die GPL-violations gids en de FAQ bevatten nuttige informatie hoe praktisch om te gaan met GPL problemen. Maar ze kunnen natuurlijk niets aan de wettelijke situatie veranderen. Je hebt een contract of niet, en als er een GPL-contract is gesloten dan kan de ontvanger zich als derde daarop beroepen.

  7. @8 Bedoel je dat je de source code niet hoeft te leveren als je GPL software op een device distribueert maar alleen als je de code zowel kopieert en distribueert?

    De GPL is daarin niet geheel helder:

    3. You may copy and distribute the Program …

  8. Ben wel benieuwd. Indien TomTec de broncode vrijgeeft, kunnen ze dan daarna, net als bij de Transformer Prime beweren dat je fabrieksgarantie vervalt zodra je je eigen aanpassingen in de broncode aanbrengt en op dit apparaat plaatst? 🙂

    Is de Android-versie van TomTec eigenlijk wel een aangepaste versie van Android of gebruiken ze gewoon de generieke code van Android? (Met misschien een aantal eigen programma’s die mogelijk niet onder GPL vallen.) Zou je, indien ze de generieke Android-code gebruiken, dan niet kunnen aannemen dat de verwijzing naar Android al een verwijzing naar de broncode is?

  9. @11: Dat is correct. De reden daarvoor is dat juridisch gezien de GPL afhankelijk is van het auteursrecht. De GPL geeft je bepaalde rechten die je vanwege het auteursrecht normaal gesproken niet zou hebben, en stelt daar voorwaarden aan. Die twee kunnen niet los van elkaar worden gezien – je krijgt de extra rechten alleen als je je aan de voorwaarden houdt, maar omgekeerd gelden de voorwaarden ook alleen bij de uitoefening van de extra rechten.

    Het doorgeven van een op legale wijze verkregen auteursrechtelijk beschermd werk in ongewijzigde vorm is geen overtreding van de auteurswet (al geldt bij computerprogramma’s geloof ik nog de beperking dat men in een dergelijk geval ook alle thuiskopieën moet mede-overdragen of vernietigen), en kan in de praktijk daarom ook niet ingeperkt worden door de GPL (zelfs als de GPL dergelijke acties zou verbieden, dan kan de ontvanger simpelweg de GPL weigeren te aanvaarden, in dat geval heeft hij nog steeds dezelfde rechten als een rechtmatig bezitter van normale copyright reserved-software).

    Overigens, ik heb de licentie voor de zekerheid even nagekeken, en een truc als ‘stuur al je software door een zogenaamd onafhankelijke distributeur om zo GPL software te gebruiken en toch je eigen broncode niet te leveren’ werkt niet. De GPL verplicht je een licentie te geven aan “anyone who comes into possession of a copy” – dus ook aan derde partijen die op deze wijze via-via een kopie krijgen.

  10. Als er geweigerd wordt om de broncode te leveren, heb je dan een reden om de koop ongedaan te maken en je geld terug te krijgen? Het zou me namelijk een logische reactie van de winkel lijken, als ze zeggen dat je dat maar met de leverancier moet uitvechten.

  11. Ja, dat is zeker een optie. En de winkel mag niet naar de leverancier verwijzen want jij beroept je op een clausule die jou een recht geeft ten aanzien van de verspreider, de winkel dus. Die levert jou de binary en die moet zich houden aan de broncodenaleveringsverplichting.

  12. Mijn interpretatie van de wet is dat je geen legale kopie van de tablet-software krijgt als de maker van het tablet zich niet aan de software licentie houdt. Daarmee levert de winkelier een illegaal, dus non-conform, product en heb jij als koper het recht de koop te ontbinden.

  13. @12: Het gaat om de kernel die is gpl. Android zelf is apache licensed. Wil je modden dan kan dat maar beperkt zonder kernel sources. daarnaast worden er binary only drivers gebruikt. Of dat mag onder de gpl v2 verschillen de meningen over. maar de code om die driver in te laden wordt in de kernel gecompileerd en moet dus zeker vrijgegeven worden. ditis ook niet gebeurd, waardoor we ook niet onze eigen kernel uit de source op kernel.org kunnen bouwen. Overigens is Tomtec niet de enige ook een samsung ‘vergeet’ bij de publicatie van de sources wel eens wat essentiele delen.

  14. @elroy, de kernel compileert volgens mij niets, toch? Ik ben maar een domme programmeur maar compileren van drivers doe je met een C++ compiler, of vergelijkbare software, die binaries uitspuugt die je dan kunt laden in de kernel. Maar ook al is de GNU C++ compiler zelf GLP’ed, de binaries die je ermee maakt zijn dat zeker niet. Er is veel discussie gaande over of alles wat je voor Linux produceert aan binaries ook meteen GPL is. Veel ontwikkelaars zien GPL dan ook als “zeer besmettelijk” en erg vervelend indien je je broncode niet weg wilt geven. Persoonlijk vind ik de GPL wel aardig, maar tevens zeer besmettelijk. Ik ben een programmeur en wil zelf bepalen onder welke licentie ik mijn code weggeef of verkoop. De GPL ontneemt mij deze keuze, wat voor mij een reden is om geen GPL te ondersteunen. Hierdoor wordt hetgeen ik ontwikkel ook beter toepasbaar voor anderen. Ik zal dus nooit mijn eigen code onder een GPL licentie verspreiden, wat betekent dat ik ook geen GPL code zal gebruiken.

    Maar we hebben het over GPL maar Android valt onder een andere licentievorm. Ja, de kernel is Linux en valt onder GPLv2 maar iedereen kan die gewoon downloaden. TomTec hoeft die dus niet vrij te geven.

    En doordat Android gebruik maakt van ASL2.0 gelden er andere regels, waardoor TomTec mogelijk alsnog hun broncode verborgen kan houden. Immers, zij bouwen voort op de licentie die zij van Android hebben overgenomen.

    Wat overblijft is de discussie of Android wel een andere licentie kan hebben dan de Linux kernel. Zo ja, dan doet TomTec waarschijnlijk niets verkeerd. Zo nee, dan is ook de Android licentie ongeldig en zijn alle Android-apparaten illegaal.

    Dus, wat nou GPL? Als TomTec bovenop Android bouwt dan ASL2.0…

  15. @wim: We hebben het niet over hetzelfde. Ik heb het over het compileren van de kernel, de kernel is uiteraard geen compiler. De kernel die je kan downloaden is niet dezelfde als degene die op de Tomtec draait. Tomtec of iemand hogrrop in de chain heeft de kernel aangepast aan de hardware. Die aanpassingen zijn het die vrijgegeven moeten worden onder de gpl. Daarnaast zijn er mogelijk enkele binary only drivers gebruikt. die kunnen niet zomaar aan de kernel gelinkt worden, dan zou namelijk de broncode vrij moeten worden gegeven. 1 van de aanpassingen aan de kernel is dan de wrapper code die deze driver als zelfstandig ‘programma’ laadt. Die wrapper valt onder de gpl en is nodig voor een werkende eigen kernel. Wanneer je dat alles hebt, dan kan je alle hardware aanspreken en je eigen custom android op basis van android open source project maken. Of onder tomtecs android een custom kernel hangen die de overklokt of meer bluetooth dongles ondersteunt etc…

    Overigens staat het jou vrin om je software onder de gpl vrij te geven en aan andere partijen onder een andere licentie. Ik zou het niemand aanraden, je mag wijzigingen van derden zonder toestemming niet relicensen en Kan die dus niet meer gebruiken. gebruim je echter een BSD achtige licentie dan heb je geen garantie dat je die wijzigingen ooit in source code te zien krijgt en maak je het proprietair dan moet je het zelf doen. Maak de keuze die het beste bij je project past zou ik zeggen. De wijzigingen die tomtec aan android heeft aangebracht vallen onder de apache license en hoeven ze inderdaad niet vrij te geven.

  16. De kernel die je kan downloaden is niet dezelfde als degene die op de Tomtec draait. Tomtec of iemand hogrrop in de chain heeft de kernel aangepast aan de hardware.
    Iemand hogerop heeft dat al gedaan. Want Google heeft Android ontwikkeld bovenop de Linux kernel. En daar zal ondersteuning in zitten voor de meest gangbare hardware waarop Android kan draaien. Dus als TomTec gewoon een verzameling generieke hardware in heeft gekocht en bij elkaar heeft gegooid in dit apparaat en daarbovenop Android installeert dan hebben ze mogelijk niets zelf hoeven te schrijven. En voor wat ze wel hebben ontwikkeld zal het lastig zijn of dit kernel-zaken zijn waarop GPL zit, of Android zaken waar ASL op zit, of gewoon propriety code die ze geheim kunnen houden.

  17. Om het complexer te maken, er is een behoorlijke discussie gaande over welke GPL licentie er nou op Linux zit. Torvald, in zijn wijsheid, heeft besloten dat alleen GPLv2 geldig is. En geen hogere versies, dus. Maar die licentie kan hij alleen geven op zijn eigen werk binnen de kernel. Er zijn honderden andere ontwikkelaars die ook delen van de kernel hebben ontwikkeld die mogelijk een andere GPL versie toelaten. Ook is er veel discussie gaande over waar de grens nou precies ligt, waarbij Torvald aangeeft dat hij vindt dat een “loadable kernel module” een afgeleid werk is van de kernel en dus onder GPLv2 valt. Maar hij kent daar een uitzondering op, namelijk een LKM die alleen gebruik maakt van publieke interfaces van de andere kernel modules, waardoor er dus toch binary-only modules binnenin de kernel van Linux kunnen zitten. Modules waar je de code dus niet krijgt. Maar standaard wordt iedere LKM gezien als een afgeleid werk, dus GPL. Verder is er enorme discussie gaande over code die niet specifiek voor de Linux kernel is ontwikkeld. Denk hierbij vooral aan drivers voor grafische kaarten waarbij de basis van die kaart gewoon generiek is voor alle besturings-systemen. Hierin zit gewoon code die via diverse hardware-poorten communiceert met de videokaart net een interface naar buiten die door het besturings-systeem kan worden aangeroepen. Die worden namelijk niet specifiek voor Linux gebouwd en bevatten ook geen specifiek gedrag voor Linux. Of de GPL dus voor dit soort drivers geldt zal uiteindelijk een rechtbank moeten beslissen maar die uitslag is niet te bepalen. En dan zijn er de firmware-specifieke “blobs” die Linux kent. Krijg je ook geen code van, want die zijn net als bij de videokaart gewoon bedoeld om de hardware aan te sturen. Die hebben geen Linux nodig, maar juist andersom. Linux heeft die blobs nodig om de hardware aan te kunnen spreken. Dus ook hier hetzelfde probleem.

    Ik vind Linux een mooi besturings-systeem en heb zelfs een laptop met een Linux-kernel erop. (En daarbovenop Chrome OS.) Maar door al dat licentie-gelazer is het gewoon niet duidelijk waar je als ontwikkelaar nu eenmaal aan toe bent. Teveel ontwikkelaars die code hebben bijgedragen en daardoor inspraak hebben over de licentie waaronder hun eigen stukje code kan worden vrijgegeven.

    Android geeft hier mogelijk een goede oplossing voor. Android wikkelt al die licenties onder de eigen code en biedt Android-ontwikkelaars een enkele licentie aan met andere restricties, te weten ASL. Het gevolg is dus dat je dus altijd moet afvragen of iets een afgeleid werk is van Android, of van de Linux kernel.

    Betreffende mijn eigen code. Ik gebruik geen GPL in mijn werk simpelweg wegens het besmettelijke karakter ervan en het feit dat er dan opeens een honderdtal ontwikkelaars eisen kunnen stellen aan de licentie op mijn werk, simpelweg omdat mijn werk is afgeleid van het werk van een honderdtal andere programmeurs. Dit maakt mijn werk wel iets lastiger omdat ik dan zelf eigen framworks moet opzetten. Maar ik kan zelf beslissen of mijn werk public domain wordt, of dat ik het vrijgeef onder een of andere licentie, of dat ik het propritary hou. Mijn werk, mijn keuze. Ik respecteer wat anderen doen maar kan het niet accepteren als anderen mij beperkingen opleggen op mijn werk.

    En als ik met Unix wil werken is FreeBSD een prima alternatief. Goed genoeg voor Apple om Darwin van te bouwen, dus ook goed genoeg voor mij. 🙂

  18. Arnoud: stel je hebt een internetabonnement lopen bij een ISP die je voorziet van een modem (een huur als onderdeel van het abonnement). Op die modem draait Linux; de ISP heeft de firmware van de fabrikant voorzien van de instellingen naar keuze.

    Heeft jouw ISP de plicht om je te voorzien van (de onderdelen van) de broncode van de firmware waarop de GPL van toepassing is?

  19. @Bastiaan: Dat denk ik wel, want ook bruikleen of huur is een vorm van openbaarmaking in de zin van de Auteurswet (art. 12 lid 1 sub 3). Maar het is discutabel, omdat je in feite niet bij de firmware kunt en voor openbaarmaking toch echt vereist is dat iemand het werk waarneemt.

  20. @Arnoud: dat is een lastige, want meestal zie je alleen de output die de software genereert. Met kantoorsoftware is het nog relatief gemakkelijk, want dan zou je aan de hand van screenshots nog kunnen aantonen dat je het werk hebt waargenomen.

    In het geval van Linux op een router zou je kunnen detecteren dat het om Linux (de kernel dus) gaat door waarnemingen van de netwerk-stack te verrichten. Zou dat voldoende zijn?

  21. Het soort firmware bepalen is meestal niet zo moeilijk als het lijkt, indien je een apparaat via een web interface kunt benaderen. Mijn Thomson router bevat verwijzingen naar ASP pagina’s dus dan is een Windows-based besturings-systeem aannemelijk. Idem voor mijn LinkSys router. Mijn Laserjet daarentegen gebruikt alleen HTML bestanden maar hier is een simpel truukje die alsnog verraadt dat deze onder Linux draait. Ik verander namelijk een letter in de URL in een hoofdletter en dat resulteert in een 404 melding. Dus http://laserjet/index.html vindt hij wel, maar http://laserjet/INDEX.html niet. Linux is case-sensitive, Windows niet. En mijn NAS schijf is wat lastiger. Een verkeerde URL stuurt mij terug naar het login scherm. Maar hier is dan weer een andere optie: de header-informatie bekijken van de webpagina. En mijn Buffalo NAS bevat de regel “Server=lighttpd/1.4.23” en dat is software die onder Linux of FreeBSD kan draaien. (Mogelijk ook Windows, maar Windows is niet hoofdletter-gevoelig.)

    Dus apparaten die via de webbrowser communiceren kun je dus op eenvoudige wijze al aardig inschatten. Alleen, draait het Linux of FreeBSD? Dat is belangrijk want hier gelden andere licenties voor.

    Helaas kan ik niet bij Buffalo aankloppen voor de broncode van hun Lighttpd versie. Want lighttpd wordt weggegeven onder een aangepaste BSD licentie.

    Maar goed, wat neem je dan uiteindelijk waar? Buffalo gebruikt lighttpd onder Linux of FreeBSD, HP gebruikt Virata-EmWeb onder Linux of FreeBSD, Thomson gebruikt iets (IIS?) onder Windows en LinkSys gebruikt “GoAhead Web Server” onder Windows. Dit zijn allen producten die bovenop het besturings-systeem draaien en we weten niet eens of het besturings-systeem er alleen maar is voor de communicatie tussen apparaat en computer of dat deze ook daadwerkelijk de aansturing regelt. Je zult dus meer informatie moeten hebben waar je eigenlijk niet bij kunt komen. Als het besturings-systeem er alleen maar zit als doorgeefluik voor de data volgens het protocol van het apparaat dan heb je daar verder weinig aan. Je komt namelijk niets te weten over het protocol zelf.

  22. @Wim, tools zoals nmap kunnen een goede indicatie van het besturingssysteem geven door te kijken naar hoe incorrecte of ongebruikelijke netwerkpakketten behandeld worden. Wanneer je een “firmware update” bestand hebt is vaak een kwestie van uitpakken en de software inspecteren…

  23. Klopt, maar zodra je het over NMap hebt, ben je met tools bezig die toch iets meer kennis vragen. De vraag is of een gemiddelde leek het zo zou kunnen bepalen en hoewel er aanwijzingen zijn, is het volgens mij lastig om het verschil te herkennen tussen Linux en FreeBSD. Dat verschil is wel zeer belangrijk want beiden hebben verschillende licenties.

  24. Hoi Wim,

    Dit is toch volgens mij heel duidelijk: (bron: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree)

    NOTE! This copyright does not cover user programs that use kernel 3 services by normal system calls – this is merely considered normal use 4 of the kernel, and does not fall under the heading of “derived work”. 5 Also note that the GPL below is copyrighted by the Free Software 6 Foundation, but the instance of code that it refers to (the Linux 7 kernel) is copyrighted by me and others who actually wrote it. 8 9 Also note that the only valid version of the GPL as far as the kernel 10 is concerned is this particular version of the license (ie v2, not 11 v2.2 or v3.x or whatever), unless explicitly otherwise stated. 12 13 Linus Torvalds


    Natuurlijk zijn er andere auteursrechthebbenden die een bijdrage leveren, maar de GPL geldt voor de hele kernel. Wil je een bijdrage leveren die niet onder de GPL valt, maar wel met GPL-code wordt gemixt, dan geldt het volgende: http://thread.gmane.org/gmane.linux.kernel/475654/focus=475824

  25. Hoi Robert,

    Klinkt allemaal logisch wat Torvalds beweert, maar uiteindelijk zal dit op waarheid beproefd moeten worden door een rechter. Plus, al geef je je code weg onder GPL, je blijft altijd nog de auteur en kunt dus de licentie later alsnog aanpassen. Alleen diegenen die je product met oude licentie hebben ontvangen kunnen dus doorwerken met die oude licentie.

    De auteurswet is behoorlijk complex en is nog complexer omdat we hier op internationaal niveau bezig zijn. Linux is namelijk grensoverschrijdend geproduceerd. De boel wordt nog complexer omdat auteurs materiaal weggeven, maar niet hun rechten weggeven. Want je rechten op je werk weggeven gaat niet zomaar.

    Torvalds is geen advocaat en al zeker niet gespecialiseerd in auteursrechten wereldwijd. Maar hij beschrijft het goed door het een grijs gebied te noemen. Dit betekent dat alles heel simpel is tot het voor de rechter komt en advocaten hun uurtarief gaan berekenen. Want dan blijkt het niet zo eenvoudig te zijn als het lijkt…

  26. @Wim, 35: Linus heeft gebruik gemaakt van de juridische kennis van de FSF (Eben Moglen). De GPL is ontworpen met internationaal gebruik en internationale geldigheid als belangrijke “ontwerpdoelen”. Tot dusver heeft de GPL alle aanvallen doorstaan; een aanzienlijk aantal inbreukmakers heeft voor de rechter (VS en Duitsland) bakzeil moeten halen.

    Het is lastig om eens gegeven toestemming (een licentie) in te trekken; voor zover ik weet is dat bij de GPL nog nooit gelukt. Het is wel mogelijk (en gebeurt ook) om extra toestemming te geven: alternatieve licenties aan te bieden.

  27. @MathFox, dan nog blijft het de mening van 1 persoon, eventueel gesteund door een bende juristen. 😉 In de VS en Duitsland zijn er inderdaad enkele successen maar dergelijke successen zijn wereldwijd noodzakelijk. En hoe zit het met GPL zaken binnen Nederland? En hadden al die GPL zaken in de VS/Duitsland betrekking op de Linux-kernel of op losse programma’s die onder GPL zijn vrijgegeven.

    Open-source licenties terugtrekken is best goed mogelijk. Borland heeft voorheen InterBase (database) als open-source vrijgegeven, maar de versie erna was weer closed-source. De OS licentie kon echter gebruikt worden voor het afgeleide werk Firebird. Daar kon Borland verder niets meer aan doen, behalve dan het blokkeren van trademarks. (Afgeleide werk mocht geen InterBase heten.)

    Met de Linux kernel is het behoorlijk lastig omdat er zoveel auteurs aan mee hebben gewerkt. Die hebben onderling de GPL afgesproken maar uit de vele discussies online is het lastig te bepalen wat al die auteurs er nu precies onder verstaan. Linus heeft zijn interpretatie, ondersteund door juristen. Maar diverse anderen wijken hiervan af in hun mening en interpreteren het toch anders.

    Vandaar dat er duidelijke rechtspraak over moet komen.

  28. Wim, je hebt gelijk; aan de GPLv3 hebben meer mensen een bijdrage geleverd. Maar ik heb Eben horen spreken over het ontwerp van de GPL (v1, 2 en 3) en ik heb met meerdere juristen mogen discussiëren over de GPL; het is niet makkelijk om er omheen te werken.

    Wim, je geeft zelf een voorbeeld hoe lastig het is om een licentie op een werk in te trekken; maar de (oorspronkelijke) auteur staat het vrij om een afgeleid werk (de nieuwe versie) onder een incompatibele licentie uit te brengen! 🙂

    Als je toestemming geeft aan Linus om jouw code onder de GPL te verspreiden, zie ik geen ambiguïteit in jouw toestemming. Wat Linus zegt is een verduidelijking van waar hij vindt dat het auteursrechtelijke werk “Linux kernel” ophoudt (en andermans werk begint.) De grijze gebieden zitten aan de rafelranden van de kernel: Loadable modules én programma’s die de kernel-configuratie-interfaces direct gebruiken. Mijn mening is dat de kernelprogrammeurs daar overvragen (maar dat beseffen ze zelf ook.)

  29. En daar raak je meteen ook de kern van dit probleem, @Mathfox. Want Linux is GPLv2 en daarbovenop zit Android met ASL en daarbovenop TomTec met hun propriety code. En het lastige is dat we eerst moeten weten waar de grenzen liggen in de code die voor TomTec wordt gebruikt. Best lastig als je die code niet hebt. Weet je eenmaal de grens dan het volgende probleem. Welke licentie is dan van toepassing op de code die TomTech heeft toegevoegd. En verplicht die licentie ook dat de code wordt vrijgegeven onder GPL of niet?

    En met dat gezegd hebbende vraag ik mij af of TomTec zich misschien precies aan de GPL houdt en dus niet gedwongen kan worden hun eigen code vrij te geven. Maar ja, daar kunnen wij meningen over hebben maar de uiteindelijke beslissing is nodig in de vorm van een gerechtelijke uitspraak. Of die ooit zal komen, geen idee. Maar TomTec zou dat nog wel eens kunnen winnen ook!

  30. @Wim, de meeste juristen weten wanneer je iets een “verzamelwerk” mag noemen en wanneer een combinatie van werken “afgeleid werk” genoemd moet gaan worden. Wat de GPL daar over zegt is in overeenstemming met de algemene juridische opinie. Mijn vuistregel is dat ieder bestand op het bestandssysteem een onafhankelijk werk is. (Een executable is geen afgeleid werk van de shared libraries waar hij mee linkt, maar wel een afgeleid werk van de statische bibliotheken waarmee hij gelinkt is.) Met die vuistregel is het heel makkelijk om te bepalen waar GPL en ASL grenzen lopen.

  31. @MathFox, ja inderdaad. De grens tussen GPL en ASL kunnen we bepalen want we hebben de broncode van de Linux kernel en van Android. Dat is het probleem niet.

    Maar de grens tussen Propriety, GPL en ASL in de TomTec code is een stuk lastiger te bepalen want we hebben de broncode niet die TomTec heeft gebruikt voor hun eigen aanpassingen. En het is ons nu juist om die broncode te doen. We moeten aantonen dat TomTec de GPL schendt, en indien alleen de Linux-kernel was gebruikt was dat redelijk eenvoudig geweest. Maar de ASL gooit roet in het eten want TomTec kan rustig de ASL code aanpassen zonder deze vrij te geven. Zolang ze maar voorzichtig zijn met code die de kernel benadert. En als je alleen de binaries tot je beschikking hebt om dit aan te tonen dan schiet je behoorlijk tekort. Dat bewijs zoeken vereist veel technische kennis en veel uren onderzoek om uitsluitsel te geven.

    Dus misschien dat TomTec inderdaad de GPL schendt, misschien ook niet. Arnoud gaat ook iets te kort door de bocht door in het artikel te stellen dat Android=Linux en dus onder GPL valt. Delen van Android vallen daaronder maar Google is slim en geeft die code uit onder een dubbele licentie! Want dat mag. En TomTec kan dan verder bouwen op die code, maar dan onder de ASL licentie. En zo is de GPL effectief gezien legaal omzeild, tenzij Google zelf ergens de fout in is gegaan…

    Maar als Google fout zit dan zijn alle Android-toestellen dus illegaal…

  32. @Wim, 41: Als je kunt aantonen dat TomTec de Linux kernel gebruikt, volgt daaruit de (GPL) verplichting om de Linux broncode voor het apparaat (mee) te leveren. Simpel. Het maakt niet uit of TomTec de kernel daarbij aangepast heeft of niet.

    Wat je met de rest van je verhaal probeert te zeggen begrijp ik niet. Of TomTec de code aangepast heeft maakt voor de GPL nauwelijks uit en voor de ASL verplichtingen ook nauwelijks. (TomTec moet zeggen dat ze de code aangepast heeft, dat is alles.)

  33. @MathFox, je vergeet dat Google een ASL tussenlaag heeft gemaakt. Heeft TomTec nou een afgeleid werk gemaakt van de GPL code of van de ASL code? Dat verschil kun je niet makkelijk zien. Daarnaast is van belang op welke wijze de kernel wordt gebruikt. Google kan immers Android vrijgeven onder de ASL licentie en is niet verplicht om alle Android-code onder GPL vrij te geven. Wel zijn er onderdelen van Android die onderdeel zijn geworden van de Linux kernel. Die onderdelen vallen dus onder de GPL. Maar omdat Google de auteur van dit werk is en dit ook onder andere licenties kan vrijgeven, is die specifieke code mogelijk ook onder ASL te gebruiken. En als TomTec daarop verder bouwt, wat dan? GPL? Of ASL?

    En ASL kun je weer gebruiken voor het produceren van Propriety code…

    En ze hoeven de broncode van de Linux kernel niet mee te geven indien deze niet afwijkt van de standaard code. Deze kun je gewoon vinden op kernel.org.

    Het is overigens opvallend hoe druk Google bezig is geweest om het gebruik van GPL code te minimaliseren binnen Android. En het feit dat Android code nu wordt samengevoegd met de Linux kernel maakt het al helemaal complex. Want Google, als auteur, geeft diezelfde code ook vrij onder ASL.

  34. @Wim:

    En ze hoeven de broncode van de Linux kernel niet mee te geven indien deze niet afwijkt van de standaard code.
    Kun je me de regels in de GPL aanwijzen waar dat staat?

    Voor de kernel is eea. vrij simpel: Zolang de Android kernel niet-Google GPL code gebruikt, is Google verplicht de kernel onder GPL-voorwaarden te verspreiden. Het maakt daarbij geen moer uit dat Linus de “Android patches” in zijn standaard kernel heeft opgenomen.

    Er zijn voor Google goede redenen om in de applicatie-laag geen GPL code te willen gebruiken. Die applicatie-laag staat voldoende los van de kernel om het als onafhankelijke werken te kunnen zien. En dus kunnen daar andere licenties gebruikt worden.

  35. Waar men hier aan voorbij gaat is dat het in de thread op GoT niet gaat om de volledige source code van Tomtec, maar om de source code van de kernel die gewoon GPL is.

    Daarnaast zijn er wellicht wat kernel modules die proprietary zijn. Die kunnen ze voor zich houden. Echter als ze aanpassingen in de kernel hebben gedaan om die modules te laden, dan vallen die wel onder de GPL. GPL v2 verplicht je om om werkende source code te leveren. Als je die compileert, dan moet die dus de proprietary delen kunnen laden. Of je daar nu de source van hebt of niet doet er niet toe.

    Wat moet Tomtec leveren: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

    C) kunnen we vergeten, Tomtec is een commerciële partij. a) en b) zijn duidelijk dat de source compleet moet zijn. De kernel op kernel.org kan niets aanvangen met de Tomtec tablet en is dus niet die complete kopie waarover wordt gesproken. Met andere woorden tomtec moet de source mee leveren of zelf aanbieden en kan niet verwijzen naar Kernel.org of waar dan ook.

    Wat betreft die discussie op de kernel list. Die is eigenlijk niet zo heel relevant. Een complete source kan je compileren en daarop kan je alle binaries die je hebt, of het nu binairy kernel modules of of user space binaries zijn draaien. Kan dat niet dan heb je weer niet of niet compleet de source van de gebruikte kernel gekregen. De discussie daar is of die binary modules dan ook onder de GPL vallen. Wijzigingen aan de kernel om die modules te laden zijn echter gewoon onderdeel van de kernel en vallen onder de GPL.

    Als je zelf een werkende kernel kan compileren die kan starten en alle hardware aan kan spreken, danwel de binary only drivers kan laden om hardware aan te spreken, dan heb je de rest van Tomtecs android distributie niet nodig. Je kan dan namelijk de basis android distributie die Google onder de ASL2 heeft vrijgegeven daarop draaien en je hebt met Tomtec en hun auteursrechten nooit meer iets te maken. Het maakt niet uit dat Tomtec eventueel ASL delen heeft aangepast, die heb je niet mee nodig.

    “Het is overigens opvallend hoe druk Google bezig is geweest om het gebruik van GPL code te minimaliseren binnen Android. En het feit dat Android code nu wordt samengevoegd met de Linux kernel maakt het al helemaal complex. Want Google, als auteur, geeft diezelfde code ook vrij onder ASL.”

    De code die in de mainline kernel is gemerged was altijd al GPL code. Ik zie nergens waar Google deze los onder de ASL heeft uitgebracht, maar dat is sowieso niet relevant. Op een werkende tablet zal deze code in de kernel gelinkt zijn en dan moet deze verplicht onder de GPL worden geplaatst. Zo niet dan mag je deze binary niet verspreiden zonder inbreuk te plegen. Het eco systeem is vrij simpel onder android: 1. Kernel -> GPL 2. Drivers in de kernel -> GPL 3. externe drivers die door de kernel geladen worden en van publieke interfaces gebruik maken in plaats van direct aan de kernel te linken-> Willekeurige licentie 4. ‘Google Android’ -> ASL 5. Android applicaties -> Willekeurige licentie Van 1. en 2. moet Tomtec de source leveren. Die source moet compileren tot een binary die met 3. kan werken, anders is het niet de juiste source. Verder heeft Tomtec geen verplichtingen, dus wat je op die kernel wil draaien moet je zelf ergens vandaan halen.

  36. Google heeft voor Android code geschreven die daardoor dus GPLv2 is geworden, want deze haakt in op de kernel. Maar als auteur heeft Google het recht om hun eigen code, en ook alleen hun eigen code, ook onder andere licenties te distributeren. En zo kun je een afgeleid werk maken van deze Google code, mits Google hier ook daadwerkelijk een dubbele licentie op heeft zitten. Welke licentie zou in dat geval zitten op de code die weer wordt afgeleid van alleen de Google code? GPL of ASL? Dat kan nog een interessante discussie worden, zeker omdat Google de GPL liever niet gebruikt.

    In ieder geval, een bedrijf dat tablets produceert en daarbij Android gebruikt kan gebruik maken van deze verwarring en dan zullen we toch eerst moeten aantonen dat ze code hebben geschreven die de kernel statisch meelinkt of die drivers in de kernel statisch meelinkt. Als we dat niet kunnen hoeft TomTec verder ook niets op te leveren. Je zou al een eind komen door een standaard Android-distributie te installeren op een TomTec en dan kijken of deze werkt. Als het lukt, pech! Dan hoeft TomTec verder niets meer op te leveren. Maar mochten er bepaalde onderdelen van het apparaat vervolgens niet meer (goed) werken dan zal je verder moeten onderzoeken of je hiervoor extra drivers nodig hebt en zo ja, of die drivers statisch of dynamisch naar de kernel linken.

    Kortom, de bewijslast ligt niet bij TomTec, maar bij diegenen die de code van TomTec willen hebben. Toon eerst maar aan dat de GPL van toepassing is op hun aanpassingen.

  37. @46: “In ieder geval, een bedrijf dat tablets produceert en daarbij Android gebruikt kan gebruik maken van deze verwarring en dan zullen we toch eerst moeten aantonen dat ze code hebben geschreven die de kernel statisch meelinkt of die drivers in de kernel statisch meelinkt.”

    Stap 1: Toon aan dat de tablet op een linux kernel draait. Stap 2: Vraag de werkende code van die kernel. Stap 3: is er niet, door stap 1 moet Tomtec bij stap 2 de source oplepelen voor de kernel waarop de tablet draait. Van alles wat ze niet opleveren moeten de binaries op de zelf gecompileerde kernel draaien, anders hebben ze niet de juiste source aangeleverd.

    We hoeven niets te bewijzen om de code op te vragen. En we kunnen eenvoudig testen of het de juiste code is als er code wordt vrijgegeven, het werkt of het werkt niet. Die statisch in de kernel gelinkte onderdelen moeten erin zitten, zo niet dan kan je nooit een kernel met die functionaliteit uit de source compileren en weet je dat ze iets hebben achter gehouden.

    Enige probleem dat blijft: sommige van die binaries die overblijven kunnen best ook onder de GPL vallen en dat is lastiger aan te tonen.

    Je schrijft mooie verhalen over hoe vaag het allemaal wel niet is, maar dat is niet hoe de feiten liggen. De feiten zijn namelijk vrij helder en eenduidig: 1. De kernel is Linux en valt onder GPLv2 2. Tomtec(Bart Smit?) moet de source van die kernel leveren of ze overtreden de auteurswet/danwel plegen contractbreuk. 3. Die source moet je kunnen compileren tot de binary die ze hebben geleverd inclusief alles wat statisch gelinkt is. Na compilatie moet je een drop in replacement kernel hebben. Zo niet dan hebben ze niet aan de GPK verplichting gedaan.

    Met andere licenties en dergelijke hebben we niets te maken en naar meer wordt niet gevraagd. De code voor hun android versie hoeven ze niet te leveren en wordt niet naar gevraagd. De binary only drivers hebben we meegeleverd gekregen en wordt niet naar gevraagd (er wordt wel gevraagd naar de sources voor een kernel waarop deze binary draait)

    “Kortom, de bewijslast ligt niet bij TomTec, maar bij diegenen die de code van TomTec willen hebben.” Niet dus de kernel is duidelijk Linux, Tomtec moet de code op verzoek 3 jaar lang leveren (is immers niet mee geleverd) en mag daarbij niet naar derden verwijzen, ze moeten het zelf leveren of er voor zorgen dat het geleverd wordt. Wijzen naar daar ergens zit het tussen voldoet niet. “a complete machine-readable copy of the corresponding source code” Let op het woordje corresponding in deze zin. De source moet dus bij de geleverde binary horen. Nadat we source hebben gehad ligt er wellicht een bewijslast probleem aan onze kant om aan te tonen dat de geleverde source niet de juiste is. Maar in eerste instantie hoeven wij niet te bewijzen, maar alleen maar te vragen.

  38. @Wim, 46, Correcties: Google heeft code geschreven die zodanig met de Linux kernel verweven is dat ze door Google onder een GPLv2 compatibele licentie verspreid moet worden. In de standaard Linux kernel zitten ook stukken BSD gelicenseerde broncode; die mogen ook in Open-, Net- of FreeBSD kernels gebruikt worden. Iemand die een afgeleid werk maakt van een stuk Open Source code en dat wil verspreiden, mag daarvoor zelf zijn licentie kiezen, mits de licentie op de oorspronkelijke code die keuze toelaat. BSD code mag onder de GPL verspreid worden, maar GPL code niet onder een BSD licentie.

    Wim, Lees de GPL; iedereen die commercieel GPL code verspreidt, moet de broncode of een aanbod tot het leveren van de broncode meeleveren. Iemand die de TomTec Linux code wil hebben hoeft alleen maar aan te tonen dat TomTec een Linux kernel in zijn apparaat heeft zitten. (Het helpt veel in je standing als je auteursrecht op een stukje Linux code hebt.)

  39. Google heeft code geschreven die zodanig met de Linux kernel verweven is dat ze door Google onder een GPLv2 compatibele licentie verspreid moet worden.

    Dat is correct. Desondanks kan Google niet worden gedwongen om hun eigen werk ook onder andere licenties te verspreiden. Google is immers de auteur van die code! Ze mogen dus een dubbele licentie plaatsen op hun code. En hier zit nu de grap van een licentie-conflict want als ik alleen de code van Google zou aanpassen dan vallen die aanpassingen onder ASL. Het wordt pas lastig indien mijn aanpassingen ook de kernel zouden raken maar dat zal dan eerst aangetoond moeten worden.

    Ik zeg ook niet dat je ongelijk hebt. Ik zeg alleen dat je eerst moet aantonen dat TomTec inderdaad de GPL negeert. Beweren dat er een Linux-kernel inzit en dus automatisch de GPL van toepassing is, betekent dat ALLE Android-toestellen dus de GPL negeren, inclusief applicaties die hierop draaien. Ja, leuk dat de kernel onder GPL valt, maar binnen Android vallen ook veel onderdelen onder ASL, wat betekent dat TomTec zich mogelijk volledig aan de licentievoorwaarden houdt. Ja, dit is een enorm grijs gebied en met loze kreten als “lees de GPL” kom je er niet. We hebben hier te maken met Android, en Android is deels GPL en deels ASL.

    In dit land ben je nog steeds onschuldig tot het tegendeel is bewezen.

    Niet dus de kernel is duidelijk Linux, Tomtec moet de code op verzoek 3 jaar lang leveren (is immers niet mee geleverd) en mag daarbij niet naar derden verwijzen, ze moeten het zelf leveren of er voor zorgen dat het geleverd wordt.
    Nogmaals, de standaard kernel is op kernel.org te vinden en je hebt niet bewezen dat TomTec aanpassingen heeft gedaan die de kernel raken. Immers, bovenop de kernel ligt Android. Android is ASL. ASL vereist vrijwel niets en een tablet-maker zou best enorm veel vanuit deze Android-laag kunnen regelen. Je neemt gewoon wat standaard onderdelen die al standaard door de kernel worden ondersteund, neemt de standaard Linux kernel, neemt de standaard Android code en bovenop de Android code ontwikkel je nog wat eigen spullen en je bent klaar. TomTec verwijst naar Android, Android verwijst weer naar de Linux-kernel dus aan het verwijzen naar de originele broncode is ook voldaan. Ik zie het probleem dus niet…

  40. Wim, het is theoretisch erg leuk, maar de kernel patches heeft google onder de GPLv2 uitgebracht zoals die voor de kernel geldt en niet onde de ASL: “For example, the Linux kernel patches are under the GPLv2 license with system exceptions, which can be found on kernel.org.”

    Jij kan google vragen om die patches onder de ASL te leveren aan jou, maar daar heb je weinig aan omdat je ze dan niet de binary, noch de source mag verspreiden waarin je deze met de kernel samenvoegt. Discussie is dus praktisch niet nuttig in deze casus.

    Aantonen dat de tablet een linux kernel draait is triviaal. Er zit noch source, nog een aanbod voor de source bij de tablet. Als je me niet gelooft, dan kan je de inhoud van de doos en tablet bij me komen bekijken. Tomtec lijkt dus in overtreding (zou kunnen dat ze Bart Smit wel een aanbod gedaan hebben), Bart Smit is zeker in overtreding. Ik zie je bewijs probleem dus echt niet.

    “Beweren dat er een Linux-kernel inzit en dus automatisch de GPL van toepassing is, betekent dat ALLE Android-toestellen dus de GPL negeren, inclusief applicaties die hierop draaien.”

    Je blijft ook maar doen alsof we om alle source code vragen. Maar we vragen aleen om de source van de kernel zoals die op de tablet draait. We hebben dus niets met dat ‘vage’ gebied met andere licenties te maken. De kernel is linux dus is daarop automatisch de GPL van toepassing, hij is niet onder een andere licentie te krijgen. En ja heel veel fabrikanten negeren de GPL en hebben dus feitelijk geen licentie, maar echt niet allemaal. Zie hier echter een lijstje met hoe slecht het er op een gegeven moment voor stond (lijst is outdated): http://www.codon.org.uk/~mjg59/android_tablets/

    “We hebben hier te maken met Android, en Android is deels GPL en deels ASL.” Dat blijf je beweren, maar we hebben te maken met de kernel en die is GPL, komt geen ASL aan te pas.

    “Nogmaals, de standaard kernel is op kernel.org te vinden en je hebt niet bewezen dat TomTec aanpassingen heeft gedaan die de kernel raken.” En nogmaals, de GPL verplicht degene die de binary verspreid om de kernel source te leveren, je kan je niet op derden beroepen. Ook als je niets veranderd hebt ben je als commerciele partij niet vrijgesteld van leveringsplicht van de source. Die source moet ook nog eens de source zijn die overeenkomt met wat gebruikt is in de binary. Als je dus niet de kernel kan compileren tot een werkende kernel dan hebben ze al niet voldaan. Verwijzen naar kernel.org volstaat dus niet. Als de code al ongewijzigd is kan tomtec die natuurlijk op een DVDtje branden en opsturen. Maar in dat geval zou de kernel op kernel.org nu ook al moeten werken en dat doet hij niet. (Al is het maar dat google een deel maar niet al zijn patches in deze kernel heeft geintegreerd)

    “TomTec verwijst naar Android, Android verwijst weer naar de Linux-kernel dus aan het verwijzen naar de originele broncode is ook voldaan. Ik zie het probleem dus niet???” Dat moge duidelijk zijn. Je gaat iedere keer weer voorbij aan de GPL plicht om conforme kernel sources te lveren, niet verwijzen naar een algemene repository. Je gaat ook voorbij aan het feit dat de kernel op die algemene repository niet werkt en dus niet voldoet aan de eis. En je blijft Android erbij halen, terwijl het alleen om de kernel gaat.

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.