Google wint van Oracle, maar de rest van de wereld heeft daar weinig aan

Google heeft geen inbreuk gemaakt op het copyright van softwarebedrijf Oracle toen het de code uit de programmeertaal Java gebruikte voor zijn mobiele besturingssysteem Android. Dat meldde RTL Nieuws onlangs. De Amerikaanse Supreme Court bepaalde namelijk dat de relevante code een fair use was onder eventuele auteursrechten van Oracle op diens Java-implementatie. Leuk voor Google, maar een uitspraak dat iets fair use is, daar heeft de rest van de wereld weinig aan. De kern van de zaak was namelijk: rust er überhaupt auteursrecht op een API definitie, wat de betreffende regels code uiteindelijk waren.

De zaak Google/Oracle draait om de universele programmeertaal Java, die begin jaren negentig is ontwikkeld door Sun Microsystems. In 2007 kwam het voor mobiele apparaten ontwikkelde besturingssysteem Android op de markt. Om ontwikkelaars over de streep te trekken Android-applicaties te maken, had Google daarin verschillende API’s opgenomen. Deze API’s bevatten elementen die ook aanwezig waren in de API’s van Java en droegen bovendien dezelfde namen. Alleen, de implementatie was verschillend.

Dat mag, zo dachten de meeste juristen destijds. Op een definitie of een naam rust geen auteursrecht. De implementatie wel, maar die was dus niet overgenomen. Desondanks kwam dit voor de Supreme Court en die bepaalde tot veler verrassing dat je op een API wél auteursrecht kunt hebben. Dit zou betekenen dat het interface-conform ontwikkelen van een implementatiekloon juridisch onmogelijk zou zijn, vandaar dat Google er met een truc een nieuwe zaak van maakte.

Die nieuwe zaak ging over fair use: mag je andermans werk gebruiken zonder toestemming als dat eerlijk of redelijk is, even kort gezegd. Dit Amerikaanse begrip is breder dan ons citaatrecht, parodierecht et cetera: weliswaar zijn al die dingen van ons vormen van fair use, maar wij hebben in Europa geen algemeen criterium “jamaar dat is toch doodnormaal, kom nou toch hoezo mag dat niet”. Dat is zowel een voordeel als een nadeel. Een nadeel, want als het niet in de wet staat dan vereist het dus toestemming. Maar ook een voordeel, want je weet nu precies wat wel en niet mag.

In de VS hebben ze dus die open norm, en de Supreme Court oordeelt nu dat Google daaronder dit mocht doen. Google had alleen die regels broncode gekopieerd – die API definities overgeschreven – die ze echt nodig had:

Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. The record demonstrates numerous ways in which reimplementing an interface can further the development of computer programs.
Het probleem is alleen: geldt dit voor íedere herimplementatie van andermans API? Hoe ver gaat dat “what was needed”, hoe anders moet jouw eigen programmeeromgeving zijn en moet het gaan om een “bekende” (familiar) programmeertaal? Als ik de API van zeg de elearning-provider op de hoek kopieer, val ik dan hieronder? En dat is dan alleen nog maar wat ik in vijf seconden kan bedenken na het lezen van deze zin; kun je nagaan wat een advocaat van Oracle daarvan maakt als hij zes maanden fulltime 800 dollar per uur daarvoor mag rekenen.

Het Hof danst om de vraag heen of haar vorige uitspraak over auteursrecht op API definities terecht was. Dat is ook lastig want zelfs de Supreme Court kan niet zomaar haar eigen precedenten opzij zetten. Men houdt het dan ook bij

We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted. … As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google).
Dit laat dus het principe overeind dat er best auteursrecht op een API als zodanig kan zitten. Weliswaar niet heel veel, maar kennelijk net genoeg. En hoe je het idéé van een API hergebruikt zonder de letterlijke functienamen en dergelijke te gebruiken, daar laat men zich wijselijk niet over uit.

We kunnen dus nu wel roepen dat Google gewonnen heeft, maar de conclusie die op lange termijn blijft staan is dat vrijwel iedere API auteursrechtelijk beschermd is, met als gevolg dat interoperabiliteit vrijwel onmogelijk wordt. Immers, wil je die herimplementeren dan heb je toestemming nodig tenzij je in een beperkte uitzondering valt.

Dit versterkt de macht van rechthebbenden enorm. En ja, ik maak me daar ook bij Europese bedrijven zorgen over. De meeste innovatieve softwaredienstverleners opereren immers vanuit de VS. De ervaring leert dat hun gedrag (en contractuele voorwaarden) sterk Amerikaans georiënteerd zal zijn, waarbij men niet snel Europeesrechtelijk water bij de wijn zal doen. Daar komt bij dat een concurrent binnen dit juridisch kader geen API-compatibele eigen dienst kan aanbieden, omdat dit op auteursrechtelijke bezwaren zal stuiten in de VS – en de dienst aldaar niet aanbieden is commercieel dan geen optie.

Daar staat natuurlijk tegenover dat zeker de web API’s vaak al onder bepaalde voorwaarden worden aangeboden, zodat de praktijk niet direct zal wijzigen. Maar API-aanbieders hebben nu wel een stuk steviger fundament voor hun voorwaarden, namelijk dat wie deze schendt, tevens het auteursrecht te buiten gaat. Een app die jouw voorwaarden schendt, kun je afsluiten van de API en dat is het. Een app die jouw auteursrecht schendt, kun je van de markt halen onder opvordering winst en een verbod voor de toekomst. Dus nee, ik vind deze ‘overwinning’ best zorgelijk.

Arnoud

Googles gebruik van de Java API is nu toch weer geen fair use

Googles gebruik van de Java API packages is geen fair use, las ik bij ITenRecht. Dit is de vierde stap in hoger beroep van de Google/Oracle rechtszaak over auteursrecht op de Java API die al enige jaren loopt. In eerste instantie bleek de API niet beschermd, in hoger beroep wel, toen bleek Googles gebruik een fair use en nu dus weer niet. Waar staan we nu met deze zaak?

De centrale kwestie is of Google de API van de taal Java van een eigen implementatie mag voorzien, om zo Java-compatibel te worden zonder een licentie van Oracle nodig te hebben. Dat kan alleen als op de API zelf geen auteursrecht rust, of als het gebruik van Google onder de Amerikaanse noemer van “fair use” gerechtvaardigd is.

In de eerste serie rechtszaken ging het om de vraag of er of de API auteursrecht rust. Een API is op zich een set creatieve keuzes (welke functie doet wat, hoe heet hij en welke variabelen zijn relevant), maar er zit ook een sterke technische component in. Daarom bepaalde de rechtbank in eerste instantie dat er geen sprake was van (Amerikaans) auteursrecht. In hoger beroep werd dat teruggedraaid, omdat weliswaar de functies zelf technische dingen doen, maar de keuze voor wélke functies en hoe dat te organiseren voldoende creatief te noemen is.

Heb je auteursrecht op een API, dan mogen anderen die dus niet gebruiken zonder een licentie. Echter, in Amerika geldt de algemene uitzondering van “fair use”: alle zeg maar legitieme, normale vormen van gebruik zijn legaal. Daarbij wordt een vierstappentoets langsgelopen waarbij zaken als de hoeveelheid overgenomen werk, de mate van aanpassing/transformatie en de aard van het werk meegewogen worden. Met deze open norm is in principe alles als “fair” aan te merken als je maar hard genoeg je best doet, maar er zit ook het nadeel aan dat je het nooit zeker weet tot de rechtbank er wat van gevonden heeft.

In het vervolg van de zaak beriep Google zich natuurlijk op fair use. Kern van het argument is dat als iemand een API maakt, het de bedoeling is dat mensen moeten weten wat deze kan. Daar een applicatie op schrijven is dan gewoon legitiem, normaal, zeker als je het argument interoperabiliteit meeweegt. Daar staat tegenover, aldus Oracle, dat Google met deze gratis weggegeven herimplementatie de hele markt voor de betaalde Java-licentie ondermijnde en vanwege de gigantische marktmacht van Google zou dat een enorme impact hebben op Oracle.

De rechtbank (en de jury) gaf Google gelijk, maar Oracle ging in hoger beroep. En nu wordt het even complex, want in de VS geldt een strikte scheiding tussen wat juries mogen zeggen en wat het primaat van de rechter is. De jury beslist wat de feiten zijn, de rechter past het recht toe. En bij fair use is dat ingewikkeld, omdat je daarbij feiten juridisch kwalificeert. Het Hof in hoger beroep moet dan ook de feiten en de juridische analyse uit elkaar trekken en vooral op die laatste gaan schieten.

Uiteindelijk weegt dan de vierde factor – het effect op de markt voor het origineel – het sterkste: Googles herimplementatie geeft een grote impact op de betaalde licentiemarkt voor Java (zelfs als je de open implementatie van Oracle zelf erbij betrekt), en daarmee blokkeert men eigenlijk de mogelijkheden voor Oracle compleet om geld te verdienen met haar werk. En iets waarmee de rechthebbende volledig met lege handen komt te staan, kan niet fair use zijn.

In Europa ligt het compleet anders. In de SAS-zaak werd bepaald dat de functionaliteit, de programmeertaal en de bijbehorende bestandsformaten geen deel van de beschermde code zijn, maar meer achterliggende ideeën of uitgangspunten waarmee je die code maakt. Zoals het Hof het formuleerde:

… neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive.

Hiermee zou een API dus wél vrij bruikbaar zijn omdat het dan enkel gaat om de functionaliteit die in de API ligt. Het ging in de SAS-zaak om het gebruik van een programmeertaal waarop auteursrecht werd geclaimd. Het schrijven in die taal zou dan inbreuk opleveren, omdat een programma in die taal immers de beschermde functionaliteit aanroept. En dát wijst het Hof van Justitie af. Dit lijkt mij 1-op-1 door te trekken naar API’s van een programma. Immers wat is het verschil tussen een instructie in een taal en een aanroep van een API?

Arnoud

Maakt die Google/Oracle-uitspraak de GPL krachteloos?

gpl-sans-plombeJe kunt je mooie GPL vaarwel kussen, las ik bij Ars Technica vorige week. Die Google/Oracle uitspraak die een API fair use verklaarde, gaat namelijk de GPL en consorten onderuit schoffelen. Oké, het was de advocaat van Oracle die dat schreef, maar er zit een argumentatie bij. Dus laten we die eens nader bekijken.

In het kort is het een typisch “de wereld stort in want ik kreeg ongelijk”-verhaal dat te reduceren is tot deze quote:

While we don’t know what ultimately swayed the jury, Google’s narrative boiled down to this: because the Java APIs have been open, any use of them was justified and all licensing restrictions should be disregarded. In other words, if you offer your software on an open and free basis, any use is fair use.

Volgens mij slaat advocate Hurst hier de plank stevig mis, want er is nogal een verschil tussen een API hergebruiken met je eigen code en het hergebruiken van code. En dát is waar de GPL voor geschreven is: copypasten van code, of het linken/combineren van die code in je eigen software. Bij dergelijke handelingen heb ik weinig twijfel dat sprake is van een auteursrechtelijk relevante handeling.

Inderdaad, als iemand een GPL header file of API zou hebben en jij zou een eigen implementatie daarvan schrijven, dan zou je waarschijnlijk in Amerika onder fair use daarmee vrij lopen zodat de GPL niet op jou van toepassing zou zijn. Maar is dat vervelend? Volgens mij is dat een behoorlijk uitzonderlijke situatie en zeker niet de normale wijze van hergebruiken van iemands GPL werk.

Dus nee, hier wordt uit de nek gekletst.

Arnoud

Amerikaanse rechtbank: Gebruik van Java API in Android is fair use

aapje-api.pngNa twee weken was de jury er snel uit: wat Google deed met de Java API in Android is een “fair use” onder het Amerikaans auteursrecht, derhalve worden geen rechten van Java-eigenaar Oracle geschonden. Dat las ik bij Ars Technica. Google en Oracle liggen al een paar jaar in de clinch over de vraag of (kort gezegd) Google een herimplementatie van Java-functionaliteit mag doen als ze daarbij de API-definities overtypt uit de specificaties van Oracle. Oracle vond van niet en eiste diverse miljarden schadevergoeding.

In 2014 werd nog bepaald dat Android wél inbreuk maakte op de rechten van Oracle. De aangeboden code en de structuur, volgorde en organisatie van de api-packages zijn creatieve keuzes die de resulterende api een auteursrechtelijk beschermd werk maken. Daarom schendt Google met Android het auteursrecht van Oracle door namen, headers en functiedeclaraties over te nemen.

Althans, in principe. Dit is immers recht: er is altijd een uitzondering mogelijk. Omdat Google ongelijk had gekregen op het punt van de auteursrechten (zij hadden gezegd dat er geen auteursrecht zit op een API) was de rechtbank niet toegekomen aan de vervolgvraag of een wettelijke uitzondering op het auteursrecht zou gelden. Dat moest dus alsnog worden bepaald, en bij deze: fair use.

Fair use is een open norm in het Amerikaans auteursrecht. Alles kan fair zijn als je maar kunt uitleggen waarom. Er zijn dan vier factoren:

  1. Het doel en karakter van het gebruik, inclusief de vraag of het gebruik commercieel is of educatief en non-profit;
  2. De aard van het beschermde werk;
  3. De omvang en de scope van het overgenomen deel in verhouding tot het beschermde werk als geheel; en
  4. Het effect van het gebruik op de potentiële markt voor of waarde van het beschermde werk.

Helaas komt dat in dit vonnis niet heel goed uit de verf. Het was een jury-oordeel en die komen niet verder dan “inderdaad, dit is fair.” De jury-instructies geven mij de indruk dat het vooral zal zijn gegaan om de aard van het werk: als Google een eigen herimplementatie mocht doen van de functies, dan móet ze wel de API overtypen anders is haar werk volslagen onbruikbaar. Maar het is nog even afwachten hoe een en ander in vonnis wordt gegoten. En natuurlijk gaat Oracle in hoger beroep.

In Europa ligt het anders. In de SAS-zaak werd bepaald dat de functionaliteit, de programmeertaal en de bijbehorende bestandsformaten geen deel van de beschermde code zijn, maar meer achterliggende ideeën of uitgangspunten waarmee je die code maakt.

… neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive.

We hebben nu dus twee systemen: in Amerika zit er auteursrecht op een API máár is hergebruik daarvan fair use, en bij ons zit er geen auteursrecht op een API dus leef je uit, qua hergebruik.

Is Java op Android eigenlijk nog wel belangrijk? Ik zie nooit meer Java-applicaties op dat platform.

Arnoud

Oracle’s Java API auteursrechtelijk beschermd in VS, Android maakt inbreuk

aapje-api.pngEen Amerikaans gerechtshof heeft vrijdag in hoger beroep bepaald dat Google met zijn Android-besturingssysteem het copyright van Oracle heeft geschonden, las ik bij Tweakers. Nadat eerder nog was bepaald dat er geen auteursrecht zat op de API’s van Oracle’s Java, beslist het Hof van Beroep nu anders: de aangeboden code en de structuur, volgorde en organisatie van de api-packages zijn wel degelijk creatieve keuzes die de resulterende api een beschermd werk maken. Daarom schendt Google met Android het auteursrecht van Oracle door namen, headers en functiedeclaraties over te nemen.

Het geschil speelt al sinds 2012. Google had in Android een aantal elementen overgenomen uit de Java API en Oracle startte daarop een rechtszaak wegens auteursrechtinbreuk. In eerste instantie won Google: een API en functiedeclaraties zijn vergelijkbaar met een inhoudsopgave, en bovendien kun je in software vaak dingen maar op één manier uitdrukken. Daarmee is er geen sprake meer van het overnemen van creatieve elementen.

In hoger beroep wordt anders beslist. Allereerst wordt vastgesteld dat het máken van een API best creatief werk kan zijn. Nadenken welke functies je gaat aanbieden, hoe je die noemt, welke argumenten ze moeten krijgen en wat voor soort resultaat er komt, vereist creatieve arbeid. En die arbeid wordt beschermd door het auteursrecht. Een ander mag dan niet zomaar de integrale resultaten van die arbeid overnemen.

Amerikaans auteursrecht verbiedt auteursrecht op methods of operation. Al in 1995 speelde dit: mocht Borland met spreadsheetprogramma Quattro de menustructuur van concurrent Lotus overnemen? Ja, zo oordeelde men destijds, want een menu is dé manier van het opereren/gebruiken van een stuk software. En in eerste instantie won ook Google het met dit argument, omdat het nabootsen van een menu hetzelfde werd geacht als het aanroepen van een API. Dat wijst het Hof af: het kopiëren van API declaraties is wat anders dan het kopiëren van labels uit een menu.

Bovendien is de Lotus-uitspraak uit een ander circuit en in de VS geldt zo’n uitspraak dan niet als bindende jurisprudentie. Het Hof valt terug op een eigen precedent dat wél bindend is: de manier waaróp je een method of operation vormgeeft, kan wel auteursrechtelijk beschermd zijn. Mits er maar meer dan één manier is om dat te doen. En dat is hier het geval: de Java-ontwikkelaars hadden de vrije keuze om hun API te maken zoals zij wilden.

In Europa ligt het compleet anders. In de SAS-zaak werd bepaald dat de functionaliteit, de programmeertaal en de bijbehorende bestandsformaten geen deel van de beschermde code zijn, maar meer achterliggende ideeën of uitgangspunten waarmee je die code maakt.

… neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive.

Hiermee zou een API dus wél vrij bruikbaar zijn omdat het dan enkel gaat om de functionaliteit die in de API ligt. Het ging in de SAS-zaak om het gebruik van een programmeertaal waarop auteursrecht werd geclaimd. Het schrijven in die taal zou dan inbreuk opleveren, omdat een programma in die taal immers de beschermde functionaliteit aanroept. En dát wijst het Hof van Justitie af. Dit lijkt mij 1-op-1 door te trekken naar API’s van een programma. Immers wat is het verschil tussen een instructie in een taal en een aanroep van een API?

Google krijgt nog een kansje in de tweede ronde: de zaak is terugverwezen naar de rechtbank om Googles verweer op grond van fair use te beoordelen. Onder fair use mag je in het Amerikaans auteursrecht iemands werk gebruiken mits dat billijk (fair) is. Daarbij spelen zaken mee als hoe concurrerend je bent, hoe commercieel je bent en hoe transformatief of juist letterlijk je gebruik is. Dat is dus een moeilijker zaak om te bewijzen dan wanneer de Java API niet auteursrechtelijk beschermd zou zijn verklaard.

Dit kan nog wel eens heel hinderlijk worden want heel veel internet-API’s worden beheerd door Amerikaanse bedrijven. En als die nu allemaal auteursrechtelijke voorwaarden gaan koppelen aan gebruik daarvan, dan gaat me dat nog flink wat juridische hoofdpijn opleveren.

Arnoud

Gedownloade software mag worden doorverkocht

software-tweedehands.jpgBaanbrekende uitspraak zeggen ze bij ITenRecht, en terecht. Gedownloade gekochte software mag worden doorverkocht, en kopers van tweedehands software hebben een wettelijk gebruiksrecht. Ongeacht wat in de licentie staat. Lekker puh. Ok, dat laatste is mijn mening maar de rest is de opvatting van het Hof van Justitie in de UsedSoft zaak (C-128/11) waarbij Oracle dit Duitse tweedehandssoftwarelicentieverkoopbedrijf had aangeklaagd.

De Softwarerichtlijn, die auteursrecht op software regelt, bepaalt dat de auteursrechten zijn uitgeput op een exemplaar van software wanneer dat door de rechthebbende in de handel wordt gebracht via verkoop. Dat exemplaar mag worden doorverkocht, ongeacht wat er in de licentie staat. Logisch, zo werkt het met boeken ook. Pardon, met auto’s want het is in de ICT verplicht om vergelijkingen met auto’s te maken. Maar hoe dit nu uitpakt met gedownloade software, wist eigenlijk niemand. Is dat ook “verkoop”? Of sluit je dan alleen een contract?

Net als ik krijgt het Hof hoofdpijn van het onderscheid tussen de software en de licentie daarop. Een kopie hebben van software is zinloos als je niet ook een gebruiksrecht daarop hebt, begint het dus. En vervolgens constateert men dat uit diverse wetten en richtlijnen volgt dat een download eigenlijk hetzelfde is als een CD kopen: je krijgt een kopie en toestemming voor gebruik. Of de kopie materieel of immaterieel is, maakt niet uit. Zo staat er in de Softwarerichtlijn dat de bescherming van software in alle media hetzelfde moet zijn. Hoewel dat ongetwijfeld opgeschreven is om te voorkomen dat men ergens mínder bescherming zou kunnen krijgen dan ergens anders, werkt die zin natuurlijk ook omgekeerd: als uitputting fysiek een grens is, dan ook op internet.

Ook stelt het Hof dat auteursrechthebbenden recht hebben op een redelijke bescherming (en vergoeding) maar niet méér. Dat bepaalden ze al eerder in de Premier League-uitspraak, over het mogen ontvangen van satelliettelevisie en de handel in decoders daarvoor. Het Hof vond de beperkingen die de voetbalauteursrechthebbenden daar aanlegden, ingaan tegen het vrij verkeer van goederen en niet noodzakelijk voor een redelijke exploitatie van het auteursrecht. Dus nee, je hebt geen recht op geld voor alles dat mensen met je software kunnen doen.

Wel moet het gaan om “verkoop”, en niet elke licentieovereenkomst is een verkoop. Er moet sprake zijn van een licentie die onbeperkt is in de tijd, en er moet een redelijke vergoeding tegenover staan die in overeenstemming is met de economische waarde van de software. Dat laatste is ter onderscheid van huur: wie 3 euro per maand betaalt, huurt de software, maar wie 300 euro in één keer betaalt en daarna nooit meer, koopt de software.

Tevens moet de verkoper zijn kopie van de software onbruikbaar maken. Dus wissen, ook de backups. Wederom logisch.

En voor het geval bijdehante rechthebbenden in de licentie doorverkoop willen hinderen: dat mag niet, lekker puh. Oeps, doe ik het weer. In de Softwarerichtlijn staat namelijk dat je het een rechtmatige verkrijger niet mag verbieden om normaal gebruik van de software te maken. En daaronder valt dus ook het mogen doorverkopen van de software met licentie, dat is ook normaal.

Tussen neus en lippen door schopt men nog even tegen de schenen van de fijnslijpers die altijd zeiden dat “rechtmatig verkrijger” iemand is die een geldige licentie bezit. Daarmee wordt dat begrip eigenlijk zinloos. De wetgever wilde een juridische positie voor afnemers scheppen, en niet een synoniem voor “contractuele wederpartij”. Als je tegen een verkrijger van een tweedehands kopie kunt optreden met je auteursrecht, is het onmogelijk om software door te verkopen.

Als beperking geldt wel dat een gekochte licentie niet mag worden gesplitst. Koop je 23 licenties in één contract, dan mag je ze alleen als bundel van 23 doorverkopen. Dat lijkt net wat strenger dan in de fysieke wereld, maar ergens klopt het wel. Als je een 23-delige encyclopedie (een papieren Wikipedia) koopt, word je geacht die alleen met z’n 23-igen door te verkopen. Niet per stuk. Dat beperkt wel de handelsvrijheid van UsedSoft, waar je wel gesplitste licenties kon kopen.

En men “beklemtoont” nog even dat Oracle wél het recht heeft om te auditten of doorverkochte software wel echt gewist is bij de eerste koper. Dat is ongetwijfeld bedoeld als een soort goedmakertje: we pakken je wel het recht af om tegen UsedSoft op te treden maar je staat niet helemaal met lege handen hoor. Hoewel ik me goed kan voorstellen dat Oracle hier in de praktijk weinig aan heeft.

Ik ben heel benieuwd wat de reactie in de markt zal zijn. In eerste instantie zet ik m’n geld op “compleet negeren en heel hard LALALA roepen als iemand erover begint”. Volhouders gaan blafbrieven van advocaten krijgen met kulargumenten als “dat was een Duitse zaak, dat geldt niet bij ons” of “ons licentiemodel is wezenlijk anders dan Oracle”. Of met het iets-minder-kulargument “onze licenties zijn 5 jaar geldig” en/of “u moet elk jaar betalen dus is het huur”. Maar dat lost zich vanzelf op als ook de eerste Nederlandse rechtszaken uitgevochten zijn. Een arrest als dit van het Europese Hof wordt echt niet zomaar genegeerd bij de rechter.

Wél pijnlijk zou zijn als rechthebbenden nu veel zwaarder in gaan zetten op technische beperkingen, zoals activatie die maar éénmalig mag worden uitgevoerd. Dan kan software doorverkopen wel maar wérkt ie gewoon niet meer bij de nieuwe verkrijger. En dáár tegenin gaan vereist vrees ik weer wel een gang naar de Europese rechter.

Arnoud<br/> Foto: Drazz, Flickr, CC-BY-SA 2.0

“Oracle misbruikt merkenrecht tegen vrije handel”

Ja, dat vond ik ook een beetje rare kop van Webwereld bij een artikel over een Engelse rechtszaak. Waar men de term ‘misbruik’ op baseert, is me niet helemaal duidelijk. In de lead heet het namelijk ineens heel neutraal ‘gebruikt’, hoewel de geladen term ‘frustreren’ wel is blijven staan:

Oracle gaat prijsconcurrentie tegen door de import van ict-goederen naar Europa tegen te werken. Het bedrijf gebruikt het merkenrecht om het vrije verkeer van goederen te frustreren.

In ieder geval, het gaat om een Engels arrest in een zaak tussen Oracle en M-Tech, een importeur van ICT-artikelen. De laatste had merkproducten van Oracle (nou ja, Sun) geïmporteerd uit China, Chili en de Verenigde Staten. Oracle vond dat niet leuk, dus startte ze een rechtszaak (ik zei het laatst al, merkhouders hebben geen gevoel voor humor).

Oracle won in eerste instantie. Op zich niet verrassend. De merkenwetgeving is duidelijk: grijze import van buiten de EU is niet toegestaan. Oracle is volgens dit arrest alleen wel érg agressief in het tegenhouden van zulke grijze import, en timmert ook nog eens de tweedehandsmarkt stevig dicht met allerlei contractuele bepalingen richting afnemers. (Ook tweedehands Oracle-spul moet bij Oracle-dealers worden gekocht.) Dat kwam haar op een klacht wegens misbruik van haar machtspositie te staan, maar dat staat verder los van het argument waar Webwereld tendentieus van werd: hoe is het merkmisbruik om grijze import tegen te houden?

Centraal hier staat het vrij verkeer van goederen binnen de EU. Iets dat hier legaal op de markt is, mag onbeperkt worden doorverkocht. De merkhouder kan dat niet tegenhouden. Maar dit geldt alleen voor merkproducten die binnen de EU legaal op de markt zijn. M-Tech had echter een creatief argument: door de harde aanpak van Oracle, plus de onmogelijkheid om aan een product te zien of het in of buiten Europa op de markt gebracht was, werd in feite het vrij verkeer toch geblokkeerd. Niemand zou dan meer Oracle-producten durven te herverkopen, want wie weet zit er wel een oorspronkelijk-buiten-Europa-verkocht product tussen en dan krijg je die humorloze club met dure advocaten op je nek. En daarmee wordt Oracle de facto de enige die nog haar producten (origineel of gebruikt) kan verhandelen. Dat is niet de bedoeling van het Europese recht.

Een creatief argument, en voor dit gerechtshof creatief genoeg – M-Tech mag het komen aanvoeren en onderbouwen. Want dit was slechts een tussenarrest over de vraag of het hoger beroep überhaupt zin heeft of meteen afgewezen (“summary judgment”) had moeten worden. Er is dus geen inhoudelijk oordeel, tenzij je “dit overleeft de giecheltoets” als inhoudelijk ziet.

Tussen de regels door zie ik dat de raadsheren overwegen vragen aan het Europese Hof van Justitie te stellen over de grenzen van merkenrecht en uitputting. Dat zou wel een goed idee zijn.

Arnoud