Internetrecht door Arnoud Engelfriet

Een beveiligingsonderzoeker heeft het gedrag van de VoIP-software Skype onderzocht. Op basis van die reverse engineering heeft hij een groot deel van de code achterhaald, meldde Webwereld vrijdag. Daarop, zo meldde Phoronix, vloog Skype meteen in de tegenaanval, met gestrekt been, Zidane-kopstoot én kruistrap:

This unauthorized use of our application for malicious activities like spamming/phishing infringes on Skype’s intellectual property. We are taking all necessary steps to prevent/defeat nefarious attempts to subvert Skype’s experience. Skype takes its users’ safety and security seriously and we work tirelessly to ensure each individual has the best possible experience.

Nu kun je natuurlijk “gatver wat een rotopmerking” zeggen, maar we zijn hier een keurig juridisch blog (niet lachen daar achterin), dus laten we eens kijken naar de achterliggende vraag: mag je Skype reverse engineeren en daarmee je eigen Voice-over-IP-client op de markt brengen?

Reverse engineeren is een algemene term voor het uit elkaar halen van een product (of software) om te zien hoe dit opgebouwd is. Specifiek voor software worden ook wel termen als disassembleren of decompileren gebruikt, maar algemeen gesproken komen ze op hetzelfde neer: de software wordt uit elkaar geplozen en geanalyseerd om te zien hoe deze werkt. Omdat hierbij een kopie van de software wordt gemaakt, valt dit in principe onder het auteursrecht.

De Auteurswet zegt dat software mag worden gereverse-engineerd om interoperabiliteit van zelf ontwikkelde software met andere software tot stand te brengen. Zo mag een ontwikkelaar een eigen driver maken om de (embedded) software in de grafische kaart te kunnen besturen. Hij mag daarvoor de bestaande driver pakken en deze disassembleren: de binaire code uit elkaar halen om zo in één keer te zien wat de driver allemaal voor commando’s kan versturen en ontvangen. Ook mag hij het communicatieprotocol observeren en daarmee achterhalen hoe zijn eigen software moet werken.

Een lastige beperking aan het recht om te reverse engineeren is dat het moet gaan om het interoperabel maken van eigen software. In veel gevallen is het doel van reverse engineering eerder het maken van eigen software die hetzelfde doet als de software die uit elkaar wordt gehaald. Het ‘klonen’ van software via reverse engineering is echter expliciet verboden. Het voorbeeld van de driver hierboven is een grensgeval: weliswaar wordt de driver een soort van gekloond, maar het doel is om de eigen software met de software in de kaart te laten werken.

In de praktijk is dit lastig werkbaar: wie een driver disassembleert en dan een nieuwe driver maakt, zal al héél snel – bewust of onbewust – auteursrechtelijk beschermde delen overnemen. Als best practice geldt daarom het principe van de “Chinese muur”, waarbij twee teams samenwerken bij de ontwikkeling van software op basis van reverse engineering. Team A haalt de oorspronkelijke software uit elkaar en documenteert de functionaliteit. Team B ontvangt alleen deze documentatie en krijgt geen toegang tot de oorspronkelijke software. Daarmee kan team B zelf software maken zonder ‘besmet’ te zijn met de gereverse-engineerde broncode.

Speciaal voor protocollen ligt het net weer anders: je mag netwerkverkeer observeren en daaruit achterhalen hoe een protocol werkt. Als je dan zonder andermans client of server te bekijken je eigen implementatie van dat protocol maakt, is er juridisch niets aan de hand. Dat reverse engineeren van een protocol is niet waar de Auteurswet op doelt. Maar in het Skype-geval is niet alleen netwerkverkeer geanalyseerd maar ook de client van Skype zelf.

Arnoud
Afbeelding: Revealing Skype Traffic: When Randomness Plays with You, Dario Bonfiglio et al., SIGCOMM’07, August 27–31, 2007, Kyoto, Japan.

Een lezer vroeg zich af:

Is het rechtsgeldig in Nederland om in een EULA reverse engineering van een softwarepakketgeheel te verbieden, ook voor toepassingen als het maken van interoperable software?

Reverse engineering, in goed Nederlands decompilatie, is volgens artikel 6 van de Software-richtlijn een handeling die geen inbreuk op het auteursrecht oplevert.

Desondanks zie je regelmatig in EULAs een tekst als “reverse engineering is forbidden”, maar dat heeft geen juridische waarde. Artikel 9 lid 1 van diezelfde Richtlijn bepaalt dat “elk contractueel beding dat strijdig is met artikel 6″ nietig is. Oftewel, de rechthebbende kan zich op zo’n beding niet beroepen, en doet hij het toch dan hoef je alleen maar naar deze artikelen uit de richtlijn te verwijzen.

Een goed geschreven EULA of softwarelicentie bevat dan ook een tekst als “reverse engineering is verboden voor zover dat juridisch toegestaan is”. Niet alle vormen van reverse engineering zijn namelijk toegestaan onder de Richtlijn. Alleen die vormen waarmee je compatibiliteit met zelfgeschreven software wilt bewerkstelligen, of waarmee je alleen de achterliggende ideeën, concepten en principes achterhaalt zijn legaal. Met name is het niet legaal om de informatie te gebruiken om een kloon van de software te maken.

Arnoud

Mag je je iPhone nou wel of niet unlocken? Over die vraag is veel speculatie, maar Apple heeft zich er altijd over in stilzwijgen gehuld. Althans, tot vorig jaar december toen Apple een commentaar op de DMCA indiende bij het US Copyright Office. De oplettende lezers bij de EFF spotten daarin deze opmerking:

Current jailbreak techniques now in widespread use utilize unauthorized modifications to the copyrighted bootloader and OS, resulting in infringement of the copyrights in those programs. … Jailbreaking () involves infringing uses of the bootloader and OS, the copyrighted works that are protected by the TPMs being circumvented. Unauthorized derivative versions of the bootloader and OS have been created. Copies of those infringing works have been stored on web sites, and infringing reproductions of those works are created each time they are downloaded through Pwnage Tool and loaded onto the iPhone.

Op zich heeft Apple daar een punt. Bij jailbreaks moet de firmware aangepast worden. Hiervoor moet je deze uit de iPhone vissen, door een tooltje halen en in aangepaste vorm terugzetten. Ik begrijp niet helemaal waar Apple de stelling op baseert dat mensen die firmware op internet zet, maar het lijkt me duidelijk dat dat niet toegestaan is. Andermans software verspreiden vereist een licentie, en die is er niet voor software.

Maar mag je voor jezelf de firmware uit apparaten aanpassen? De EFF vindt van wel, en kwam met dit briljante argument:

But the courts have long recognized that copying software while reverse engineering is a fair use when done for purposes of fostering interoperability with independently created software, a body of law that Apple conveniently fails to mention.

Een recht dat wij in Nederland kennen in artikel 45m Auteurswet. Het maken van een kopie van een stuk software en het “vertalen van de codevorm daarvan” (ik vermoed dat men compileren bedoelt) is toegestaan als

deze handelingen onmisbaar zijn om de informatie te verkrijgen die nodig is om de interoperabiliteit van een onafhankelijk vervaardigd computerprogramma met andere computerprogramma’s tot stand te brengen

In de Richtlijn waar dit wetsartikel uit komt, staat dat “deze uitzondering onder meer ten doel heeft het mogelijk te maken alle componenten van een computersysteem, ook die van verschillende fabrikanten, aan elkaar te koppelen, zodat die systemen samen kunnen functioneren”.

En laat dat nou precies het doel zijn van jailbreaken: applicaties te laten werken op het OS van Apple, ook als ze niet door Apple zijn goedgekeurd.

Slim gevonden, nietwaar?

Arnoud
Foto via Crunchgear.

Het is toegestaan om te achterhalen hoe dingen werken. Heb je een mooie grafische kaart gekocht, en wil je weten welke signalen deze afgeeft, dan mag je gerust met je multimeter aan de slag. Wil je zien hoe je televisie er van binnen uitziet, veel plezier met de schroevendraaier. De garantie vervalt natuurlijk wel, maar dat terzijde.

Wil je met die informatie een eigen product bouwen, dan mag dat ook. Ideeën en technische principes zijn vrij. Daar is één uitzondering op: je kunt tegen octrooien aanlopen natuurlijk. Voor een octrooi maakt het niet uit of je het product zelf gemaakt hebt of hebt afgekeken: als het doet wat in het octrooi staat, pleeg je inbreuk.

Afgezien van octrooien is het reverse engineeren van de werking van hardware dus legaal. Dat is erg handig voor bijvoorbeeld open source zoals Linux, waarvoor minder aanstuursoftware (drivers) voor hardware beschikbaar is dan bij Windows. Een open source-ontwikkelaar mag dus kijken welke commando’s er van de driver op de PC naar een hardwarekaart (of terug) gestuurd worden en welk effect dat heeft. Hij kan daarmee zijn eigen driver maken die op het juiste moment de juiste commando’s stuurt. Dit mag: artikel 45l Auteurswet bepaalt dat een licentienemer van de software mag achterhalen hoe de software werkt “teneinde de daaraan ten grondslag liggende ideeën en beginselen te achterhalen.” Daaronder valt ook het achterhalen van de communicatie tussen de driversoftware en de hardware.

Een nadeel van deze aanpak is dat je dan niet zeker weet dat je alle situaties gehad hebt. Misschien is er wel een commando dat alleen gestuurd wordt als de kaart erg warm wordt, of wanneer iemand een resolutie van 1194×768 pixels gebruikt en een 3D-bal wil laten stuiteren als screensaver.

Een betere oplossing is dan ook de bestaande driver pakken en deze disassembleren: de binaire code uit elkaar halen om zo in één keer te zien wat de driver allemaal voor commando’s kan versturen en ontvangen. Daarmee is dan een nieuwe driver te maken die hetzelfde doet, maar dan voor Linux.

Deze oplossing ligt juridisch iets lastiger. Software is beschermd door auteursrecht. Bij reverse engineeren moet je de software uitvoeren om te kunnen zien wat hij doet. Dat is normaal inbreuk op het auteursrecht. Maar voor deze vorm van reverse engineering is er artikel 45m.

Dit artikel zegt dat je mag reverse engineeren om interoperabiliteit van je eigen software met andere software tot stand te brengen. Bijvoorbeeld dus je eigen driver maken om de (embedded) software in de grafische kaart te kunnen besturen. Het recht is in zoverre beperkt dat je alleen datgene mag reverse engineeren wat je nodig hebt om je eigen driver te kunnen maken.

Dit artikel is natuurlijk ook relevant voor andere soorten software, zoals de vele open source alternatieven voor gesloten software zoals Microsoft Office. Daar kom ik binnenkort op terug, want de situatie is daar iets minder rooskleurig dan bij drivers.

Hoe dan ook, je mag dus een driver reverse engineeren en met de gevonden informatie je eigen driver maken. Wat niet mag, is stukken van de oorspronkelijke driver overnemen in je eigen driver. Dan pleeg je inbreuk op het auteursrecht. Je mag alleen achterhalen wat de driver doet, en vervolgens moet je je eigen software schrijven die dezelfde activiteiten verricht. Zonder te kijken op welke slimme manier de oorspronkelijke software dit doet.

Dat zal bij drivers gelukkig niet altijd een groot probleem zijn. De implementatie van een driver is namelijk voor een groot deel bepaald door de hardware. Er moet nu eenmaal code 0×31337 gestuurd worden om een bepaald beeld op het scherm te tonen, en als de printer de code 0xDEADBEEF stuurt, dan is het papier op en moet het printen tijdelijk ophouden. Daardoor zit er weinig creatieve ruimte voor programmeurs bij het schrijven van drivers. Hoewel dus een nieuwe driver voor een deel zal lijken op het origineel, komt dat door die technisch bepaalde factoren. En iets dat hetzelfde is vanwege een technische eis, is geen inbreuk op het auteursrecht.

Bij dit soort activiteiten wordt wel de bewijslast omgekeerd: als beide drivers hetzelfde doen, moet de maker van de nieuwe driver bewijzen dat hij geen code heeft overgenomen van de oorspronkelijke driver. Vandaar de clean-room praktijk: laat de ene persoon achterhalen en documenteren wat de driver doet, en laat een andere persoon op basis van die documentatie een nieuwe driver schrijven. De andere persoon kan dan geen code hebben overgenomen, want daar had hij geen toegang toe. En de eerste persoon heeft geen code geschreven, en heeft dus ook geen inbreuk gepleegd.

Deze bepalingen zijn dwingend recht. Dat betekent dat dit recht niet in een softwarelicentie (EULA) verboden kan worden. Staat het toch in een EULA, dan zal de rechter die clausule negeren.

Arnoud