Koper van SCO’s OpenServer klaagt IBM en Red Hat aan

| AE 12605 | Intellectuele rechten | 5 reacties

Oh nee. Softwarebedrijf Xinuos klaagt IBM en Red Hat aan voor het illegaal kopieren van zijn broncode voor besturingssystemen voor servers, las ik bij Tweakers. Xinuous is de rechtsopvolger van het beruchte SCO, dat IBM een jarenlang slepende rechtszaak aandeed met de meest onzinnige claims over “gestolen IP” dat IBM in Linux zou hebben gestopt. Of zoiets. Ik blogde in mijn begintijd over die zaak, de kern is dat het totale onzin was en iedereen knettergek was van hoe veel werk het bleek om dat te weerleggen. En dan nu wéér?

Het eerste dat me opviel is dat Xinous de zaak op de Amerikaanse Maagdeneilanden heeft aangespannen. Dat leek me een transparante truc om de zaak over te mogen doen: je kunt immers niet tweemaal procederen over hetzelfde, maar wél als je in een andere jurisdictie staat. Maar dat blijkt te komen omdat Xinous haar hoofdkwartier op dat 100.000 inwoners tellende eilandengroepje heeft.

Daarnaast blijkt Xinous iets concreter over de “stolen IP”: het zou gaan om een emulatorlaag waarmee IBM’s eigen besturingssysteem AIX Linux-applicaties kan draaien. Die emulator, Affinity geheten, zou regelrecht gekopieerde broncode bevatten waar Xinous het auteursrecht op heeft. Ook betreft het de UnixWare 7 print subsystem en de multipath IO routines, en nog het een en ander. Nou kijk, daar kunnen we wat mee. Om nu op woensdagochtend even een volledige source review te doen gaat me wat ver, maar ik moet toegeven dat dit een concrete én andere beschuldiging is dan waar SCO destijds mee kwam.

IBM lijkt -aldus de aanklacht, een verweerschrift is er nog niet- te denken dat zij dit mochten doen omdat deze code uit UNIX en UnixWare komt, waar Novell (de echte eigenaar van UNIX, zo bleek in de SCO rechtszaak) ze een licentie op gegeven heeft. Maar Xinous zegt dus dat nou net díe auteursrechten naar hen zijn gegaan.

Gek genoeg komt er dan ook een zeer paranoïde klinkend verhaal over hoe IBM samenzwoer met Red Hat (dat inmiddels een IBM-dochter is) om zo de markt voor Unix-achtigen te verpesten:

As a result of these activities, Xinuos has been excluded from key opportunities in the market. For example, despite Xinuos offering a FreeBSD-based operating system with substantial commercial value for enterprise users, Xinuos was unable to garner as much financial support or customer interest in OpenServer 10 as it could and should have due to the market conditions. Indeed, the market is so distorted that Xinuos has determined that over 70% fewer of its customers are in a position to license its new operating system than would be available in a functioning market. The foreclosing effect on Xinuos is felt by all competitors as well.
Ik kan hier dus werkelijk geen chocola van maken, met name omdat men óók nog even Linux-alternatief FreeBSD aandraagt als slachtoffer van IBM’s Linux tactieken. De eis bij deze beschuldiging is overigens dat de aankoop van Red Hat ongedaan gemaakt moet worden, wat in theorie kan maar volgens mij nog nooit met succes geëist is.

Het wachten is nu op de eerste reactie van IBM. Echt een kloon van de SCO soap zou ik dit niet meteen willen noemen, de feitelijke beschuldigingen zijn daarvoor te concreet. Maar je mag het een reboot noemen met een nieuwe regisseur.

Arnoud

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

| AE 12602 | Intellectuele rechten | 10 reacties

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

Laten we ophouden te doen of het EPO ooit wat nieuws over softwarepatenten bepaalt

| AE 12562 | Intellectuele rechten | 3 reacties

Naar aanleiding van het persbericht van het EPO over de laatste uitspraak inzake softwarepatenten kreeg ik vele vragen, allemaal met de strekking “zijn softwarepatenten nu alsnog legaal geworden”. Het maakt nogal indruk natuurlijk: de Grote Kamer van Beroep bepaalde dat simulatiesoftware octrooieerbaar kan zijn, en dus niet categorisch uitgesloten zijn. Maar al meer dan twintig jaar gaat het over “kan”, en nooit over “is”. Want dat is het fundamentele probleem: het EPO neemt geen harde stelling, maar interpreteert het Europees Octrooiverdrag soort van pro-softwareoctrooi maar tegelijk ook weer niet. En elke nieuwe zaak voegt weer een nieuwe kronkel toe, zoals ook hier.

Deze zaak ging over het simuleren van systemen, een op zich relevante tak van sport binnen de technologie. Het is handig als je het rijgedrag van een nieuwe auto kunt simuleren, of in een computer kunt testen of een nieuwe chip zuiniger, sneller of wat dan ook is voordat je het ding van plakjes silicium gaat maken. Dus een betere simulatie-omgeving is dan goed voor de technologie, want dan komt de simulatie dichter bij de werkelijkheid.

Het probleem zit hem al sinds 1974 in de Europese octrooiwet: daar staat dat “software als zodanig” niet voor octrooi in aanmerking komt (idem voor algoritmen, wiskundige technieken trouwens). Maar wat betekent dat nou? Vele woorden zijn erover geschreven – vaak boos – maar nooit is er een definitieve uitspraak gekomen. Het EPO heeft zelf ook not een duidelijk standpunt in willen nemen maar is blijven modderen in de marge. Het begon bij de zogeheten IBM uitspraken eind jaren negentig, waarin men soort van erkende dat software die een bestaand systeem iets technisch nieuws laat doen, dat systeem ook technisch nieuw maakt. Dit omdat diezelfde vernieuwing gebakken op een chip toch ook octrooieerbaar zou zijn, en wat is het verschil tussen software in een geheugentje en een chip die exact hetzelfde doen?

Vervolgens kom je dus in een enorm moeras terecht over zaken als “hetzelfde” en wat te doen met de niet-technische aspecten van zo’n nieuw systeem. Daar heb ik ooit een serieus artikel over geschreven, maar daarna had ik wel een week vakantie nodig. De kern van de aanpak komt op het volgende neer:

  1. We kijken allereerst of het systeem als geheel iets technisch heeft of doet. Indien niets, dan is het “software als zodanig”.
  2. Als dat wel zo is, kijken we wat er technisch nieuw aan is.
  3. We bedenken een probleem dat door dat nieuwe wordt opgelost, en we kijken of die oplossing voor de hand lag gezien dat probleem.
  4. Eventuele niet-technische dingen aan het systeem zijn deel van het probleem (“business requirements”, als het ware)
Dat punt 4 ligt niet goed bij octrooigemachtigden, omdat je normaal de nieuwe dingen niet mee mag laten doen aan het probleem. Want alles ligt voor de hand als je de oplossing kent, dus delen van de oplossing mogen niet in het probleem staan. Dus.

Maar goed, het EPO hanteert nu deze truc waardoor men vrij gemakkelijk de meeste softwarepatentaanvragen af kan schieten: je noemt iets “niet-technisch”, en je zegt vervolgens dat het probleem is hoe je dat niet-technische wilt implementeren en dan heb je eigenlijk de hele uitvinding al onderuit gehaald. Ja, dat werkt, maar om nou te zeggen dat daar diepe fundamentele redeneringen aan ten grondslag liggen, nee.

En van tijd tot tijd worden er dus nieuwe uitspraken gedaan over wat nou wel of niet “niet-technisch” mag zijn en wat dan “technisch” zou kunnen betekenen. Nu is er dus een nieuwe uitspraak aan het spectrum toegevoegd, namelijk over het simuleren van al dan niet technische systemen. Ik citeer even:

The Enlarged Board stated that a claimed feature of a computer-implemented invention may contribute to the technical character of the invention not only if it is related to a technical effect in the form of input (e.g. the measurement of a physical value) or output (e.g. a control signal for a machine). Such a direct link with physical reality is not required in every case. In particular, technical effects may also occur within the computer-implemented process (e.g. by specific adaptations of a computer or of data transfer).
Dit gaat dus over die eerste stap: een simulatiesysteem kan technisch zijn als de simulatie een technisch effect laat zien. (Ja, dat is een kwestie van labeltjes. U begint ‘m te voelen.) Dat effect hoeft niet perse te zijn dat het in de echte wereld ook zo werkt. (Precies.) Het kan ook iets zijn in de computer zelf, maar dan moet het wel meer zijn dan enkel dat er stroompjes gaan lopen in de computer. Maar wat dan? Nou ja, iets technisch. Dat zeggen we net.

Nou ja, u voelt de conclusie hopelijk al aankomen: dit voegt niets nieuws toe en hakt in ieder geval geen knopen door. Er is niets veranderd, er kon niets gepatenteerd worden dat niet al kon en er is niet ineens een categorie uitvindingen uitgesloten van octrooi. En zo zal het nog lange tijd doorgaan. Een echte gedurfde nieuwe uitspraak, ik geloof er niet meer in.

Arnoud

 

Anti-embed trucjes hebben auteursrechtelijke kracht gekregen van het Hof van Justitie

| AE 12552 | Intellectuele rechten | 25 reacties

Het embedden of framen van andermans werk in je eigen site is tegenwoordig ook al auteursrechtinbreuk, althans soms. Dat maak ik op uit een recente beslissing van het Hof van Justitie (C-329/19) over een zaak waarbij foto’s van kunstwerken werden geëmbed. Het is dus niet, zoals Mr het samenvat, dat je mag beslissen of je wordt geframed…. Lees verder

Gastblog: Ervaring uit de praktijk: hoe kun je het beste reageren bij een online auteursrechtinbreuk (3/3)

| AE 12481 | Intellectuele rechten | 54 reacties

Deze gastblog is geschreven door een bezoeker die anoniem wenst te blijven. Hij is meester in de rechten en procedeert regelmatig, maar is in het dagelijks leven niet werkzaam als jurist. In de voorgaande twee blogs heb ik een situatie beschreven waarin de beheerder van een website eigenlijk niet zoveel fout deed, maar toch met… Lees verder

Gastblog: Ervaring uit de praktijk: auteursrechtinbreuk (2/3)

| AE 12479 | Intellectuele rechten | 13 reacties

Deze gastblog is geschreven door een bezoeker die anoniem wenst te blijven. Hij is meester in de rechten en procedeert regelmatig, maar is in het dagelijks leven niet werkzaam als jurist. Vorige week in  Gastblog deel 1 de casus en de vraag: wat zou de rechter gaan doen? We gaan kijken hoe dat uitpakt, zo vertelt de… Lees verder

Is een contributor license agreement wel gunstig voor een OSS ontwikkelaar?

| AE 12468 | Intellectuele rechten | 19 reacties

Een lezer vroeg me: Ik wilde een bijdrage doen aan een opensourceproject. De stichting erachter geeft echter aan dat ik daarvoor een contributor license agreement (CLA) moet tekenen. Dit omdat OSS licenties problematisch zijn in Europa vanwege morele rechten? Enig idee hoe dat zit? En welke nadelen haal ik me op de hals? Een contributor… Lees verder

Gastblog: Ervaring uit de praktijk: auteursrechtinbreuk (1/3)

| AE 12474 | Intellectuele rechten | 28 reacties

Deze gastblog is geschreven door een bezoeker die anoniem wenst te blijven. Hij is meester in de rechten en procedeert regelmatig, maar is in het dagelijks leven niet werkzaam als jurist. Mijn cliënt heeft ongeveer tien jaar geleden in zijn studententijd een website opgezet die een soort wiki is voor een specifieke beroepsgroep in Nederland…. Lees verder

Facebook moet 3,83 miljoen euro betalen aan ontwikkelaar wegens kopiëren Nearby

| AE 12443 | Intellectuele rechten | 6 reacties

Een Italiaanse rechtbank heeft in hoger beroep bepaald dat Facebook 3,83 miljoen euro moet betalen aan de Italiaanse softwareontwikkelaar Business Competence. Dat las ik bij Tweakers. Een Italiaanse rechtbank vonniste dat de dienst het auteursrecht op een app (genaamd Faround) heeft geschonden door haar eigen concurrerende dienst. Opmerkelijk aspect: dat lijkt met name het geval te… Lees verder