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

| AE 10509 | Software | 13 reacties

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

Licentiecodes meenemen van je werk is geen diefstal

| AE 10503 | Arbeidsrecht, Software, Strafrecht | 18 reacties

Een licentiecode meenemen van je werk als je ontslag neemt, is geen diefstal of heling. Dat vonniste de rechtbank Den Haag onlangs. De verdachte in deze strafzaak had ontslag genomen en wilde kennelijk met die licentiecode goede sier maken bij de nieuwe werkgever, iets dat de oude werkgever zó ernstig vond dat men aangifte deed, en bij het OM vonden ze het ook ernstig genoeg om te vervolgen. Maar de rechtbank ziet hier geen diefstal in, omdat een licentiecode immers geen ‘goed’ is dat je kunt stelen.

De precieze reden voor het meenemen kan ik niet uit het vonnis halen, maar ik lees dat diverse werknemers tegelijk ontslag namen en bij de concurrent gingen werken. Deze werknemer had in dat verband die licentiecode voor een Amerikaans softwarepakket naar zichzelf gemaild vanaf het werk. De werkgever kwam hierachter en deed aangifte.

De verdachte werd formeel vervolgd voor het misdrijf bekendmaken van vertrouwelijke informatie (schending van bedrijfsgeheimen). Het is namelijk strafbaar om door misdrijf vertrouwelijke bedrijfsgegevens te achterhalen en bekend te maken (artikel 273 Strafrecht). Dat kan ook gaan om digitale informatie, en bij licentiecodes zie ik wel waarom je die als vertrouwelijk zou aanmerken.

Voor de rechtbank was er echter een principieel bezwaar: welk misdrijf dan? Want de verdachte was op zich gerechtigd in de computer van de werkgever die licentiecode op te vragen, dus er was geen sprake van computervredebreuk.

Je zou dan eerder van diefstal of verduistering moeten spreken, net zoals je het diefstal noemt als een werknemer legaal de kantine in gaat en een zak met koffiebonen meeneemt. Maar voor diefstal (of verduistering) is vereist dat er een ‘goed’ wordt weggenomen. En volgens de jurisprudentie kan dat alleen als het slachtoffer de feitelijke macht over die informatie verliest zodra de dader zich deze toe-eigent.

Bij objecten in virtuele werelden is voorstelbaar dat je spreekt van “feitelijke macht verliezen”. Als speler B dat zwaard te pakken krijgt van A, dan heeft A het automatisch niet meer. Idem voor zeg een bitcoin of een belminuut. Maar bij een licentiecode is daarvan geen sprake. De code is dan op twee plaatsen aanwezig, en twee partijen hebben er dan macht over. Daarom geen diefstal en dus geen strafbaar onthullen van bedrijfsgeheimen.

Op zich een logische uitkomst, zeker als je bedenkt dat de volgende Wet Computercriminaliteit dit expliciet wél strafbaar gaat stellen. A contrario redenerend doe je dat alleen als het nu niet strafbaar is, dus is het nu niet strafbaar.

Arnoud

Wat moet ik doen als mijn klant me productiedata geeft om te testen?

| AE 10350 | Beveiliging, Privacy, Software | 19 reacties

Een lezer vroeg me:

Wij ontwikkelen enterprisesoftware voor klanten, en testen deze uiteraard ook. Meestal ontvangen we daarvoor de testdata van de klant en soms zit daar ineens productiedata tussen inclusief persoonsgegevens. Zijn wij daarvoor aansprakelijk onder de GDPR?

Het is uiteraard een goed idee om software te testen alvorens je deze gebruikt, zeker wanneer die software persoonsgegevens gaat verwerken. Dergelijke software moet immers veilig zijn en voldoen aan de beginselen van privacy by design en privacy by default.

Goede testdata is daarbij van belang, maar is vaak moeilijk te krijgen. Daarom zie je regelmatig dat er toch met productiedata wordt getest, dat is dan de enige bron van een grote hoeveelheid uiteenlopende data waarmee genoeg aspecten getest kunnen worden.

Handig, maar erg problematisch: je weet immers per definitie nog niet of de software veilig is en wel privacytechnisch dichtgetimmerd is. Daarmee neem je als bedrijf (de klant dus van de vraagsteller) een serieus risico op datalekken. Bovendien moet je met je wederpartij (zoals de vraagsteller dus) een verwerkersovereenkomst sluiten waarin je de omgang met deze data expliciet reguleert, en dat wordt vaak vergeten want “het is maar om te testen”.

Het ontwikkelbedrijf zou ik adviseren om expliciet in de overeenkomsten op te nemen dat er géén productiedata wordt geleverd en al helemaal niets waar persoonsgegevens in zit. Een anti-verwerkersovereenkomst, zeg maar. Stuurt de klant die dan toch, dan heb je in ieder geval een sterk argument dat dit niet de bedoeling was. Uiteraard moet je dat bij ontdekking wel melden en die data vervolgens meteen wissen.

Arnoud

Mag Destiny achteraf de inhoud van een game aanpassen?

| AE 10007 | Cloud, Software | 6 reacties

Onlinespelaanbieder Bungie heeft bepaalde spelelementen uit Destiny 2 vergrendeld voor bezitters van de game die niet de nieuwe Curse of Osiris downloadable content kopen, zo las ik bij Tweakers vorige week. Deze spelelementen waren origineel wel inbegrepen, maar wie de aanschaf van deze download weigerde, blijkt niet langer in staat om alle inhoud van het… Lees verder

Moet alle oude software worden afgeschaft onder de Privacyverordening?

| AE 9721 | Privacy, Software | 16 reacties

Een lezer vroeg me: De Algemene Verordening Gegevensbescherming (AVG of GDPR) stelt strenge eisen aan ICT-systemen, zoals privacy by design en beveiliging. Hebben wij nu een probleem met al onze legacy software? Op 25 mei 2018 wordt de Algemene Verordening Gegevensbescherming (AVG of GDPR) van kracht. Deze gaat een grote verandering opleveren bij alle bedrijven… Lees verder

Kun je Microsoft aansprakelijk stellen voor schade uit een ransomware-aanval?

| AE 9521 | Aansprakelijkheid, Software | 25 reacties

De computersystemen zijn nog steeds niet bruikbaar, zo liggen beide containerterminals van APM in de Rotterdamse Haven nog steeds stil. Dat las ik bij Bright. De ransomware Petya wist vele computers te gijzelen in de IT-omgeving van de Haven, en dat is niet eenvoudig op te lossen. De reden blijkt een bug in Windows, die… Lees verder

Ministers stelt ontwikkelaars aansprakelijk voor softwarefouten

| AE 9502 | Aansprakelijkheid, Software | 23 reacties

Demissionair staatssecretaris Klaas Dijkhoff heeft in een Kamerbrief gezegd zegt dat softwareontwikkelaars op verschillende manieren aansprakelijk zijn voor schade die als gevolg van hun product ontstaat. Dat las ik bij Tweakers. Juridisch gezien zegt hij weinig nieuws; de regels over conformiteit bij producten bevatten immers geen uitzondering voor de software-delen van producten. Nieuw is wel… Lees verder

Mag ik mensen certificeren als Agile scrum master?

| AE 9331 | Merken, Software | 22 reacties

Een lezer vroeg me: Mag je zomaar een certificaat ontwikkelen en uitgeven? Wij geven trainingen en workshops in Scrum, een vorm van Agile. Andere opleiders geven een certificering uit. De cursist is na het volgen certified scrum master, certified agile coach et cetera. Kan dit zomaar c.q. kunnen wij dit ook doen? De term ‘certificaat’… Lees verder

Moeten we echt elk jaar de copyrightvermelding in onze broncode updaten?

| AE 9248 | Software | 23 reacties

Een lezer vroeg me: Alle broncodes binnen ons bedrijf hebben een copyrightvermelding, als volgt: Copyright © 2016 $NAAM THIS SOURCE CODE IS THE UNPUBLISHED AND CONFIDENTIAL PROPERTY OF $NAAM< AND MAY NOT BE COPIED, MODIFIED OR DISTRIBUTED WITHOUT PRIOR WRITTEN AUTHORIZATION. (Iets ingekort in verband met leesbaarheid.) Nu moet ik al die notices aanpassen want... Lees verder

Google moet wél buitenlandse e-mails overdragen aan de FBI

| AE 9261 | Privacy, Software | 19 reacties

Een Amerikaanse rechter heeft bepaald dat Google ook e-mails die op servers buiten de VS zijn opgeslagen moet overdragen aan de FBI in een zaak over binnenlandse fraude. Dat meldde Nu.nl onlangs. Deze beslissing staat lijnrecht tegenover de hogerberoepszaak van Microsoft dat géén berichten opgeslagen in het buitenland hoefde af te geven aan de Amerikaanse… Lees verder