Vlákno názorů k článku Klony RHEL jsou hrozbou, nejsme povinni jim to usnadňovat, říká Red Hat od Josef Jebavý - Podleme ten kdo jim nechce platit jim stejne...

Tu aplikaci můžete sestavit sám – když tomu bude věnovat dostatečné úsilí. To úsilí, které normálně věnují správci balíčků jednotlivých distribucí (těch opravdových, které balíčky vytvářejí, ne jen přebírají odjinud).

Takhle ale GPL funguje odjakživa – GPL vám dává právo jenom na zdrojáky, ale jak aplikaci sestavit, to už je na vás. Proto vznikly linuxové distribuce, které tohle za vás řeší.

Vypadá to, že současná situace kolem RHELu ve skutečnosti jenom ukázala, že spousta lidí pohybujících se ve světě opensource ve skutečnosti jen s překvapením zjišťuje, co znamená opensource, jak vypadají zdrojové kódy z upstreamu a jaká je role distribucí.

> GPL vám dává právo jenom na zdrojáky, ale jak aplikaci sestavit, to už je na vás.

Z licencie GPL:

> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

Interpretacia tejto casti ide dokonca az tak daleko, ze ked sa binarka podpisuje, tak aj podpisovaci kluc (tzv. "anti-tivoization clause"). Je to presne dovod, preco Microsoft odmietol podpisat GRUB (GPL) s UEFI CA klucom, ale nemal problem so shim.efi (BSD).

@ja.:

Toto vůbec není porušeno. Kód k dispozici je, ani řádek nechybí. Zkuste najít příklad, kdy nemůžete sestavit stejnou binárku, jako je v RHEL v důsledku chybějícího kódu. Takovou situaci byste neměl najít.

Moja reakcia bola na p. Jirsaka, ktory argumentoval, ze "jak aplikaci sestavit, to už je na vás.". To nie je celkom tak pravda.

Situacia s RH bude pravdepodobne opacna; vypublikovanych verzii balickov bude viacero, ako je v RHEL a vediet, ktory je ten spravny a ktore ignorovat bude to, o co pojde.

@ja.:

Ale poznámka pana Jirsáka jednoznačně pravda je. GPL nevyžaduje, abyste dostal na stříbrném podnose reprodukovatelný build binárky. GPL vyžaduje, aby Vám nechyběl ani řádek kódu při Vaší vlastní snaze. Znalost, jak to zkompilovat - tj. s jakými parametry, v jakém prostředí, jak otestovat výsledek - to už je všechno know how distribuce, které už ale není vynuceně k dispozici. Vy máte zaručen zdrojový kód a know how si budujte sám.

Samozřejmě ad absurdum by se mohlo stát, že Red Hat zaplaví repozitáře balastem, aby se v nich reálný kód skutečně nedal najít. Jenže to se neděje. Celá veřejnost má v CentOS Stream k dispozici vše, kromě té informace o výběru do RHEL. A zákazníci RHEL mají k dispozici dokonce i to.

No a presne v tomto pripade je ta hranica src.rpm; to, ako si zbuildujete do binarneho rpm je na vas, tam si nastavite parametre,. prostredie, ako to otestovat... ale obsah src.rpm spada pod "including scripts to control those activities."

Ci to niekto bude buildovat rucne, alebo si rozbeha koji+mock je na nom. Drviva vacsina software, ci uz open-source alebo nie, nema reprodukovatelny build, takze to je pase tak ci tak. A minimalne pre rpm je v hlavicke build host, takze pokial to nebuildujete na rovnakych hostoch ako redhat, tak v binarnych rpm rozdiel bude, bez ohladu na GPG podpis.

Moja reakcia bola na p. Jirsaka, ktory argumentoval, ze "jak aplikaci sestavit, to už je na vás.". To nie je celkom tak pravda.
Je to pravda. Zveřejnit musíte skripty, ale nemusíte zveřejňovat, s jakými parametry jste ty skripty spouštěl ani jaké ostatní aplikace a knihovny máte v systému nainstalované.

Kdyby to bylo tak, jak si představujete, neřešily by distribuce v minulých letech složitě reprodukovatlené buildy, protože by všechny buildy GPL aplikací byly reprodukovatelné odjakživa.

Pokud je na knihovně aplikace závislá, musím její verzi/kód zveřejnit, podle GPL.

Reprodukovatelný build je přece o naprosto něčem jiném než, že jsem schopný mít stejné verze závislostí.

Pokud je na knihovně aplikace závislá, musím její verzi/kód zveřejnit, podle GPL.
Ne, nemusíte. Navíc ta závislost často není jen na nějaké verzi knihovny, ale na tom, s jakými parametry ta knihovna byla sestavena. A možná i na tom, v jaké verzi a s jakými parametry byla sestavena knihovna, na které ta knihovna závisí.

Podívejte se třeba na ebuildy Gentoo – tam uvidíte, na čem všem závisí to, jak bude vypadat výsledná binárka.

Pořádně si to přečtěte. Ten směr závislosti je důležitý.

Jako teoretické cvičení:

GPL aplikace může záviset na BSD knihovně. Zdrojáky BSD dynamické knihovny by se teoreticky daly nezveřejnit. Jediné co je nutné je zveřejnit informaci o té závislosti.

Jestli se nepletu, tak přesně takto byly dělány Nvidia ovladače. GPL wrapper + binární blob.

A aby nedošlo k mýlce: Žádné takové plány rozhodně nemáme, to by byla neakceptovatelná praktika i pro spoustu lidí uvnitř. Je nás dost, kterým na filozofii firmy pořád záleží.

Nie je to v pripade Nvidie naopak? Binarny blob zavisi na GPL-wrapperi.

GPL aplikacia moze zavisiet na BSD kniznici, ale v tom pripade BSD kniznicu musite zverejnit. GPL na to pamata, jedina vynimka je pre kniznice, ktore su sucastou platformy, ktore sa tym pokladaju za vseobecne dostupne.