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
De interpretatie van Google lijkt me toch niet zo raar.
Waar het om gaat is of Google door het nemen van een octrooilicentie bij een derde partij de verantwoordelijkheid heeft om deze door te geven aan iedereen die de source code download.
Ongeacht of de licentie dit verlangt lijkt me dit zeer onredelijk. Je kunt van Google niet verlangen dat zij de octrooilicentie betalen voor iedereen die FFMPEG wil gebruiken ??? want daar komt het op neer. Iedereen die FFMPEG legaal wil gebruiken zal het via Google downloaden.
Google zegt dat de octrooilicentie die zij hebben genomen alleen is voor de verspreiding van Chrome ??? de closed source browser. Op zich lijkt me dit te mogen omdat de LGPL het toestaat om de library op te nemen in een closed source programma. De enige voorwaarden hiervoor zijn punten 1 en 2 van de LGPL.
Tevens wordt Google door de LGPL verplicht om de gebruikte source code van FFMPEG te verspreiden. Dit is een aparte distributie welke los staat van de distributie van Chrome. Google zegt geen octrooilicentie te hebben voor het verspreiden van deze source code en hoeft deze dus ook niet door te geven.
Dit is gelijk aan de oorspronkelijke ontwikkelaars van FFMPEG. Deze hebben ook geen octrooilicentie en geven deze dus ook niet door. Waarom zou Google dit dan niet mogen?
Je krijgt anders ook wel een erg onmogelijke situatie: als je geen octrooilicentie neemt mag je FFMPEG van de octrooihouders niet gebruiken, maar als je wel een octrooilicentie neemt mag je FFMPEG niet gebruiken volgens de LGPL.
Die “onmogelijke situatie” is wat de GPL auteurs voor ogen hadden: men wilde voorkomen dat de ene partij wel en de andere partij niet de software kan gebruiken en verspreiden. Iedereen moet even veel rechten hebben.
In GPLv3 (en dus ook in LGPLv3) is dit als volgt opgelost:
Oftewel: als u van een licentie profiteert, moet u anderen dat ook laten doen of zelf de licentie opgeven.
Ik denk dat we het beste de LGPLv3 hier buiten beschouwing kunnen laten omdat FFMPEG onder LGPLv2 is verspreid en mogelijkerwijs nooit onder de LGPLv3 verspreid zou kunnen worden.
Ook denk ik dat we er van uit kunnen gaan dat de onmogelijke situatie niet iets is waar de ontwikkelaars van FFMPEG bewust voor gekozen hebben. Het lijkt me niet logisch om bewust code onder LGPL vrij te geven zodat dat niemand het kan gebruiken.
De grootste verwarring komt waarschijnlijk door dat de meeste mensen de GPL gewend zijn. De LGPL lijkt voor een groot gedeelte erg op de GPL, maar is op een paar punten toch duidelijk heel anders. De LPGL voorziet namelijk heel duidelijk in een scheiding tussen:
a) Het “gecombineerde werk”, welke niet onder de LGPL valt en b) De “externe bron code” welke wel onder de LGPL valt.
Ook het voorbeeld uit de GPLv3 hierboven is iets wat alleen op de “externe bron code” zou slaan en zeker niet op het “gecombineerde werk”.
Het “gecombineerde werk” – in dit geval Chrome – kan extra rechten en plichten met zich meebrengen zonder dat dit invloed heeft op de “externe bron code”.
Mijn grootste vraag is: “Wat koop je eigenlijk wanneer je een MPEG-licentie neemt?” Wat is de reikwijdte van de MPEG-patenten als je de uitsluiting op “computerprogramma’s als zodanig” in het Europese octrooirecht in aanmerking neemt? Ik kan me herinneren dat de ontwikkelaars van de LAME mp3-encoder alleen de broncode publiceerden, onder het motto “Dan hebben we een goede verdediging tegenover octrooiadvocaten.”
Er is goede argumentatie te vinden dat publicatie van broncode en algoritmen niet onder de reikwijdte van een octrooi kan vallen: De octrooiaanvrager had deze informatie in zijn aanvraag openbaar horen te maken. Een los objectcodebestand is nog geen “Computerge?mplementeerde uitvinding”, daarvoor moet het gecombineerd worden met geschikte hardware…
Mijn conclusie is dat je met zo’n licentie een recht koopt om de software te draaien op je eigen systeem en, afhankelijk van de voorwaarden, je klanten het recht geeft de software te draaien. Verspreiding van software valt (naar mijn mening) buiten de reikwijdte van het Europese octrooirecht.
Als je dan artikel 10 volledig leest:
leid ik af dat Google de door FFMPEG gegeven rechten niet mag beperken.Dan blijft artikel 11 over; problemen daar kunnen mijns inziens opgelost worden door de licentieovereenkomst correct te formuleren, wat dat betreft kan Niels het bij het rechte eind hebben.
Een MPEG octrooi bevat geen broncode omdat dat helemaal niet hoeft: een beschrijving moet alleen zodanig duidelijk en volledig zijn dat een vakman aan de hand daarvan de uitvinding kan toepassen. Bovendien zou je MPEG ook kunnen toepassen met specifieke hardware; het is alleen maar een implementatie om dat te doen met een general purpose processor waarop MPEG software draait, en een octrooibeschrijving hoeft nu eenmaal niet alle mogelijke implementaties op te sommen.
Zelfs al zou gelden dat MPEG software zelf geen directe inbreuk op een MPEG octrooi maakt, dan geldt in ieder geval wel dat een computer waarop de MPEG software draait wel inbreuk maakt op een MEPG octrooi, en dat de computer MPEG-octrooi inbreukmakend wordt gemaakt door daar de MPEG software op te laten draaien. In zo’n situatie geldt Artikel 73 Rijksoctrooiwet 1995: een octrooihouder kan zijn octrooi ook inzetten tegen personen die bedrijfsmatig voor het toepassen van de uitvinding wezenlijke bestanddelen verschaffen. In het onderhavige geval is de MPEG software zo’n wezenlijk bestanddeel, en het is dan ook terecht dat Google een MPEG octrooilicentie heeft genomen.
@Leo Steenbeek:
Ik kan artikel 2 van de Rijksoctrooiwet moeilijk anders lezen “wiskundige methode” of “computerprogramma als zodanig”. Aangezien deze vraag voor de rechter ligt stel ik voor uitspraak en argumentatie af te wachten.Laten we Artikel 73 als uitgangspunt nemen, betekent dat dat Google een licentie nodig heeft voor het verspreiden van broncode, voor de objectcode? Aan welke eisen moet de octrooilicentie dan voldoen om aan de eisen van de LGPL 2.1 te voldoen?
@Mathfox: je zegt “Aangezien deze vraag voor de rechter ligt stel ik voor uitspraak en argumentatie af te wachten.” Welke vraag en bij welke rechter?
De Grote Kamer van Beroep van het EOB is geen rechter en die gaat niet zeggen of verspreiding van broncode wel of niet onder een claim kan vallen. Het EOB gaat alleen over octrooieerbaarheid, niet over inbreuk.
Google zegt dat zij geen licentie heeft voor het verspreiden van de broncode. De licentie die zij genomen heeft is alleen voor het “gecombineerde werk” – Chrome. Dit heeft twee kanten.
Allereerst kan Google dus zonder problemen aan de LGPL voldoen. Aangezien zij geen licentie heeft voor het verspreiden van de broncode hoeft zij het gebruiksrecht dat een dergelijke licentie geeft ook niet aan alle gebruikers van de broncode door te geven. Google heeft simpelweg niets om door te geven.
Aan de andere kant kan dit een potentieel gevaar voor Google opleveren. In het algemeen wordt aangenomen dat het verspreiden van de source code van een beschermd algoritme zonder licentie kan gebeuren. Alleen het gebruik of het verspreiden van werkend programma zou een licentie nodig hebben. Of dit daadwerkelijk zo is, is de vraag. Dit kan ook per juridictie verschillen.
Het risico dat Google hiermee neemt lijkt me echter een interne zaak voor Google. Als de octrooihouders problemen hebben met de werkwijze van Google dan zullen zij Google daar wel op aanspreken. Iets wat voor alle ontwikkelaars of gebruikers van de FFMPEG source code geldt. Het enige verschil is dat Google een wat grotere vis is.