Moet je anno 2022 de broncode van Linux meeleveren?

| AE 13396 | Intellectuele rechten, Ondernemingsvrijheid | 10 reacties

Een lezer vroeg me:

Bij de ontwikkelaars van Arch Linux is discussie ontstaan over het mee moeten leveren van de broncode van de GPL software die daar deel van uitmaakt. Vanwege bandbreedte/opslagbeperkingen wil men dit liever niet, maar de GPL lijkt duidelijk te zijn dat het wel moet. Zijn er juridische opties?
Arch Linux is een Linuxdistributie die zich richt op gevorderde Linuxgebruikers die een snel, stabiel, lichtgewicht en minimalistisch systeem willen hebben. (Aldus Wikipedia.) Een bekende feature van Arch is het Pacman package systeem, waarbij je snel voorgecompileerde applicaties kunt downloaden.

Een punt daarbij is dat je Arch Linux en de applicaties vaak alleen in gecompileerde vorm aantreft. Dat is lastig vanuit de GPL, de meestgebruikte open source licentie, die immers eist dat je de broncode erbij doet.

Het is natuurlijk eenvoudig om zo’n package tot de bron(code) te herleiden als je dat graag wil, en vanwege het gemak en de doelgroep zullen weinigen hier een punt van te maken. Maar dat heeft nog nooit een advocaat weerhouden om op een licentie-overtreding te wijzen.

Veel software in de Linux context is GPL versie 2. Deze licentie (uit 1991) is vrij simpel: je doet de broncode erbij, of een brief waarin je zegt dat jij de broncode op verzoek nastuurt. Dat moet je zien in de context van 1991, namelijk dat broncode online vinden en downloaden lastig en tijdrovend is. Een doosje floppies per post was sneller dan een modem (dit was voordat Al Gore het internet uitgevonden had namelijk). Het achterliggende argument dus: je mag de ontvanger het niet moeilijk maken, het is jouw probleem dat deze de broncode (gratis) kan krijgen.

Een contractuele eis wordt door de rechter altijd gelezen in de context van de huidige situatie. Anno 2022 zal voor de meeste mensen (in de Westerse wereld dan) het downloaden van broncode sneller zijn dan een doosje met een USB-stick laten versturen per post. Zeker voor developers, de doelgroep van de broncode-eis. Het lijkt mij dan ook zeer te verwachten dat een rechter mee zal gaan met het argument dat een URL van de broncode hetzelfde is.

GPL versie 3 vermeldt expliciet dat het mogelijk is de broncode ergens anders vandaan te laten komen (artikel 6 sectie d), zelfs als die ergens anders bij een ander onder beheer is. De eis is alleen dat jij (als verspreider van de gecompileerde code) er voor zorgt dat de broncode beschikbaar blijft op de aangegeven plek.

Arnoud

 

Broncode van originele WipEout-game voor PSX en Windows verschijnt online

| AE 13253 | Ondernemingsvrijheid | 1 reactie

De originele broncode van de eerste WipEout-game is op internet verschenen, las ik bij Tweakers. Een groep historici heeft de broncode gevonden van de futuristische game uit 1995, een van de launchgames van de originele PlayStation. Men meldt op Twitterr dat onduidelijk is of de code zal compileren, en verzoekt vriendelijk doch dringend niet te vragen om licenties want men is de uitgever (Psygnosis) niet. Psygnosis, u wellicht bekend van Lemmings, is in 2012 opgeheven. Wat natuurlijk de vraag oproept, wat is de auteursrechtelijke status van deze software?

Het makkelijke antwoord is natuurlijk: er zit auteursrecht op die software, want het is in 1995 voor het eerst verschenen, de maker is een bedrijf dus 70 jaar daarna: 1 januari 2066. Maar de complicatie is dan, wat is er gebeurd met de auteursrechten toen in 2012 de studio werd gesloten. Wanneer de rechthebbende ophoudt te bestaan, verdwijnen ook de auteursrechten.

Tenzij natuurlijk de rechten voor de opheffing zijn overgedragen of verkocht. Dat is bij auteursrechten een eenvoudige handeling, een stuk papier met handtekening en klaar ben je. Gezien Psygnosis door megacorp Sony is gekocht in 1993, zou het mij hogelijk verbazen als niemand hieraan gedacht heeft voordat men de boel ophief. Van WipEout kan ik het niet vinden, maar van Lemmings staat vast dat de rechten bij Sony liggen. Ook las ik dat Sony recent een beeldmerk van Psygnosis heeft hernieuwd, wat alleen maar kan als je er de rechthebbende van was. Dan durf ik wel te zeggen, iemand heeft destijds alle IP van Psygnosis overgedragen naar Sony.

Kun je je wellicht beroepen op de juridische regeling voor abandonware? Artikel 16o van de Auteurswet bepaalt namelijk dat je in sommige gevallen werken mag herpubliceren zonder toestemming, wanneer de rechthebbende niet te vinden blijkt. Maar dit artikel geldt niet voor software (alleen voor boeken, tijdschriften, films, series en muziek en dergelijke), nog los van het feit dat deze uitzondering alleen opgaat voor erfgoedinstellingen, museums en onderwijsinstellingen.

Maar stel nou eens dat ze bij Sony vergeten waren deze rechten mee te nemen. Dan kun je je inderdaad afvragen waar de auteursrechten zijn gebleven. Verdedigbaar is dat die dan in het niets zijn opgelost, net zoals de achtergelaten bureaustoel van niemand meer is als de curator de deur voor de laatste keer dichttrekt, de verhuurder de sleutel terugkrijgt en alle rekeningen zijn vereffend. Maar ik neig zelf meer naar het standpunt dat het bedrijf dan niet écht opgeheven is. Een rechtspersoon blijft na ontbinding voortbestaan voor zover dit tot vereffening van zijn vermogen nodig is, zo staat in de wet. Ook zijn er mogelijkheden om een opgeheven bedrijf te laten herleven of heropenen als later blijkt dat er nog baten in de boedel zijn. Dat kan dus riskant zijn, want reken maar dat men dat gaat onderzoeken als iemand anders geld dreigt te gaan verdienen met de achtergebleven/vergeten auteursrechten.

U mag nu Lemmings spelen.

Arnoud

Mag je Legend of Zelda decompileren en een bitwise identieke versie maken?

| AE 13045 | Intellectuele rechten | 8 reacties

aerozol / Pixabay

Het Zelda Reverse Engineering Team meldt dat ze vrijwel klaar zijn met het decompileren van de binaries van The Legend of Zelda: Ocarina of Time voor de Nintendo 64. Dat las ik bij Tweakers vorige week. Nintendo is fel tegen fanprojecten zoals ports van hun games naar andere platformen, zo voegt men daaraan toe. Toch meent dit project legaal te opereren binnen het auteursrecht, wat natuurlijk de vraag oproept hoe dat dan zit met decompileren, namaken en porten van software.

Legend of Zelda is een klassieke serie voor Nintendo-gamers, en Ocarina of Time (1998) de bekendste uit de reeks. Het spel was echter nooit beschikbaar voor moderne computers, totdat dus deze groep enthousiaste programmeurs haar decompilatie voltooide. De binaries (de machine-leesbare code van het programma) zijn via decompilatie terugvertaald naar broncode, die door mensen, althans programmeurs, gelezen en aangepast kan worden.

Punt is alleen dat dat aanpassen (en het produceren van nieuwe binaries) inbreuk op auteursrecht is. Maar het RET doet dan ook iets anders: ze vogelen uit wat de N64 binaries doen, en schrijven dan zelf broncode die na compilatie datzelfde doet. Dat is géén inbreuk op auteursrechten, want achterhalen wat iets doet is legaal, en in je eigen woorden dat navertellen is dat ook.

Deze nieuwe code is dus een soort van spirituele kloon: hij doet hetzelfde, maar op een eigen manier en zonder code van Nintendo over te nemen. Maar daarmee is men er nog niet:

But even though the game’s code has been fully decompiled, there’s still a lot of remaining work for the ZRET team including creating documentation, re-naming and re-organisation of code and definitions, and support for asset-handling so viewing or modifying on modern computers is easier.
Zodra je natuurlijk originele beelden van personages (of achtergronden of andere assets) uit het spel gaat overnemen, trap je alsnog in de auteursrechtinbreuk. Ik ben benieuwd hoe ze dat gaan oplossen.

Ook heel benieuwd ben ik naar hun reden om te gaan voor een bit-for-bit identieke binary als uitkomst, in plaats van enkel een functioneel identiek spel. Want hun streven is dus echt om hun eigen code zo te maken dat deze na compilatie en linken (haha) exact uitkomt op dezelfde nullen en enen als het origineel van Nintendo. Dat voelt voor mij als een moeilijke manier om een kopie van die nullen en enen te maken, en dat is inbreuk. Maar het zal wel een hoger artistiek doel dienen?

Arnoud

Eh nee, F12 indrukken bij een website is geen criminele handeling

| AE 12980 | Ondernemingsvrijheid, Security | 24 reacties

(Geen zorgen, nog een keer F12 en je scherm is weer normaal.) Het ziet er misschien heel imponerend uit, maar dit is gewoon het onderwaterscherm waarmee je onder meer de broncode van de huidige site in beeld krijgt. Dan kun je soms net iets meer informatie zien. Zoals recent journalist Josh Renaud uit Missouri ontdekte: de social… Lees verder

Ga er maar aanstaan als deskundige: moet die broncode opnieuw geschreven?

| AE 12312 | Ondernemingsvrijheid | 40 reacties

Deskundige vereist voor beoordeling gebrekkige broncode, meldde ITenRecht onlangs. In een automatiseringsgeschil tussen softwareontwikkelaar Capgemini en haar klant Equihold (die de software wilde inzetten bij onder meer FC Barcelona) ontstond discussie over de kwaliteit van de tot dan toe gemaakte broncode. Een mooi voorbeeld van hoe de rechtspraak omgaat met inhoudelijk diepgaande issues. Ik las laatst… Lees verder

Wat mag ik met snippets van Stack Overflow?

| AE 11706 | Intellectuele rechten | 17 reacties

Een lezer vroeg me: Zoals vele ontwikkelaars neus ik vaak op Stack Overflow naar oplossingen voor mijn programmeerproblemen. Ik zie dan vaak broncode die de oplossing implementeert, maar ik weet dat ik die niet zomaar mag copypasten in verband met licentieproblemen. Maar wat mag ik dan wel? Stackoverflow is de bekendste site voor programmeurs om… Lees verder

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

| AE 9248 | Intellectuele rechten | 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

Mag je software reverse engineeren om fouten te vinden?

| AE 8023 | Intellectuele rechten, Security | 31 reacties

Een lezer vroeg me: Is reverse engineering legaal als het doel is om beveiligingslekken te vinden? Jij zei ooit van wel, maar in de wet staat volgens mij dat je alleen mag reverse engineeren om compatibiliteit te realiseren. Oef, dat is lang geleden, maar inderdaad: Alleen die vormen waarmee je compatibiliteit met zelfgeschreven software wilt… Lees verder

Schendt HTC de GPL door broncode vertraagd te publiceren?

| AE 2269 | Intellectuele rechten | 29 reacties

Een lezer wees me (dank!) op een bericht bij Freedom to Tinker waar werd gesignaleerd dat de Android-gebaseerde HTC smartphone Linux draait, maar de broncode maar moeizaam beschikbaar komt. Linux is open source (GPL versie 2) en de broncode moet dus meegeleverd worden (of er moet een schriftelijk aanbod bij zitten waar staat waar je… Lees verder