De legaliteit van reverse engineeren - hardware en drivers
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
