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
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?
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.
Kun je de media markt of blokker of weet ik veel welke winkelier het ding geleverd heeft aanspreken?
Die hebben en slotte het ding met de software ook gedistribueerd.
???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?
Dat kun je wel doen maar geeft je geen verspreidingsrecht. Je erkent in feite dat je auteursrechten aan het schenden bent. Dat zal geen zinnig bedrijf doen, tenzij ze een excuus kunnen verzinnen waarom het auteursrecht niet geldt.
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:
http://gpl-violations.org/
@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.
Dit is ook wel nuttige info over de GPL: wat mag en moet: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
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.
@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:
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?
@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.
@André: dat doorgeven geldt enkel en alleen wanneer je de originele fysieke drager doorgeeft. Een kopie of elektronisch verkregen stuk software mag nooit en te nimmer zonder licentie worden doorgegeven aan een ander.
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.
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.
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.
@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.
De GPL bevat een interessante clausule: als je je niet houdt aan de verplichtingen broncode te leveren, vervalt je complete gebruiksrecht. Er hoeft dus maar 1 persoon te vragen om de broncode. Wordt deze niet gelevert, dan betekent dat automatisch dat alle tomtec tablets illegale software bevatten.
En wat doen we ook al weer met de directeur van organisaties die wellicht auteursrecht schenden?
@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…
@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.
Even om de bron van de spraakverwarring te killen, Elroy bedoelt waarschijnlijk “code om die driver in te laden wordt in de kernel
gecompileerdgelinkt.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.
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.
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?
@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.
@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?
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.
@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…
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.
(verwijderd)
“over de broncodes van de Linuxkernel”
Broncode is ontelbaar en heeft dus geen meervoud. “Broncodes” is dus geen Nederlands evenmin als ‘source codes’ Engels is.
(verwijderd)???
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
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…
@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.
@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.
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.)
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!
@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.
@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…
@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.)
@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.
@Wim:
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.
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.
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.
@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.
@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.)
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.
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…
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.
@Elroy, die theorie is iets waar binnen de GPL nog best veel onduidelijkheid over is. Dit is bovendien de reden dat GPLv3 is uitgekomen die dergelijke constructies probeert tegen te houden, alleen heeft Linus bepaald dat voor zijn aandeel van de kernel-code alleen GPLv2 van toepassing is en verder geen andere GPL versie. Maar voor het werk van andere auteurs zou zomaar GPLv3 van toepassing kunnen zijn. Of in het geval van Google, ASL.
We praten hier over een afgeleid werk van een afgeleid werk. De basis is GPL en daarbovenop zit code die (mogelijk) onder ASL valt. (Want Google geeft liever niet vrij onder de GPL maar moet dit nu eenmaal doen voor bepaalde onderdelen.)Je kunt dus doorbouwen op de ASL laag zolang je de GPL laag maar niet raakt.
Verder blijf jij gewoon aannemen dat TomTec aanpassingen aan de kernel heeft moeten maken om Android op hun systeem te laten werken. Nogmaals, TomTec draait Android. Android is ontwikkeld om met bepaalde standaard-componenten meteen te werken zonder aanpassingen. En ja, Android maakt weer gebruik van de Linux kernel. En wat dan nog? TomTec verwijst naar Android, Android verwijst naar Linux, case closed.
Niet moeilijker doen dan het al is, okay?
Ik ga zeker niet voorbij aan de GPL plicht om conforme kernel broncode aan te leveren. Die wordt ook geleverd door de Android website. Nogmaals, wat is het probleem dan?
Maar goed, even wat research doen en dan deze site tegenkomen. Zo te horen kan er zo een andere Android-versie op gezet worden zonder al te veel bijzonderheden. Standaard Android met de daarvoor gebruikte standaard Linux Kernel. We hebben het dus over hardware waar je kennelijk je eigen Android-versie op kunt plaatsen zonder problemen. Dan lijkt het mij voldoende om Android plus versienummer te noemen om aan de GPL te voldoen. Je kunt immers de broncode zo krijgen en dus ook compileren en installeren op dit apparaat. Misschien mis je wat apps die door TomTec zijn gebouwd maar hey, die apps blijven gewoon propriety, tenzij jij kunt aantonen dat ze op de GPL leunen. (Want apps onder Linux en Android kunnen gewoon propriety blijven, onder voorwaarden.)
Oh, even kijken. Bart Smit verkoopt deze TomTec en in de beschrijving wordt verwezen naar “High Resolution Android 4.0 versie 3″. Die specifieke versie staat bij Google met alle toebehoren. Duidelijker kan het niet, denk ik. Bart Smit verwijst naar Android, want Google is de distributeur van deze software, niet Bart Smit. En Google volgt netjes de GPL.
Waar gaat deze discussie dan nog over?
@51 & 52:
Welke onduidelijkheid Wim? Ik vraag me langzaam af of je het niet wil begrijpen. Android kan me geen moer schelen, het gaat alleen om de linux kernel die er onder zit. En jij blijft maar aankomen met de android code en de ASL. Ik weet dat ze die niet hoeven leveren en ik ben er ook niet in geinteresseerd.
De site die je tegen komt doet niet meer dan samenvatten wat er in het Tweakers draadje wat Arnoud aanhaalt staat. Die namen die ze noemen zijn allemaal mensen op GoT. De Android 4.0.3 versie die ze erop zetten is een ROM voor de Newsmy K97, dat is dezelfde tablet als de Tomtec, maar dan met 16GB ipv 4GB interne opslag. Ook van deze kernel is geen source beschikbaar. Newsmy begaat dus de zelfde fout als Tomtec en Bart Smit. Die site veranderd helemaal niets, er is nog steeds geen kernel source vrijgegeven voor de Tomtec.
“Ik ga zeker niet voorbij aan de GPL plicht om conforme kernel broncode aan te leveren. Die wordt ook geleverd door de Android website. Nogmaals, wat is het probleem dan?”
Na meerdere posts is het je dus nog steeds niet duidelijk dat 1) De android website geen kernel source bevat, alleen wat patches en 2) De source op kernel.org samen met de patches niet compileert tot de kernel op de tablet. Er zijn dus andere wijzigingen op doorgevoerd. Met andere woorden, de conforme source code is NIET vrijgegeven.
“We praten hier over een afgeleid werk van een afgeleid werk. De basis is GPL en daarbovenop zit code die (mogelijk) onder ASL valt.”
Nee, we hebben het over de linux kernel die onder de GPL valt, we hebben het niet over de code die erop draait. (Die laatste willen we nu juist vervangen)
Kunnen we de ASL alsjeblieft vergeten die is irrelevant, niets van wat we willen hebben valt onder de ASL. We willen de source voor een werkende Linux kernel en wel de source van de kernel die op de tablet is geleverd.
@Elroy, nogmaals. TomTec levert een systeem met Android, niet met Linux. Dat Linux weer binnen Android zit maakt gewoon geen verschil. Zolang TomTec die kernel niet raakt en dus alleen Android distributeerd, met eventueel enkele aanpassingen aan de Android-code is er geen sprake van een GPL-overtreding.
Je gaat steeds weer voorbij aan het feit dat, doordat deze apparaten op Android draaien, er dus is voldaan aan de verwijzing naar de Linux kernel. Google is namelijk, als distributeur van Android, hiervoor verantwoordelijk. Niet TomTec, niet Bart Smit, maar Google. En Google houdt zich keurig netjes aan de GPL en geeft zelfs code terig die momenteel in de kernel wordt opgenomen.
De verwijzing naar Android, die weer verwijst naar de broncode, is gewoon voldoende. Als dat namelijk niet het geval was dan zijn enorm veel producenten van Android-toestellen in overtreding.
Of liever gezegd, de “Open Handset Alliance” is verantwoordelijk voor het onderhouden van de Linux kernel binnen Android en de Hardware Abstraction Layer (HAL) die daarbovenop rust. De HAL maakt het weer mogelijk om daarbovenop weer code te plaatsen die niet aan de GPL hoeft te voldoen, zodat Google dus gewoon hun eigen licentie kan toepassen op de code boven de HAL. De code onder de HAL is standaard en wel zo bekend dat iedereen deze wel weet te vinden.
Maar misschien moet deze discussie gewoon aan Linus Torvald voorgelegd worden. Hij is immers de copyrighthouder van het gehele Linux-concept, ook al is hij geen copyright van de gehele broncode. Het is en blijft zijn project. Zijn standpunt wijkt af van wat de FSF bijvoorbeeld zou willen en Linus blokkeert dan ook dat Linux onder GPLv3 vrijgegeven wordt, hoewel hij die restrictie dus alleen op zijn eigen werk kan plaatsen. Een leuk onderwerp hierbij is Tivoization waarbij TiVo Linux gebruikte op hun hardware, maar dan voorzien van een speciale, digitale handtekening. Ze gaven hun code wel vrij, maar de hardware weigert gewoon indien de code niet digitaal getekend is met de digitale handtekening waar alleen TiVo over beschikt. Dit was een reden om GPLv3 te ontwikkelen, waar Linus het dus niet helemaal mee eens is.
Maar goed, het probleem is gewoon dat er enorm veel discussies zijn over wat de GPL nu wel en niet dekt, welke versies van toepassing zijn en, zoals in dit onderwerp, wanneer en hoe je de broncode moet vrijgeven van de kernel die je in je hardware gebruikt.
Laten we even de punten doorlopen van GPLv2. Punt 0 is de inleiding. Blah, blah. Okay, punt 1 spreekt over distributie van broncode en dat doet TomTec niet. Niet van toepassing. Punt 2 heeft het over aanpassingen van de code, of delen daarvan, maar dat heeft TomTec niet (aantoonbaar) gedaan. Ze draaien kennelijk een standaard Android-versie zonder aanpassingen. Punt 2 is dus niet van toepassing. Punt 3 dan? Punt 3 gaat over het distributeren van programma’s genoemd onder punt 2. Dus om afgeleide werken. TomTec heeft niets afgeleid, dus ook niet van toepassing. (Google heeft wel afgeleid!) Punt 4 en 5 zijn ook niet echt van toepassing. Komen we bij punt 6, namelijk het doorgeven van de licentie aan de ontvanger van het programma. Tja, dat zit ook al ingebakken in Android, volgens mij. Even op mijn Galaxy tab nakijken… Settings, About Device, Legal information… Yep! Daar is het… Punten 7, 8 9 of 10 dan? Of 11 of 12? Nee, ik zie nergens staan dat bij gebruik van een standaard Linux kernel de leverancier ook de broncode moet aanleveren. Alleen in geval van een afgeleid werk.
En dan keren we gewoon weer terug naar het punt wat ik steeds benoem. Heeft TomTec een afgeleid werk gemaakt van de Linux kernel? Of van Android? Of beide? Zeg het maar en toon het maar aan. Maar als TomTec gewoon de standaard Android installatie gebruikt dan hoeven ze verder niets aan te leveren. De GPL wordt keurig nageleefd, volgens mij. TomTec heeft geen afgeleid werk gemaakt en hoeft dus geen broncode aan te leveren.
Nogmaals, wat is het probleem? Wat snap je niet?
@54: Tomtec levert een systeem met linux en Android. Dat zijn twee aparte dingen net als Linux en LibreOffice twee aparte dingen zijn.
En om maar even op je analyse van de GPL in te gaan: Punt 3 zegt: You may copy and distribute the Program (or a work based on it, under section 2)…
Punt drie gaat dus over zowel ongewijzigde distributie als over distributie van afgeleide werken en daar gaat jouw analyse fout. Ik heb de cruciale ‘or’ Maar even vet gemaakt. Het gedeelte tussen haakjes is geen uitleg van hetgeen ervoor staat, maar een uitbreiding.
Met andere woorden je moet aan 3. voldoen of je het programma nu aanpast of niet. Dit betekent dat bij mijn Tablet of 1) Dec ode moest zitten (niet het geval) of 2) Een written offer om die code te leveren (ook niet het geval). Het vervolgens verwijzen naar een website van derden waar een heleboel verschillende code staat waaronder misschien ook de code van het programma voldoet hier niet aan. De licentie eist namelijk dat de verspreider van het programma de source verspreid, niet dat hij verwijst naar een andere partij. tl;dr Distributie van ongewijzigde binaries verplicht ook tot disctibutie bijbehorende source.
Wat ik niet snap is hoe jij tot de conclusie komt dat android en linux vermengt zouden zijn, hoe jij concludeert dat Tomtec android distribueert en niet linux en hoe jij tot de conclusie komt dat je alleen source hoeft te leveren als je iets hebt aangepast. Alle drie de uitspraken zijn niet waar.
@Elroy, er is geen enkele hardware-leverancier die een ongewijzigde Linux-kernel zelf oplevert met hun hardware. Geen enkele. Ik betwijfel zelfs of er software-bedrijven zijn die zich hier netjes aan houden. De reden hiervoor is ook eenvoudig, want de ongewijzigde code is voor iedereen eenvoudig te vinden. Google onderhoudt de kernel-versie voor onder Android en kernel.org de standaard kernel. Niemand zit te wachten op al die hardware-bedrijven die deze broncode ongewijzigd door-distributeren.
Wil je de broncode hebben? Wel, je weet de Android-versie die op je tablet wordt gebruikt dus bij Android.com is deze op te vragen. Waarom zou iedere hardware-fabrikant nou een exacte kopie hiervan moeten aanleveren indien deze gewoon al beschikbaar is? “Accompany it with a written offer…”? Wel, tablet draait Android x.y en op http://source.android.com/ kun je de broncode hiervan vinden. Nergens in de GPL staat dat een bedrijf zelf de broncode moet aanleveren. Ze moeten alleen duidelijk maken waar deze te vinden is. De verwijzing naar de specifieke Android-versie lijkt mij al meer dan genoeg.
Van een ongemodificeerde Android-versie is de broncode eenvoudig te vinden. Een bedrijf kan dus volstaan met een verwijzing hiernaar. Zonder aanpassingen aan de Linux-kernel binnen Android voldoe je dus al vrij gemakkelijk aan deze eis.
Om te beginnen heb je het weer over de android broncode, terwijl ik het over de kernel broncode heb. Kunnen we eindelijk een keer ophouden over android code. Ik weet waar die te krijgen is en ik weet ook dat die een licentie heeft die je niet verplicht om de broncode te publiceren. De kernel waar android op draait is echter uitgebracht onder een licentie die die verplichting wel heeft en daar gaat het om.
Ik zal het even tot de essentie terugbrengen. Eerst een uitgebreide quote van sectie 3, daarna in een enkele eenvoudig te lezen zin de kern van het probleem.
“provided that you also do one of the following:
a) …
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) …”
Het vet gedrukte deel leest als een volzin, weggelaten zijn dan alleen wat randvoorwaarden die niets aan de situatie veranderen op dit moment:
Provided that you accompany it with a written offer to give any third party a complete machine-readable copy of the corresponding source code.
Dus ja, je bent zelf verplicht om de source te geven en kan dus niet zeggen kijk daar maar, daar staat het ergens. Ik heb buiten tablet en telefoon nog nooit een hardware apparaat gekocht waar Linux bij werd geleverd, maar alle Linux distributies die ik in de jaren heb gebruikt kwamen met de source op diskette (ja zo lang geleden), CD of DVD. Ubuntu, debian, redhat bieden alemaal packages aan met de door hen gebruikte kernel
“er is geen enkele hardware-leverancier die een ongewijzigde Linux-kernel zelf oplevert met hun hardware. Geen enkele.”
Ik durf deze uitspraak wel aan: Geen enkele distributie gebruikt de kale sources van kernel.org! Bij een distributie als Gentoo heb je wel de optie om die kale kernel te gebruiken en door het systeem wat ze gebruiken laden sommige packages de kale kernel van kernel.org en laten daar specifieke patches op los. Debian, Ubuntu, RedHat, alemaal leveren ze je aangepaste kernels.
En om het nog makkelijker te maken: De tomtec tablet gebruikt een Rockchip 2918 SoC, de mainline kernel bevat niet de code om die aan te sturen.
Er zijn inmiddels wel twee andere tablets met deze chip waarvoor kernel sources zijn gepubliceerd:
https://bitbucket.org/paulobrien/androidkernelandypad/src
en op
http://www.odys.de
Alleen is de hardware van deze tablets anders dan van de Tomtec, beide hebben bijvoorbeeld een ander scherm.
@Wim:
Hoe moet ik dit dan interpreteren:
Naar Google wijzen is voor een commerciële Android distributeur niet genoeg.
Wel MathFox, TomTec draait Android x.y versie z. Deze is op android.com te vinden.
Ik zie nog steeds het probleem niet. Zolang TomTec een standaard Android versie gebruikt, is de GPL gewoon opgevolgd omdat Android -inclusief bijbehorende Linuxkernel- door Google wordt gedistributeerd. Bart Smit levert keurig netjes de informatie aan over de gebruikte Android versie wat meer dan genoeg informatie is, volgens mij.
@Elroy, betreffende die Rockchip 2918 SoC, ik heb geen idee of de drivers voor dit ding propriety is of niet. Als jij kunt aantonen dat TomTec een driver gebruikt die niet aan de GPL voldoet maar hier wel aan zou moeten voldoen, dan heb je een punt. Maar vergis je niet! Er bestaan Propriety modules voor onder de Linux kernel!
We hebben het verder ook niet over de kernel zoals aangeleverd door kernel.org maar over de kernel aangeleverd door Google.com. En dat maakt het grote verschil.
B heeft het over de manier waarop de boel gedistributeerd kan worden. Iedere electronische wijze dus. Een verwijzing naar een andere distributeur voldoet hieraan, zolang er niet zelf aanpassingen zijn aangebracht.
Je kunt de GPL ook exact tot de letter willen opvolgen maar zelfs Linus Torvalds vindt dat niet al te practisch. Dat is ook de reden waarom Linus niet met GPLv3 accoord gaat. Te veel extra restricties. Het doel is dat gebruikers van dit Android apparaat zelf met de kernel-code aan de slag kunnen, indien ze dat willen. En omdat niet aangetoond wordt dat TomTec aanpassingen aan de kernel heeft gemaakt is dus te voldoen met de verwijzing naar Android en de binnen Android zittende Linux kernel, zoals wordt gedistributeerd door Google.
Zonder aanpassingen aan de Linux kernel is TomTec alleen het werk van Google door aan het sturen. Daar is het ook voor iedereen beschikbaar.
@Wim, de meeste personen zullen er de voorkeur aan geven om broncode te downloaden, in plaats van te wachten op een CD in de brievenbus. Als je als tabletmaker de broncode op je website aanbiedt zal er waarschijnlijk nooit iemand om een CD vragen, maar als er iemand komt kun je simpel een CD van de code op de website branden.
Het verwijzen naar code op de website van een ander is riskant; een website kan oude versies van de code verwijderen of de hele site kan zelfs compleet verdwijnen. Daarnaast geldt dat vrijwel altijd kleine aanpassingen aan de code plaatsvinden, voor de Linux kernel wordt bijna altijd een machinespecifieke configuratie gemaakt. En volgens de GPL is het configuratiebestand ook broncode.
Wim, mijn tablet draait op dit moment Android 4.0.3 op Linux kernel 3.0.8(+).
Android 4.0.3 is op de website van android te vinden, maar ik zie niet hoe dat relevant is. We hebben het over GPL verplichtingen en dus niet over android.
De kernel valt onder de GPL en daarvoor geldt wat MathFox en ik citeren. Kernel.org bevat heel veel code, de GPL zegt niet u zult wijzen naar ergens waar het staat en laat maar zoeken, ze zegt u zult de juiste code geven.
Ik ben me bewust van proprietary drivers onder Linux. De meest gebruikelijke interpretatie is dat als een driver alleen publieke interfaces in de kernel aan ropet, dat het geen afgeleid werk is en de source niet vrij hoeft te worden gegeven. Die publieke interface wil echter van kernel versie op kernel versie nog wel eens wijzigen en dan werkt die binary driver niet meer. Daarom is het ook zo van belang dat je de juiste conforme kernel code krijgt en niet naar een verzameling op kernel.org verwijst als dit soort drivers gebruikt worden.
Wat betreft de Rockchip 2918, code om de CPU te innitialiseren kan niet als een loadable module worden gecompileerd, deze zit per definitie hard in de kernel binary gelinkt en valt dus zeker onder de GPL. Dat kan wel voor andere in de SoC geintegreerde randapparatuur, maar met de juiste source is dat geen probleem.
“En omdat niet aangetoond wordt dat TomTec aanpassingen aan de kernel heeft gemaakt is dus te voldoen met de verwijzing naar Android en de binnen Android zittende Linux kernel, zoals wordt gedistributeerd door Google.”
Dat zou mooi worden, wat jij nu zegt is “Iedereen mag de regels negeren, zolang anderen maar niet aan kunnen tonen dat dat je het doet”. Dat je er in de praktijk mee weg kan komen wil niet zeggen dat het mag. Ik mag dus ook 120 door de bebouwde kom rijden, als niemand maar kan bewijzen dat ik dat doe? Als Tomtec een aangepaste kernel gebruikt heeft (of ik dat nu kan bewijzen of niet) zijn ze verplicht om daarvan de source te leveren. Stel dat ze dan zeggen wij hebben niets aangepast en ze verwijzen naar kernel.org, dan staan daar veel verschillende kernels en zullen ze naar de juiste moeten wijzen. Vervolgens zal blijken dat je met die source geen kernel voor de tablet kan compileren. En helaas kan je dan als koper weinig en ben je afhankelijk van acties door auteursrechthouders in de kernel source. Maar of ik weet/kan bewijzen of niet dat de kernel is aangepast, veranderd niets aan de verplichting van mijn leverancier om een conforme kernel te leveren.
(Stock kernels zullen sowieso niet werken, aangezien ze patches missen die nodig zijn om android erop te kunnen draaien. Die patches staan weer bij google, dus op zijn minst zal je daar ook naar moeten verwijzen dan. Daarnaast heb je dan nog patches voor de hardware ondersteuning,die bij de fabrikant vandaan zulen moeten komen.)
Zie hier hoe Samsung het doet: https://opensource.samsung.com