Internetrecht door Arnoud Engelfriet

Een 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

Een lezer vroeg me:

Ik ben fotograaf en maak portretfoto’s. Nu had ik het idee om een dienst aan te bieden waarbij je gratis een portretfoto kunt maken, onder de Creative-Commonslicentie Naamsvermelding-NietCommercieel-GeenAfgeleideWerken (BY-NC-ND). Zo kunnen mensen als privépersoon een mooie foto publiceren op hun Facebookpagina en krijg ik naamsbekendheid. Willen mensen die foto commercieel gebruiken, dan moeten ze apart komen betalen.

Nu liep ik tegen één probleem aan: wat nu als mensen die foto op een bedrijfswebsite zetten of aan hun Linkedin- of Plaxo-profiel koppelen? Dat zijn immers zakelijke netwerken. Is dan sprake van ‘commercieel gebruik’? Hoe kan ik aangeven dat dat wel mag (met mijn naamsvermelding natuurlijk) zonder meteen ál het commercieel gebruik toe te staan?

Creative Commons is een set standaardlicenties waarmee je kunt aangeven dat mensen je werk mogen gebruiken, behoudens enkele uitzonderingen Auteursrecht zoals het zou moeten werken dus. Omdat het standaardlicenties zijn, zijn de regels zwartwit en is het niet mogelijk om eigen uitzonderingen toe te voegen.

Speciaal voor commercieel gebruik betekent dat dat je alleen mag kiezen of dat wél of niet mag, maar niet welke vormen van commercieel wel of niet mogen. Je mag bijvoorbeeld niet zeggen dat een goed doel je foto wél mag gebruiken voor een wervingscampagne maar een bedrijf niet in zijn advertentiecampagnes. Beide campagnes zijn gericht op “financieel gewin” en dat is de definitie van “commercieel”. Dus of beiden mogen, of geen van beiden.

Een oplossing die soms werkt, is toelichten hoe je een bepaald twijfelgeval interpreteert. Zo’n toelichting is formeel geen deel van de licentie, maar hij kan wel tegen je worden gebruikt want hij bewijst hoe jij het licentiecontract interpreteerde. En daar mag de wederpartij je dan aan houden.

Je zou dus kunnen zeggen “Ik vind het gebruik van een portretfoto op een profielpagina geen ‘gebruik voor direct of indirect geldelijk gewin’ zolang geen geld wordt gevraagd voor het bekijken, publiceren of kopiëren van de foto.” Dit is een verduidelijking van het verbod, en deze gaat niet in tegen de tekst van het verbod zelf. Dat is dus prima.

Natuurlijk zitten hier grenzen. Een uitzondering als “ik vind het maximaal 50 euro vragen voor een kopie geen commercieel gebruik” gaat natuurlijk niet werken, want die tekst spreekt de definitie van ‘commercieel’ tegen. Geld vragen voor een kopie is zó evident commercieel dat je dat niet met een uitzondering opzij kunt zetten.

Arnoud

Een lezer stelde me een vraag over chatclient Jabber. Hij gebruikt deze op het werk inclusief de feature van end-to-end encryptie: OTR. Voor de iPad en iPhone is ook een Jabber-client beschikbaar, OneTeam geheten. Deze had echter geen encryptie. Op zijn verzoek of dat binnenkort dan opgenomen zou worden, reageerde het bedrijf met:

Chances to get encryption in OneTeam on iOS are very low, as we would have to ask permission to US government (as requested by Apple). This is a hassle we would like to avoid.

De vraag is natuurlijk, wat heeft de Amerikaanse regering te maken met encryptie op je iPhone?

In eerste instantie niet per se heel veel, maar Apple voelt zich als Amerikaans bedrijf geroepen de Amerikaanse wet te handhaven. Daarom staat in de voorwaarden voor app-developers dat zij bij gebruik van encryptie moeten bewijzen dat het Ministerie van Handel de export van deze technologie heeft goedgekeurd. Dat proces is een heel gedoe, maar het kan wel.

Deze regels gelden ook voor andere besturingssystemen en software, alleen wordt daar niet heel hard op gelet. Maar reken maar dat Microsoft keurig toestemming heeft gevraagd alvorens Windows met encryptie aan boord uit te leveren.

Vroeger waren er heel strenge regels over encryptie: je mocht als Amerikaan geen sterke encryptie naar buiten het land exporteren, wat inhield dat een sleutel bijvoorbeeld maar 40 bits lang mocht zijn (en niet de 128 bits die het zou moeten zijn om veilig te zijn). Dat geldt niet meer, er is alleen nog een verbod op export naar Libië, Iran en die landen. Voor de rest geldt een meldingsplicht en een paar beperkingen.

Voor open source is ook dat nog een probleem, want je hebt geen idee waar je software naartoe gaat dus je kunt niet garanderen dat de software niet naar Iran zal gaan. Daarom is er een uitzondering in de export control wetgeving opgenomen (art. 740.13 e-CFR), die zegt dat software in broncodevorm die publiek op internet downloadbaar is niet onder de strenge wetgeving valt.

Dat is volstrekt onlogisch gezien doel van de wet maar wel handig voor open source: wie producten met encryptie verkoopt, moet nagaan wie de klanten zijn en goedkeuring voor export hebben, maar wie het gratis op internet zet hoeft dat allemaal niet. Je moet alleen melden dat je cryptografische open source op internet hebt gezet.

In Europa geldt geen eis van melding. Wel is het verboden encryptie opzettelijk te exporteren naar landen als Libië, Noord-Korea of Iran. Want ja, encryptietechnologie wordt nog steeds gelijkgeschakeld met wapens en munitie.

Arnoud

Omdat 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

Als je afspreekt dat je software alleen mag verspreiden in versleutelde vorm, maar er zit open source in, schend je dan de licentie door toch broncode vrij te geven? Jaja, het lijkt er zowaar op dat we een vonnis hebben over de ‘virale’ werking van open source. Maar dat valt vies tegen: de rechtbank doet geen uitspraak (via) over de bindendheid van de ‘open licenties’ omdat de licentienemer deze er eenvoudig uit had kunnen slopen.

Het bedrijf Purple Pigeon had software (’Eigen Chatbox’, ‘WebAgenda Multi-User’, ‘WebEnquete PRO’, ‘Web to Go Personal’ en ‘Web To Go Professional’) ontwikkeld, en met Quinarx een exclusieve distributieovereenkomst gesloten. Die werd later omgezet in een nieuwe overeenkomst, waarbij afgesproken werd dat de broncode te allen tijde gecodeerd (versleuteld) zou moeten worden met een pakket als SourceCop. Ook moest altijd het copyright van Purple Pigeon worden vermeld.

In 2010 constateerde Purple Pigeon dat de software nog steeds werd verkocht, en ook nog eens met vrij beschikbare broncode en zónder auteursvermelding van PP. Volgens Quinarx was daar geen sprake van, waarop Purple Pigeon naar de rechter stapte en een terughaalactie (recall) eiste plus een schadevergoeding.

Eén van de verweren van Quinarx was dat het programma open source bevatte, en dat het daarom niet zomaar versleuteld verspreid mocht worden. Op zich een terecht verweer: de GPL bijvoorbeeld verbiedt zulke distributie, de broncode moet er echt bij zitten (of op verzoek nageleverd worden). Maar de rechter oordeelt dat je als licentienemer niet zomaar eenzijdig mag besluiten om dan de broncode maar openbaar te maken. Als je zo’n compliance probleem signaleert, moet je de rechthebbende benaderen en ze daarop wijzen.

Terecht, maar jammer dat dit punt niet nader is uitgewerkt. Ik had wel eens willen zien wat de rechter zou zeggen van het verweer dat Quinarx (en ook Purple Pigeon) gewoon gebonden was aan de GPL en daarom wel moest handelen op deze manier.

Arnoud

Een nieuw voorgestelde opensourcelicentie zorgt voor de nodige beroering bij het Open Source Initiative, dat licenties van een officieel stempel voorziet. De Chicken Dance License bevat namelijk naast enkele typische juridische clausules ook de nodige humor. Net als de WTF Public License zorgt dat voor discussie: mag dat wel, humor in een licentie?

De licentie is een variant op de bekende BSD licentie, die eigenlijk alleen eist dat je de bronvermelding intact laat en de auteurs niet aanklaagt als er problemen zijn met de code. Maar wanneer iemand software onder deze licentie wil verspreiden zonder de broncode te delen, dan moet hij voor elke 1000 kopieën zijn personeel één keer naar de Ententanz (de Duitse versie inderdaad) laten luisteren. Wie meer dan 20.000 kopieën in binaire vorm wil verspreiden, moet zelf een video publiceren waarin de Ententanz wordt uitgevoerd. En verder is het licentienemers te allen tijde verboden het woord plinth (sokkel) te gebruiken.

De auteur van de motiveert deze beperkingen als volgt:

“The purpose of this license is to make intellectual property far more entertaining to deal with,” writes Andrew Harris, the author of the license. “Rather than boring old GPL violations or licensing agreements for GPL software, [an] entertaining video of people doing the chicken dance is produced. If this was taken to court, CDL violators may even have to perform the chicken dance retroactively!”

OSI heeft al laten weten dat officiële goedkeuring onwaarschijnlijk is: de licentie discrimineert mensen met een handicap, die immers de dans niet kunnen uitvoeren. Ook wordt de gehele sokkelindustrie uitgesloten van het gebruik, wat in strijd is met de OSI-regels dat open source in elke tak van de industrie gebruikt moet kunnen worden. Als de wapenindustrie Linux in een kruisraket mag stoppen, dan moet de sokkelindustrie toch ook gewoon deze software kunnen gebruiken.

Zelf vraag ik me nog af hoe het zit met de Buma/Stemra/Sena-rechten over de muziek. Indirect wordt er nu toch de eis gesteld van een financiële vergoeding, immers over de muziek moeten BUMA- en Sena-rechten worden betaald. En geld laten betalen om open source te mogen gebruiken is ook tegen de OSI-regels.

Arnoud

Een 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

Een lezer vroeg me:

Omdat ik gezeur met softwarelicenties vrij zat ben, ben ik van plan m’n eigen code te publiceren onder de WTFPL (Do What The Fuck You Want To Public License). Ik vraag me alleen af hoe serieus een rechter een licentie als deze zou nemen. Er staan immers geen juridische frases in, en bovendien is er sprake van grof taalgebruik. Loop ik dan een risico als ik die licentie gebruik?

Er is geen regel in de wet die zegt dat een licentiecontract moet voldoen aan welke taaleis dan ook. Zo ongeveer de enige eis is dat de partijen bij het contract kunnen bepalen wat hun rechten en plichten zijn. En je hebt ook niet per se een advocaat, notaris of jurist nodig om een licentiecontract “rechtsgeldig” te krijgen, behalve in een paar héél bijzondere gevallen zoals de koop van een huis.

Er is dus op zich niets tegen een licentie in gewone taal. Ik heb zelf ooit een standaardreglement voor forums gemaakt waar volgens mij ook nauwelijks jargon in staat. Als je echter ál te ludiek bent in je teksten, zou een rechter in theorie kunnen oordelen dat je licentie niet als serieus aanbod bedoeld was.

De Do What The Fuck You Want To Public License (WTFPL) komt neer op:

You just DO WHAT THE FUCK YOU WANT TO.

En inderdaad is dat wel erg kort - hoewel heel veel meer strikt gesproken niet nodig is. Misschien nog een “Don’t FUCKING SUE ME FOR ANYTHING” als disclaimer, maar verder lijkt me intentie en strekking vrij duidelijk: ga je gang met die software en ik wil er niets over horen.

Waarom dan toch vaak dat moeilijke taalgebruik? Tsja, dat is een goeie. Voor een deel is het vaak een kwestie van onbewust jargon gebruiken. In de wandelgangen met collega’s spreek je als jurist eerder van “exoneratie” dan van “beperking van aansprakelijkheid”, en als je niet uitkijkt komt dat ook in de documenten voor je klanten terecht.

Ook speelt mee dat je graag 100% correct wilt formuleren. Als je zegt “ik ga niet programmeren als jij me onbruikbare input geeft”, dan krijg je wellicht discussie over wat “onbruikbaar” is en hoe je dat meet. En wat is “input”? Elke onbegrijpelijke mail? De specificaties? Ook zou je je nu kunnen afvragen of dat niet-aan-de-slag-gaan een verplichting is of alleen maar een recht van de ontwikkelaar. Als je daar als jurist een correcte en dichtgetimmerde formulering van wilt maken, dan krijg je zoiets (artikel 2.3 van de ICT~Office voorwaarden, module Ontwikkeling van programmatuur):

Leverancier is gerechtigd, doch niet verplicht, de juistheid, volledigheid en consistentie van de aan hem ter beschikking gestelde gegevens, specificaties of ontwerpen te onderzoeken en bij constatering van eventuele onvolkomenheden de overeengekomen werkzaamheden op te schorten totdat cliënt de betreffende onvolkomenheden heeft weggenomen.

Ik geef toe, het is minder leesbaar dan “ik ga niet programmeren als jij me onbruikbare input geeft” maar het is wel minder vatbaar voor discussie.

Soms is het helaas meer een kwestie van niet duidelijk kunnen formuleren of niet genoeg weten van de business van de klant om een toegesneden clausule te maken. En dan copypasten we maar het vorige contract want dat zal dan wel goed genoeg zijn.

Arnoud
Foto: mjaysplanet, Flickr.com CC-BY 2.0

Een lezer vroeg me:

De opleiding die ik momenteel volg maakt gebruik van een Flash applicatie voor de wiskundelessen. Ik gebruik Linux, en daar werkt die applicatie eigenlijk niet goed op. Ik heb verschillende distributies, van Gentoo tot Ubuntu, geprobeerd maar het probleem blijft. Mijn docent geeft echter aan dat ik dat maar te accepteren heb: “Moet je maar gewoon Windows gebruiken”. Dus nu vroeg ik me af, kan ik van de school eisen dat ze hun applicatie crossplatform maken, of kunnen ze mij verplichten een dure Windowslicentie aan te schaffen?

Ik ken geen regels die zeggen dat opleidingen OS-agnostisch moeten zijn. Heel misschien als je indirect benadeeld wordt in een handicap of zo (screenreader die het alleen doet onder MacOS, of braille-apparaat met Linux).

In het algemeen geldt voor zover ik weet dat een onderwijsinstelling zelf mag bepalen welke eisen zij willen stellen aan deelnemers, zolang het maar geen verboden discriminatie oplevert. Als zij eisen dat je een roze sweater draagt, dan zal dat moeten. Willen ze geen leren tassen, dan zul je een geweven rugzak moeten kopen.

Voor software geldt denk ik hetzelfde. Zij hebben bepaalde software, en als jij die vakken wilt volgen dan moet je hun software gebruiken. Dat is denk ik niet anders dan wanneer ze je boeken voorschrijven of een rekenmethode die jou misschien niet ligt (de moderne staartdeling, wtf?). Dat jij liever een ander boek hebt, of dat jouw boeken goedkoper zijn, is geen argument om af te mogen wijken van de verplichte literatuur. En daarom denk ik dat Windows ook voorgeschreven kan worden.

Arnoud

Een ontwikkelaar van de open-source video-encoder x264 beschuldigt het bedrijf Tandberg ervan dat zij open-sourcecode heeft gestolen en die nu wil patenteren. Tandberg ontkent. Dat meldde Webwereld gisteren, en Tweakers al zondag. In patentaanvraag WO2010077148 blijkt een algoritme beschreven te worden dat wel héél sterk lijkt op een in 2006 bedacht algoritme voor de open source video encoder x.264.

De overeenkomsten zijn inderdaad zeer opmerkelijk. De indieningsdatum is 2 maanden na de publicatie van de broncode uit de encoder. Er ontbreekt een niet onbelangrijk onderdeeltje in de patentaanvraag - en precies dat onderdeeltje was pas een tijdje later aan de encoder toegevoegd. En volgens de ontwikkelaars was bekend dat Tandberg-mensen meelezen bij hun project. Bij Slashdot zien ze dan ook meteen een complot om heel open source te patenteren. /aluhoedje

Tandberg ontkent alle beschuldigingen en wijst erop dat hun aanvraag toch echt anders is dan de encoder, en dat ze zeker niet meelezen of code overtypen. (Er staat ook geen broncode in de patentaanvraag.) En de ontwikkelaars reageren daar weer op dat dat best zou kunnen; het algoritme uit de patentaanvraag is volgens hen zó triviaal dat je er toch geen patent op moet kunnen krijgen.

Hoe nu verder? Het literatuuronderzoek van WIPO noemt deze prior art niet, maar na al deze heisa een mogelijke octrooiverlenende instantie mogelijk wel. Of Tandberg besluit zelf de aanvraag in te trekken, dat kan ook altijd.

Webwereld meldt nog deze aperte onzin:

De x264 projectgroep kan overigens nog wel bezwaar indienen tegen het patent bij de World Intellectual Property Organization. Die organisatie kan de patentaanvraag ongeldig verklaren als blijkt dat het algoritme van Tandberg inderdaad te veel overeenkomt met het open-source algoritme.

Die mogelijkheid bestaat juridisch eenvoudigweg niet. Het WIPO publiceert internationale octrooiaanvragen en publiceert een literatuuronderzoek, meer niet. Wie echt een octrooi wil, moet daarna naar de octrooiraden van de landen waar hij dat octrooi wil. En die kunnen eventueel de bezwaren van de x.264 groep in behandeling nemen.

Arnoud