A Red Hat és a "takargatott" kernelpatchek

Nemrég Raphaël Hertzog interjút készített Maximilian Attems-szel, a Debian kernelcsapatának tagjával. A riportban Maximilian megemlítette, hogy 2.6.32-es kernel feletti össznépi együttműködés a disztribútorok közt nagyszerű dolog, de a Red Hat megnehezíti a dolgokat azzal, hogy a Red Hat Enterprise Linux 6 kernelforrását egy darab nagy kátránylabdaként szállítja ahelyett, hogy szállítaná az upstream forrást és amellé tenné az egyes patcheket. Így aki kíváncsi arra, hogy mit változtatott a Red Hat az eredeti forráson, az leginkább csak a changelog alapján találgathat. A Debian kernelkarbantartója azt állítja, hogy a Red Hat gyakorlatilag "obfuszkálja" az általa szállított kernel forrását.

Az interjúban olvasható kijelentések nyomán nyomozni kezdett az LWN főszerkesztője, Jonathan Corbet. Megkereste és letöltötte a Red Hat 2.6.32-71.14.1.el6-os forráscsomagját és ellenőrizte a Debian karbantartó állításait. Arra jutott, hogy a Red Hat valóban szakított korábbi gyakorlatával és valóban nem mellékeli a patcheket a kernelforrás mellé, inkább alkalmazza azokat a forráson és már a megpatchelt forrást adja közre. Corbet szerint ezzel az a probléma, hogy - ugyan a GPL-t ez nem sérti, de - jelentősen megnehezíti annak a dolgát, aki arra kíváncsi, hogy mi változott a kernelben. Corbet reményét fejezte ki, hogy ez csak egy egy alkalomra szóló hibás lépés volt a Red Hat-tól és a disztribútor hamarosan kiköszörüli a csorbát.

A H Open is cikkezett a témában. Viszont szerintük ez feltehetően nem véletlen, hanem szándékos lépés volt a Red Hat-tól, mégpedig azért, hogy megnehezítse a konkurencia, főként az Oracle dolgát, amely újracsomagolja a Red Hat forrását az Unbreakable Linux termékéhez.

Amikor a Red Hat-nél rákérdeztek erre a dologra, a vállalat hivatalos válasza "no comment" volt. Viszont a H Open állítja, hogy egy, a Red Hat működésével tisztában levő forrás megerősítette számára, hogy ez az "obfuszkálás" szándékos a Red Hat részéről és az a célja, hogy megnehezítse a RHEL források downstream felhasználóinak - kiváltképp az Oracle - dolgát.

Úgy tűnik, hogy a Red Hat saját mérnökei sem örülnek ennek a helyzetnek. Attems szerint a Red Hat-nak visszakoznia kellene és nem kellene ilyen hülye menedzsment(től induló) lépéseket tennie.

A jelentések feltételezik, hogy a Red Hat lépései leginkább az Oracle ellen születtek, de megjegyzik, hogy más disztribútorok - például a CentOS - dolgát is megnehezíthetik.

A részletek itt.

Hozzászólások

Én nem látok ebben problémát. Egyrészt egy rövid, a diffet hívó script le tudja gyártani a patcheket ha fogjuk a red hat féle kernel forrását és a megfelelő vanilla kernel forrását. Másrészt ha én pénzt ölnék valaminek a fejlesztésébe, de eleget kellene tennem bizonyos licenceknek, én is keresném a kiskaput ha a konkurencia fel akarná használni az én munkám ingyen.

--
Don't be an Ubuntard!

a GPL-ben nem a forras vagy srpm kozzetetelerol van szo, hanem a 'preferred form of the work for making modifications to it'-rol. amit a RH jelenleg kozzetesz, az minden, csak nem preferred. nem csak a nagyvilag szamara, de meg a sajat programozoik szamara sem, l. kulon letoltheto patch-ek a fizeto ugyfeleknek. na az a preferred form.

Nagy ferdito vagy te, hallod:

"The “source code” for a work means the preferred form of the work for making modifications to it."

Nem tokeletesen mindegy, milyen formaban erheted el a forraskodot?

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

> Nagy ferdito vagy te, hallod:

lehet en tudok angolul, te meg nem? tudod mit jelent a 'means' szo? (mar eleve vicces megkerdezni is, de latom, ma rajtad fogunk nevetni ;). az altalad bemasolt mondat *definialja* (a GPL szamara) a 'source code' fogalmat. az, hogy te hetkoznapi (nem)programozokent mit tartasz forraskodnak tokeletesen erdektelen, a GPL szempontjabol az relevans, amit a GPL annak definial. namarmost a GPL egyertelmuen 'preferred form'-rol beszel, sot azt is megmondja, hogy mihez preferred: az adott 'work' *modositasahoz*. a RH kernele eseten a 'work' egy Linus kernelbol szarmazo alkotas, vagyis Linus fa + RH modositasok. a preferred form ebbol kovetkezoen a szeparalt forma, nem az egyesitett.

" RH kernele eseten a 'work' egy Linus kernelbol szarmazo alkotas, vagyis Linus fa + RH modositasok."
Nem. Ok egy termeket allitanak elo, amely a vanilla kernelbol szarmazik, inallo termek. Kozze is teszik a kodjat. Ok nem patchseteket keszitenek, hanem kernelt. Kozze is teszik a forrasat.

> Nem. Ok egy termeket allitanak elo, amely a vanilla kernelbol szarmazik, inallo termek.

mi nem? ;) mi a kulonbseg a 'Linux fa + RH modositasok' es 'vanilla kernelbol szarmazik' kozott? semmi?

> Ok nem patchseteket keszitenek, hanem kernelt. Kozze is teszik a forrasat.

a GPL nem siman a 'source code' kozzetetelerol szol, hanem a preferred form-rol. az, hogy te mit ertesz forraskodon, erdektelen, az szamit, amit a GPL annak definial. marpedig a 'nagy osszemerge-lt forrasfa' az nem preferred form, akarmelyik programozo megmondja neked. de szerintem ezt te is tudod...

> A Red Hat szamara a preferred form a sajat forras tarball es kesz.

nem kesz, mert ez egyszeruen nem igaz. ok egyedi patch-eken dolgoznak (fizeto ugyfelek le is tolthetik, mar varom, hogy valaki vegye a batorsagot, es kozzetegye oket), sot megsaccolom, hogy jo par git fat/branch-et is karbantartanak.

Tehat mindenki, aki nem patchsetet tesz kozze (es nem is a sajat forrasfajat), az GPL serto. Nos, nezzuk csak:
http://www.gnewsense.org/Documentation/BuildKernel
nem latom, hogy patchseteket hasznalnanak, sajat kerneluk van, sajat terjesztessel. Logfile van a modositott fileok listajaval, de diff nincs.
Pedig ez a distro az FSF szerint elismert es tamogatott distro. Ezek szerint megis GPL-t sert, mert nem az elvart formaban teszi kozze a dolgokat?

> nem latom, hogy patchseteket hasznalnanak, sajat kerneluk van, sajat terjesztessel. Logfile van a modositott fileok listajaval, de diff nincs.

ha a fejlesztok igy fejlesztenek, akkor ez az elvart forma, nincs semmi gond. en is terjeszthetnem a PaX-ot szetszeparalva, de nem teszem, mert ilyen formaban nem letezik (pedig neha jo lenne meg nekem is), de ettol meg nem sertek GPL-t. ha viszont en magam ilyen formaban tartanam karban, de csak a jelenlegi omlesztett maszlagot tennem kozze, eltussolva azt a format, amit en magam hasznalok a fejleszteshez, nos akkor ugyanolyan rossz fiu lennek, mint most a RH. bar most, hogy van ra precedens, lehet nekem is meg kene probalni, remelem majd megvedtek engem is ;).

ja neked is felteszem a kerdest: hogyan lehetseges az, hogy eddig a preferred form a szeparalt patch sorozat volt, RHEL6-nal meg az egybeolvasztott fa? mert ugye ugyanazok az emberek fejlesztik mindkettot, es egy programozo szamara vilagos, hogy a ket forma meroben elter egymastol, amikor tovabbi modositasokrol van szo, tehat mindketto nem lehet preferred (mint ahogy nem is az). azt is megmagyarazhatod, hogy miert erhetok el a kulon patch-ek tovabbra is (a fizeto felhasznaloknak), ha a te logikad szerint az kevesbe preferred, mint az omlesztett (ti. akkor mire jo? es miert jobb ugy, mint az omlesztett, miert nem mondja a RH az ugyfeleknek, hogy de hat az omlesztett az igazi...). bar szerintem nem fogsz rajuk valaszolni, mert te is nagyon jol erted, hogy itt bizony a RH szemet volt es ezen nincs mit szepiteni.

"hogyan lehetseges az, hogy eddig a preferred form a szeparalt patch sorozat volt, RHEL6-nal meg az egybeolvasztott fa?"
A vilag valtozik. Tegnap meg ez volt a jo, ma mar mas a jo.
"azt is megmagyarazhatod, hogy miert erhetok el a kulon patch-ek tovabbra is (a fizeto felhasznaloknak)"
Talan pont azert, mert fizetnek erte? Plusz szolgaltatas.

A Red Hat nem szemet, hanem vedi a piacat. Akkor bezzeg mindenki tud orulni, amikor bejelentik, hogy "hu, mar egymilliard dollar forgalmunk volt", akkor is, amikor "huuu, nezd, a kernelt am fizetett fejlesztok fejlesztik, nem hobbikoderek", de akkor, amikor olyat tesz, amit nem szokott, es teljesen legalisan teszi, csak eppen valakinek nem tetszik, akkor "fujj redhat buzik, csalok, hazugok." Hatalmas kettosmerce van a legtobb Open Source hivonel, csak nem kepes belatni azt.

> A vilag valtozik. Tegnap meg ez volt a jo, ma mar mas a jo.

nem ertetted a kerdes lenyeget akkor ;). nem tegnap/ma kulonbsegrol van szo, mivel a RHEL[45] meg a RHEL6 sorozat *egy idoben* ket *kulonbozo* modon erheto el 'forraskod formaban'. az a kerdesem, hogyan lehetseges, hogy mindketto preferred. mert igazabol minden programozo tudja, hogy ez nem lehetseges, marpedig akkor a RH rossz fiu.

> Talan pont azert, mert fizetnek erte? Plusz szolgaltatas.

nem mondtad meg, mi lenne ez a plusz szolgaltatas. magyaran miert jo ez barkinek. es ha jo valamiert, miert nem jobb az omlesztett forma. ha mar egyszer az a preferred form, es nem a szeparalt patch. mert azt erted, hogy a logikad bedol, ha kiderul, hogy igazabol a szeparalt patch a jobb forma akarmihez. leginkabb a tovabbi modositashoz, amirol a GPL explicite megemlekezik ugye (es amit minden programozo tud, nem veletlenul a felhordules mindenhol, bar csodalom, hogy csak ennyi honap utan kezdtek el piszkalni az ugyet, engem speciel mar az elso RHEL6 megjelenese ota zavar).

> A Red Hat nem szemet, hanem vedi a piacat.

a ket dolog egyreszt nem zarja ki egymast, masreszt milyen piacot ved meg azaltal, hogy omlesztett patchet tesz ki a nepnek, a fizetoknek meg tovabbra is odaadja a szeparalt patcheket? (tudom, paran itt meg mashol is kiokoskodtak, hogy biztos az Oracle ellen van, ami eleg nevetseges, mert ebedpenzbol kifizetnek egy RH licenszet, ha arrol van szo)

> [...]es teljesen legalisan teszi[...]

errol beszelunk, hogy egyaltalan nem biztos az a 'teljesen legalis' dolog...

> Hatalmas kettosmerce van a legtobb Open Source hivonel, csak nem kepes belatni azt.

azt azert tegyuk hozza, hogy a RH magarol alakitotta ki a nyilt forrasert kuzdo keresztes hadsereg kepet. aztan ez a mostani huzasuk meg valahogy nem illik a kepbe, es ez sokaknak feltunt.

"az altalad bemasolt mondat *definialja* (a GPL szamara) a 'source code' fogalmat."
De nem kovetkezik ebbol, hogy a forraskodon elkovetett modositasokat kulon, az eredeti kodtol kell terjeszteni.

Akkor lenne igy, ha a modositasok terjesztesenek formajat is eloirna.

Megjegyzem: a preferred form alapu definicio igy elegge butacska. Ha _nekem_ a binarisbol visszafejtett assembly kod optimalizalasa a preferred (mert eppen compiler bug miatt nem jo a generalt assembly kod, de a forras jo), akkor onnantol kezdve nekem az szamit forraskodnak, nem mas, igy azt kell terjesztenem tovabb. Nagyon buta ez a megfogalmazas.

Szerencsere nem az en problemam, hogy el tudod olvasni ugyan a szavakat, de belole epkezlab tartalmat nem tudsz magadnak osszeallitani:

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.

Hello.

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

hello, latom sehogy se akar osszeallni ez az angol ma. az altalad most bemasolt mondat nem a source code-t definialja, hanem azt irja le, hogy amikor azt kozzeteszik, az milyen (file)formatumban legyen (pontosabban milyen kovetelmenyeknek feleljen meg a formatum). szoval hogy jott ez most ide?

Az eg aldjon mar meg, nincs jobb dolgod, mint hulyesegeket beszelni? A GPL egyertelmuen definialja, mi a forraskod, tudnam, mi a francnak lovagolsz rajta. Azt is megmondja, milyen formatumban kell kozzetenni. A Red Hat mindkettot egyertelmuen teljesiti. Innentol fogva mar csak az izzo lelku sotetszobai trollok kotnek bele.

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

Még szerencse, hogy Te érted az angolt, ahogy kell. :)

"The “source code” for a work means the preferred form of the work for making modifications to it."
Ha most a work=termék durva egyszerűsítéssel az én értelmezésemben:
A termék forráskódja a termék preferált formája ahhoz, hogy módosításokat lehessen elvégezni rajta.

:)
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

A termék forráskódja jelenti a termék preferált formáját ahhoz, hogy módosításokat lehessen elvégezni rajta.

Csak, hogy meglegyen. :)

Bár ilyen esetekben a "means" szó direkt fordítása nem szerencsés, ezért inkább úgy kell fogalmazni, hogy az bele legyen értve.
Hasonlóképpen egyébként a magyarázó angol szövegekben előforduló "that" és "that means" szerkezetek fordítási analógiájához.

Ja ... és ez csöppet sem ideologizálás, hanem fordítás.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

A "The “source code” for a work means the preferred form of the work for making modifications to it." véletlenül sem azt jelenti, hogy "A termék forráskódja jelenti a termék preferált formáját ahhoz, hogy módosításokat lehessen elvégezni rajta". Remélem nem ezen vitatkozunk.

"Egy munka forráskódja a munkának azt a formáját jelenti, melyben a módosításokat szokás végezni."
Szerintem az én fordításom is ezt a tartalmat hordozza.

hint: http://hup.hu/cikkek/20100302/a_red_hat_es_a_takargatott_kernelpatchek#…

Esetleg nyelvész zsenik prezentálhatnának egy szerintük frankó fordítást.

"krisztus anyja ne hagyj el"
Ez eléggé szabad fordítás ... :):)
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

baratom te osszekevered a szezont a fazonnal, vagy adott esetben az alanyt a targgyal. 'A means B' eseten A az alany, B a targy (vagy akarmi mas, csak nem az alany). a 'means' ige jelentese, nehez most mar rohoges nelkul leirni, de ugy latszik muszaj: '[uj fogalom] jelent [regi/meglevo fogalom]'. a te ferditesed ott csusztatja el a dolgot, hogy jatszik a magyarra oly jellemzo szosorrenddel es ezaltal mas ertelmet ad neki, mint az eredeti angol. amikor azt mondod, hogy 'A jelenti a B-t' akkor az a B-t definialja A-ra (A a regi fogalom, B az uj fogalom). ha azt mondod, hogy 'A B-t jelent', akkor meg A-t definialod B-re (A az uj fogalom, B a regi). erted? nem a farok csovalja a kutyat, nem a forraskod definialja, hogy mi szamit preferred form-nak, hanem pont forditva, az szamit forraskodnak (marmint a GPL szamara), ami a preferred form.

en meg azt magyaraztam el neked, hogy amit te ferditettel ill. amit belinkeltel, az homlokegyenest ellenkezo. amugy meg nem ertem mire akarsz kilyukadni, ha egyszer elismered, hogy az altalad beidezett forditas a helyes (mint ahogy az is, a 'work' felreforditasat leszamitva, az alkotas/mu" pontosabb lett volna). mert hogy az pontosan azt mondja, amit en is: a GPL adott mondata definialja az adott kornyezetben a 'source code' jelenteset (ha lattal mar jogasz altal irt szoveget, biztos feltunt, hogy tele van az adott kontextusra specifikus definiciokkal, a GPL sem kivetel ez alol). megpedig ahhoz koti, amit a "preferred form for making modifications" hataroz meg. tehat edesmindegy, hogy a (programozo) koznyelv mit tekint forraskodnak, a licensz szamara az a forma a relevans, ami teljesiti ezt a feltetelt. marpedig amit a RH kozzetesz, az minden, csak nem preferred, ezt *senki* nem vitatja. akkor viszont az sem vitathato, hogy ezzel a RH nem tesz eleget a GPL-nek. vili?

> akkor viszont az sem vitathato, hogy ezzel a RH nem tesz eleget a GPL-nek.

Dehogynem :-)

A gondolatmenetedet követve tegyük fel, hogy 1 cég 2-féle formátumban adja ki ugyanannak a termékének a forráskódját. Nyilván csak az 1-ik formátum lehet "preferred"(?), de akkor a 2-ik (szerinted) "nem tesz eleget a GPL-nek"?

Csak azért kérdezem, mert ha a 2-ik (nem "preferred") kiadás is eleget tesz (szerinted) a GPL-nek, akkor a RedHat féle (nem "preferred") kiadás is eleget tesz.

> a GPL adott mondata definialja az adott kornyezetben a 'source code' jelenteset

Épp hogy nem definiálja, hanem a szokásokra utal. Hogy azt nevezzük forráskódnak, amit az emberek választanak, amikor módosítani akarnak egy (szoftver)terméket.

Logikus, hogyha csak 1-féle formátumban adják ki a forrást, akkor azt az 1-et fogják választani, vagyis az lesz a "preferred".

:-)

> A gondolatmenetedet követve tegyük fel, hogy 1 cég 2-féle formátumban adja ki ugyanannak a termékének a forráskódját. Nyilván csak az 1-ik formátum lehet "preferred"(?), de akkor a 2-ik (szerinted) "nem tesz eleget a GPL-nek"?

nem tudom, milyen konkret peldara gondolsz, de ugy altalaban ha letezik egy preferred formatumu forraskod kiadas, teljesen mindegy, hogy hany masfele modon teszik meg kozze a forraskodot, a GPL arrol mar nem rendelkezik ;). a RHEL6 eseten en egyfajta forraskodrol tudok (marmint ami nem az elofizetoknek szol) es az ugye teljesen mas (modosithatosag szempontjabol), mint amit egy RHEL[45] srpm-ben megtalalsz (magyaran aki a RH donteset meg akarja vedeni, annak meg kene tudni magyarazni, hogyan lehet mindket formatum preferred, persicsb-t mar fentebb megkerdeztem, es nem lettem eddig okosabb, de talan te meg tudod magyarazni? ;). ha lenne RHEL6-hoz a regi feldarabolt patch-es srpm is, akkor semmi gond nem lenne, max a kutya nem hasznalna a mostani omlesztett verziot.

> Épp hogy nem definiálja, hanem a szokásokra utal. Hogy azt nevezzük forráskódnak, amit az emberek választanak, amikor módosítani akarnak egy (szoftver)terméket.

ize, szerintem beszelj egy jogasszal. ez egy definicio, ami a licensz adott reszeben az adott kifejezest ertelmezi, pontosan azert, hogy ne szokasokra, meg 'en azt hittem, hogy...' tipusu ertelmezesekre kelljen hagyatkozni (ami ugye nemdeterminisztikussa tenne a licensz szoveget, marpedig az ilyet rettenetesen utaljak a jogaszok), hanem ehelyett valami preciz fogalmat akar adni. az, hogy ez mennyire sikerult, az mas kerdes, ha megse egyertelmu a definicio valamiert, akkor majd egy biro eldonti egy adott perben. a mostani esetben ugye a 'preferred' kitetelen el lehetne vitatkozni, hiszen amikor a GPL2-t irtak, a tarball+patch terjesztesi forma nem nagyon volt divatban meg, de egy biro biztosan figyelembe venne egy adott ugyben, hogy a RH maga is egy adott formatumot hasznalt elotte, es megkerdezne, hogy hirtelen miert egy masik formatum lett a preferred (plane ugy, hogy vele egyidoben a regebbi termekeinel megtartotta az elozo format).

vagy maskepp megvilagitva: ha az adott mondat a GPL-ben azt mondana, hogy a forraskod az, amiben ascii viragokkal dekoralt kommentek vannak, akkor a licensz szempontjabol az lenne a forraskod definicioja, es ahhoz kellene mindenkinek magat tartani, akkor is, ha amugy nem szokas ascii viragokkal dekoralni a kommenteket. ezert van az a jo tulajdonsaga a licenszeknek, hogy nem kotelezo oket elfogadni.

> Logikus, hogyha csak 1-féle formátumban adják ki a forrást, akkor azt az 1-et fogják választani, vagyis az lesz a "preferred".

nem, nem attol lesz preferred valami, mert azt dobtak oda koncnak, hanem attol, hogy a derived work-ot kiado maga milyen formatumot hasznal a sajat modositasaihoz. mert ha o nem azon a formatumon dolgozik, mint amit kiad (marpedig tudjuk, hogy nem), akkor bizony ott sunyisag van es lehet jogosan haborogni (es most mar vegre eleg sokan meg is teszik, meg egy Greg K-H kaliberu fejleszto is szova tette a legutobbi 2.6.32.x stable kiadasban).

"ugy altalaban ha letezik egy preferred formatumu forraskod kiadas,"
Es innentol nem erdekes a tobbi. NEM letezik ilyen allat. Nincs, kesz, elfogyott, sosem volt. A preferred formatum a mu altalanos formatumarol beszel, ami program eseteben valoban a forraskod, egy bicikli eseteben meg a tervrajzok.

A tevedesek elkerulese vegett: ha publikus az SVN repo, az is teljesiti a GPL eloirasait, mert a forras elerheto, nem kotelezo meg katranylabdat is gyartani hozza. A GPL elsosorban a forras elerhetove tetelerol szol, nem pedig annak formatumarol, tekintve, hogy errol nem is mondhat semmit, ugyanis a GPL licensz nem korlatozodik szoftvertermekre, sot, meg az IT iparagra sem. GPL licenszu lehet peldaul egy etel is, melynek kozzeteteli formaja a recept, mert a modositasokat ezen szokas elvegezni (ez lesz a preferred formatuma) - es ez tokeletesen kielegiti a GPL licenszt, amennyiben ez a recept publikusan elerheto, vagy egy ingyenes kerelem elleneben elerheto.

--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

> Es innentol nem erdekes a tobbi. NEM letezik ilyen allat.

marmint mi nem letezik?

> A GPL elsosorban a forras elerhetove tetelerol szol, nem pedig annak formatumarol

tevedes, a GPL egy copyright licensz, az azzal kapcsolatos jogokrol (ti. hogy te mint felhasznalo, kapsz olyan jogokat, amik amugy nem illetnenek meg), ill. azok kovetkezmenyeirol szol (nincs ingyen a menyasszony, az extra jogokert cserebe neked is kell tenni valamit). a 'forraskod' (altalanos programozo ertelemben, nem a GPL ertelmeben) teljesen mellekes reszlet, az informacio/tudas (a mu") hordozoja sok mas is lehet (szerzoi jog ala esnek pl. fenykepek is).

a konkret esetben a GPL definialja a 'forraskod' kifejezest a "preferred form for making modifications"-ra, amit mindig az adott mure kell ertelmezni, ez nyilvanvalo. az viszont *nem* annyira nyilvanvalo, hogy egy 'forraskod' mikor lesz 'preferred form' (pontosabban nekem az adott esetben egeszen egyertelmu, hogy az omlesztett tarball helyett az eredeti tarball+patchek a preferred, es meg nem hallottam egy ervet sem, hogy ez miert lenne maskepp). ebbol kovetkezik, hogy az adott esetben igenis szamit a 'formatum', vagyis hogy mi az srpm file tartalma. ha igazad lenne es nem szamitana, akkor ennyi erovel minden sort kulon file-ba szedve is kiadhatna a RH a 'forraskodot', de kotve hiszem, hogy megusznak per nelkul. de tudok jobbat a kerdes eldontesere: csinalj *te* egy ilyen linux forraskod kiadast, jol reklamozd be lkml-en, es meglatjuk a reakciot ;).

> GPL licenszu lehet peldaul egy etel is,

ez ugy baromsag, ahogy van. ami GPL licenszu lehet, az maga a recept, nem az etel, ami az alapjan keszul. azt erted, hogy a GPL egy copyright licensz es etelre olyan allat nem letezik, hogy teged idezzelek? a copyright (nalunk szerzoi jog) kifejezetten szellemi alkotasokra vonatkozik, se egy tal etel, se egy bicikli nem az. az adott dolgok elkeszitesehez szukseges tudas/informacio/leiras/stb mar szellemi alkotas viszont (legalabbis jo esely van ra, mert ugye vannak azert kitetelek meg arra vonatkozoan, hogy mi esik a szerzoi jog hatalya ala, pl. egy jogszabaly megalkotasa hiaba kerul valakinek sok idejebe, attol meg nem valik szerzoi joggal vedett muve).

A GPL preferred form kitetele nem errol szol. A mondat jelentese: a szoftvert modositani a forraskodon keresztul ajanlott, nem pedig mas uton (reverse engineering, a binarisok modositasa).
"The source code for a work means the preferred form of the work for making modifications to it."
A mu forraskodjanak modositasa a muhoz keszult valtoztatasok ajanlott formaja. Ezt jelenti ez a mondat. Semmit nem mond a modositasok terjesztesenek formajarol.

> A mondat jelentese: a szoftvert modositani a forraskodon keresztul ajanlott, nem pedig mas uton (reverse engineering, a binarisok modositasa).

nem, a mondat nem ezt jelenti, szo sincs benne ajanlasrol, plane modositasi technikakrol. a mondat *definialja* a 'source code' fogalmat.

> A mu forraskodjanak modositasa a muhoz keszult valtoztatasok ajanlott formaja. Ezt jelenti ez a mondat.

ezt sem jelenti.

> Semmit nem mond a modositasok terjesztesenek formajarol.

de mond. a bekezdes eloszor definialja a 'source code' fogalmat, azutan pedig erre alapozva a 'complete source code' fogalmat, a 3. paragrafus elotte levo bekezdesei (az a/b/c pontok) pedig leirjak, hogy a 'complete corresponding machine-readable source code'-t hogyan kell elerhetove tenni.

ha neked lenne igazad, akkor ennyi erovel lehetne C helyett gas kimenetet is terjeszteni linux forraskod cimen (hiszen abbol egyertelmuen eloallithato a binaris kimenet, tehat megfelel a 'complete corresponding' feltetelnek).

Sracok, en most le fogom loni a poent: a GPL licensz elerheto magyarul is, bar nem hivatalos forditaskent, megis, ugy gondolom, hogy akik forditottak, talan nem teljesen inkompetensek az angol nyelv teruleten. Az erintett szakasz magyarul ez:

A program (vagy a programon alapuló munka a 2. szakasz alapján) másolható és terjeszthető tárgykódú vagy végrehajtható kódú formájában az 1. és 2. szakaszban foglaltak szerint, amennyiben az alábbi feltételek is teljesülnek:

a) A teljes, gép által értelmezhető forráskód kíséri az anyagot, melynek terjesztése az 1. és 2. szakaszban foglaltak szerint történik, szoftverterjesztésre használt hordozón; vagy

b) Egy legalább három évre szóló írásos ajánlat kíséri az anyagot, mely szerint bármely külső személynek rendelkezésre áll a teljes gép által értelmezhető forráskód, a fizikai továbbítást fedező összegnél nem nagyobb díjért az 1. és 2. szakaszban foglaltak szerint szoftverterjesztésre használt adathordozón; vagy

c) Olyan tájékoztatás kíséri az anyagot, mely tartalmazza az írásos ajánlat szövegét a forráskód biztosítására. (Ez az alternatíva csak nem kereskedelmi terjesztés esetén alkalmazható, abban az esetben, ha a terjesztő a Programhoz a tárgykódú vagy forráskódú formájában jutott hozzá az ajánlattal együtt a b. cikkelynek megfelelően.)

Egy munka forráskódja a munkának azt a formáját jelenti, melyben a módosításokat szokás végezni. Egy végrehajtható program esetében a teljes forráskód jelenti a modulok forráskódját, a kapcsolódó felületkezelő definíciós fájlokat, és a fordítást vezérlő parancsfájlokat. Egy speciális kivételként a forráskódnak nem kell tartalmaznia az operációs rendszer főbb részeit (kernel fordítóprogram stb.), melyen a végrehajtható kód fut, hacsak nem tartozik ehhez maga a program is.

Ha a végrehajtható program vagy tárgykód terjesztése a forráskód hozzáférését egy megadott helyen biztosító ajánlattal történik, ez az ajánlat egyenértékű a forráskód terjesztésével, még akkor is, ha másoknak így nem kell a forrást lemásolniuk a tárgykóddal együtt.

Es mindenki vonja le maganak a konzekvenciat. Az a szakasz ezt jelenti.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

hat szerintem felreertelmezed, szubjektiv dolgokat nem szoktak jogi szovegekbe rakni. ezzel megprobalja definialni a forraskod fogalmat, ami az a formaja a termeknek, amiken a valtoztatasokat szokas vegezni.: c programnal nyilvan a c forraskod es nem a binaris, vagy assembly. butykos tengelynel ugye nincs forraskod, hanem muszaki rajz van, aramkornel meg kapcsolasi rajz

--
NetBSD - Simplicity is prerequisite for reliability

Én nem tudtam kielemezni, hogy a méltatlan jelző kire vonatkozott, a redhatre vagy ezen hozzászólás:
http://hup.hu/cikkek/20100302/a_red_hat_es_a_takargatott_kernelpatchek#…
utolsó mondatára. Támogatom azt a gondolatot, hogy ez a hsz méltatlan az opensource-hoz.

A redhatról meg annyit, hogy én nem érzem ezt olyan nagy akadályozásnak, kicsit vihar került a bilibe...

Azt írtad, hogy ha .... akkor te is keresnéd a kiskaput.

Ez nem opensource eszmeiség, ha kényszerülve lennék kiadni a forrást, annak csak egy oka lenne: opensource cuccokat használtam fel. Tehát engem megtámogatott az opensource közösség, és akkor én nem akarom ezt valahogy viszonozni?

nem győztél meg, hogy ez megfelel az os szellemiségének. A redhat is kapott egy halom dolgot az opensource-tól, nem ők írták az egész kernelt meg a teljes userlandet, úgyhogy az ő bevételük egy részének is az opensource szerzők az "okozói". Jogos elvárni a viszonzást.

mindezt szigorúan imho. hogy az most a saját véleményed volt, vagy idézet, annyiból releváns, hogy neked vagy másnak kell címezni a beszólást:)

Az a baj, hogy ha a red hat megtámogatja a közösséget, azon keresztül megtámogatja a konkurenciáját. Nyilván senkinek nincs azzal baja, ha egy vagy több hobby kernel coder nézegeti a forrást, és még csak az se lenne baj, ha az oracle ezen munkát is felhasználva saját megoldást építene. A gond az, hogy az oracle szinte kizárólag ezen munkát felhasználva épít saját megoldást.

--
Don't be an Ubuntard!

Pár gondolat:
- a redhatet meg mások támogatták meg. azok a mások miért nem pampognak most?
- ha opensource-t használsz, akkor (feltéve, hogy okosan előre olvastad a licenszet) erre fel kellett készülnöd. egy kicsit olyan utólagos szerződésmódosítás szaga van a dolognak számomra még akkor is, ha ez jogilag nem ide illő kifejezés volt
- a redhat írta az oracle rdbms-t meg a rac-ot meg ezeket? nekem valahogy úgy tűnik, hogy az oracle-nel nem a linux a lé forrása, hanem a dbms, az alkalmazási cuccok, meg a köré növesztett ecosystem
- elvileg, ha minden az álmok szerint működik, akkor az oracle a mysql-ben vissza fog juttatni dolgokat a közösségnek. lehet, hogy azért fog más cég redhatet venni, mert mysql-t akar futtatni rajta. Akkor pampogjon az oracle is?

> Kozreadjak a forrast? Igen. Elerheto a source RPM? Igen.

Ezek jogi kérdések. Azt mondta, jogilag oké. A ,,méltatlan'' az egy kicsit más terület.

Lehet úgy felfogni az egészet, hogy elég szó szerint igazodni a leírt megállapodásokhoz (pl. licencszerződésekhez). Amíg azokat betartom, kb. azt csinálok, amit akarok, pl. kereshetek kiskapukat magamnak.

Meg lehet úgy is felfogni, hogy a szabály van az emberért. A megállapodáshoz akkor is igazodni kell (illetve érdemes), de itt többről van szó. Pl. ha nincs leírva, hogy még milyen módokon ne csesszek ki a másikkal, attól még nem keresem annak lehetőségét.

Szerintem ez a kérdés oda vezet vissza, hogy az Oracle hogyan fogja fel a dolgot; ha nem jól, akkor azzal kell kezdeni valamit (valószínűleg itt bukna el a projekt). Utána jöhetne, hogy most a Red6 - ha méltányos akar lenni - változtasson-e a politikáján.

le is van maradva a CentOS az aktuális kiadással.

a Red6 következő kiadására portolni kellene az Android Dalvikját és arra építeni pár fontos admin toolt:) érdekes dilemma elé állítanák az Oraclet.

En inkabb ezt sajnalom:

http://people.redhat.com/linville/kernels/rhel6/

"Due to changes in Red Hat policy regarding release of test kernels, I
am no longer at liberty to release test kernels to the general public.

If this is inconvenient for you, please register your complaint through
whatever Red Hat support means are available to you."

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

Addig nem kell izgulnia a senkinek amig ilyen "kivalo" kernelt szallitanak a 6-os rhel-hez ;o) Vegulis csak folyamatosan all fejre egy papiron tamogatott szerveren (hp dl380 g7) a radeon kernel modullal ;o) es amig meg az oracle sem supportalt rajta addig marad a jo oreg bevalt rhel 5.5 a friss hus 2.6.18-as kernelevel ;o))Mielott kifelejtem a supportalt bnx2-es driver is igencsak panaszkodik az adott szerveren (bezzeg a support matrixon kivuli squeeze-vel megy ;o))) A hpsum futtatasa utan annyival bovult a kor hogy az mpctl is hanyja magabol az error-t ;o) Nagy vonalkban ennyit errol a 2.6.32-es rhel kernelrol ;o)

Ami azt illeti, nálam az aktuális xserver-xorg-video-radeon meghajtóval a Debian Squeeze is fejreáll.

No nem azonnal, de napi 1-3* átlagban. Persze ez notebook, grafikus felülettel, úgyhogy ennek itt sok értelme nincs, gondolom. :)

Megoldást eddig az hozott, hogy visszatértem a 6.12.6-os verzióhoz és visszatartom a frissítéstől. Egyelőre így működik rendesen.
6.13-tól viszont fagy "keményen", egy villanást követően merevre fagy az egész gép, általában a tartalom marad. Bár volt fehér kép és talán zagyva is. KMS ki/bekapcsolt állapotától függetlenül.

Mindenkinek, akinek a man diff parancs jutott a cikkrol eszebe.

Eloszor is, egy fejlesztes nem ugy mukodik, hogy az ember nekiul, es fejleszt, es fejleszt, a program meg elobb-utobb kesz lesz. A fejlesztesnek fazisai vannak, egy jol strukturalt fejlesztesnel feature-k, bugok, improvementek, meg mas effelek vannak. A patch alapu kozzetetel a katranylabdashoz kepest pusztan annyi elonyt nyujt, hogy az egyes valtoztatasi fazisokat egyenkent, kulon elerhetove teszi.
Ez azt jelenti, hogy ha egy adott valtoztatas erintett 8 fajlt, akkor a valtoztatas alapjan kepezett patch file _kizarolag_ az erintett 8 fajl valtozasait tartalmazza, minden egyeb felesleges zaj nelkul (legfeljebb minimalis zajjal).

S hogy miert vazoltam a patch fajlok lenyeget? Nos, egy tobbezer soros, tobbszaz fajlt erinto patchet atlatni nem egyszeru. Sot, nagyon nehez. Ott, ahol amugy is keves a fejleszto (pl. CentOS) nagyon sok idot elvesz annak megallapitasa, hogy az o sajat patcheik, illetve a RedHat monumentalis patche mennyire korrelalnak egymassal. Azonban, egy sok fejlesztot foglalkoztato cegnel, vagy ahol 1:1 veszik at a RedHat kernel forrasat, ugyan hasonlo nehezsegeket okoz a monumentalis patchek kezelese, viszont van eleg ember szetcsomozni a szalakat.

Ami ehhez a sajat velemenyem: reszben jogos a RedHat fellepese, az Oracle kezd eleg komoly versenytarssa valni. Reszben viszont nem baratsagos lepes az olyan, opensource projektek fele, akik az RHEL alapkoveire epitkeztek.

Mindazonaltal, en ugy velem, hogy a RedHat ettol meg joceg maradt, legalabbis ahhoz kepest, amit az Oracle muvel a Solarissal. De ez a dontes konkretan parasztsag volt.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ami ehhez a sajat velemenyem: reszben jogos a RedHat fellepese, az Oracle kezd eleg komoly versenytarssa valni.

Te se érted... Az Oracle vesz egy RHEL6 licencet és máris hozzáfér a különálló patchekhez (neki ez annyi, mint neked egy gombóc fagyi), ergo az Oracle ellen pont nem hatásos ez a lépés. Akiket ez rosszul érint azok a non-profit szervezetek és a közösségi projektek, mint pl. a Debian vagy a CentOS.

De, pontosan ertem. Viszont nezd meg az erem masik oldalat: az eddigi politika mellett tokeletesen felesleges lett volna az Oracle-nek penzt adni a RedHat-nek, amikor a kiadott forrasokbol siman at tudtak mindent emelni. Most ez a lehetoseg megszunt, lehet pengetni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Itt nem arrol van szo, hogy kinek mennyire faj ha 300-400 dollar gazdat cserel, hanem az elvekrol. Nem ingyen van. Ez - legalabbis en ugy latom - presztizskerdes, nem pedig penzkerdes. Errol az oldlarol nezd a dolgokat. Adott esetben az is eredmeny lehet, ha az Oracle CEO egy napot kenytelen kihagyni a golfban, mert RHEL licenszet vett.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Na és? A Redhat védi a saját trágyadombját a többiektől.

Move on, there's nothing to see here... :))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

Katranylabda ... Ez komoly tarball helyett, vagy itt csak vicc akar lenni? Edited: Kozben latom nem csak nekem tunt fel, mind1.

Ó, ha tudtam volna, hogy ez ennyire tetszik, akkor többet használtam volna. Felírom, hogy ezután rendszeresen használjam. Igaz, az eredeti kitalálója már nem dolgozik nálunk, de ha összefutok vele, elmesélem neki, mekkora sikere volt ;)

Az azért kemény, hogy csak lgb beírása után kezd itt egyeseknek leesni a tantusz. :)

--
trey @ gépház

Hala az egnek nem emlekszem ra, h belefutottam volna, mar a rendszermagfolttakaro is hatalmas torest okozott az eletemben. Bar az elso ilyen elmenyem a Szirmay-Kalos fele graf. konyv simaborozese, buckaterkepe es csucspontarnyaloja reven adodott. Az is rettentoen fajt. :)

---
pontscho / fresh!mindworkz

Ja valahol en is olvastam ilyan barosagokat mint pl:

magbetyar: kernelhacker (magbetyart olvasva, valami porno jutna inkabb eszembe, betyaros stilusban)
"fel kell csatolni a lemezes kepallomanyt a visszacsatolo eszkozon": ez mar nem olyan vicces mint az elozo, de elsore ezt sem tudtam mi a fenet jelenthet (inkabb a vissza a jovobe cimu sorozat ugrana be, amint a Doki eppen a fluxuskondenzatort szereli, es kozben ilyeneket mormol)

meg van par ilyen eroltetett forditas, bar, ezek meg talan mindig kevesbe baromsagok mint a "tar" esete, ahol aztan tenyleg semmi koze nincs a dolognak a "katranyhoz" :)

Mellékszál, de éppen most nézegettem DB2 hibákat, és a böngsző magyar nyelvéből következően magyarul írta ki a hibákat a hibakódokkal az IBM-es weboldal... idéznék:
"A megadott becenevek statisztikái nem frissültek teljeskörűen a távoli és a helyi katalógusok sémái közötti eltérések miatt. "
"A program törlési vagy frissítési lyukat észlelt "
"A felhatalmazási azonosítónak nincs jogosultsága végrehajtani az így megadott műveletet. "
"A csomópontcsoport definíciójában többszörös csomópont fordult elő. "
"A fedőnév nem hozható létre, mert ez ismétlődő fedőnévlánchoz vezetne. "
"A program előkészítő feltevései hibásak. "
"Az összeköttetés sikertelen, mert jelenleg nincs szoftverengedély. "
"Hiba történt a beleértett újrakötés vagy előkészület közben. "

Lehet csámcsogni és értelmezni, hogy mit is akartak kiírni tulajdonképpen... :)

De egyelőre a "put the bean into the session" magyarításaként "betesszük a babot a menetbe" egyelőre mindent üt... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ha mar szoba kerult lenne egy-ket kerdesem.

Neha elofordul, hogy egy-egy szoftware elertheto mondjuk svn en es tar.gz formaban is.
A baj csak az, hogy tar.gz -rol legtobbszor nem tudom melyik svn verzioval egyezik meg leginkabb. Van -e ennek kideritesere valami eszkoz ?

A RHEL6 eseteben legtobb modositas back port jeleggu, ezek egy reszet nem lehetne automatikusan beazonositani mondjuk a linus faban tortent valtozasokkal valo hasonloasag alapjan?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

ha jol van megcsinalva a cucc, akkor a forras fajlban van valahol egy $Id$ szoveg.
es be van allitva az svn:keywords. ezutan svn exportkor (vagymikor) az atirodik a megfelelo adatokra (rev szam, ido, kicsinalta, stb).

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

"jol van megcsinalva"
Egy idealis vilagban leirjak, hogy melyik svn verzio az amit kiadtak. Ill. csinalnak ra egy "tag"-et is.

Ha lenenek ilyen $id$-k, akkor valoszinuleg a maximomot kene kivadasznom az osszes filet nezve, de az elet ettol kegyetlenebb szokott lenni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az a baj, hogy azzal az infoval semmire se mesz, hogy (git eseteben) ez most a 90fff6501cf512656864cb4c88a0ec0bfd5a7a94 reviziobol szarmazo fajl, ha nem fersz hozza az adott repohoz, hogy megnezd, az pontosan mifele valtozas volt. Lehet, hogy eppen az csak egy vesszo volt. A revizioszam - foleg, ha meg a verziokezelo sem egyezik - ugyancsak el tud terni egy beolvasztott valtozasnal. A commit logban benne van, hogy az a merge mit committolt - a commit uzenetben. Gondolom erzed a dolog abszurditasat.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

és ha minden sorba belenyúltak? :O

:D

No rainbow, no sugar

Amíg az "értelmét" megtartják: és csak változónév cserék, definíciók sorrendjének cseréje, whitespace módosítások, meg ilyesmit csinálnak addig még léteznek AST-n működő diff szerű megoldások, legalábbis rákeresve találtam: http://www.semanticdesigns.com/Products/SmartDifferencer/

Ha totálisan újraírják, akkor meg akár a gpl-t is eldobhatják... ;)

lehetne úgy írni, hogy még jobban üssön... hogy:
...Úgy tűnik, hogy a "piros kalapos" mérnökök sem örülnek..

bár az eljárás rossz a közösségnek (centos, amazon, akármi) sajnos egyetértek vele. egy olyan oracle, aki ennyire védi a saját szarjait, ilyen pofátlanul lopja^Wmásolja más munkáját -> én is obfuszkálnék.

"Az, hogy nekem nem hoztal patchet, bunko, tirpak dolog"