"Illegálisan használ GPL kódot az Androidban a Google?"

 ( trey | 2011. március 18., péntek - 10:59 )

"A Google illegálisan használhatott fel GPL licenc alatt álló kódot az Androidban, állítja Raymond Nimmer, a Houston Egyetem szabadalmi jogra specializálódott professzora. Úgy tűnik, a szoftvercég több száz kernel header fájlt épített be az operációs rendszerbe, miután egyszerűen eltávolított belőlük mindenféle kommentet és a licencelésre vonatkozó információt, ami minden bizonnyal jogsértő."

A teljes cikk itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Érdekes...

Mondjuk ha glibc-re váltanának, azzal jól járnánk, egyszerűbb lenne mindenféle hackelés (MeeGo HTC-n valaki?), de szerintem nem fog megtörténni. Inkább újraírják a header fájlokat...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

a glibcre váltás kényszerűsége téves konklúzió. az angol blog ezt egészen hosszan részletezi, de bárhogyan csűri csavarja, akkor sincs ilyen kényszer. elég a bionic C libet licencelni LGPL alatt, amit egyébként ma is bárki megtehet, mert a BSD licenc bármikor, a copyright holderek külön engedélye nélkül is megváltoztatható GPLre vagy LGPLre.
az is tény ugyanakkor, hogy abszolút értelmetlen és felesleges volt a bionic C a Google részéről. azok az érvek, miszerint a glibc túl bloated és a bionic kevesebb erőforrásigénye musthave mobil eszközöknél egyszerűen nevetségesek. a lassan egy évtizedes linux PDA, a Sharp Zaurus is vígan elfutott glibcvel, ill a MeeGo és a WebOS számára sem jelent semmilyen problémát a glibc, ahogy azt a blog helyesen meg is említi. ill lehetne használni Embedded GLIBCt, azaz eglibc libet is, amit egyébként egy ideje már a Debian és az Ubuntu is használ.

az írás legnagyobb tévedése, hogy a GPL kötelezővé tenné a userspace programok GPL kiadását, de ez nevetséges. ma is számtalan zárt kereskedelmi software kapható, amelyek GPL Gnu/Linux rendszereken futnak. ugyanez a lehetőség továbbra is adott marad akkor is, ha LGPLre kellene váltania a Googlenek a bionic C lib licencét.

UP. amennyiben valóban közvetlenül a kernelből másolt kódot a Google a BionicCbe, akár csak headerek formájában, elég nagy ostobaságot csinált. nem véletlenül LGPL a glibc. a Linux kernel GPLv2 licence linking exception nélküli. de jure nagy a valószínűsége, hogy így minden Bionicra linkelő alkalmazás forráskódját kötelező GPLv2 alatt is kiadni. a mobilgyártóknak akart kedvezni a Google de így hatalmas öngólt rúgott.

az Oracle Java vs Google Dalvik konfliktus is komoly következményekkel járhat. a Dalvik Apache licence már nem kompatibilis a Java GPL licencével. ráadásul még libc változatból annyi van mint égen a csillag, addig a Java valóban a SUN illetve ma már az Oracle unique szoftvere, amit okkal véd szabadalmakkal.

Ha igaz az, hogy ezek a linux headerek GPL alá esnek, akkor ezzel sikeresen "megfertőzik" nemcsak az Android hanem bármilyen Linux alapú rendszer user-space-ét, amiben szerepel a #include <linux/barmi.h>, ide értve kb. az összes hello world-nél bonyolultabb programot ami Linuxon fut.

Attól, hogy a glibc LGPL-es, a linux kernel headerek nem válnak azzá, tehát mivel a glibc használja a Linux headereket, ezért azt sem szabadna LGPL alatt terjeszteni, csak GPL alatt -> itt is ugyanolyan problémát jelent, csak eddig ezen mindenki (kényelmesen) átsiklott.

A probléma megint arra vezethető vissza, hogy a Linux kernel userspace API-ja nincs rendezve (jogi és technikai szempontból sem).

Üdv,
Gergely

a glibc és kernel fejlesztése egymással összehangoltan zajlik. az adott kernel kódrész írója természetesen berakhatja a saját kódját a glibcbe is LGPL alatt.
az Android esetében viszont erről szó sincs. itt egy script generálja ezeket, természetesen az eredeti szerzők engedélye nélkül, ráadásul közvetlenül a GPL licences linux kernelből és nem az LGPL licences glibcből. így a Bionic C licence GPL és az erre linkelő össze alkalmazásé is GPL.

már az első Androidos híreknél pont veled vitáztunk az Android szerintem szerencsétlen libc választásáról. semmi haszna a Bionicnak, a _kis_erőforrásigény_ nevetséges érv. számtalan a lowend Androdid mobiloknál is jóval kisebb régebbi hw használta sikeresen a glibct, pl előző Zaurusok. a WebOS és MeeGo ma is glibct használ, a Maemo pedig eglibct.
a BionicC egy totál felesleges lépés volt, ami ráadásul fordítva sült el.

> ráadásul közvetlenül a GPL licences linux kernelből

Az nem hiszem hogy számít.

Idézet:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".

ftp://ftp.kernel.org/pub/linux/kernel/COPYING

ez még nem jogosít fel senkit kernel kódok, legyenek azok akár csak headerek, másolására és átlicencelésére.

> ez még nem jogosít fel senkit ...

Az adja a feljogosítást, hogy nincs szükség feljogosításra.

Pld te fel vagy-e jogosítva arra, hogy itt hozzászólj? Igen, mert nincs rá szükség.

Ignoráld nyugodtan a COPYING fájlt; egy cikk vagy egy lev.lista hozzászólás (sajátos értelmezése) nyilván többet nyom a latban. :-)))

hát ez csak a linux kernel maintainerértől származó hozzászólás, a teljesen jelentéktelen lkml levlistára. egy szót sem érdemel:)

Na, csakhogy egyet értünk végre.

félreértettél egy poént attól tartok:)

a ftp://ftp.kernel.org/pub/linux/kernel/COPYING nem része a linux kernel GPL licenc szögének, ez egy licencen kívül eső könnyítés ami csak "user programs that use kernel services by normal system calls" esetre vonatkozik és csak a Linux kernel vonatkozásában. kód copy/paste másolására nem vonatkozik. copy/paste esetén a kernel licence él, ami GPL.

Láttam hogy poénnak szántad, de én meg egyetértek vele.

> ami csak "user programs that use kernel services by normal system calls" esetre vonatkozik

Ez nekem új. Mármint hogy NEM "user program that ..."-ról van szó.

a BionicC esetén nem normal system callsról van szó, hanem linux kódrészek copy/paste másolásáról.
az idézett rész csak egy megjegyzés, egyértelműen elkülönítve a GPL licenc szövegétől. nem véletlenül szerepel "NOTE!" szó az elején. ugyanúgy Linus Torvalds írta, aki azt a "jelentéktelen" levlista hozzászólást is, a relevanciája azonos:)
viszonylag ritka eset, hogy libct megkerülve nyúlnak közvetlenül programok a linux kernelhez közvetlenül. a http://sta.li/ a ritka kivételekhez tartozik. ilyen projektek létezéséhez szükséges az általad citált, licencet megelőző Torvalds megjegyzés.

ami az általad gondolt könnyítést lehetővé tenné az a GPL linking exception, de Linus NOTEja ennél lényegesen kevesebb.

a glibc és kernel fejlesztése egymással összehangoltan zajlik. az adott kernel kódrész írója természetesen berakhatja a saját kódját a glibcbe is LGPL alatt.

Fordítottál már glibc-t? Az a lépés megvan, hogy "és most töltsd le a kernelforrást, hogy használni tudjam belőle a headereket?"

De hogy konkrét számokat is nézzünk: Az Ubuntu 10.04-esem /usr/include/linux könyvtárában egy gyors grep (igen, nem 100% a sortörések miatt):
24. db file van "Lesser GPL" alatt
1 db file van "Library GPL" alatt (coda.h - használ még valaki CODA-t? :))
kb. ~200 file van rendes GPL alatt

Nem néztem meg, de tippem szerint a glibc használ ezek közül a GPL-es fájlok közül egyet-kettőt.

Ez alapján fenntartom, hogy ha a Google GPL-t sértett, és a system call híváshoz használatos információk tényleg GPL alá esnek, akkor a glibc is, és az összes glibc-t használó Linux rendszer ugyanolyan licencsértő helyzetben van, ami _minden_ Linux kernelt használó rendszert érint.

Az a 3 sor, ami a COPYING fájl elején van + a gyakran idézett kiabálós levele Linusnak távolról sem elég a jogi helyzet rendezéséhez. Elég nagy cégek fognak Linusnál kopogtatni, hogy gondolja át ezt a dolgot, mert nincs kedvük újra csinálni a headerekből clean-room implementációt...bár néhány távol-keleti SW fejlesztőnek biztosítva lenne a megélhetése.

A másik oldalról: ha valóban nem copyrightolható az információ, amit a Google kiszedett, akkor pedig nem beszélhetünk GPL sértésről, meg a copyright holder engedélyéről.

már az első Androidos híreknél pont veled vitáztunk az Android szerintem szerencsétlen libc választásáról. semmi haszna a Bionicnak, a _kis_erőforrásigény_ nevetséges érv. számtalan a lowend Androdid mobiloknál is jóval kisebb régebbi hw használta sikeresen a glibct, pl előző Zaurusok. a WebOS és MeeGo ma is glibct használ, a Maemo pedig eglibct.
a BionicC egy totál felesleges lépés volt, ami ráadásul fordítva sült el.

A fentiek miatt vagy egy sima MS (közeli) FUD-ról van szó, vagy pedig minden Linux rendszer érintett.

Egyébként továbbra sem értünk egyet. Az Android nem GNU/Linux rendszer, elég sok user-space tool BSD irányból érkezik (a Bionic jelentős része), vagy új fejlesztés.
Ebből az egész licenc mizériából látszik, hogy miért volt jó döntés a Google részéről száműzni a GPL / LGPL licences kódokat a userspace-ből.

A kis erőforrásigény, kis méret, és BSD licenc külön - külön is igazolja a bionic létjogosultságát.
Az, hogy más rendszerek nem így jártak el, szerintem nem bizonyítja ennek az ellenkezőjét. De szerintem felesleges újra lefolytatni egy régi vitát. :)

Végül: Szerintem akkor járna mindenki a legjobban, ha végre megnyugtatóan rendezésre kerülne a Linux userspace API kérdéskör jogi és technikai szempontból is. Ugyanis a userspace API távolról sem azonos a syscall listával.
És valaki végre törölhetné már a stable-api-nonsense.txt -t is a forrásból...

Üdv,
Gergely

-

"Fordítottál már glibc-t? Az a lépés megvan, hogy és most töltsd le a kernelforrást, hogy használni tudjam belőle a headereket"?
fordítás és forráskód között lényeges a különbség licencelés szempontjából.
fordítás során akár egymással licenc inkompatibilis kódokat is legálisan fel lehet használni. ahogy például előre megírtam legálisan lehetséges a natív ZFS támogatás Linuxon is.
a felhasználó bármilyen szabad licencelésű kódot egybepatchelhet magának és le is fordíthatja. csak egyben nem terjesztheti az inkompatibilis licencelésű forráskódokat.

"Nem néztem meg, de tippem szerint a glibc használ ezek közül a GPL-es fájlok közül egyet-kettőt".
használja vagy megtalálható a glibc forráskódjában?
ez egyáltalán nem mindegy.

"Elég nagy cégek fognak Linusnál kopogtatni, hogy gondolja át ezt a dolgot, mert nincs kedvük újra csinálni a headerekből clean-room implementációt...bár néhány távol-keleti SW fejlesztőnek biztosítva lenne a megélhetése".
általában glibc használata van elterjedve, ezekben az esetekben nincs miért aggódni.

"Az a 3 sor, ami a COPYING fájl elején van + a gyakran idézett kiabálós levele Linusnak távolról sem elég a jogi helyzet rendezéséhez".
ebben teljesen igazad van. de nem a gentleman agreementek világában érünk már. ITben ennél sokkal jelentéktelenebb bakikból is jelentős perek indulnak. szerintem sem jó ez így, de ezek a játékszabályok.
copy/paste kódmásolgatás komoly jogi kockázatot jelent. Linus véleményétől teljesen függetlenül is.

"A másik oldalról: ha valóban nem copyrightolható az információ, amit a Google kiszedett, akkor pedig nem beszélhetünk GPL sértésről, meg a copyright holder engedélyéről".
valóban ez itt a kulcskérdés.

"A fentiek miatt vagy egy sima MS (közeli) FUD-ról van szó, vagy pedig minden Linux rendszer érintett".
nem hiszem, hogy megvádolható lennék MS fanboysággal:D
a MS kommunikációja egyébként sem releváns egy licencsértési ügyben. ha ez jogilag megtörtént, akkor ezen a tényen az sem változtat semmit, ha a MS FUDgépezet csinál belőle ügyet.

"Egyébként továbbra sem értünk egyet. Az Android nem GNU/Linux rendszer"
sohasem állítottam ilyet sőt! Android/Linux talán még találóbb név:)

"Ebből az egész licenc mizériából látszik, hogy miért volt jó döntés a Google részéről száműzni a GPL / LGPL licences kódokat a userspace-ből".
nem! ebből csak az látszik, hogy totál felesleges volt berakni egy új libct, aminek semmi előnye nincs, csak hátránya, potenciális jogi támadási felület.
egyetlen gyártó sem igényelte az egyedi libc lehetőségét.
a Dalvik miatt indított per is előre látható volt.
ha a Google nem kezdett volna teljesen feleslegesen kártyázni a free licencekkel, ezeket mind elkerülhette volna.
a GPLv2 + linking exception Javara vannak zárt proprietary kereskedelmi programok bőven, bármilyen jogi aggály nélkül.
LGPL licences glibc Gnu/Linuxokon szintén vannak zárt kereskedelmi alkalmazások. nincsenek licencviták.
a gyártók dolgát csak egyszerűsítené a glibc, mint a már említett Motorolaét.

"A kis erőforrásigény, kis méret, és BSD licenc külön - külön is igazolja a bionic létjogosultságát".
ezt a Googlen kívül az összes többi mobillinuxot fejlesztő szereplő másként látja. WebOS, MeeGo, Maemo jól megvannak e/glibcvel is. de még az iOS is megtartotta az OSX Darwin alapjait.

Végül, senkinek nem érdeke egy zajos pereskedés az OSS világon belül. de ugyanakkor figyelmet kell fordítani a free kódok licenceire is. az Android és Gnu/Linux közötti erősebb kompatibilitás előnyeiből mind a két fél profitálna.

Glibc-nél nem tudom hogy oldották meg, hogy LGPL lehessen, de a bionic C-t nem elég csak LGPL-essé tenni. Ha tényleg használ GPL-es dolgokat, akkor GPL-es kell legyen, nem elég az LGPL.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

imho itt a freesoftware társaságon belül senki nem akar ebből túl nagy balhét, mert azzal végül mindenki csak vesztene. de a licencek feltételeit ettől még be kell tartani. a legoptimálisabb megoldás az volna, ha a Google dobná az egyébként is totál felesleges Bionicot, és helyette az eglibc kapna egy Bionic personality layert, így a kompatibilitás nem törne meg. továbbá egyszerűbbé válna a hagyományos gnu/liunx alkalmazások Androidon való futtatása, amit ma már a gyártók is igényelnek. a Motorola már kijött egy olyan mobillal, amin egy teljes Debian fut párhuzamosan, egy dockon keresztül rakható ki nagy lcdtvre, egérrel és billentyűzettel.
egyedi módosított gyártói BionicCre pedig nincs igény.

Ilyenkor hol van az FSF és Eben Moglen?


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Hogy az FSF hol van azt nem tudom. Eben Moglen 2007-ben elhagyta az SFLC-t. Akit keresel az szerintem Bradley M. Kuhn.

--
trey @ gépház

Valóban, az FSF igazgatótanácsát hagyta el 2007-ben.

--
trey @ gépház

s/FSF/SFLC, I stand corrected
De akkor is hol van ez a ban^H^H^Htársaság ilyenkor? :-)


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

"Donate to SFLC online via Google Checkout"

"many payments from Google in association with their 'Summer of Code' programme (in which Google funds a student to work on a free and open source project while making a small donation to the project itself) go uncollected because the projects have no organisation to accept them. Forming a corporate legal entity to represent a project can also help when contracting with external commercial bodies"

"To this list, the SFLC had added its own organisation, the Software Freedom Conservancy, of which Sandler herself is the Secretary."

upsz:-(

Pop-corn bekészít, lesznek még itt vicces dolgok.

Valószínűleg meg lesz valahogy gányolva az egész. Vagy újraimplementálják azokat, ami elég vicces jelenet lesz.

Bár valószínűleg az eredmény minden lesz, csak műszakilag nem szép megoldás. (Éljen a GPL).

----------------
Lvl86 Troll

gondolj bele, ha *bsd alapot valasztottak volna, akkor ez az egesz herce-hurca nincs, es akkor "mindenki boldog lenne" :)

csak hat a linux mint markanev valoszinuleg kellett hozza, hogy ilyen felkapott platform legyen...
___
info

En csak azon rohogok, hogy epp most telepitek egy virtualis Windows XP-t a MacOS X-emre, hogy vegre frissiteni tudjam az Androidos telefonom.

Ezt beszéld meg a gyártóval, De tényleg vicces. Nekem se windows se linux, se semmi nem kell, elég maga a telefon ugyanerre. Merthogy az OTA frissítés megoldott, működik. Gratulálok a telefonod gyártójának, hogy nem képes/akarja használni...

Ja nincs, mert meg mindig nem erte volna el a piacot.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

+1

+1

"linux mint markanev "

Amit azért nem hangoztatnak sehol se nagyon az oldalukon ;)

----------------
Lvl86 Troll

androiddal ellentetben, amit meg a baratnom 13 eves huga is ismer es japanban kulon android magazinokat lehet kapni az ujsagosnal

--
NetBSD - Simplicity is prerequisite for reliability

Ugye nem hiszi komolyan bárki, hogy ha lenne még egy olyan elterjedt, gyakorlatilag _minden_ beágyazott hardvergyártó által támogatott Unix-szerű kernel BSD licenccel, mint a Linux, akkor az Android fejlesztők szerencsétlenkednének itt a GPL-lel? Azt a pár feature-t, amit a Linuxba belefejlesztettek (pl. Binder, Power Management, Ashmem), simán bármely BSD-re portolni lehetne.

Mivel ilyen kernel nincs (nagyon sokan örülnének, ha lenne, legfőképp a HW gyártók), ezért maradt a Linux kernel.

Az Android azért lett felkapott platform, mert a Google jól pozícionálta:

- olyan rendszert csinált, amit a HW gyártók szívesen használnak (ha a fejlesztőcsapatod nem félhülye, 1-2 hét alatt átkonvertálhatod őket Androidra, nincs licencdíj, Linux kernel támogatást eddig is muszáj volt csinálniuk)
- Az Android Challenge-ek megteremtették azt a fejlesztőbázist, ami ahhoz kell, hogy relatíve gyorsan elég sok program elkészüljön
- A referencia UI-al sikerült megugrani az első időszakot a felhasználók számára, mostanra úgyis minden komoly HW gyártó portolta a saját UI-ját
- Az alsó kategóriás telefonok miatt azokhoz is eljut, akiket teljesen hidegen hagy, hogy milyen OS van a telefonjukon, csak az árakat nézik -- ezzel gyakorlatilag a Symbiant is kiüti a piacról

Üdv,
Gergely

Itt nem csak errol van szo. Alapvetoen nem lenne itt semmi baj, ha a licenszhuszarok nem akarnanak allandoan toszakodni. Bizonyos szempontbol megertem az Apple-t, hogy kidobta a GPL alkalmazasokat az App Store-bol, sok cseszegetesnek elejet veve ezzel. Ha vegre a nyilt kod fejlesztoi a fejlesztessel foglalkoznanak, akkor mindenki sokkal boldogabb lenne.
Nem gyozom hangoztatni, hogy en pont ezert terjesztem a cuccaimat CC BY(-NC)-SA licensz licensz alatt. Van 3-4 egyszeru pont, amit be kell tartani, es ennyi. Es nem kell attol tartanom, hogy majd jon a CC es engem bizony jol megved, ha akarom, ha nem.

Megertem en, hogy van szellemi tulajdon is a vilagon, de... nem tudom, ebben a licensz haboruban valahogy en nem tudom meglatni a nyilt forras lenyeget. Csak azt latom, hogy van par ember, aki imad bunyozni cegekkel, es ezt lepten-nyomon meg is teszi.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Licenchuszárok? Én éppen arról olvastam, hogy a témát felvető "segítőkész" ügyvéd a Microsoft korábbi ügyvédje volt. Miután kipattant az ügy, ezt a tényt úgy fest el akarta rejteni. Kitörölte a publikus életrajzából - itt már nincs benne, de a Google cache-ben látszik, de sikertelenül, mert lebukott.

Ha igaza van, akkor a Google álljon neki és orvosolja a problémát. De miért rejtegeti a tényt az ügyvéd úr, hogy szoros szálak fűzték a Microsoft-hoz? Nekem ez nem licenchuszárkodásnak tűnik, hanem jól felépített, a konkurenciához visszavezethető lépésnek.

--
trey @ gépház

> ha a licenszhuszarok nem akarnanak allandoan toszakodni.

Tételezd fel nyugodtan, hogy a "licenszhuszárok" leginkább azért "toszakodnak", mert vannak olyan esetek, amik alkalmat adnak rá. Indíts egy "toljunk ki a licenszhuszárokkal: tartsuk be a licenszeket" mozgalmat, és akkor majd eltűnnek. :-)))

> Ha vegre a nyilt kod fejlesztoi a fejlesztessel foglalkoznanak

Látom, össze vagy zavarodva. Ugyebár azért nevezed őket "a nyílt kód fejlesztői"-nek, mert nyílt kódot fejlesztenek. Durván ellent mondasz magadnak.

> valahogy en nem tudom meglatni a nyilt forras lenyeget.

Egyszerű: a lényeg a változékonyság állandósága. :-) Ami tegnap nyílt volt, az ma is nyílt, és holnap is nyílt lesz.

vajon miért baszogatják folyamatosan a bithument _licenc_huszárok_?:)
és bizony nem a GPL vagy más opensource licenc megsértése miatt. eddig minden GPL licencsértéssel kapcsolatos pereskedést megelőzött pár valóban udvarias levél.
ha kereskedelmi EULAt sértesz, akkor amint beazonosítanak rád törik az ajtót, néha szó szerint.
nagyon más mentalitás a kettő.
ameddig az proprietary EULA lobbi ennyire hajthatatlanul fanatikus, addig nagyon is indokolt a GPL szabadság fenntartását kikényszerítő szemlélete.

a CC alatt terjesztett _cuccaidhoz_ pedig gratulálok, ha azok softwareket jelentenek:D

Gondolom 100%-ig biztos vagy benne, hogy a Google "csökött" mérnökei a Linuxot választották alapnak bármi más helyett, főként marketing célból. :)

--
fantázisdús aláírás v1.09

Az Androidot nem a Google talalta ki. Megvettek a ceget (Andy Rubin es tsai), akik csinaltak, aztan jol eladtak a maguk neve alatt.

valószínűleg az volt a cél, hogy működjenek is az Androidos telefonok, ahhoz pedig széles körű hw támogatás kell.

szeles koru hw tamogatas?!

Ugyan mar, egy telefonban jol behatarolhato hw elemek vannak, lehet n gyarto, gyartonkent m eszkoz, de meg igy is veges szamu hw-re kell portolni az os-t, nem ugy, mint a dzsunka desktop pc-knel ahol teljesen eltero dolgokat kell tamogatni. A masik meg az, hogy nem hinnem, hogy egy adott telefon gyarto a vanilla androidot rakna fel, hanem ok is atirjak / kioptimalizaljak a keszulekukre.

Android tema eddig hidegen hagyott, es ameddig lehet addig szerintem hidegen is fog. A telefon telefonalasra valo ;)
___
info

ez akkor nem jelent nagyobb problémát, ha mobilgyártó mindent maga gyárt házon belül, pl Samsung. nekik van is BSD mobiljuk, a Bada nem linux kerneles változata BSDt használ.
olyan gyártók akik külső beszállítóktól függenek, mint a Motorola vagy a HTC, már jobb ha készen kapják a hw támogatást a default kernellel, és nekik legfeljebb az egyedi mobilfény driverével kell foglalkozniuk:)

nem vanilla androidot használnak a gyártók, de túl sok egyedi módosítást sem tesznek hozzá. a gyártói egyediség kimerül pár userspace alkalmazásban és néhány mobilhoz kötődő eye candy hw támogatásában.
a letölthető CyanogenMod minden további nélkül működik a legtöbb Android mobilon.
egyébként én sem vagyok egy Android fan;)

Szerintem a Linux márkanév nem volt annyira vonzó, nem véletlen, hogy a Google "aktívan" nem beszél arról, hogy az Android valójában Linux alapú (kis túlzással csak egy speciálisabb Linux disztró). Ezt inkább csak a hozzáértőbbek tudják.

Én arra tippelek, hogy a Linux kernel hardver támogatása jóval erősebb volt mint a BSD-é, főleg mivel már hosszú ideje rengetegen használják embedded alkalmazásokban. (disclamer: nem ismerem túlságosan a BSD-t, bocs ha tévedek).

Egyébként a Linux hardvertámogatásának mostanság történő rohamos erősödését sokan az Android javára írják, mivel a komponens gyártók most már rákényszerülnek a driver-ek megírására (vagy nem tudnak beszállítani Android-os készülékekbe). Minden kernel verzió egy jó nagy kupac driver-el bővül és erős a gyanúm, hogy ezek javarészét a gyártók adják hozzá a kernel-hez.

Nem feltetlen, bizonyos telos cuccok drivereit a mai napig ugy kell osszebanyaszkodni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

qurva nagy a támogatás, de egy nyomorult hotsync program sem került ki ami Linux alatt használható lenne..

-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

Ma mar a cloud a kulcsszo. Van plugin a Google Contacts szinkronizalasara.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal