Az OpenELA elérhetővé tette a RHEL-kompatibilis forráskód tárolóját

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

Augusztus közepén megalakult a non-profit Open Enterprise Linux Association (OpenELA) egyesület az Oracle, SUSE és a CIQ közreműködésével. Az ok, amiért összeálltak: a Red Hat RHEL körüli drámája. Az alapítvány mottója: "No subscriptions. No passwords. No barriers. Freeloaders welcome."

Az egyesület most bejelentette, hogy elérhető a Red Hat Enterprise Linux-kompatibilis forráskód tárolója (repository), amelynek segítségével lehetővé vált egy "enterprise Linux disztró" build-elése. Részletek a bejelentésben.

( hajbazer v | 2023. 11. 04., szo – 11:35 )

Csúnya™ gonosz™ ingyenélők™ gyülekezete. Hogy tehették?!

Mi lesz így szegény™ Red Hat IBM extraprofitjával?

Munkás István

Munkás Munkácsy :P

Na mégiscsak ők a főgonosz

Mindig az a főgonosz, akinek szándékában áll a Linux-világot felforgatni és azokat szembeköpni, akiknek hálával tartozik. Hogy ezt a szerepkört épp ki szeretné betölteni saját elhatározásból, illetve önző, mohó profitérdekből, az idővel változhat. A picipuha már nem lát ellenséget a Linux-világban, sem az Open Source közösségekben. Megtanult velük együtt élni és együttműködni. A Red Hat az Open Source világból nőtt ki, a létét is ennek köszönheti, most pedig az asztalra szart, némi extraprofit reményében, hiszen az IBM-nek hozni kell a százalékokat, hiába már egy telített piacról beszélünk. Ezért jó, ha egy multinak vannak releváns versenytársai, mert bár ők sem makulátlanok, azért móresre tudják tanítani. Ahogy Frankó Mérnök Úr fogalmazta meg egy korábbi OpenELA hírtopikban...

Ez az a meccs, ahol minden résztvevőnek van kisebb-nagyobb visszaélése a nyílt forrással és kb. minden pofon jó helyre megy.

Semmi nem lesz. Szívjanak gázt, és tanulja meg az IBM is, hogy mitől FOSS a Linux világa, és ez alól ők sem lesznek kivételek, mert ők a nagy IBM, nem zárhatják be. Nem is értem, hogy minek nekik egy zárt Linux, van nekik már zárt Unixuk, z/OS, AIX.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem először látom. Én sose támogattam ezeket a corporate disztrókat, és intettem óvva mindenkit, hogy ezeket használja kizárólagosan, Ubuntut is pont ezért nem szeretem, a Canonical tolja bele a nagyvállalati hülyeségeket, Snap, stb.. Ilyen szempontból jobban a közösségi disztrók, azokba nem tesznek ilyet, meg korlátozásokat, nem zárják be a kódokat, nem teszik fizetőssé, stb..

Egyébként semmi nem Unix, csak maguk az eredeti AT&T Unix kiadások. Az összes többi leszármazott rendszer hoz újdonságokat, változásokat, kiegészítéseket, saját megoldásokat, saját initrendszer, csomagkezelő, saját virtualizáció, stb.. Ez csak egyszerű névhasználati jog, meg marketing. Ez is corporate hülyeség, mert régen sok cég erre adta be történetileg a derekát, hogy neki eredeti Júniksz kell, és ha el akartad nekik adni a saját POSIX kompatibilis, Unix-ihletésű rendszeredet, hogy adoptálják, akkor rá kellett tenni, meg kellett hozzá venni a Unix plecsnit, meg kellett venni névhasználati jogot, különben addig nem vettek komolyan, nem rendeltek tőled semmit. Pl. az EulerOS is egy Linux disztró volt, ami megvette a Unix minősítést.

Így ma már egyik modern rendszer sem Unix, inkább csak unixlike, a Unix-szal csak szabványok szintjén kompatibilis. A modern BSD-k, MacOS, AIX, Illumnos és Linux disztrók is. Hiába szeretik egyes fanboy-ok hangoztatni, hogy a BSD-k, MacOS azok igazi Unix, nem azok. Csomó bővítés, modernizáció van ezekben, sok extra driver, absztrakciós réteg, hálózati, kriptográfiai funkciót, biztonsági funkciók, sok millió új kódsor, stb..

Ezeknek a rekurzív neveknek sem kell bedőlni, ez is jogi maszlag. GNU's not Unix, Linux is not Unix, Lame Ain't an mp3 Encoder, Wine is not an Emulator. Igazából meg pont azok, amiknek nem mondják magukat, csak ha annak mondanák, akkor jogi következményekre számíthatnának.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Én sose támogattam ezeket a corporate disztrókat, és intettem óvva mindenkit, hogy ezeket használja kizárólagosan

Mekkora szerverpark volt a legnagyobb, ahol pl. ilyen javaslatot tettel? (Es mekkora volt, ahol el is fogadtak? :))

Az a baj, hogy vannak cegek, ahol tizezres nagysagrendben kellene uzemeltetni ezeket, es hat baromira nem trivialis mindenfele kozossegi kezdemenyezesre supportot szerezni. Nekem mar volt nem egy olyan esetem, hogy az ugyfel ticketjere konkret patchet adtunk, ezt melyik kozossegi OS csinalja meg, termeszetesen SLA-val?

Ez csak egyszerű névhasználati jog, meg marketing.

Meg egy garancia, hogy a cucc tenyleg tudja azt, ami ra van irva. Mint az ISO minositesek, nem feltetlenul arrol szol, hogy a gyartott termek mennyire "jo", hanem hogy a gyartasi folyamat mennyire konzekvens.

Nem szerverparkokra tettem, általában írtam. A méretekről szóló érvet sem tudom elfogadni, sok szervert is kb. annyi üzemeltetni, mint keveset, pont ez a buktató, hogy a szívás csak egy új disztróval meg meg új rendszernél csak az elején jön elő, az első egy pár rendszernél, ha ott kitanulod, megtanulod tényleg működőképesen üzemeltetni a dolgokat, onnantól azt már bármennyi gépre átviszed, automatizálod később. Plusz attól, mert sok szerver van, nem kell mindet egyféle disztrón tartani, meg egyszerre lecserélni, lehet fokozatokban, fázisokban be/kivezetve is. Nyilván azt senki nem várja, hogy ha valakinek van egy nagy RHEL alapú szerverparkja, akkor majd holnapra minden lecseréli a rendszert.

A másik pont ez az, amit írsz, hogy a névhasználat semmit nem garantál. Egy plecsni, nem lesz tőle a rendszer jobb. Még kompatiblisebbnek sem mondanám, mert azt meg a szabványok (POSIX, SUS, stb.) garantálják, nem maga a megírt kódnak az egyezősége az eredeti Unix-szal.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Raynes, annyi igazság van abban amit mondasz, hogy az enterprise linux rendszerek piaca nem túl nagy, néhány tízmilliárd dollár lehet évente. Nyilvánvalóan nincs szüksége erre mindenkinek.

Ettől függetlenül létezik ez a rétegpiac, és ha túl tudunk lépni azon a narratíván, hogy ezt a néhány tízmilliárdot szellemi fogyatékosok lapátloják ki az ablakon, és a Red Hat, SUSE, Oracle, Google stb alkalmazásában álló kiváló szoftvermérnökök százai csak a körmüket reszelgetik naphosszat munkaidőben, akkor akár fel is tehetjük magunknak a kérdést, hogy vajon miről is szól ez az egész.

Részben a minősítésekről, ahogy az korábban elhangzott, pl Common Criteria; vannak erősen szabályozott területek (pl amerikai kormányzati rendszerek), ahol ezek megkerülhetetlenek.

Más részben a hosszú távú támogatásról. Amíg egy enterprise linux terjesztés eldönti, hogy melyik kernelt tudja 15 évig támogatni, csak az nagyjából egy év. És ebben benne is van ez a meló meg a tudás.

Aztán van az L3 szupport, amin szintén mérnökök százai dolgoznak a QA részlegekkel együtt, itt jön be a képbe az üzemeltetett rendszerek száma: ha egy ügyfél naponta százezer dollárokat veszít egy leállással, akkor nincs ideje megvárni, amíg a debian közösség vagy kitol egy peccset, vagy nem.

És még lehetne sorolni.

Nyilván nem érthetünk mindannyian mindenhez, én csak azt szeretném, ha lenne bennünk némi szakmai alázat, és amit nem ismerünk, afelé érdeklődéssel forduljunk, ahelyett hogy leosztanánk könyökből.

Köszönöm, hogy elmondhattam :)

Félre ne érts, én nem vagyok ellene ennek az OpenELA-nak, azt tisztelem, hogy van, aki ingyen megoldást nyújtana azoknak, akiknek van ilyenre szüksége. Nekem a bajom azzal van, hogy bőven van normálisabb ingyenes, közösségi Linux disztró, ami épp úgy használható szerverekre, meg cégeknek, szervezeteknek is, és nem majmolja az IBM/Red Hat ökoszisztémát, ennek az utóbbinak vagyok ellene.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Kimaradt, de az IBM-re mindig is ez a pénzéhség volt jellemző. Minap néztem egy MVS 3.8 emulátoros videót, ahol mutatja a csóka, hogy az emulátor méri a MIPS-t, az elvégzett millió műveletek számát, mert régen az árazás ezen alapult. A kommentek alatt írja valaki, hogy ez mainframe-eknél az IBM-nek 2019-ig szokása volt. Agyrém.

Az is igaz, hogy nem az IBM találmánya, egy másik Multics-ot ismertető videón meg mutatja a fószer, hogy ott is írja bejelentkezéskor a shell, hogy mennyi CPU/memóriát használt eddig a bejelentkező user, az alapján mennyi dollár fogyott a kreditjéből. Nem adok még 5 évet, és a MS is újra feltalálja ugyanezt az árazási, lehúzási szisztémát, és el fogják adni saját találmányként.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A Microsoft inkább azt a taktikát követi, hogy csomagban elad szolgáltatásokat olyan áron, hogy érdemes legyen átszokni az ő platformjára. Ha a desktop, a fájlszerver, a címtár, a levelezés mellé beugrik a csoportmunka, akkor pillanatok alatt olyan Ms függőségű lesz a cég, mint a legjobb drogosok. Onnan aztán nincs megállás. A CRM, a vállalatirányítási és controlling rendszer, a projekt management, meg még ki tudja, mi minden lesz Ms alapú. Itt már felesleges olyanokon recskázni, hogy mennyi volt a felhasználó cpu használata, mert ha a cég nem akarja az üzletmenet folytonosságot kockáztatni, valamint nem akar rendszerek kiváltására csilliárdokért fejleszteni, akkor szó nélkül tejel a Microsoftnak, csak hogy működjön minden.

( solt87 | 2023. 11. 04., szo – 20:55 )

Kicsit kiábrándító, amikor az ember olvas valami érdekeset, de a hivatkozásnál meglátja, hogy github.(com|io). Akkor már Codeberg, vagy még inkább Sourcehut. #nekteksemmisejó :P

Ahogy látom, privát repót azután kezdtek adni, hogy a Gitlab is kínált ilyet, de a Bitbucket még a Gitlab-et is megelőzte. Szóval e téren semmi újat nem adtak, hanem a konkurencia mögött kullogtak. Az Actions-ről nem tudok nyilatkozni, de CI/CD máshol is van. (Lásd a már linklt cikket, miszerint pl. a Sourcehut-é is tud olyat, amit az Actions (akkor még?) nem.) A Codespace-t egy online kurzusnál próbáltam, mert ők azt nyújtják alapértelmezett felületnek, de nekem nem jött be, számomra nagyon kényelmetlen. (Szerencsére van Docker image is a kurzushoz, én azt használom a saját gépemen, így saját környezetben, kényelmesen és gyorsabban tudok dolgozni.) Persze látom, hogy sokaknak meg bejön, és használják, de nem láttam belőle annyit, hogy bármi elengedhetetlent észrevegyek. A havídíjcsökkentés kifejezetten előnyösnek tűnik felhasználói oldalról, de nyilván az MS-nek van miből megengednie, még a kódlopkodás nélkül is (nem beszélve az azóta erősödő konkurenciáról), szóval ezért még nem avatnám őket szentté. :)

Nyilván a dolog részben véleményes, de azért vannak tényszerű ellenvetések is. Lásd pl. az itt leírtakat. Azon vitatkozhatunk, hogy a "Microsoft-kerülés" kinek mennyire szempont, nekem bizonyos kereteken belül az. Mondjuk szerintem közösségi(nek mondott) dologhoz eleve nem illik egy MS-es tároló. (Arról nem beszélve, hogy sokan azt hiszik, hogy a [Gg]it egyenlő a Githubbal, ennek minden káros következményével.)

> "Microsoft-kerülés" kinek mennyire szempont

minden gonoszmultit ugyse lehet kikerulni... mar minden erdekesre ratette valamelyik a mancsat ugyis. a fuggetlenek meg elobb utobb vagy ugyanerre a sorsra jutnak vagy csodbe mennek, mert az egyre nagyobb infra fenntartasa sok penzbe kerul...

a python modulok forrasa szinte kivetel nelkul github-on van, de amugy is szinte barmi amit hasznalok onnan jon, nagyon nagyon ritka hogy valami gitlab vagy mas lenne.

a pytorch raadasul (amire fel eve attertem a google-fele tensorflow-rol) szinten MS (es Meta) cucc, szoval nekem mar ugyis mind1 :)

minden gonoszmultit ugyse lehet kikerulni

Ha mindet nem is (vagy akár egyet is teljesen), szerintem a Github mint online kódraktár tökéletesen kiváltható mással. A falamon lévő képzeletbeli Pareto-arcképre nézve megkockáztatom, hogy a Github (nem fizető) felhasználóinak többsége vígan ellenne a Gitlab ingyenes szolgáltatásaival, de talán még a Codeberg-éivel is. Értem én, "minden is" Github-on van -- én is megtartottam a fiókomat, hogy időnként egy-egy *eglépelés kijavítására a Githubon kérjek cibálási kérelmet, mert ott van az eredeti cucc. De minden másra ott a minden más (Gitlab, Codeberg, Sourcehut, saját telepítésű Git-akármi, tudom is én...). (És természetesen nem ragaszkodom az ingyenes szolgáltatáshoz, de felteszem, a Githubból is sokan csak az ingyenes változatot használják, azt meg könnyű helyettesíteni.)

> Értem én, "minden is" Github-on van

pont azert pakoltam en is oda a public kodjaimat, mert ott megtalalja akit erdekel.

csinalhatnek sajat szervert is, de minek? a git repo elvan localban is, amugy meg en elvoltam 20 evig CVS-en is jol. a githubra mint egy reklamfeluletre pakoltam ki ezt-azt, erre pont jo.

ha meg az AI-jukat tanitjak az en kodommal, akkor ugyis mehet az egesz a kukaba :) mar ha nem fagy le tole egybol :)

H'ja, csak amikor megneztem az alternativakat, es a 4 dollaros GH elofizumat 29 dollar lenne kivaltani Gitlabbal, akkor ugy dontottem, hagyom a fenebe. Ha csak az ingyenest hasznalod, akkor oke, de nekem ebbol a 4 dollarbol megy az osszes vackomnak a CI/CD, Pages, stb. Illetve open source projektnel is egy durva korlatja a projekt lathatosaganak, ha nem Githubon vagy.

4 dollaros GH elofizumat 29 dollar lenne kivaltani Gitlabbal,

Ez egy hónap? Mert akkot elég soknak tűnik még a 4 dollár is. Ilyen 25-30 dollár/éves VPS-en nem tudod ugyanezt futtatni? (Egyébként Sourcehut-előfizetést perpill még évi 20 dollárért is lehet kapni. Azt mondjuk nem tudom, hogy az ő build-cuccaikból pontosan milyen CI/CD-t lehet összehozni, de vannak, akik a Githubbal összevetve is dicsérik.)

open source projektnel is egy durva korlatja a projekt lathatosaganak, ha nem Githubon vagy.

Ezt hogy kell érteni? Ugyanannyiba kerül rákattintatni egy `(gitlab.com|codeberg.org)/jgypsum/fooproject` vagy `git.sr.ht/~jgypsum/fooproject` stb. linkre, mint egy `github.com/jgypsum/fooproject`-esre. Személyes weboldalra, Linkedin-re, önéletrajzba betenni szintén ugyanannyiba kerül. Akárhogy nézem, ugyanannyira látszanak.

Ezt hogy kell érteni? Ugyanannyiba kerül rákattintatni egy `(gitlab.com|codeberg.org)/jgypsum/fooproject` vagy `git.sr.ht/~jgypsum/fooproject` stb. linkre, mint egy `github.com/jgypsum/fooproject`-esre. Személyes weboldalra, Linkedin-re, önéletrajzba betenni szintén ugyanannyiba kerül. Akárhogy nézem, ugyanannyira látszanak.

Úgy, hogy szerintem elég jelentős azoknak a száma, akiknek ha kell valami OS tool, akkor beírják a github keresőjébe, aztán ha ott nagyon nincs semmi használható, akkor gugliznak.

Akkor mégegyszer: az, hogy valaki kifejezetten csak Github-on keres valamit, amiről nem tudja kifejezetten, hogy ott van, az az ő hibás döntése, ez nem láthatóság kérdése. Ha nem látja, akkor azért, mert csak egy helyen nézi, ami éppen nem jó hely. Itt nem én ülök fordítva semmilyen állaton.

Nézd, attól, hogy ez a user hibás döntése (szerinted), ettől még a userek egy jelentős része ezt fogja csinálni. Ha kell neki opensource Enterprise FizzBuzz, akkor beírja a github keresőjébe. Ha talál olyat ott, ami neki jó, akkor nem fog tovább túrni. Ha a projekt nincsen ott, nem nagyon fogja senki megtalálni, nem lesz olyan jó a láthatósága. Ráadásul mivel kevesen találják meg, kevés lesz rá a link, kevésbé felkapott siteon lesz, ezért a sima keresők is hátra fogják pakolni (jó eséllyel egy rakás githubos projekt mögé), szóval megintcsak nem fog javulni a láthatósága, még azoknak se, akik (szerinted) nem hibásan keresnek.

Szóval de, fordítva ülsz a lovon.

Ha talál olyat ott, ami neki jó, akkor nem fog tovább túrni.

Ez rendben van. Viszont fentebb gelei még "projekt láthatóság[...]"-ról beszélt, te meg "valami OS tool"-ról, legutóbb meg "olyan"-ról, "ami neki jó", ami már több lehetőség is lehet. Ha konkrét programról/projektről van szó, és az nem Github-on van (és tükrözve sincs ott), akkor igenis hibás keresés, ha csak Github-on keresed. Lásd még a "streetlight effect"-et, aminél ez a csak Github-os példa még szörnyűbb is. Ha csak egy helyen keresel valamit, de nem találod (pedig máshol ott van), akkor a sikertelenség egyeotlen oka a hibás (túl szűk) keresés. (Ezen az sem változtat, ha ez egy elfogadható eredmény.) Másrészt túl tágan használod a láthatóság fogalmát: az, hogy nem nézel rá valamire, attól az a valami még tökéletesen látható, csak te nem látod, mert nem nézel rá. Ez "nézés" kérdése, nem "láthatóság"-é. (Én pl. nem látlak téged. Akkor te láthatatlan ember vagy? Na ugye. :) )

Szerintem meg pont ott a félreértés, hogy te túl szűken veszed a láthatóság fogalmát, vagy valami nagyon mást értesz alatta, mint én (és meg merem kockáztatni, hogy mit gelei). Nekem az ebben a kontextusban azt jelenti, hogy egy projekt megtalálható, felfedezhető, hamar ott van a user orra előtt, amikor az még nem tud róla. Az, hogy valami olyat keresek, amiről már egyébként is tudok, az már nem növeli (vagy legalábbis elhanyagolhatóan) annak a projektnek a láthatóságát, mert aki keres, az már tud róla. Itt azokról van szó, akik nem a konkrét projektet keresik, hanem egy megoldást valami problémára. És ha találnak a githubon valamit, ami jó, akkor nem lesznek sikertelenek, csak max nem a superlibregithostingra tett projektet találják meg (ami pedig lehet, hogy jobb, vagy éppen ugyanolyan jó). A user jól lesz, a projekt meg nem lesz annyira látható.

en eloszor google-val szoktam keresni, ha kell valami speci algoritmus implementacio. nagyon ritkan ad ertelmes talalatot, es altalaban az is githubra mutat. ellenben ha a github keresojebe irom, akkor valogathatok 10-20 fele implementaciobol...

pl. nemreg kellett hirtelen egy GIF parser (foleg az LZW-jere voltam kivancsi), talaltam is:

https://github.com/deshipu/circuitpython-gif/blob/master/code.py

kivancsi lennek ezt google-val ki tudja megtalalni... nem mondom hogy lehetetlen, de nekem az nem talalt semmi hasznalhatot.

( ggallo | 2023. 11. 04., szo – 23:26 )

Aki ehhez ért, az írja már le nekem, hogy hogyan lesz folyamatosan RHEL kompatibilis egy tök más által gründolt rendszer, ha az eredeti RHEL kódot ők sem használhatják fel ilyesmire, még ha hozzá is férnek? Amikor ez a hír először megjelent, már akkor sem tudtam elképzelni, ez hogyan valósulhat meg. Addig értettem, hogy a CentOS helyett azon elvehet folytatva, az RHEL kódbázist használva csináltak Alma- meg Rocky Linux-ot. De az eredeti RHEL kód nélkül ez hogyan lehetséges?

Bevallom, sohasem használtam, RH-féle Linux-ot (Debian vonalon mozgok), de ez talán nem lényeges a kérdésem szempontjából.

Ha Debian vonalon mozogsz, akkor arra fogom levetíteni a példát:

Ha van egy általad készített szoftver, aminek a függőségei, nagyon minimálisak és mind Debianon és Ubuntun is elérhető ugyanaz a függőség, akkor módosítás nélkül működni fog a szoftvered mind a két rendszeren.

 

RH vonalon is ez a szituáció. Ha nem használsz RHEL specifikus RH kódot a szoftveredben, akkor annak minden probléma nélkül működnie kell az azonos verzión álló RHEL, CentOS, Alma, Rocky és az új OpenELA rendszereken. Így mondjuk ha olyan szoftvert készítesz, akkor nem kell RHEL a fejlesztéshez, hanem elég egy ezzel azonos kódbázison alapuló rendszer és kész. Vagy ha a vevő nem akar RHEL venni, akkor is tudja használni.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Fogják a RHEL forráskódokat valamilyen más céges regisztráció alatt, a hivatalos nyílt forráskódú licencek alapján szépen átemelik a saját rendszerükbe. Majd nem mondják meg, hogy honnan van a forráskód, erre semmilyen licenc nem kötelez. A RH/IBM letilthatja az adott céges regisztrációt, na de melyiket? Ha nem a saját nevükön vagy hozzájuk köthető leánycég nevében töltik le, még be sem azonosítható melyik cég red6-os accountjával töltötték le (továbbra is a licencek értelmében full legálisan).

- A RH/IBM próbálkozhat vízjelezéssel azonosítani minden ügyfelét, de ebből hatalmas botrány lenne és kiszűrni is egyszerű a vízjeleket. 

- Ha a RH/IBM megváltoztatja a nem copyleft licenceket valami restriktív EULA-ra, amire szintén van legális lehetőség, akkor ebből lenne a legnagyobb botrány és a végeredmény az lenne, hogy utána senki sem fejlesztene RHEL-ra, és akár ez az OpenELA és átvehetné a korábbi RHEL szerepét, akkor már szándékosan forkolva és más irányba fejlesztve. 

- Ha Oracle fiúk és barátaik direkt beleállnak egy perbe az eleve csak Contract law amerikai jogrendben, esélyes hogy megnyerik az RH-el szemben. 

Ebben az egészben imho több a jogászkodás komponens mint bármi más. 

Mit értesz az alatt hogy nem használhatják fel? A gpl pont azt biztosítja hogy de igen. Max kell egy előfizetés és ennyi. A rh semmilyen korlátozást nem vezethet be, mert a GPL copyleft, úgyhogy még amit ők írnak hozzá az oss szoftverhez azt is megfertőzi, mint egy vírus.

hat ez azert nem ilyen egyszeru...

- nem minden oss szoftver gpl, sok lgpl bsd mit stb licenszu

- ha a redhat ir a csomaghoz sajat buildelo, telepito scripteket, az nem "fertozodik" meg, az attol meg az ovek... azzal ok nem modositjak az eredeti program forrasat, csak melle raknak valamit

igen, pontatlan voltam, a kernel es sok mas alap util gpl, azokra vonatkozik a mondandom. A masodik pont is ugy igaz, ahogy mondod. A kerdes, hogy a gpl es RH altal mellerakott kod mekkora hanyada a "rendszernek". En el tudom kepzelni, hogy sok gpl-es util ad rpm descriptiont (meg deb-et is mondjuk), szinten gpl alatt.

> mellerakott kod mekkora hanyada a "rendszernek"

hat 1-1 linux disztribucio hozzaadott erteke pont ezek a csomagolo/buildelo scriptek.

mert amugy ezek a cegek - keves kivetellel, bar a redhat ebben pont elen jar - nem folynak bele a fejlesztesbe, csak leforditjak, becsomagoljak es atkotik masnival, guis telepitovel stb.

Jaja, a(z ideológiai) blablán túl az a két dolog életbevágó náluk (CentOS alternatíváknál), hogy hogy szerzik be a forráskódot és milyen build rendszert sikerült összehozni.

Még lehet nézegetni, hogy átlagosan hány nap alatt "vezetnek át" változásokat az upstream-ből, de ez lehet hogy már keveseket érdekel.

Esetleg szívmelengető lehet, hogy ha véletlenül valami gond náluk jön ki, akkor jelentik felfelé is ill. lehet (tovább) köpködni RH-t, ha nem akaródzik azonnal beolvasztani a javítást. :)