Zitten fabrikanten Android zonder GPL-distributierecht voor Linux?

| AE 2659 | Intellectuele rechten | 19 reacties

android-open-source.pngOmdat de code van besturingssysteem Android niet (volledig) openbaar is en gepubliceerd wordt, vervalt het recht voor veel fabrikanten om Androidtoestellen te verkopen, meldde Nu.nl gisteren. Men baseert zich op Florian Mueller, die het weer uit de VS haalde.

Het pijnpunt zit hem in artikel 4 van de GPL:

You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

Op zich geen gekke clausule: je moet je aan de licentie houden, en doe je dat niet dan vervalt de licentie en mag je helemaal niks meer.

Mueller’s zorg is gebaseerd op de boude statement dat “virtually every Android OEM … was out of compliance at some point”, oftewel iedereen die Android uitlevert heeft ooit wel een keer een hoekje van de GPL geschonden en is daarmee zijn licentie kwijtgeraakt. Waar hij dit op baseert, weet ik niet. Het gaat me wat ver om te zeggen “iedereen zal wel een keer de licentie geschonden hebben”, hoewel het me zou verbazen als de meerderheid van Android-leveranciers zich perfect aan de GPL houdt.

De lastige consequentie van de GPL schenden is wel dat je het distributierecht kwijt bent totdat je van alle relevante auteursrechthebbenden hernieuwde toestemming hebt gekregen. Dat zegt in ieder geval de Sofware Freedom Law Center, de handhaver van de GPL. En bij Linux is het zo goed als onmogelijk die toestemming te vragen, want er zijn honderden zo niet duizenden auteurs met minstens één regel creativiteit in de Linuxkernel.

Dit principe is echter nog nooit bij de rechter getest, en eerlijk gezegd gaat het me wel érg ver. Volgens mij kun je gewoon opnieuw de Linuxkernel downloaden, en dan krijg je daar een nieuwe licentie bij. Die nieuwe licentieverlening staat los van je eerdere schending. En als dat al te bijdehand klinkt: wacht dan eventjes tot er een nieuwe major release uit is en ga dan netjes daarmee werken. Ik kan me níet voorstellen dat een rechter zal zeggen “u had de licentie op versie 2.3.12 geschonden, dus versie 2.6 mag u niet gebruiken”. Die twee licenties zijn weliswaar inhoudelijk identiek maar gaan over duidelijk verschillende programma’s.

Oh, en open source is nu echt mainstream: GPL-licentieruzies halen Nu.nl.

Arnoud

Mag je LGPL software subclassen?

| AE 2468 | Intellectuele rechten | 5 reacties

ketting-chain-link.pngEen lezer vroeg me:

Naar aanleiding van het softwareboek vroeg ik me af of je ook aandacht gaat besteden aan de kwestie over linken, met name bij de LGPL. Ik weet dat dat legaal is, maar hoe werkt dit bij talen waarbij het concept ‘linken’ niet bestaat? Denk aan objectgeorienteerde talen zoals Java of Objective-J. Daarbij maak je eerder gebruik van code door objecten te subclassen (vererven). Is een klasse die eigenschappen erft een afgeleid werk? En mag je die klasse dan onder een eigen licentie uitbrengen als hetgeen waar je van afleidt, LGPL is?

De GPL en LGPL zijn de twee bekendste opensourcelicenties. Ze zijn grotendeels hetzelfde in opzet. Het belangrijkste verschil zit hem in hoe wordt omgegaan met ‘afgeleide werken’ of wat we in Nederland ‘verveelvoudigingen in gewijzigde vorm’ zouden noemen. Daarvan is sprake als je eigen code op bepaalde manieren combineert om zo een nieuw stuk software te maken.

De GPL eist dat dergelijke afgeleide werken óók weer GPL worden gemaakt wanneer je ze verspreidt. De LGPL doet dat niet, in ieder geval niet als je je eigen code via linking combineert, zo staat in artikel 5 van de LGPL v 2.1. Je bent bij de LGPL alleen verplicht om daadwerkelijke wijzigingen aan de LGPL-code zelf beschikbaar te stellen in broncodevorm wanneer je deze distribueert.

De LGPL is geschreven met C in het achterhoofd, vandaar de vrij specifieke bepalingen over linken. Het is dan ook erg moeilijk om te zeggen hoe de licentie uitpakt voor talen die niet linken maar juist subclassen of een framework bieden waar je mee ontwikkelt.

Er lijkt binnen de Java community een consensus te zijn dat LGPL klassen wél gesubclassed mogen worden maar GPL klassen niet. Maar dat is meer een informele afspraak tussen developers en niet echt een juridisch afdwingbaar iets – tenzij de rechter vindt dat die afspraak gezien mag worden als heersende mening oftewel gewoonterecht. De FSF schrijft “niets aan de hand, gewoon doorlopen”

The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

Voor LGPLv2.1 wordt er dan aan toegevoegd dat “function signatures are checked against the library, creating a link”, wat me een beetje een gezochte interpretatie lijkt want dat is niet het soort ‘link’ dat LGPLv2.1 bedoelt. Maar goed.

De LGPLv3 lost het iets handiger op. Daar wordt in meer algemene zin gesproken van “combining or linking an Application with the Library.” Het lijkt mij dat subclassen of vererven van code ook wel onder die definitie valt.

Alles bij elkaar denk ik dat je met LGPL-code in een objectgeorienteerde taal mag subclassen of erven zonder dat je je eigen code LGPL zou moeten maken bij distributie. Wel moet je ervoor zorgen dat de LGPL code in een aparte JAR of ander soort bestand komt te staan. Ga je copypasten, dan val je buiten de uitzondering in de LGPL.

Arnoud

Schendt HTC de GPL door broncode vertraagd te publiceren?

| AE 2269 | Intellectuele rechten | 29 reacties

Een lezer wees me (dank!) op een bericht bij Freedom to Tinker waar werd gesignaleerd dat de Android-gebaseerde HTC smartphone Linux draait, maar de broncode maar moeizaam beschikbaar komt. Linux is open source (GPL versie 2) en de broncode moet dus meegeleverd worden (of er moet een schriftelijk aanbod bij zitten waar staat waar je de broncode kunt bestellen). Ene “vladyman” had HTC gevraagd hoe dit zit, en kreeg als antwoord:

Thank you for contacting HTC Technical Assistance Center. HTC will typically publish on developer.htc.com the Kernel open source code for recently released devices as soon as possible. HTC will normally publish this within 90 to 120 days. This time frame is within the requirements of the open source community.

Nou, dat lijkt me niet. Ik heb nog nooit gehoord van een tijdsbestek van 90 tot 120 dagen voordat broncodes beschikbaar komen. De GPL zelf bevat zo’n vertragingsmechanisme al helemaal niet: de broncode moet gewoon bij het product zitten.

Er zijn verschillende verklaringen waarom HTC zo reageert: ze hebben de juiste broncodes niet paraat, er zitten codes van derden in die (nog) geen GPL mogen worden, men is naar de verkeerde cursus open source compliance geweest of men werkt gewoon altijd al zo en dus nu ook, want wetten en regels kunnen natuurlijk niet het bedrijfsbeleid in de weg zitten. Of, en dan wordt het wat meer aluhoedje: men is bang dat afgifte van de broncode zal leiden tot een succesvolle jailbreak van de telefoon.

Het blijkt namelijk dat de HTC G2 wel te jailbreaken is, maar tot nu toe levert dat slechts beperkte resultaten op. De meeste hacks worden bij de eerstvolgende reset ongedaan gemaakt door een speciaal stukje firmware. Vanuit Linux zou dat stukje firmware aan te sturen moeten zijn, maar daarvoor is wel de broncode van de Linux-kernel in het apparaat nodig. En die komt “normaliter” pas na 90 tot 120 dagen beschikbaar.

Frustrerend is wel dat eigenlijk alleen de auteursrechthebbenden op de Linuxkernel hier wat tegen kunnen doen. Als ontvanger van de code kun je je niet op de GPL beroepen tegenover HTC (of T-Mobile, die het toestel uiteindelijk aan je levert) want de GPL is een licentie tussen jou en de auteursrechthebbende, niet tussen jou en T-Mobile. Ik heb me wel eens afgevraagd of het geen goed idee zou zijn om juist wél toe te staan dat jij mag procederen uit naam van Linus over jouw exemplaar van Linux.

Update (15 oktober) in de comments wijst Piet erop dat HTC de code ruim binnen die 90 dagen heeft vrijgegeven.

Arnoud

Apple App Store voorwaarden botsen met GNU GPL

| AE 2169 | Intellectuele rechten | 20 reacties

Apple weigert een GPL-gelicentieerde app voor het spel Go in haar App Store op te nemen. De Free Software Foundation heeft met Apple overlegd over hoe GPL-software kan worden gedistribueerd via de App Store van Apple, las ik bij Webwereld. De GPL-voorwaarden zouden incompatibel zijn met de eisen die Apple oplegt. Het nieuws is al… Lees verder

Kun je Creative Commons iconen in GPL applicaties stoppen?

| AE 1825 | Intellectuele rechten | 5 reacties

Via-via kwam ik op het Alientrap forum waar een interessante discussie liep over het mixen van GPL code met anders gelicentieerde code. Meer specifiek: kun je plaatjes die onder Creative Commons zijn, eigenlijk wel laten verschijnen in een programma dat onder GPL uitgebracht is? Hoofdregel van de GPL open source licentie is dat “verveelvoudigingen in… Lees verder

Rusland gaat open source gebruiken, niet teruggeven

| AE 1507 | Intellectuele rechten | Er zijn nog geen reacties

Intrigerend maar wel lastig te lezen. De Russische Federale overheid overweegt (via Google Translate) bij de selectie van software de voorkeur te geven aan vrije en open source software, zo meldde Livre afgelopen week. Waarom het dan weer Russian FOSS (FROSS) moet heten in plaats van gewoon “open source” is me niet duidelijk. Het feit… Lees verder

After-dinner dip: mijn lezing over GPLv3, 13 november

| AE 1290 | Intellectuele rechten, Iusmentis | Er zijn nog geen reacties

Op 13 november organiseert de Vereniging Informaticarecht Advocaten een studiemiddag/avond over open source software (meelezende advocaten: 5 PO punten!). Drie keer raden wie er over GPLv2 versus GPLv3 mag komen vertellen. De organisatie was zo vriendelijk mij na de borrel en het diner in te plannen, dus dat kan nog leuk worden. Arnoud