"linux kernel vs. zárt forrás" mizéria

Hmm, még emlékszem, anno GKH-ék az nvidia, philips webcam meg talán wifi chipsetek kapcsán elég hangosan cirmogtak, hogy a kernel nyílt forrású meg gpl-es meg minden, és dzsihadot/keresztes háborút hirdettek, hogy ne is lehessen zárt forrású cuccra kihívni belőle, mert az milyen csúnya dolog.
Megvan a véleményem a témáról, ezt már végigrágtuk a fórumon épp elégszer, viszont egy korsó sör mellett felmerült egy nagy kérdés ezzel a keménytökű hozzáállással kapcsolatban.
Nevezetesen, a kernel jócskán beszélget a bios-szal (BIOS Enhanced Disk Drive calls determine boot disk, APM BIOS support, Use real mode APM BIOS calls, PCI Access mode: BIOS, stb), nomármost, a bios minden, csak nem nyílt forrású, hogy a gpl-ségéről ne is beszéljünk.

Egyéb #1: az "Intel IA32 CPU microcode support" által használt bytekód sem nyílt forrású, ha jól tudom, a kernel mégis lelkiismeretfurdalás nélkül módot ad a prociba betöltésére.
Egyéb #2: ha jól tudom, a boot loader-ek is használnak bios-t (nem csinálnak mindent portszinten), pedig azok is gpl-esek
Egyéb #3: bár már rég volt, és nem teszem a torkom a kés alá, hogy jól láttam, de mintha az X is beszélne a bios-szal, legalábbis alpha-n egynémely videokártyával ilyesmiért gyűlt meg a bajom
Egyéb #4: a kernel module autoloading szintén szó nélkül kihív egy általam megadott programra (root joggal ugye), amire szintén semmi garancia, hogy gpl-es
Egyéb #5: a binfmt_misc úgyszintén

Akkor most hogy is állunk? Nem szabad kihívni ilyesmire (lásd a fenti cirmogások tárgyait), kivéve amikor nekik is szükség van rá? Hol maradt akkor a híres keményvonalas "csak a szent gpl" következetessége? Szóval hmmm...

( sz | 2006. 05. 09., k – 15:19 )

Az ati, nvidia, wireless, akármi drivereket a kernelhez linkelik. A BIOS-t, külső programokat meg nem.

A philips webcam esetén meg a kernelbe csak egy hook került, amivel a vezérlést kiadhatta a luserspace-ben futó zárt forrású kódnak, (pont ahogy most az APM kód kiadja a bios-nak,) és ez sem volt jó.

A másik pedig, hogy ha netán az nvidia azt mondaná, hogy oké, amit eddig binárisban adtam ki, azt most megkapjátok forrásban: 


/* Háde dikmán vigyázzá, ix86 only! */
int nyolc_nop(void)
{
    asm (".byte 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90");
}

szóval így már mindenki boldog lenne tőle, GKH arcán elégedett mosoly suhanna át, RMS-t pedig örömmel töltené el a nyílt forrás ilyetén térnyerése, ugye :).

Csak mert ha igen, akkor én szívesen megírom az erre építő "binary2opensource.pl" nevű scriptet, csak hogy a sok gpl-huszár végre gyakorlatiasabb dolgokkal is foglalkozhasson...

A Philips webcam esetében nem userspace-ben futott a zárt forrású kód, hanem azt modulként be kellett tölteni a kernelbe.

Én az ilyen nyolc_nop()-ot nem tekintem nyílt forrásnak, és gondolom a "gpl-huszárok" sem, legalábbis valamikor volt róla szó, h az ilyeneket is eltávolítják.

Hmm, ez egyrészt felveti, hogy akkor mi a nyílt forráskód definíciója (csak hogy vitázni is lehessen róla, mert technikai értelemben ez is az), másrészt pedig akkor mi a helyzet az intel mikrokód supporttal, amikor is az inteltől letölthetsz egy byte-halmazt, amit, mint zárt firmware-t 'feltölt' a prociba a kernel megfelelő része.

Harmadrészt pedig a bios-t nem 'linkeled' ugyan a kernelhez a hagyományos object-szimbólum-stb. módon, viszont már eleve 'hozzá van linkelve', kb. mint a gcc által a C utasításokat megvalósító kódrészletek (pl. long long aritmetika 32 bites procin), és _a processz vezérlése direkt átadódik a benne lévő kódnak_, márpedig, ha jól emlékszem, ez volt anno a sarkalatos pont egy "hozzálinkelek egy lib-et vagy domain socket-en beszélgetek egy daemon-nal" vitában, ahol is az jött ki, hogy zárt kódú daemonnal beszélgetni kóser, zárt lib-et linkelni nem.
Ebből a szempontból a kernelből bios-t hívni ugyanaz a kategória, mint ha egy zárt forrású lib-be hívnánk ki, nem?

Jut is eszembe, ugye a nyílt forrásúság nincs nyelvhez (C-hez) kötve?
Mert ha nincs, akkor egy assembly forrás is lehet nyílt. A fenti nyolc_nop pedig szintaktikailag helyes assembly forrás, warning nélkül fordul, stb. Ja, igen, elég tréh, de gpl-es C forrásban is láttunk már hajmeresztő dolgokat, ugye.
De ne is menjünk bele az inline hexdump megítélésébe! A nyílt forrásúságnak szintén nem feltétele a beszédes nevek használata, hiszen miért is ne nevezhetném én el a változóimat, függvényeimet 'a_81151' jelleggel?
Ha pedig ez így van, akkor az nvidia-nak mást se kell tennie, mint a kész, le-strip-pelt bináris driverére ráengedni egy disassemblert, ami szépen növekményesen hasonló nevekre bont le mindent. Assembly forrás lesz, nem hexdump, igaz, semmitmondó szimbólumnevekkel. Ezzel senki előbbre nem jut, mint a bináris driverrel, mert a fenti művelet amúgy is kb. öt percet vesz igénybe. Ez így jó lenne?

"Nincs értelme precízségre törekedni, amíg nem tudjuk, miről is beszélünk" - Neumann János

Ebben az értelemben minden nyílt forráskódú, csak maximum módosítás ellen védett... Te tényleg ASM-ben programozol, vagy csak kötözködés... Mert végülis a bináris megvan nekled is a kernelből meg a forráskód is, lássuk melyikbe teszel elöbb valami hasznos szolgáltatást...

Természetesen a forrásban módosítok könnyebben. A binárisban nem is kezdek módosítani, nem is azért van, hanem azért, hogy fusson.
Ugyanis attól, hogy valamibe nem tudok beletúrni, attól még használhatom. Lásd pl. azokat, akiknek a disztrib kerneleket ajánlgatják agyba-főbe: ha jól tudom, ezek az emberek is (túlnyomó részt) binárisan felteszik, és nagyon nem érdekli őket, hogy akár hozzáférhetNÉnek a forráshoz: nem teszik, mert csak _használni_ akarják.

És ha a fejlesztő nem akarja valamiért kiadni a forrást, akkor mi légyen? Ez az ő dolga, az meg, hogy én így használom-e, az meg az enyém, és vagyok annyira viszkaszmacska, hogy GKH nélkül is tudjam, hogy mi a jó nekem :).

De hogy ne csak tájszépészeti szájtépészet legyen, nézzük meg, hogy miért is nem adja ki a forrást a cuccához:

Nem akarja:
- pl. a videokártya-gyártók, mert ezzel az architektúrájukról is árulnának el részleteket, amiket aztán (a nyílt forrás okán) bármelyik konkurrensük koppinthatna, gyengeségeket fedezhetne fel benne, amire alapozhatna kampányt, stb., amit így (zárt drivernél) csak visszafejtéssel tudhat meg, ami viszont pl. bíróság előtt kevésbé állja meg a helyét
- pl. az, aki anno külsősökkel fejleszttette a modult, és a publikálás jogát 'elfelejtett' megvenni tőlük

Nem teheti:
- pl. a wifi- és tuner-kártyák fejlesztői, akiket sajna kötnek a hírközlési törvények, hogy nem forgalmazhatnak olyan készüléket, ami bizonyos nem polgári célú sávok (rendőrségi, honvédségi, stb.) vételére alkalmasak. Ezt megtehetik hardverből, és akkor a konkurrencia röhögve alájuk megy árban, ill. megtehetik szoftverből, csak akkor nem adhatják ki a forrást, hogy ne patchelje ki belőle az első jöttment érdeklődő.

Ezzel aztán gyönyörűen biztosítva is van, hogy a fenti cuccokhoz nem lehet és nem is lesz nyílt forrás, akár elvesztik ezzel a linuxos tábort (és viszont), akár nem.
Csak persze ezek az érvek némely csőlátásos fanatistáról úgy pereg le, mint a homok, és inkább lezárják a normális (értsd: rendesen működő) támogatás lehetőségét az emberek elől is.

A zárt forrású driverrel kiadott WiFi/tuner kártyák nem sértik a törvényt? Elvégre is maga a kártya alkalmas bármilyen sáv vételére, és elvileg (ha sok időbe telik is) a zárt forrású drivert is át lehet írni. Egyébként pedig nagy marhaság tiltani bizonyos sávok vételét, aki akarja, úgyis csinálhat vevőt, ha van elég pénze. A rendőrség/honvédség használjon titkosított csatornákat. (Valószínűleg azt is használ, ha tényleg titkos dolgokat akar átvinni.)

Pontosan nem tudom a vonatkozó rendelkezéseket, de úgy rémlik, hogy itt a kártya hardvere és a hozzá adott driver egységnek számít a legelső API-tól az antennáig, és ennek nem szabad tudnia lefoglalt sávot használni.
Persze akár a driver buherálásával, akár a kártyába belepiszkálással erre alkalmassá lehet tenni, de ahogy írtad is, ez ellen technikailag nem lehet védekezni, ezért is van a jogi tiltás, azaz "csináld, ha akarod, de ha rajtakapunk, megjárod".
Ez a tiltás szerintem egyáltalán nem marhaság, pláne nem az "aki akar, az úgyis megcsinálja" megindoklással, mert a., a rendőrség/katonaság munkájára szükség van, ahhoz meg a privát sávra, b., ez a tiltás visszalöki 99%-át azoknak, akik ezen gondolkoznak.
:set demagog
Ezzel az erővel nagy marhaság, hogy büntejtük a rablógyilkosságot, mert aki akarja, az úgyis ölni és rabolni fog.
:set nodemagog

Most itt "aki akarja" alatt azokat a maffia/terrorszervezeteket/idegen államok hírszerzőit értem, akiknek jó eséllyel úgyis meg van az apparátusuk olyan vevő készítéséhez, amivel bármilyen sávot lehet venni, a korlátozás csak a közönséges felhasználókat korlátozza, akik emiatt nem használhatják a vevőt Linuxon. A tiltásra van technikai megoldás, ti. nyilvánoskulcsú titkosítás használata, könnyen lehet, hogy használják is. Ha igen, legkevésbé sem kell, hogy zavarja őket, ha veszem a rendőrségi sávot, mert úgysem tudom visszafejteni.

Civil hozzáállás :)... Ha van lehetőség még egy védvonal felhúzására, és ráadásul semmibe sem kerül, akkor azt fel kell húzni. Ha fölösleges, akkor i.j., veszteség akkor sincs.
Természetesen még elérhető technológiával is lehet ezeken a sávokon működő vevőt építeni, viszont ha Próba Bélát egy jogszabály okozta nehézségek/kockázatok ettől eltántorítanak, akkor eggyel kevesebb szem van arra, hogy az esetleges hibákat felfedezzék. Ha egymillió P.B. áll el ettől, akkor annyival kevesebb.
Meg a másik oldala, talán a fontosabb, hogy nemcsak ne vegyél azokon a sávokon, de adni se tudj, mert lehet, hogy _érvényes_ forgalmat nem tudsz generálni, de zajt igen, és a sávszélességüket le tudod terhelni vele. Persze, ezt is meg lehet csinálni, csak ha egy ember teszi, azt be lehet mérni és ki lehet rá küldeni a kéményseprőket (fekete maszk, fekete ruha, stb.), de ha mindenki joggal teheti, akkor az egész város egy nagy zajforrás lesz.
Ugyanilyen okból nem kapsz a boltban egyenruha-tartozékokat sem, csak szolgálati igazolvány felmutatása után, nem dekorálhatod a kocsidat "Rendőrség" felirattal.
Kb. ezen a gondolatmeneten alapul a forgalmi megkülönböztető jelzésekre (sziréna, piros/kék villogó) vonatkozó szabályozás. Persze nevetve meg tudnád építeni, de neked ez tilos, és azért tilos, hogy ha a feltűnik egy ilyen, akkor onnan egyértelmű legyen mindenkinek, hogy azt a megfelelő intézmény használja.

Amúgy kellett már linux alatt is asm-ben kódolnom, mert a drága gcc képtelen volt úgy fordítani egy 5 változót használó ciklust (i386, tehát 7 általános célú regiszter van ugye) egy grafikának a pixelenként futó részénél, hogy ne legyen benne 3 db memóriahivatkozás, kb. 20%-ot lassítva ezzel a dolgon. Mondjuk ez még a 2.95 idején volt, de nagyot dobott rajta az a másfél-két képernyőnyi asm :).

Az (kéne, hogy legyen) a forráskód, amiben eredetileg megírták a kódot, és nem valami átmeneti, vagy utólag visszafejtett dolog. (Elvileg írhatták volna gépi kódban is, de egy bíróságnak talán mégse tudnák beadni.) Ez azt jelenti, hogy pl. ha a cég egy gépén megtalálják a C forrást, akkor bizonyított, hogy nem az Assembly volt az eredeti, mert egy olvasható C forrásnak nagyobb az információtartalma, mint egy Assembly kódnak.

Tetszik a megközelítés, de határt kell húzni itt is valahol.
Ugyanis vannak pl. olyan eszközök, amik UML/OMT osztály- és állapotdiagramokból generálnak kód-vázlatot, azt hiszem 'dia2code' néven van nyílt forrású is ilyesmi, de van ennél többet, jobban tudó zárt forrású is. Mi történjék, hogyha az illető cég egy ilyesmi eszközzel csinálta a kódot, és a C (vagy ennyi erővel akár asm) forrás már csak 'átmeneti dolog'?
Illetőleg, bár ez elég elméleti jellegű, mi történjék, ha valaki saját nyelvet és fordítót használ, amit meg akar tartani magának, csak az azzal előállított terméket, a futtathatót akarja közzé tenni? Kiadhatja a forrást is, de a nyelv specifikációja nélkül az nem biztos, hogy ér is valamit.