Internetrecht door Arnoud Engelfriet

Opmerkelijk: de basisbouwsteen van vrijwel alle open source blijkt nooit 100% open source te zijn geweest. Pas vorige week is de GNU C Library (glibc), de standaardbibliotheek voor Linuxapplicaties, ontdaan van een stukje antieke code die voorzien was van een licentie die niet voldeed aan de definitie van open source.

Glibc is een onderdeel van Linux dat door vrijwel elke applicatie wordt gebruikt. Deze bibliotheek implementeert alle standaardfuncties uit de programmeertaal C. De licentie is de Lesser GPL, die toestaat om applicaties te maken zonder dat die zelf ook weer open source moeten worden. Maar enkele jaren terug werd ontdekt dat er code in zat die stiekem eigenlijk niet open source was.

Nu was die code uit 1984, toen het hele idee van open source nog niet bestond. De bedrijfsjuristen van Sun Microsystems, die de code had uitgebracht, hadden dan ook hun eigen tekst verzonnen die op zich best liberaal en netjes was:

Sun RPC is a product of Sun Microsystems, Inc. and is provided for unrestricted use provided that this legend is included on all tape media and as a part of the software program in whole or part. Users may copy or modify Sun RPC without charge, but are not authorized to license or distribute it to anyone else except as part of a product or program developed by the user.

(inderdaad, tape media)

Het stukje in italics leverde het pijnpunt op: open source moet op elke mogelijke manier kunnen worden hergebruikt, niet alleen als onderdeel van een groter product. Omdat je dit stukje code van Sun niet op zichzelf mag doorverkopen, is het geen open source, en het kan dan dus ook niet opgenomen worden in glibc.

Dat is best wel een probleem voor zo’n belangrijk en essentieel stuk software. Oplossen is echter lastiger dan je zou denken, zoals Simon Phipps aangeeft, want:

1. Waar komt de code vandaan?
2. Wie heeft deze geschreven, en was die persoon in dienst bij het bedrijf of een leverancier of inhuurkracht?
3. Wie is tegenwoordig verantwoordelijk voor deze code en mag beslissen dat deze open source wordt?

In dit specifieke geval was de uploader Sun nog wel te vinden, maar moest er in een papieren archief worden gedoken om te achterhalen waar de rechten lagen. En dat werd nog eens extra moeilijk omdat de nieuwe eigenaar van Sun (Oracle) druk bezig was met afhandelen van de aankoop en alle juristen in de “geen commentaar”-modus zaten.

Alles bij elkaar duurde het meer dan een jaar om de wijziging door te voeren. Maar het ís gelukt, en dat is wel een complimentje waard.

Arnoud
Foto: GNU C Library handleiding, Free Software Foundation.

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 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

Gisteren verscheen in Computable een artikel over open source in de standaard inkoopvoorwaarden van het Rijk. Daarin werd ik geciteerd als:

Engelfriet vertelt dat bij softwareleveringen aan de overheid het eigendom vaak overgaat naar de overheid, zeker als het maatwerk betreft. Bij opensourceproducten kan dat echter niet.

en meteen kreeg ik wat bezorgde mails of ik nu echt bedoelde dat je het eigendom niet over kunt laten gaan bij opensourceproducten.

Nee, natuurlijk niet. Als je software schrijft, heb je daar het auteursrecht op en dat houd je ongeacht de licentie die je erop plakt. Je kunt dat auteursrecht gewoon overdragen aan wie dan ook.

Wat niet kan, is het eigendom overdragen op ándermans software. En dat is waar ik op doelde. Bij maatwerk wordt standaard geëist dat alle eigendom overgaat naar de klant. Maar opensourceleveranciers maken ook in maatwerk gebruik van open source. Je kunt dan niet het eigendom op het maatwerk overdragen, want het maatwerk is dan niet 100% van jou.

Je kunt alleen de rechten op jouw toevoegingen overdragen. Of dat zinvol is, weet ik niet: als het werk als geheel GPL is, dan maakt het niet heel veel uit of de auteursrechten bij jou of bij de klant liggen. De klant zal bij herdistributie de GPL moeten respecteren. Hij kan natuurlijk de bestaande GPL code eruit knippen, maar dat lijkt me niet zo zinvol.

Een interessante vraag is nog wel wat er gebeurt met een reeds verstrekte opensourcelicentie nadat het auteursrecht is overgegaan. Ik denk dat die gewoon in stand blijft, de nieuwe rechthebbende zal deze moeten respecteren.

Arnoud

In 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

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 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

Bij Wikipedia vond ik een discussie over het kunnen intrekken van een Creative Commonslicentie. De aanleiding was zo te lezen dat iemand zijn CC-foto ergens op zag duiken zonder de verplichte naamsvermelding erbij. Daar wilde hij actie tegen ondernemen, maar heeft dat veel nut als de foto als Creative Commons online staat? De inbreukmaker kan immers achter zijn rug om snel de naam erbij zetten en dan heel onschuldig kijken.

Een oplossing kan zijn gauw je foto overal verwijderen (of in ieder geval de Creative Commonslicentievermelding weghalen) en dan pas gaan klagen. Het juridische idee hierachter is namelijk dat de Creative Commonslicentievermelding (Creativecommonslicentievermelding? Creative-Commonslicentievermelding? Argh.) een aanbod is. Als je dat aanbod intrekt voordat de wederpartij het heeft kunnen aanvaarden, dan is het niet meer geldig.

Ene Wimmel vat mij samen:

[A]ls ik een aanbod doe een afbeelding aan jouw te licenseren onder bijvoorbeeld CC-BY, kan ik dat aanbod intrekken zolang jij dat nog niet hebt aanvaard. Heb je het wel aanvaard (en gebruik je die afbeelding dus onder de CC-BY voorwaarden), kan ik dat niet intrekken. Als een afbeelding op wikipedia zelf gebruikt wordt, kan ik dat dus ook niet stoppen. Maar wel verdere verspreiding voorkomen, waardoor het niet meer aan de doelstellingen van wikipedia voldoet.

Op zich klopt dat helemaal. Er is echter één angel hier: wat gebeurt er als iemand de foto plus de Creativecommons-licentievermelding (argh) van een derde ontvangt en dan mijn aanbod aanvaardt, terwijl ik net bezig ben overal die vermeldingen te verwijderen? Dan zit ik er toch gewoon aan vast, lijkt me zo. Ik heb het aanbod gedaan, en iemand die dat aanbod aanvaardt, mag de foto verspreiden. In mijn licentie staat dat die iemand dan alle ontvangers erop moet wijzen dat de Creative Commons-licentievermelding (argh) van toepassing is. Daarmee nemen al die ontvangers ook kennis van mijn aanbod.

Oftewel: ik kan mijn aanbod wel willen intrekken, maar zolang er ook nog maar één kopie ergens legaal online staat, is het altijd mogelijk de creativeCommonsLicentieVermelding (ARGH) alsnog te aanvaarden. Ik kan van een licentienemer niet verlangen dat hij de foto offline haalt, of dat hij die ARGH intrekt. Ik kan het vriendelijk vragen maar hij is niet verplicht mee te werken zolang hij zich netjes aan de voorwaarden uit de ARGH houdt.

En noodzakelijk gevolg van dat netjes de voorwaarden naleven is dat anderen mijn aanbod te zien krijgen en het daarmee kunnen aanvaarden. Ik krijg dus nooit meer de kans om tijdig aan hen te melden dat het aanbod is ingetrokken.

Arnoud

Een lezer mailde me:

Wij gebruiken al een flink aantal jaren een bepaald softwarepakket voor onze bedrijfsvoering. De leverancier heeft het onderhoud vorig jaar gestaakt, en dat begint nu een probleem te worden. We zouden nu graag een ander wat noodzakelijk onderhoud laten uitvoeren, en een paar nieuwe features inbouwen. Maar kan dat zomaar?

Nee, dat kan niet zomaar. De auteursrechten op het pakket liggen nog steeds bij die leverancier, en dat betekent dat je zijn toestemming nodig hebt om het pakket te mogen wijzigen. En dat gaat geld kosten, zeker als je ook nog eens de broncodes wilt hebben. In de meeste gevallen vermeldt het contract niets over de mogelijkheden van onderhoud nadat de leverancier ondersteuning heeft beëindigd.

Het is wel toegestaan dat de nieuwe ontwikkelaar de API’s en interfaces achterhaalt en op basis daarvan eigen modules maakt. Daarvoor heb je geen medewerking van de huidige leverancier nodig. Ik hoop voor je dat de software dergelijke interfaces heeft op een eenvoudig te achterhalen manier.

Er is bar weinig jurisprudentie op dit gebied. Als het gaat om maatwerksoftware, dan is er het arrest Van Genk/De Wild kun je dan aanspraak maken op de broncodes om zo onderhoud te verrichten. Wel moet het contract dan bepalen dat je de volledige eigendom krijgt van de maatwerksoftware (een gebruikelijke bepaling overigens). Maar bij standaardsoftware kun je het vergeten.

Er zijn genoeg bedrijven die dan maar de code afschrijven en een nieuwe codebase laten bouwen waarbij ze wel de gewenste rechten hebben. Steeds meer kiezen daarbij voor open source, omdat je dan per definitie dit probleem niet hebt.

Arnoud

Al eerder gemeld, maar nu is het definitief: de nieuwe open source licentie voor open en vrije databanken. Databanken bevatten vooral feitelijke data, en er komt zelden creativiteit aan te pas. Bestaande open source licenties zijn eigenlijk vooral bedoeld voor software, en ook de Creative Commons-licenties passen niet goed bij databanken. Vandaar deze nieuwe licentie.

De licentie noemt expliciet drie rechten: auteursrecht, databankenrecht en het recht op toegang tot de databank. Recht op toegang? Ja, wie een database publiceert, of algemener gezegd wie een dienst aanbiedt met een server, kan op grond van zijn eigendomsrecht op die server regels stellen over het gebruik van die dienst. Daar hoef je uiteindelijk helemaal geen intellectueel eigendomsrecht voor te hebben. Slim gevonden dus.

Ik heb al een paar keer (deel 1, deel 2, deel 3) aandacht besteed aan de vraag hoe het zit met afgeleide werken, kaarten die gemaakt worden op basis van de OpenStreetmap-databank. Ik kom volgende week met deel 4 trouwens, beloofd.

De ODBL is speciaal geschreven voor dit soort situaties. De definities bevatten de term “Produced Work”, en die luidt als volgt:

a work (such as an image, audiovisual material, text, or sounds) resulting from using the whole or a Substantial part of the Contents (via a search or other query) from this Database, a Derivative Database, or this Database as part of a Collective Database.

En het is natuurlijk de bedoeling dat zo’n Produced Work net zo vrij beschikbaar is als de oorspronkelijke brondatabase. Vandaar:

If You Publicly Use a Derivative Database or a Produced Work from a Derivative Database, You must also offer to recipients of the Derivative Database or Produced Work a copy in a machine readable form of:

a. The entire Derivative Database; or
b. A file containing all of the alterations made to the Database or the method of making the alterations to the Database (such as an algorithm), including any additional Contents, that make up all the differences between the Database and the Derivative Database.

Onder “Use” wordt dan weer verstaan “alles wat normaal onder auteursrecht of databankenrecht valt, maar in ieder geval kopiëren, verspreiden, openbaar maken etcetera”. En “publicly” wil hier zeggen “naar personen die niet voor jou werken”.

Kort gezegd: wie een kaart maakt van een ODBL-databank, en deze kaart online aanbiedt aan het publiek, moet de databank erbij doen inclusief alle wijzigingen die hij op de databank heeft doorgevoerd.

En dat geldt zelfs als blijkt dat je helemaal geen recht hebt op grond van je auteurs- of databankenrecht om zoiets te eisen: het is immers een gebruiksvoorwaarde om toegang te krijgen tot de site. Op zich is dat slim bedacht, hoewel ik me afvraag in hoeverre dat ook echt werkt. Tegenover de persoon die dit accepteert en de site bezoekt lijkt het me wel rechtsgeldig. Die gaat het contract aan, en kan daar in principe aan gehouden worden. Uit het XS4All/Ab.Fab-arrest van de Hoge Raad blijkt dat je als eigenaar van een site in principe elke voorwaarde aan het gebruik mag stellen die je wilt. Maar tegenover derden? Dat kan nog een hele interessante worden.

Arnoud

En daar waren we dan weer met deel drie van de vraag welke rechten er op de databank van het vrijelandkaartenproject Openstreetmap zitten. Al in deel 1 bleek dit een lastige kwestie. Want: wat wordt nu precies waarvan afgeleid? (Waar vanaf geleid? Waar van afgeleid? Argh.) In deel 2 leek de tussenconclusie te zijn dat de kaarten gemaakt uit de OSM-database een afgeleid werk lijken te zijn van de stylesheet.

Kaarten uit OpenStreetmap worden namelijk gemaakt door een grote hoeveelheid GPS-coördinaten in een databank te stoppen en te voorzien van verbindingen die labeltjes krijgen met bijvoorbeeld “fietspad” of een straatnaam. Op basis van die databank kun je dan kaarten genereren voor elk oppervlak en op elke schaal die je wilt. Die stylesheet bepaalt welke kleuren en dergelijke er in die kaarten terechtkomt. Een voorbeeld uit de OSM-documentatie:

Het lijkt me dus zeker verdedigbaar dat een stylesheetmaker een auteursrecht kan claimen op de stijlkeuzes. Maar is een kaart een afgeleid werk van de stylesheet?

Ik vermoed van wel, al zal het afhangen van welke elementen uit de stylesheet zelf in de kaart terechtkomen. Want een afgeleid werk moet wel op een of andere manier concrete beschermde elementen uit het werk overnemen waar het van afgeleid is. Nu hoeft dat niet letterlijk - een toneelstuk is een afgeleid werk van een boek bijvoorbeeld, zelfs als de spelers geen woord letterlijk zeggen zoals het in het boek staat. In die situatie zijn zaken als het plot, de karakters, uiterlijk, verloop en dergelijke van het verhaal overgenomen, en dat is al genoeg.

Maar: wat neem je over uit de stylesheet in de kaart die uiteindelijk gegenereerd wordt? De kleurkeuzen in ieder geval, en de kleur en positionering van teksten zo te zien ook. De derde kaart uit dit voorbeeld heeft bijvoorbeeld veel duidelijker aanduidingen van plaatsnamen dan de andere drie.

Opvallend (voor mij dan) is dat ik geen enkele stylesheet kan vinden waar een expliciete licentie bij staat. De meest gebruikte stylesheet is Mapnik maar zelfs daarvan zie ik nergens wat daarmee mag. Ik neem aan dat ze onder dezelfde Creative Commonslicentie horen te vallen als de rest van het project, maar het staat nergens.

Nou, en nu eens inlezen in het databankenrecht zoals dat geldt voor kaarten.

Arnoud

Google Chrome, de minimalistische browser van het advertentie- en zoekmachinebedrijf bevat veel open source. Recent bleek de browser echter ook de open source FFMPEG videosoftware te bevatten om zo filmpjes op webpagina’s beter te kunnen afspelen. En dat is opvallend, omdat FFMPEG onder de LGPL 2.1 open source licentie is uitgebracht. De verhouding tussen LGPL 2.1 en de MPEG-octrooilicenties is op zijn zachtst moeilijk te noemen.

Wie MPEG-functionaliteit aan zijn product wil toevoegen, heeft octrooilicenties nodig. Organisaties als MPEG-LA verstrekken dergelijke licenties, uiteraard tegen betaling. Daarbij geldt de eis dat je alleen voor je eigen producten kunt betalen: maakt de klant een kopie, dan moet die zelf een nieuwe licentie komen halen. Iets dat moeilijk ligt bij open source software, omdat het daar juist de bedoeling is dat klanten het ook weer kopiëren en verspreiden.

De LGPL bevat namelijk een aantal clausules die bedoeld zijn voor deze situatie. De belangrijkste is artikel 10:

You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License.

Oftewel: u mag anderen geen beperkingen opleggen op de rechten die u zelf krijgt van de LGPL. Deze clausule maakt het, zo werd altijd aangenomen, erg moeilijk om open source te gebruiken als daarvoor betaalde octrooilicenties van derden nodig zijn. Maar, wat zegt nu Google’s open source program manager Chris DiBona:

(a) Party A gives Party B a library licensed under the LGPL 2.1
(b) Party B gets a patent license from Party C
(c) Party B then distribute the library under the LGPL 2.1

This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 for a license that does deal with this situation). Under the LGPL 2.1, the fact that Party B may have a patent license with an unrelated third-party is irrelevant as long as it doesn’t prevent Party B from granting people the rights LGPL 2.1 requires they grant them (namely, only those rights it in fact received from Party A).

Oftewel (ik krijg er ook hoofdpijn van): het “further restrictions” gaat om restricties die de verspreider van de software oplegt, terwijl de MPEG-licentie een restrictie van een derde is. Google kan er niets aan doen dat derden een betaald licentieprogramma hebben op de software die zij van FFMPEG hebben gekregen.

Meer to-the-point is DiBona’s collega Daniel Berlin verderop:

Nowhere in the LGPL 2.1 are we required to grant you patent rights that we may have.

Dat is op zijn minst een originele interpretatie te noemen. In artikel 11 van de LGPL staat namelijk:

If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.

De gebruikelijke interpretatie van dat voorbeeld is dat een octrooilicentie gratis voor de hele wereld moet zijn, wil de licentienemer in staat kunnen zijn de software onder LGPL te mogen verspreiden. Maar Google komt nu met de creatief gevonden interpretatie dat de MPEG-licentie haar niet verbiedt de software onder de LGPL te verspreiden. Helaas krijgen afnemers geen MPEG-licentie, maar dat is niet verplicht volgens de LGPL.

In Google’s visie moet de MPEG-licentie zeggen “U dient ervoor te zorgen dat uw afnemers geen kopieën maken van de MPEG-software” voordat haar verspreiding de LGPL zou overtreden. Maar dat doet deze niet - er staat alleen “u moet betalen per kopie die u verspreidt”. En zolang Google dat maar braaf doet, is er weinig aan de hand. Chrome-gebruikers mogen de MPEG-functionaliteit gebruiken. Alleen, als ze kopieën gaan maken is dat geheel op eigen risico.

Helaas loopt de discussie een beetje snel dood nadat Håkon Lie zich erin mengt met terechte en kritische vragen - Lie is van Chrome-concurrent Opera. Het is namelijk een zeer fundamentele vraag.

Persoonlijk zou ik het Google-standpunt niet snel durven verdedigen, hoewel ik er niet meteen grote gaten in kan schieten. Het is evident de bedoeling van de LGPL om dit soort uitzonderingsposities tegen te gaan. Maar aan de andere kant, er waren hele lappen tekst GPLv3 nodig om het op te schrijven dus het staat er niet expliciet. En als de bedoeling er niet staat, heeft over het algemeen de licentiegever pech.

Arnoud