Asus zet gpl-overtreding Eee PC recht

Asus is ervan beschuldigd dat het bij het ontwikkelen van de Eee PC de gpl heeft geschonden. Het bedrijf heeft nu laten weten dat een van zijn programmeurs in de fout is gegaan.

Java-ontwikkelaar Cliff Biffle claimde dat een 1,8GB groot zip-bestand, dat Asus op zijn website had gepubliceerd, niet de door Asus aangepaste versie van de acpi-kernelmodule bevat, zoals het Taiwanese bedrijf wel beweerde. Asus zou hiermee de General Public License, waaronder de module is vrijgegeven, overtreden.

Asus verklaarde dat het de gpl altijd gerespecteerd heeft en dat een fout van een softwareontwikkelaar ertoe leidde dat de betreffende broncode niet beschikbaar was, aldus Digitimes.

Het bedrijf heeft toegezegd dat het de code in kwestie op Linux-fora zal publiceren en dat het de broncode bovendien ter download zal aanbieden. Volgens Ars Technica is het belangrijk dat de gewijzigde broncode wordt gepubliceerd, omdat andere Linux-distributies daarmee de Eee PC makkelijker kunnen ondersteunen.

Reacties (34)

[GENETX]

Ik kan niet anders zeggen dan dat het door Asus gewoon professioneel wordt opgelost. J ekan zeggen wat je wilt, maar ik geloof ze ook gewoon. Binnen een groot bedrijf met een toch vrij groot project als deze kan er nou eenmaal wat misgaan met de communicatie. Jammer dat niemand bij Asus dat had ontdekt, maar dat ze zonder slag of stoot gewoon de volgende dag melden dat het beschikbaar komt vind ik gewoon professioneel.

[bbob]

Het lijkt idd opgelost maar het neemt niet weg dat ze hun huiswerk niet gedoen gedaan hebben.

Dit soort voorwaarden zijn er nu éénmaal en het kan niet zo zijn dat een bedrijf ze naast zich neerlegt en pas als er commentaar gegeven wordt men het rechtzet.

Daarnaast is het leuk dat een softwareontwikkelaar de schuld krijgt, maar dat neemt niet weg dat Asus er voor verantwoordelijk is.

Misschien had men ook beter kunnen vertellen hoe men dit in de toekomst wil voorkomen.

Draai het eens om, iemand maakt gebruik van een patent van Asus en zegt oeps dat wisten we niet, maar pas als Asus ze aanklaagt stoppen ze gebruik te maken van dat patent. Een overtreding is en blijft dan ook een overtreding in de ogen van Asus.

[ShadowLord]

@ bbob1970

ASUS heeft het gewoon 100% correct opgelost. Als je de GPL had doorgelezen, wist je dat het helemaal niet nodig is om de broncode ter download aan te bieden vanaf de dag dat je de gecompileerde code rondstuurt. Het is zelfs zo dat je deze helemaal nooit publiekelijk ter download hoeft aan te bieden.

Het is genoeg om, zodra iemand er om vraagt, de broncode te verstrekken. Dat is precies wat er in dit geval is gebeurd. Iemand die beschikte over de gecompileerde code heeft gevraagd om de broncode. ASUS heeft deze code opgezocht en, geheel volgens de GPL regels, verstrek aan deze persoon. Daarnaast heeft ASUS het nu ter publieke download aangeboden als een service.

[Verwijderd]

@ShadowLord

Jouw verhaal klopt niet, moet namelijk op het zelfde moment gedaan worden dan de niet source vorm beschikbaar is. Zie sectie 6 van de GPL

6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
... etc

Als extraatje wat GPL zaken en gpl-violations.

@Arnoud Engelfriet

Dit is inderdaad GPL v3

Voor GPL v2 geldt.

3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
..etc

Kortom wat Asus heeft gedaan is tegen de GPL zowel v2 als v3.

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 10:19]

[Arnoud Engelfriet]

Je citeert uit GPLv3, terwijl de software in kwestie onder GPLv2 valt. Dat maakt hier nogal uit, omdat GPLv3 toestaat dat je de broncode op een netwerkserver zet (item 6b2) als je een fysiek product met de binary er in verkoopt. GPLv2 verbiedt dat. Onder GPLv2 moet er of een CD met broncode of een brief (written offer) in de doos met het product zitten.

[PhoenixT]

Mis. Asus had de broncode van de eee PC software al publiekelijk beschikbaar gemaakt, maar dit was helemaal niet de echte broncode. Wél een overtreding dus. Overigens ben je wel verplicht de broncode makkelijk beschikbaar te maken, al is het maar op een cd'tje bij het product of een linkje op internet. Het probleem was dus dat Asus de verkeerde broncode online had gezet

[Arnoud Engelfriet]

Inderdaad, slordig. Maar het is en blijft gewoon erg lastig om dit goed te doen, zeker als je een groot bedrijf bent dat gesloten software gewend is.

Het is namelijk geen kwestie van "developer compileert broncode, developer flasht binary in product, developer zipt broncode en plaatst die op de website".

En niet alleen omdat je de GPL schendt als je de broncode van je product alleen op je website aanbiedt.

Tussen de developer en degene die de doos in de winkel schuift, zitten zo veel schakels dat je je hele bedrijfsproces moet aanpassen om hiermee om te gaan. En dat valt niet mee. Totdat dat op orde is, ga je dit soort slordigheden krijgen.

Nou kun je wel zeggen, dat had je dan vooraf moeten uitwerken en implementeren, maar ik ben hier al sinds 2002 mee bezig bij mijn werkgever en het blijft lastig. Developers leveren de verkeerde code, de mensen van de handleiding vinden de GPL te lang en laten 'm dan weg, een leverancier zweert dat 'ie alles zelf geschreven heeft terwijl de code exact dezelfde bugs heeft als Busybox, er is statisch gelinkt met LGPL code maar we mogen geen object files van de rest uitleveren van de leverancier daarvan, en zo kan ik nog wel even doorgaan. Alleen door schade en schande word je wijs.

Overtreding is overtreding, dat ben ik met bbob1970 eens. Maar niet elke overtreding is een opzettelijke grove schending met als doel iedereen van de vier vrijheden van Stallman te beroven. Never attribute to malice what can be attributed to incompetence.

[Verwijderd]

Even op commerciële producten projecteren.

Tussen de developer en degene die de doos in de winkel schuift, zitten zo veel schakels dat je je hele bedrijfsproces moet aanpassen om hiermee om te gaan.

Als dit commerciële producten zouden zijn van een machtige leverancier zou dit niet voorkomen cq de kans veel en veel kleiner zijn.

Developers leveren de verkeerde code,

Als je professioneel programmeert dan gebruik je een versie controle systeem daar zou ook de license in gecommit moeten zijn. Lijkt me ook logisch dat je de license kent.

de mensen van de handleiding vinden de GPL te lang en laten 'm dan weg,

Dit kan gewoon niet en zal in geen geval gebeuren bij een grote commerciële leverancier. Als je dit met bijvoorbeeld Microsoft of Oracle programmatuur zou zou je een enorm probleem hebben.

een leverancier zweert dat 'ie alles zelf geschreven heeft terwijl de code exact dezelfde bugs heeft als Busybox

Als een leverancier de binaries van bijvoorbeeld Oracle of Microsoft zou verkopen als zijn code zou dit einde oefening zijn voor de fabrikant. Dan werd het x* geleden schade per product = astronomisch. Lijkt me trouwens ook logisch dat je zo'n fabrikant bij het grof vuil zet als je er ooit achterkomt.

er is statisch gelinkt met LGPL code maar we mogen geen object files van de rest uitleveren van de leverancier daarvan, en zo kan ik nog wel even doorgaan.

Dan lijkt me dynamisch linken een optie. Statisch linken van commerciële software met GPL code is erg dom. Dan zal de rest GPL moeten worden.

Bij Asus is het echt niet per ongeluk gebeurd zie:

# They appear to have stripped out all attribution. (Kernel modules contain information about the module name, version, and author. This has been removed.)

# They appear to have attempted to hide what they were doing. (All references to "asus_acpi" have been removed, but other identifying features remain.)

Het is hun tweede gpl overtreding dit is de eerste.

Mogelijk dat het een interne medewerker is. Naar buiten toe is het Asus.

[Arnoud Engelfriet]

Als dit commerciële producten zouden zijn van een machtige leverancier zou dit niet voorkomen cq de kans veel en veel kleiner zijn.

Grapjas. Hoe groter de leverancier, hoe meer schakels. En hoe meer onzekerheden.

Als je professioneel programmeert dan gebruik je een versie controle systeem daar zou ook de license in gecommit moeten zijn. Lijkt me ook logisch dat je de license kent.

Wat doet een license tekst in een versiecontrolesysteem? We hadden het over een groot bedrijf, toch? Licenties horen door de bedrijfsjurist beoordeeld en bijgehouden te worden. Die weet hoe hij ze moet lezen en hoe de verplichtingen vertalen naar de bedrijfssituatie.

Een van mijn grote irritaties is dat programmeurs zelf licenties lezen en besluiten wat de verplichtingen zijn. "Oh, het is LGPL dus onze code mag gesloten blijven stond op Groklaw". En dan vervolgens statisch linken.

Dit kan gewoon niet en zal in geen geval gebeuren bij een grote commerciële leverancier. Als je dit met bijvoorbeeld Microsoft of Oracle programmatuur zou zou je een enorm probleem hebben.

Noem mij eens 1 MS of Oracle licentie waarbij je in documentatie naar eindgebruikers toe een licentietekst moet opnemen?

[...]
Dan lijkt me dynamisch linken een optie. Statisch linken van commerciële software met GPL code is erg dom. Dan zal de rest GPL moeten worden.

Ik zei LGPL, niet GPL. Je mag gesloten software linken met LGPL software zonder een eis dat die software open moet. Probleem is bij statisch linken alleen dat je dan object files moet meeleveren zodat mensen kunnen herlinken.

Embedded systemen hebben nog wel eens de onhebbelijkheid dat alle code als 1 grote statisch gelinkte blob in het flashgeheugen moet.

Maar ik zeg niet dat die voorbeelden goed zijn. Ze gebeuren. En je moet je bedrijfsproces elke keer aanpassen als je tegen dit soort dingen aanloopt. Dat is een continu verhaal, je kunt het niet in 1 keer goed ontwerpen. Ook open source policies moet je debuggen.

[Verwijderd]

Grapjas. Hoe groter de leverancier, hoe meer schakels. En hoe meer onzekerheden.

Ik bedoelde hier mee te zeggen dat als de code van bijvoorbeeld Microsoft of Oracle zou zijn dit veel minder zou voorkomen. Omdat ze dan aangeklaagd zouden worden en met veel geld over de brug zouden moten komen.

Wat doet een license tekst in een versiecontrolesysteem? We hadden het over een groot bedrijf, toch? Licenties horen door de bedrijfsjurist beoordeeld en bijgehouden te worden. Die weet hoe hij ze moet lezen en hoe de verplichtingen vertalen naar de bedrijfssituatie.

Als je de code correct importeert zit er standaard ook de licentie bij. Minimaal dat het bijvoorbeeld GPL is.

Ik ben eens dat uiteindelijk de juridische afdeling de licenties moet behandelen.

Een van mijn grote irritaties is dat programmeurs zelf licenties lezen en besluiten wat de verplichtingen zijn. "Oh, het is LGPL dus onze code mag gesloten blijven stond op Groklaw". En dan vervolgens statisch linken.

Dit kan ik me inderdaad voorstellen. Dat zie je hier al welke gedachten er op tweakers leven. Ik denk dat een nadeel van de licenties is dat het niet echt leesbaar is. Dat merkte ik ook toen ik door de GPL ging zoeken.

Noem mij eens 1 MS of Oracle licentie waarbij je in documentatie naar eindgebruikers toe een licentietekst moet opnemen?

De EULA bij bijvoorbeeld een windows CE apparaat neem ik aan?

Het nadeel van GPL is dat bij overtreding de gevolgen voor de schender minimaal zijn. Daarom word er waarschijnlijk bij veel bedrijven niet veel energie in gestoken. Na het publiceren van de code is het weer goed. Als het niet ontdekt word hoef je niets te doen.

Dit is anders bij commerciële bedrijven/code daar kan de schadevergoeding in de miljoenen lopen.

[Arnoud Engelfriet]

Ik bedoelde hier mee te zeggen dat als de code van bijvoorbeeld Microsoft of Oracle zou zijn dit veel minder zou voorkomen. Omdat ze dan aangeklaagd zouden worden en met veel geld over de brug zouden moten komen.

Mensen die GPL code misbruiken, worden ook aangeklaagd. Harald Welte heeft er bijna een dagtaak aan. En dat is bijzonder pijnlijk. Je product moet terug, je moet documentatie herzien, broncode bijleveren die je waarschijnlijk niet (meer) hebt, enzovoorts. Om nog maar niet te spreken van de imagoschade.

[Verwijderd]

Ze zetten het toch zonder zeuren (en met spoed) recht?
Als je zo'n groot product op de markt met een helemaal aangepast operating system dan kan je dat gewoon niet feilloos doen. Asus bestaat tenslotte ook maar uit mensen en mensen maken helaas fouten.

[Verwijderd]

Binnen een groot bedrijf met een toch vrij groot project als deze kan er nou eenmaal wat misgaan met de communicatie.

Dit niet misgaan met communicatie. Informatie uit een kernel module strippen is IMO niet misgaan.

Zie[http://cliffhacks.blogspot.com/2007/11/asus-eeepc-first-impressions-and-gpl.html] link[/url].

Through disassembly (I can do that, the software is GPL'd), it appears that ASUS has extensively modified the asus_acpi kernel module from Linux 2.6.21.4, so that it now works with the eee's hardware. This would be good except that


* They appear to have stripped out all attribution. (Kernel modules contain information about the module name, version, and author. This has been removed.)

* They appear to have attempted to hide what they were doing. (All references to "asus_acpi" have been removed, but other identifying features remain.)

Dit is een heel kwalijke zaak. Ik hoop dat Asus hier eindelijk van geleerd heeft en zich aan de GPL license blijft houden.

[SRI]

Dit was maar een van de klachten, ze zaten er ook nog mee dat de dingen niet gemerkt waren met een nieuw versienummer, naam en copyright informatie en dat je om de garantie te behouden alleen bij Asus mocht upgraden... Daar hoor ik nu niks meer van. Iemand enig idee hoe het daarmee zit?

[crashmatrix]

Goed punt, maar niet relevant voor dit artikel. Dat is meestal het geval met dit soort dingen, worden lekker naar de achtergrond geschoven (bewust of onbewust) en bij de massa komt het in de vergetelheid te liggen.

[GENETX]

Naam en Copyright zal wel goed zitten bij de nieuwe versie. Waarschijnlijk hadden ze een oude en een nieuwe en is per ongeluk de oude met verkeerde data online gezet.

Over de garantie, er zijn wel emer merken war bij van alles je garantie verloopt. Over het algemeen doet Asus niet moeilijk. Op het orginele latje in mn Asus laptop stond ook dat de garantie verviel wanneer ik het latje er uit zou halen, geen enkel probleem gehad. Nou kunnen ze dat ook niet testen. Maar ik vraag me af hoe moeilijk Asus gaat doen als die stikker mist, opzich mag je bij hun vrij veel aan je laptop sleutelen. Het zal meer zijn om leken tegen te houden. Een gemiddeld tweakert gokt het er op en weet zeker wel dat het geheugen gaat werken.

[Blaurens]

Het is nog niet 100% opgelost, want de wifi-module wordt nog niet optimaal ondersteund door andere distributies dan de stock-distro die erbij zit. Het werkt op bijv. ubuntu alleen met ndis-wrapper.

[Vaudtje]

Vallen die wifi-modules wel onder de GPL?

[GekkePrutser]

Dat hangt ervan af. Het staat Asus natuurlijk vrij om zelf van de grond af een kernel module te schrijven voor hun hardware, en die alleen als gecompileerde code aan te bieden. Het is dan niet verplicht om de broncode aan te leveren omdat er geen gebruik gemaakt is van gemodificeerde GPL-code.

Als ze echter gebruik hebben gemaakt van bestaande GPL code en hier wijzigingen aan hebben aangebracht, dan moeten ze wel de broncode verstrekken. En ik geloof dat dat hier het geval is, naar ik begreep hebben ze een aangepaste versie van de 'Madwifi' driver gebruikt.

[Arnoud Engelfriet]

Als het madwifi is: die code is dual GPL/BSD, Asus zou dus kunnen claimen dat zij de BSD licentie gekozen hebben en dan hoeven ze geen broncode vrij te geven.

Uit de originele blogpost begrijp ik dat het om de asus_acpi kernel module gaat en om Busybox. Die zijn GPL.

[Reactie gewijzigd door Arnoud Engelfriet op 3 augustus 2024 10:19]

[Neko Koneko]

Is toch geen onderdeel van de kernel?

[SRI]

Misschien is dat gewoon omdat het nog niet zolang uit is en de nieuwe drivers of wat dan ook nog niet verwerkt zijn in andere linux versies?

Edit: oeps daar heb je een punt ja,... maar als het goed is komt dat nu wel beschikbaar. Dan is het alleen nog de vraag hoeland de andere erover doen om het over te nemen en te intergreren in hun pakketten

[Reactie gewijzigd door SRI op 3 augustus 2024 10:19]

[Blaurens]

De drivers zijn in broncode niet beschikbaar, dus ze kunnen nog niet worden toegevoegd aan andere distributies Dat is precies het hele punt

[Nickname55]

In sommige landen mogen fabrikanten van wifi hardware de broncode van de drivers hiervoor niet openbaar maken ... als ik het goed heb ... Omdat men anders bang is dat gebruikers gaan zitten tweaken om zo de kwaliteit van de verbinding verbeteren. Daar heb je bij Windows gebruikers geen last van, die vinden gesloten software heel normaal, die vinden het heel normaal dat hun verbinding zo af en toe weg valt. Maar jah... die gekke Linux gebruikers ... er zijn erbij die dan gelijk in de broncode gaan zitten neuzen hoe ze de zend en of ontvangst sterkte(of wat dan ook) op kunnen voeren.

[Rigs]

Kan me voorstellen dat wanneer je deze laptop koopt in de winkel en dan later hoor je wanneer je wilt upgrade doen dat je garantie weg is ... zulke dingen zorgen gewoon voor slecht imago voor asus.
Nochtans heb ik thuis altijd goeie ervaring gehad met asus hardware (weliswaar non laptop). Alleziens is er zekers een toekomst voor low inch laptops

[GENETX]

Garantie raak je pas kwijt wanneer je het geheugen upgrade, en dan zie je die stikker echt wel. Echter zal het wel preventief werken voordat een prutser er een DDR1 SoDimm probeert in te rammen oid. Bij Asus mag je best veel sleutelen aan je laptop zoals gezegd.

Heb zelf wel met een laptop ervaring. Had er per ongeluk ranja overheen gegooid. Onderdeel voor reparatie liet echter meer dan een maand op zich wachten en ze belden me. Ik heb keurig gratis een nieuwe laptop gekregen, wat dat betreft gewoon topservice.

[SideSwipe]

Tja... Makkelijk inderdaad... Maar stel nu eens voor dat het nu gewoon het geval was

Netjes opgelost van Asus, daar kun je voor de rest niets over zeggen

[Pietervs]

Los van de vraag of het inderdaad de schuld van de programmeur was. Het is gewoon netter als je als bedrijf zegt "wij zijn in de fout gegaan" in plaats van "wij wisten van niks, maar hebben een prutser in dienst".
Om dan wat meer duidelijkheid te geven over wat er gebeurd is kunnen ze in plaats van "de programmeur" in hun verklaring ook spreken over "een van onze medewerkers". Nu wordt het heel erg duidelijk bij één persoon (of een groep personen) neergelegd. Niet echt sjiek van Asus...
Want uiteindelijk is toch het bedrijf (in dit geval Asus) verantwoordelijk voor wat er op de markt komt.

Maar het belangrijkste is (zowiezo) dat het opgelost wordt, en dat doet Asus dan wel weer goed.

[Roland684]

Je kunt (naar buiten toe) de schuld niet bij je werknemers neerleggen. Die werknemer is mogelijk wel de oorzaak, maar Asus is de verantwoordelijke.

[Reactie gewijzigd door Roland684 op 3 augustus 2024 10:19]