Tag: Broncode

About Broncode

Subscribe Feeds

Moet je anno 2022 de broncode van Linux meeleveren?

Geplaatst op in 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

Geplaatst op in Ondernemingsvrijheid, 1 reacties

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?

Geplaatst op in 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

Geplaatst op in 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 security nummers van tienduizend docenten uit de staat. Mag dat? Nee, dat is crimineel, aldus gouverneur Mike Parson. Moehaha kom nou, aldus de hele wereld.

Het bronbericht geeft een 451 error (lawyer says no) vanuit Europa, maar het betrof een zoekfunctie voor docenten, waarbij de zoekresultaten werden meegegeven aan de resultaatpagina inclusief hun social security number, zeg maar hun bsn. Bij het programmeren van de site bedacht iemand toen dat dat niet echt handig is om te publiceren, dus werd het verborgen in de uitvoer. Maar het stond dus nog gewoon in de broncode, en die krijg je te zien met een druk op de knop.

Een datalek, zouden wij in Europa zeggen. Een beperkte security. Want als die data niet zichtbaar hoeft te zijn in resultaten, dan hoeft deze ook niet mee naar de webpagina om daar vervolgens buiten beeld te blijven. Dan houd je dat gewoon lekker op de server. Afijn, de melding werd opgepakt, de fout werd hersteld, daarna pas publiceerde men, weinig bijzonders.

Bijzonder was wel de reactie van de gouverneur, want in de vertaalslag omhoog naar het politieke ging iets mis. “Onze server stuurde bsn’s mee en dat kon iedereen zien die op F12 drukt” werd namelijk dit:

Through a multi-step process, an individual took the records of at least three educators, decoded the HTML source code, and viewed the SSN of those specific educators.
Die meer dan drie klopt (het waren er 100.000), de rest is laten we zeggen een ietwat complexe voorstelling van zaken. Die multi-step is namelijk dat je een zoekopdracht doet, de resultaatpagina krijgt, F12 drukt en in de broncode scrollt tot je “ssn” ziet. “Decoding the HTML source code” is, eh, zeggen dat je langs <tags> kunt lezen?

En dan gaat men nog verder:

A hacker is someone who gains unauthorized access to information or content. This individual did not have permission to do what they did. They had no authorization to convert and decode the code.
Het punt is alleen dus dat de code in kwestie is wat er naar je computer wordt gestuurd, en dat deze voor mensen leesbaar is. Of nou ja, leesbaar:
<div class=”text”><h1><a reF=”https://blog.iusmentis.com”>Internetrecht door Arnoud Engelfriet</a></h1> <p>Arnoud Engelfriet is ICT-jurist, gespecialiseerd in internetrecht.Hij werkt als partner bij juridisch adviesbureau <a Href=”http://ictrecht.nl” rel=”external” target=”_blank”>ICTRecht</a>. Zijn site <a hRef=”http://www.iusmentis.com/”>Ius mentis</a> heeft meer dan 350 artikelen over internetrecht.</p></div>
Ik wil niet zeggen dat dit metéén net zo helder is als een gemiddeld juridisch contract, maar om dit nu een “code” te noemen die je moet “ontcijferen” gaat wel erg ver. Maar hoe dan ook is het absurd om te zeggen dat hier sprake is van “toegang zonder toestemming”, dit is gewoon wat de server je geeft en het is juist je browser die er wat moois van maakt.

En natuurlijk, voor computercriminaliteit is niet perse nodig dat je een moeilijke technische truc uithaalt. Zodra je ergens bent waarvan je weet dat je er niet mag zijn, ben je eigenlijk al in overtreding. Vandaar die discussie over URL-manipulatie, het aanpassen van een URL om te gokken dat je elders nog informatie kunt vinden waarvan je zo snel niet de navigatie erheen kunt bepalen. Maar hoe je het ook bekijkt, zelf een URL aanpassen om te raden wat elders staat, is complexer dan bekijken welke HTML broncode een site naar je stuurde.

Arnoud

 

 

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

Geplaatst op in 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 weer dat rechters moeten leren programmeren omdat ze anders dit soort zaken niet kunnen doen. Onzin, wat mij betreft. Daar heb je deskundigen voor. Maar bij deze zaak denk ik dan wel, blij dat ik die deskundige niet ben.

In 2002 ontwikkelde Equihold een sportapplicatie met de naam 1-2 Focus. Deze applicatie was geschreven in de programmeeromgeving en programmeertaal VB6. In 2004 besloot men deze om te werken naar Microsoft .NET, waarna men in 2005 een raamovereenkomst sloot met Capgemini om het werk te laten doen. Ik zal u de verdere tijdlijn besparen, maar in 2010 eindigde het feest met een brief aan Capgemini met als titel “1-2Focus; developed by Capgemini A Showcase of Bad Practices”.

Wat was er nu precies aan de hand met die broncode? Helaas is dat in het arrest niet in detail te achterhalen. We moeten het doen met uitspraken als

Volgens [B] , een voormalig werknemer van Equihold, heeft de broncode niet de gewenste laagstructuur, bestaat deze uit onnodig veel regels en is deze onsamenhangend. Zijn conclusie is dat de broncode van zo bedroevende kwaliteit is dat het volledig herschrijven daarvan onvermijdelijk is. SQMI is volgens [appellant] een gerenommeerde en onafhankelijke partij die een onderzoeksmethode gebruikt die is ontwikkeld door het Institute for Software Quality (IfSQ). Het rapport SQMI concludeert dat de broncode een hoog aantal ‘defect indicators’ heeft, dat de onderhoudskosten van de software onnodig hoog zijn en dat de software ongeschikt is als platform voor verdere ontwikkeling. Graham Bolton, oprichter van IfSQ en directeur van SQMI, (verder Bolton) voegt daar in een schriftelijke verklaring aan toe dat het verbeteren van de geconstateerde gebreken meerdere jaren in beslag zou nemen, en zelfs meer tijd zou kosten dan het geheel opnieuw schrijven van de applicatie.

Capgemini kon daar echter een ander rapport tegenover stellen dat juist aantoont dat de onderhoudbaarheid marktconform is.

Dan krijg je dus de situatie dat partijen elkaar tegenspreken, en dat je als rechter dan moet vaststellen wat er nu waar is. In een geval als dit is dat erg lastig, allereerst natuurlijk omdat broncode op kwaliteit toetsen sowieso ingewikkeld is (de een z’n ***var is de ander z’n nachtmerrie) maar ten tweede omdat dit om zo’n grote codebase gaat dat er een hele partij werk in gaat zitten. Oh ja, en omdat er natuurlijk niet echt objectieve standaarden zijn om codekwaliteit vast te stellen.

Een belangrijke factor in het geschil was de onderhoudbaarheid: kun je op lange termijn hiermee door, ook (denk ik) met een andere onderhoudspartij dan Capgemini zelf. Bij grote applicaties is langdurig gebruik te verwachten, dan heb je andere verwachtingen qua onderhoud en aanpasbaarheid voor de toekomst dan bij een snelle app voor een event begin volgend jaar.

Dus, ik gooi hem eens in de groep, voor al die IT-ers die denken dat rechters meer verstand van software nodig hebben: hoe zouden jullie bij deze berg aan code objectief vaststellen of de kwaliteit voldoet aan de contractuele eis van ‘high quality software’?

Arnoud

Wat mag ik met snippets van Stack Overflow?

Geplaatst op in 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 met elkaar tips, ideeën en oplossingen te delen. Meestal gebeurt dat in de vorm van programmeercode (broncode) omdat dat nu eenmaal de meest exacte en directe manier is om aan te geven hoe je in software een bepaald probleem aanpakt. Die oplossingen zijn vaak relatief kort en worden dan ook wel snippets genoemd.

Op software rust auteursrecht. Je mag dus iemands software niet overnemen, ook niet als hij de broncode publiceert of die broncode ergens neerzet waar het de bedoeling is om erover te praten en er naar te kijken. Alleen als er een licentie bij staat, kun je de software gebruiken – binnen de grenzen van de licentie. Helaas zetten maar weinig SO gebruikers expliciet een licentie bij hun snippets.

Bij snippets kun je dan weer wel je afvragen óf er auteursrecht op rust. Er moet wel iets van creativiteit in het werk zitten. Dat kan bij een kort werk, maar zeker bij software is dat geen automatisme. Een snippet die laat zien hoe een API aangeroepen moet worden, zou ik niet creatief noemen. Dat is alleen “kijk hier moet de sessiesleutel, hier zet je parameters zoals kleur en gewicht en dan krijg je een array terug met de actuele voorraad”. Zo’n snippet heeft geen auteursrecht en daarmee mag je natuurlijk doen wat je wil.

Helaas is zodra je boven dergelijke trivialiteiten gaat het al snel onduidelijk. Er zijn geen juridische vuistregels zoals dat tot tien regels code vrij van rechten zijn. Zo werkt auteursrecht gewoon niet. Je moet dan inhoudelijk je afvragen of dit iets creatiefs is of ‘gewoon’ zoals je het zou doen. Dertig regels code met hoe een quicksort werkt zou ik niet creatief noemen (dat is nu eenmaal grofweg een standaard algoritme) maar 5 regels om snel een matrix te scannen is vaak juist héél creatief.

Wat natuurlijk wel altijd mag, is het idéé dat men je communiceert met zo’n snippet overnemen en in eigen code verwerken. Ideeën, principes en algoritmes vallen buiten het auteursrecht en mogen dus vrij worden gebruikt. Dat doe je dan dus door eerst in eigen woorden (of pseudocode) op te schrijven wat er onder die geposte broncode zit, en daarna dat in echte code uit te werken in je eigen applicatie.

Arnoud

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

Geplaatst op in 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 het is 2017. Kan dat echt niet anders?

Vrijwel alle broncode heeft een copyright notice, maar juridisch is dat eigenlijk nergens voor nodig. Heel formeel bestaat een copyrightvermelding uit drie elementen, in deze volgorde:

  • Het woord "copyright", de afkorting "copr." of het C-in-een-cirkel symbool ©. Allebei is dus eigenlijk dubbelop, en wie "(C)" doet is eigenlijk fout bezig.
  • Het jaar van eerste publicatie van het werk. Als het gaat om een aangepaste versie, dan moeten de jaren van elke wijziging ook worden vermeld. Zo geeft "1985, 1987-1989" bijvoorbeeld aan dat het werk gemaakt is in 1985 met wijzigingen in 1987, 1988 en 1989. Onze vraagsteller hoeft dus niet álle bestanden aan te passen, maar alleen bij de eerste wijziging in 2017 dat jaar toe te voegen.
  • De naam van de auteur. Dit mag een afkorting of pseudoniem zijn, zolang de auteur maar te identificeren is. In dit geval mag de statutaire naam worden gevoerd, of een andere handelsnaam die het bedrijf gebruikt.

Het punt is alleen dat geen enkele wet een copyrightvermelding eist als voorwaarde om auteursrecht te hebben op die software. Auteursrecht ontstaat namelijk enkel door het werk te maken, ongeacht wat er bij staat aan naams- of copyrightvermeldingen.

In de VS was het tot 1978 wél verplicht om zo'n vermelding te doen, anders was je werk niet beschermd. Maar juristen zijn een conservatief stel mensen, en bovendien het stáát heel juridisch dus laten we het maar doen. Cargo culting dus. Hetzelfde geldt voor all rights reserved.

Een naamsvermelding van de rechthebbende is natuurlijk wel zo handig, en een waarschuwing dat zonder licentie deze broncode niet mag worden verspreid kan ook geen kwaad. (Alleen graag zonder hoofdletters, dat leest beter.) Het is dus prima om vanaf nu "Copyright $NAAM" zonder jaartal te doen, dan hoef je er nooit meer aan te komen (tenzij je de auteursrechten verkoopt uiteraard.)

Arnoud

Mag je software reverse engineeren om fouten te vinden?

Geplaatst op in 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 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.

Waar de vraagsteller naar refereert, is het wetsartikel dat het eerste deel van die zin onderbouwt:

Als inbreuk op het auteursrecht op [software], worden niet beschouwd het vervaardigen van een kopie van dat werk en het vertalen van de codevorm daarvan, indien 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, mits: (bla)

Dit is inderdaad beperkt tot reverse engineeren met als doel het maken van een interoperabel eigen programma. Soms is het daarvoor nodig dat je de broncode van andere software achterhaalt, omdat je anders onvoldoende informatie hebt over hoe je eigen software moet gaan werken. Het vinden van een fout in software is natuurlijk niet hetzelfde als “interoperabiliteit tot stand brengen”, tenzij je zegt “ik moet weten hoe die fout werkt want ook daarin moet ik compatibel zijn”.

Er is echter nog een ander artikel dat specifieker op fouten ziet:

De verveelvoudiging, als bedoeld in de eerste zin, die geschiedt in het kader van het laden, het in beeld brengen of het verbeteren van fouten, kan niet bij overeenkomst worden verboden.

Reverse engineeren is een vorm van verveelvoudigen. Dat is waarom deze actie in principe inbreuk op het auteursrecht maakt. Echter, dit artikel verklaart het verveelvoudigen ter herstel van fouten legaal (zelfs als in de EULA staat dat dat niet toegestaan is). Daarom zou dit volgens mij toch gewoon toegestaan zijn.

Dus ik geloof dat ik toch gelijk had, hoewel om een andere reden dan ik zei 🙂

Arnoud

Schendt HTC de GPL door broncode vertraagd te publiceren?

Geplaatst op in 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 de broncode kunt bestellen). Ene “vladyman” had HTC gevraagd hoe dit zit, en kreeg als antwoord:

Thank you for contacting HTC Technical Assistance Center. HTC will typically publish on developer.htc.com the Kernel open source code for recently released devices as soon as possible. HTC will normally publish this within 90 to 120 days. This time frame is within the requirements of the open source community.

Nou, dat lijkt me niet. Ik heb nog nooit gehoord van een tijdsbestek van 90 tot 120 dagen voordat broncodes beschikbaar komen. De GPL zelf bevat zo’n vertragingsmechanisme al helemaal niet: de broncode moet gewoon bij het product zitten.

Er zijn verschillende verklaringen waarom HTC zo reageert: ze hebben de juiste broncodes niet paraat, er zitten codes van derden in die (nog) geen GPL mogen worden, men is naar de verkeerde cursus open source compliance geweest of men werkt gewoon altijd al zo en dus nu ook, want wetten en regels kunnen natuurlijk niet het bedrijfsbeleid in de weg zitten. Of, en dan wordt het wat meer aluhoedje: men is bang dat afgifte van de broncode zal leiden tot een succesvolle jailbreak van de telefoon.

Het blijkt namelijk dat de HTC G2 wel te jailbreaken is, maar tot nu toe levert dat slechts beperkte resultaten op. De meeste hacks worden bij de eerstvolgende reset ongedaan gemaakt door een speciaal stukje firmware. Vanuit Linux zou dat stukje firmware aan te sturen moeten zijn, maar daarvoor is wel de broncode van de Linux-kernel in het apparaat nodig. En die komt “normaliter” pas na 90 tot 120 dagen beschikbaar.

Frustrerend is wel dat eigenlijk alleen de auteursrechthebbenden op de Linuxkernel hier wat tegen kunnen doen. Als ontvanger van de code kun je je niet op de GPL beroepen tegenover HTC (of T-Mobile, die het toestel uiteindelijk aan je levert) want de GPL is een licentie tussen jou en de auteursrechthebbende, niet tussen jou en T-Mobile. Ik heb me wel eens afgevraagd of het geen goed idee zou zijn om juist wél toe te staan dat jij mag procederen uit naam van Linus over jouw exemplaar van Linux.

Update (15 oktober) in de comments wijst Piet erop dat HTC de code ruim binnen die 90 dagen heeft vrijgegeven.

Arnoud