Tag: Gpl

About Gpl

Subscribe Feeds

Spionagemalware Duqu schendt GPL

Geplaatst op in Intellectuele rechten, Iusmentis, 25 reacties

duqu-gpl.pngSjongejongejonge, wat zullen de Duqu-makers daar wakker van liggen: de beruchte spionagemalware Duqu bevat open source-code die onder de ‘virale’ licentie GPL vallen, las ik bij Webwereld. Duqu blijkt open source blokken te bevatten van derden en die licentie te negeren.

Tsja, wat moet je met zo’n berichtje? Ik noem het maar ‘grappig’, wanthet is ergens wel grappig om te denken dat malwaremakers die economische spionage en mogelijk zelfs hardwarevernielingen gaan veroorzaken een opensourcelicentie zullen respecteren. Gelukkig dus maar dat er “This post is for fun, don’t take it too seriously,” bij staat.

En dan maar doorpakken op een stukje irritatie van mij: je kunt in situaties als deze de GPL niet schenden, want de GPL is niet bindend als je je er niet aan houdt. Je pleegt auteursrechtinbreuk, natuurlijk, maar eisen dat iemand de GPL naleeft is onmogelijk. Tenzij iemand gezégd heeft de GPL te willen naleven en vervolgens dat blijkt niet te doen.

In maart hadden we nog een discussie over GPL bij tablets, waarbij de discussie was of je als koper de GPL kon afdwingen. Dat kan (via een derde-begunstigde discussie) maar wél moet dan eerst vaststaan dat de verkoper zich aan de GPL heeft gebonden.

Het enkele feit dat iemand GPL-licensed code verspreidt, is nog geen bewijs dat hij zich aan de GPL heeft geconformeerd.

Arnoud

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

Geplaatst op in Intellectuele rechten, 61 reacties

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

Zijn WordPress themes GPL?

Geplaatst op in Intellectuele rechten, 10 reacties

wordpress-bible.pngEen lezer vroeg me:

Alweer een tijdje geleden speelde een discussie over het Thesis theme voor WordPress. Dat is een systeem voor layouts en uitbreidingen op het WordPress blogsysteem, dat eerst onder een gesloten (niet-open source) licentie beschikbaar was. WordPress zelf is GPL, en de auteurs daarvan eisten dan ook dat Thesis ook GPL moest worden. Eerst wilde Thesis dat niet, maar na na flink wat discussie hebben ze het uiteindelijk toch GPL gemaakt. Maar had dat nou echt gemoeten?

De open source licentie GPL eist dat “afgeleide werken”, bij ons “verveelvoudigingen in gewijzigde vorm” van hun code alleen maar verspreid mag worden onder diezelfde GPL. Je kunt geen afgeleid werk verspreiden onder een andere licentie. (Maar je hóeft je code niet te distribueren als je dat niet wil; wie dus voor zichzelf GPL code aanpast hoeft niets te delen.)

De vraag wat een afgeleid werk precies is, is al zo oud als de GPL zelf. De discussie over plugins op GPL code hebben we al een paar keer gehad, maar die voor themes nog niet.

Een theme is voor mij net wat anders dan een plugin. Een plugin is nieuwe code die inhaakt op de originele code, en de functionaliteit daarvan uitbreidt. Ik denk dat je een plugin dan ook wel als een afgeleid werk kunt zien, hoewel er in de GPL een uitzondering staat voor

If identifiable sections of [the modified] work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

WordPress vindt dat dit een uitgemaakte zaak is: WordPress extensies en themes zijn altijd afgeleid van WordPress zelf, hoewel ze qua onderbouwing niet verder komen dan “Drupal zegt het veel beter dan wij” en Drupal niet meer zegt dan “Ja dat is zo”.

Als je kijkt naar hoe themes gebouwd worden, dan zie je dat ze een vrij standaard structuur volgen om de layout te definiëren en op bepaalde punten routines uit WordPress aanroepen (“plak hier de titel van de blog”, “doe dit voor tien blogberichten”, “zet hier de datum, in formaat mm-dd-jj”) zodat de bezoeker de juiste informatie in de juiste layout te zien krijgt. Ik zie niet hoe je dat kunt zien als een verveelvoudiging van de WordPress-code zelf. Het aanroepen van een functie maakt je code nog niet “afgeleid”.

Daar komt bij dat eind vorig jaar het Europese Hof van Justitie bepaalde dat user interfaces géén deel zijn van de copyright op de software zelf (en een theme is de realisatie van een interface). Toegegeven, dat ging over de vraag of het kopiëren van de interface een auteursrechtschending was, maar als het auteursrecht op de software zich niet uitstrekt tot de interface, waarom zou het dan wél gelden voor andermans interface?

Ik denk dan ook dat je pas van een afgeleid werk kunt spreken als de theme code kopieert of diep ingrijpt in WordPress zelf, bijvoorbeeld door het vervangen van core code. Een ‘gewoon’ theme is geen afgeleid werk.

Arnoud

Zitten fabrikanten Android zonder GPL-distributierecht voor Linux?

Geplaatst op in 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?

Geplaatst op in 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?

Geplaatst op in 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

Geplaatst op in Intellectuele rechten, 20 reacties

apple-app-store.pngApple 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 wat ouder, maar vakantie is er om oud nieuws in te halen, niet?

Het gaat volgens de vrijesoftwarejongens vooral om het artikel uit de App Store-voorwaarden dat zegt dat je de software op maximaal vijf apparaten mag installeren. Dat is een probleem voor de GPL: die eist dat iedere ontvanger het recht krijgt om de software zo veel & vaak als men wil te installeren en verder te verspreiden.

Ars Technica wijst er echter op dat de EULA van Apple een specifieke uitzondering voor open source bevat:

You may not copy (except as expressly permitted by this license and the Usage Rules), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, or create derivative works of the Licensed Application, any updates, or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law or to the extent as may be permitted by the licensing terms governing use of any open sourced components included with the Licensed Application).

Vertaling: er mag niets tenzij wij zeggen van wel – behalve als er een opensourcelicentie op de software zet, want dan moet u daar lezen wat er mag.

Maar daar zet de FSF weer tegenover dat elders staat

The Usage Rules shall govern your rights with respect to the Products, in addition to any other terms or rules that may have been established between you and another party.

Oftewel: oh ja, maar ondanks dat gelden onze gewone regels toch boven alles.

Persoonlijk lijkt dit me een al te strikte lezing van de Apple EULA, maar goed, formeel staat het er inderdaad.

Arnoud

Noord-Koreaanse Linux schendt GPL?

Geplaatst op in Intellectuele rechten, 8 reacties

north-korea-red-star-linux.pngIn een artikel over Noord-Korea’s Red Star Linux meldde Webwereld:

Zoals valt te verwachten wordt de broncode niet gedeeld, en schendt de Noord-Koreaanse staat dus de GPL-licentie die aan Linux gekoppeld is

Waarom dat te verwachten was, ontgaat me. Maar ik vroeg me toen wel af, kan de GPL in Noord-Korea wel geschonden worden? In ieder geval wat Linux betreft dan.

Bestaat auteursrecht in Noord-Korea? Jazeker: de North Korea Copyright Act (vertaling door KoryoPAT). Software wordt genoemd (artikel 9 sub 8).

Geldt dat ook voor plutocratische imperialistenbuitenlanders? Jazeker, de Democratische Volksrepubliek Korea is lid van de Berner Conventie sinds 2003. En daarmee erkent het land buitenlandse auteursrechten.

Dat biedt dus hoop voor Linus en zijn medeprogrammeurs. Maar in de wet op auteursrecht op software staat een opmerkelijke bepaling (artikel 2):

Registration of software is the prime process in the protection of software.

Software wordt dus alleen beschermd na registratie. Ook als de software uit het buitenland komt:

The copyright of a software that has been developed by a foreign legal person or an individual and registered first in the DPRK shall be protected by this law.

Nu is dat een probleem, want de Berner Conventie verbiedt registratie als eis alvorens auteursrechten toe te kennen. Je zou dus als Linux-auteursrechthebbende in een Noord-Koreaanse rechtbank op grond van de Berner Conventie kunnen eisen dat je auteursrechten direct worden erkend, ook zonder registratie. Ik ben heel benieuwd wat de reactie zal zijn.

Verder staat er nog in artikel 35 een leuke bepaling die heel relevant voor open source lijkt te zijn:

One may copy and use a software without the permission of the copyright holder in the following cases; … * When the software has been distributed free of charge.

Linux wordt zonder vergoeding verspreid en zou daarmee onder deze uitzondering kunnen vallen. (Natuurlijk, je mag geld vragen voor Linux maar er staat “has been distributed” en dat is zeker het geval bij Linux.) In feite staat hier dat het concept van open source niet kan bestaan in Noord-Korea, want alle software die eenmaal legaal gratis in omloop is gekomen, valt onder deze uitzondering.

Alles bij elkaar lijkt de conclusie dat Red Star de GPL schendt ietwat prematuur.

Arnoud

Kun je Creative Commons iconen in GPL applicaties stoppen?

Geplaatst op in Intellectuele rechten, 5 reacties

alientrap.pngVia-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 gewijzigde vorm” of ook wel “afgeleide werken” alleen mogen worden verspreid onder diezelfde GPL voorwaarden. Hoe je precies een “afgeleid werk” herkent, is al jaren een lastige vraag voor juristen. Er zijn allerlei theorieën, variërend van “alleen gewijzigde bestanden” tot “alles dat je meelinkt” tot zelfs “alles waarbij de intentie is dat het nauw samenwerkt”. Ik besprak dit een tijd geleden in de context van plugins (Joomla of phpBB).

Het bijzondere in deze discussie is dat het nu eens niet gaat over combinaties van software met software, maar over combinaties van software met data zoals plaatjes of muziek. Kun je bijvoorbeeld een icoon laten verschijnen in de interface van een GPL programma dat zelf onder Creative Commons uitgebracht is? Of een helptekst uit Wikipedia halen?

De discussie werd kernachtig samengevat als:

Whether it is allowed to mix licenses in such a way has not been decided in any court yet, so both views may be possible. However, think about this: if it WERE allowed to mix GPL code with non-GPL data, why wouldn’t it be allowed to link GPL code against non-GPL libraries (and vice versa)? The library is just as dynamically loaded as the content. Yet still it is the common legal opinion that GPL code can NOT be linked against non-GPL libraries. The engine loads the data just like it loads its libraries (DLLs). Why should these be considered different, legally?

Het verschil zit hem niet zozeer in het laden, maar in het gebruik van de materialen nadat deze geladen zijn. Code wordt uitgevoerd, en mixt daar met de code die al geladen is. Een plaatje wordt geladen en doorgegeven, dat blijft in principe geïsoleerd van de code die aan het draaien is. Het lijkt me moeilijk om te betogen dat het plaatje op welk moment dan ook onderdeel van de applicatie is.

De enige mogelijkheid die ik zie is dat alles dat in de context van die applicatie op het scherm verschijnt, daar onderdeel van is. Een icoontje verschijnt als onderdeel van de knoppenbalk, en een kaart voor een spel verschijnt in het gebied waar je met je avatar rondloopt. Maar dan is de tekst die ik nu in dit editvenster typ, ook een afgeleid werk van mijn blogsoftware WordPress. En de webpagina’s die in mijn Firefox verschijnen zijn afgeleide werken van die browser. Nee, dat wil er bij mij niet in.

Het zou misschien anders worden als de plaatjes echt als onderdeel van de applicatie worden geïntegreerd, bv. zoals Windows-applicaties het icoontje voor op de desktop met zich meedragen. Dat icoon zit echt fysiek in de applicatie zelf, en zou dus als onderdeel daarvan kunnen worden gezien. Maar een icoon dat los in een map op de harde schijf staat? Nee.

Arnoud

De (il)legaliteit van audio/video codecs

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 17 reacties

media-player-classic-video-audio-codec.pngOp het NedLinux forum mailde men mij over een interessante vraag:

De vraag is alleen (wat me bezig houdt), in hoevere is de codecs die niet officieel aangeschaft zijn illegaal ? Ik bedoel…. hoe is dat geregeld in Nederland ? Ik zie dat Frankrijk al erg moeilijk doet als je VLC gebruikt of Mplayer.

Een codec is een stuk software waarmee audio of video ge(de)codeerd kan worden. Wie alleen naar de radio luistert en DVD’tjes koopt in de winkel en die afspeelt op zijn DVD-speler, heeft daar niet zo veel mee te maken. Maar als je muziek en films gaat downloaden dan kom je allerlei rare formaten tegen en moet je de bijbehorende codecs gaan installeren. Sommige codecs zijn makkelijk te vinden, voor anderen moet je op vage Russische sites rondspeuren.

Maar mag dat nou zomaar? Dat is een moeilijke vraag, want er spelen een heleboel aspecten mee.

Auteursrecht op de codec<br/> Ten eerste is er de vraag of die codec zelf (de DLL dus) wel legaal verspreid mag worden. Er zijn gevallen genoeg bekend van simpelweg gestolen codecs: mensen kopen software waar codecs bij zitten en zetten die gewoon op internet. Zo zijn er complete collecties met Windows Media A/V codecs, die echter gewoon uit de C:WindowsSystem directory van iemands Windows-PC afkomstig zijn. Ook enkele Quicktime-codecs zouden op die manier verkregen zijn.

Wordt een codec op die manier verspreid, dan is het niet toegestaan om die te downloaden en te gebruiken. De thuiskopie-uitzondering geldt niet voor software en dus ook niet voor codecs. Dat je toevallig ergens een Windows-licentie hebt liggen, verandert daar niets aan lijkt mij; die hoort bij jouw aangeschafte Windows en kun je niet zomaar van toepassing verklaren op alle Microsoft-software die je downloadt.

Octrooien op de algoritmen<br/> Ten tweede implementeren veel codecs namelijk beschermde algoritmen. De octrooihouders hebben geen licenties gegeven voor die codecs, zodat vrije verspreiding niet zomaar mogelijk is. Voor persoonlijk niet-commercieel gebruik hoef je je geen zorgen te maken, octrooi-inbreuk is alleen mogelijk als je commercieel bezig bent.

Ik hoor nu een aantal mensen “jamaar softwarepatenten zijn niet geldig in Europa” denken. Nou is dat een heel grijs gebied, maar als we het hebben over audio/video-coderen zit je toch aan de witte kant van dat gebied. Het manipuleren van audiovisuele signalen is een vorm van technologie en valt daarmee onder de octrooiwetgeving. Er zijn dan ook genoeg octrooien op dit gebied, die in rechtszaken ook gewoon overeind blijven. Het verkopen van audio/video-afspeelsoftware of apparaatjes met zulke codecs erin betekent dus dat je een octrooilicentie moet kopen.

En ja, open source codecs hebben daar een probleem. Want de meeste van die octrooilicenties voorzien niet in de mogelijkheid dat de licentienemer de codec gaat doorleveren aan derden die ook weer kopieën van de codecs gaan maken. En de GPL heeft weer een bepaling dat die octrooilicentie daar wél toestemming voor moet geven, anders mag je de software in het geheel niet verspreiden. Een soort van Mexican standoff dus.

Kopieerbeperkingen omzeilen<br/> Ten derde willen sommige codecs nog wel eens kopieerbeperkingen negeren. Het beroemdste voorbeeld is DeCSS, waarmee de beveiliging op DVD-inhoud omzeild kan worden. Nu is dat strikt gesproken geen codec, maar als je een codec voor DVD content wilt gebruiken, kom je niet ver zonder deze functionaliteit.

Het omzeilen of uitschakelen van “effectieve” kopieerbeveiligingen is verboden, net als het verspreiden van hulpmiddelen die daar speciaal voor gemaakt zijn. Volgens een Finse rechtbank zou DVD-beveiliging CSS niet effectief zijn omdat het zo eenvoudig te breken bleek. Daarom was DeCSS niet verboden.

Oh ja, dat verbod geldt zowel in Amerika (onder de DMCA) als bij ons in Europa onder de Auteursrechtenrichtlijn en artikel 29a Auteurswet.

Sommige codecs voor Windows Media (WMV/WMA) omzeilen de DRM-functies die Microsoft er in gebouwd heeft. Dat was in één geval in ieder geval aanleiding voor Microsoft om een rechtszaak te beginnen, maar een jaartje later trokken ze die weer in. Overigens zonder uit te leggen waarom, dus dat schiet niet erg op.

Er is dus niet een duidelijk ja/nee-antwoord te geven op deze vraag. Het hangt af van de codec, waar deze vandaan komt en welk algoritme er gebruikt wordt. Codecs die bv. bij Fluendo te koop zijn, mag je legaal gebruiken. Die zijn door het bedrijf zelf ontwikkeld, zodat je voor auteursrechtschendingen niet bang hoeft te zijn. Die codecs komen ook met een octrooilicentie en omzeilen geen kopieerbeveiligingen.

Ook de Ogg Vorbis- en Theora-codecs zijn legaal, om dezelfde redenen. Al heeft niemand ooit kunnen bewijzen dat deze technieken octrooivrij zijn.

Download je van voornoemde vage Russische site een gratis exemplaar van de commercieel verkochte DivX-codecs, dan zit je in het donkergrijs tot zwarte gedeelte van dat grijs gebied. En heb je waarschijnlijk ook een Trojan of drie op je PC.

Arnoud