Een lezer vroeg me:
In deze presentatie vertelt iemand hoe hij een emulator aangepast heeft zodat hij z’n iPod kan emuleren. Daarbij valt me op dat hij toegeeft gelekte (gestolen) source code van Apple te hebben gebruikt. Is dat dan niet vreselijk riskant om zo in het openbaar te zeggen?Dit is inderdaad een opmerkelijke. Ik citeer even uit de video:
But it turned out the iBoot source code got leaked in 2018. I was very lucky with that. I don’t know who leaked it, but I am very grateful for them. Because it really helped me understand […].In 2018 lekte inderdaad de broncode uit van het deel van Apple’s iOS besturingssysteem dat voor het opstarten (booten) zorgt. Apple being Apple leidde dat natuurlijk tot vele juridische dreigementen. Het bleek om een werknemer te gaan, en al snel werd duidelijk dat de code intussen verouderd was en daarmee niet echt meer commerciële waarde.
Deze persoon had er echter toch wel baat bij: de broncode gaf gedetailleerde inzichten in hoe de iPod opstart en daarmee hoe deze precies in elkaar zit. Dat heb je weer nodig om een emulator te maken – een softwaretool die zich voordoet als een iPod, zodat applicaties voor dat platform daarmee gebruikt kunnen worden.
Is dit juridisch riskant? Allereerst het stukje van de gelekte geheimen. Die broncode was inderdaad een Apple bedrijfsgeheim, maar door het lek is die status er wel behoorlijk af ondertussen. Dat is het probleem met geheimen: als het eenmaal op straat ligt, dan is die status weg. En dan kun je blaffen wat je wilt als IP-advocaat, maar het wordt écht niet meer terug een bedrijfsgeheim.
Auteursrecht blijft natuurlijk wél gewoon bestaan bij een ongeautoriseerde publicatie (openbaarmaking en/of verveelvoudiging) van het werk. Apple kan dus zeer zeker op grond van haar auteursrecht verwijdering van die broncode eisen waar ze die ook ziet. Bij het eerste lek was ze er ook zeer snel bij met een DMCA takedown.
Deze meneer publiceert de broncode niet zelf: hij laat in de presentatie een paar screenshots zien met vooral feitelijke informatie, en legt uit dat hij zo vele inzichten kreeg en details kon achterhalen over de werking van het systeem, die dan weer zijn emulator kon.
Ideeën en principes halen uit een werk is geen inbreuk op het auteursrecht. Je schendt namelijk pas het recht als je het creatieve, het originele kopieert of herpubliceert. Zien dat je 42 moet zeggen als er een randapparaat aangezet wordt, is zeer zeker niet iets waar het auteursrecht wat van vindt. Dus de broncode door-akkeren en structuren, ideeën en namen documenteren is prima.
Wat niét mag, is die broncode even laten draaien en zien hoe het geheel werkt. Dat staat weliswaar in artikel 45l Auteurswet, maar dat geldt alleen voor mensen die bevoegd zijn de software te hebben:
Hij die bevoegd is tot het [laden, in beeld brengen, uitvoeren, transmitteren of opslaan van het software-werk], is mede bevoegd tijdens deze handelingen de werking van dat werk waar te nemen, te bestuderen en te testen teneinde de daaraan ten grondslag liggende ideeën en beginselen te achterhalen.Zo te luisteren is dat ook niet gebeurd, maar als achteraf blijkt dat er bepaalde technische informatie is verkregen die je alleen bij het werk-in-uitvoer had kunnen krijgen, dan heb je wel degelijk een probleem.
Is het nou handig dit zo te zeggen? Meh. Ik weet niet of Apple nu echt zó veel zorgen heeft over gelekte broncode uit 2016 die al in 2018 niet meer relevant was. Het betreft hier ook geen commercieel misbruik maar een particulier project om oude Apple-hardware te emuleren.
Arnoud
Eens met je analyse dat “deze persoon” vermoedelijk in het bezit is van een illegale kopie van Apple’s broncode. Er is geen regel in de auteurswet die je verbiedt deze kopie te lezen. (Jurisprudentie zegt wel dat de kopie in je editor ook illegaal is… Maar het aantal veroordelingen van particulieren voor bezit van illegale kopieën van software is laag.)
Je mag lezen en de informatie uit de gelezen code gebruiken in code voor een andere applicatie, zolang je maar geen code kopieert. In dit geval is het iets van “zo werkt Apple’s code en dat heeft dan deze implicaties voor de emulator”. Omdat een emulator iets heel anders is dan een bootloader is het (bijna) onmogelijk dat het kopiëren van de code zinvol is.
Ik begrijp wat je zegt, maar wat is nou het verschil met informatie die je verkrijgt door code uit te voeren? Dezelfde argumenten lijken daarvoor op te gaan (“Er is geen regel in de auteurswet die je verbiedt te kijken naar de output van een illegaal uitgevoerd programma.” en “Je mag lezen en de informatie uit de output gebruiken in code voor een andere applicatie, zolang je maar geen code kopieert.”) Toch schrijft Arnoud dat je een probleem hebt als je informatie gebruikt die je hebt verkregen door het uitvoeren van code.
Het verschil tussen kijken en kopiëren is dat na kopiëren er een kopie van (een deel van) de code rondzwerft. Dat loopt tegen de Auteurswet aan. Het uitvoeren van code is evenzo auteursrechtelijk verboden, tenzij je een licentie hebt.
Volgens mij praten we langs elkaar heen. Het gaat om de volgende twee situaties:
1: Een onderzoeker downloadt code van Github die daar zonder toestemming is geplaatst (lokale kopie maken is verveelvoudiging en dus inbreuk). Vervolgens leest hij de code en doet hij kennis op.
2: Een onderzoeker voert code uit (ook een verveelvoudiging en dus inbreuk) en doet kennis op.
Waarom mag hij de kennis die hij op de eerste manier opdoet wel gebruiken, en op de tweede manier niet?
Het verschil tussen 1 en 2 is dat je bij 1 de broncode zelf bestudeert, en bij 2 de code in uitvoering (bv in een debugger). Juridisch is dat anders, voor 2 is alleen een exceptie beschikbaar die eist dat je een licentie hebt om het werk uit te mogen voeren. Software in uitvoering bestuderen mag niet als je die software illegaal verkregen hebt.
Bij 1 gaat het wel mis omdat je geen software mag downloaden zonder licentie. Maar dat staat los van met je handen op de rug mogen kijken naar een vel papier op je bureau of broncode op je beeldscherm.
Dat volg ik niet. Als die man zelf legaal een iPod in zijn bezit heeft dan is hij toch gemachtigd die software te draaien? Als het goed is draait daar dezelfde software op als die hij draait vanuit zelf gecompileerde broncode. Als de minimale verschillen in compilatie-stijl uitmaken, dan impliceert dat ook dat Apple een ‘nieuw werk’ produceert elke keer als zij een compiler-flag aanpassen. Dat zou er bij mij niet in gaan.
Interessante opmerking! Maar hierbij komt het er ook op aan hoe de licentievoorwaarden geformuleerd zijn. Ik neem aan dat je bij de aankoop van een iPod een (impliciete) licentie voor het draaien van die software op die specifieke iPod verkregen hebt. Je mag die software dus op die iPod observeren (debuggen).
Maar betekent dat ook dat je die software onder je emulator mag draaien en daar debuggen? Sommige licenties zijn er heel duidelijk in dat de software maar op een specifieke machine uitgevoerd mag worden; anderen geven de gebruiker meer vrijheid. Ik zou graag weten wat Apple’s licentie zegt.
Het flauwe juridische argument is dat de software op je iPod niet hetzelfde is als de software op de harddisk van je laptop. Je hebt een licentie om die instantie op de iPod te draaien (en dus ook te observeren) maar niet om die andere instantie op je harddisk te draaien. Zeg maar zoals je ook niet jouw exemplaar van een boek mag omruilen met het exemplaar in de boekwinkel, ook niet wanneer jouw exemplaar nog volledig als-nieuw is.