Funguje / nefunguje to je jen část problému.
Mnohem větší problém je (nikoli pro korporace, které to vnucují), že to není pod GPL licencí, rezivé Coreutils jsou pod MIT licencí.
Osobně preferuji GPL kdekoli to jen jde. Chci skutečně svobodný software, který nemohou korporace sežrat a ukrást pro sebe.
Osobně preferuji GPL kdekoli to jen jde. Chci skutečně svobodný software, který nemohou korporace sežrat a ukrást pro sebe.
Já to chápu jako principiální postoj, stejně jako si dovedu představit, že někdo např. ze stejných důvodů v určitém projektu nepoužije třeba LLVM/Clang a bude to vyvíjet a podporovat sestavování jen s GCC.
Ale v tomhle konkrétním případě, prakticky vzato bych si spíš pokládal otázku, co by korporace získaly uzavřeným vývojem svých Coreutils nebo suda? A jinak mimochodem to původní sudo mělo ISC licenci (víceméně jako BSD) a nikdo se nad tím, minimálně veřejně, ani nepozastavil.
Ale v tomhle konkrétním případě, prakticky vzato bych si spíš pokládal otázku, co by korporace získaly uzavřeným vývojem svých Coreutils nebo suda?
A z jakého jiného důvodu Coreutils přepisují?
Dělají to protože Rust je memory safe? Určitě? S kompilerem jazyka, který se programátorům údajně mění pod rukama? Nebylo by lepší jít cestou memory safe C kompileru, který už, možná jako reakce na Rust, taky vzniká? Nebylo by mnohem snazší důkladněji auditovat GNU Coreutils?
A pokud jde o bezpečnost, proč se to snaží tak moc uspěchat? Nevyzkoušený kód přináší, kromě nedoladěnosti očividně i bezpečnostní rizika. Viz report přímo od Ubuntu https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
A pokud to dělají kvůli licenci, co přesně tím sledují? Co jim MIT licence přinese? MIT licence neukládá povinnost zveřejnit zdrojáky k distribuovaným binárkám. MIT licence dovoluje přidat kód z takto licencovaného programu do komerčního uzavřeného software. Možná se tak nestane (brzy) v Ubuntu. Ale je toto cíl? Mít k dispozici uzavřitelné utility kompatibilní s GNU Coreutils?
Těžko zpochybnit, že to budí podezření.
Nechce se mi věřit, že to je jenom Rust fanatismus i když toho je tam asi taky vrchovatě.
A pokud to dělají kvůli licenci, co přesně tím sledují? Co jim MIT licence přinese? MIT licence neukládá povinnost zveřejnit zdrojáky k distribuovaným binárkám. MIT licence dovoluje přidat kód z takto licencovaného programu do komerčního uzavřeného software. Možná se tak nestane (brzy) v Ubuntu. Ale je toto cíl? Mít k dispozici uzavřitelné utility kompatibilní s GNU Coreutils?
To se mi jako motivace opravdu zdá jako blbost. Co by komerční firmy získaly tím, že projekt typu Coreutils si budou moct forknout, vyvíjet nějakou proprietární verzi a nevracet to do projektu. Není případné změny jednodušší prostě upstreamovat? Chápu tohle třeba u nějakých serverových produktů, databází atp. kde můžu mít třeba nějaký otevřený základ a pak prodávat i odvozené verze za peníze, případně omezit komerční užití. Nedovedu si upřimně představit monetizaci Coreutils.
Navíc to pozadí, proč je to pod MIT/Apache 2.0 a to že tohle mají ty linkované crates, co to používá, jsem tu psal v jiném postu.
A stran ostatních produktů pod podobnými licencemi, mimo původního suda a ntp, tak třeba OpenSSH nebo OpenSSL taky nejsou pod GPL. Jsou to všechno důležité komponenty, najdete je skoro v každé linuxové distribuci už roky.
Fakt nevím, ale občas mi to přijde ta snaha vidět vždycky za roh trochu přehnaná.
Sami autoři ty důvody píšou vcelku jasně.. https://uutils.github.io/
A ano téměř hned se typicky projeví hromada rozumbradů.. co všechny důvody stejně zpochybní a nabídnou své vysvětlení nebo technický rozbor (Cabal, Rust sekta.. anti-GPL.. přeci nejsou tak pitomý, stejně to neřeší 100% chyb, já sám chyby v C nikdy nedělám, navíc jsem si tohle vyřešil už před 30 lety - podívej se do adresáře utils na gizmo_alloc.c, gizmo_threads.c takže.. atd :)
Ten projekt začal už před víc než deseti lety a na začátku byli nejspíš opravdu nadšenci. Pak se to s pokračujícím vývojem možná zalíbilo i Canonicalu a sponzorům.
Jinak chápu, pro někoho to výchozí nasazení do distribuce může být předčasné. Zas si myslím, že se na tom dají najít i světlé stránky, protože měli jasný deadline, dostalo to vcelku velkou expozici, nechali si udělat ty zmíněné analýzy a můžou spousty věcí relativně rychle dotáhnout, což bude benefitem pro všechny uživatele projektu.
Problém s GPL licencí není přímo u samotného díla, ale spíš u děl odvozených. Udělat proprietární verzi Coreutils moc smysl nedává. Mít možnost udělat systém pro podnikové přihlašování a správu (obdobu Active DIrectory od Microsoftu) a propojit to i se sudo a dalšími utilitami, aniž bych to jako odvozené dílo musel zveřejňovat pod GPL, to smysl dává. Nemusí to být v tuto chvíli konkrétní plán. Je to prostě jen nezavření si té možnosti. A třeba důvod, proč Canonicalu dává smysl zrovna tenhle projekt podpořit.
Nemyslím si, že Rust Coreutils vznikly kvůli změně licence. Ale chápu, že když se zbavují staré zátěže, zbaví se i GPL. (Sic!)
Souhlas. Ale jak už jsem tu několikrát zmiňoval, oni se v tomhle případě spíš přizpůsobili tomu ekosystému Rustích crates, které jsou vesměs všechny pod tou MIT/Apache licencí. Spousty z nich tam používají. Naopak je zas možné použít v jiných projektech funkcionalitu (třeba různé abstrakce napříč operačními systémy) z knihovny uucore https://crates.io/crates/uucore z uutils-coreutils. Tam pak samozřejmě to, že to není pod restriktivní copyleft licencí, může být pro ostatní projekty výhoda.
Jinak co se týká té další povinnosti z GPL vyplývající, tzn. poskytnutí zdrojových kódů uživateli i když tam nedělám žádné změny a jen to sestavím do binární podoby.
Tam by ten benefit pro nějaký komerční produkt, výrobce by podle mě byl pouze v případě, že by ty GNU Coreutils byl ten poslední komponent, co by tímhle způsobem musel řešit.
Protože jakmile tam bude ještě cokoliv dalšího s copyleft licencí, tak už stejně musím mít nachystaný nějaký přístupný repozitář, tarball, kde budou všechny zdrojáky, build skripty a ideálně i nějakou automatizaci (skript, CD úlohu), co to vyplivne po každém releasu. A pak už je mi vcelku jedno, jestli tam bude třeba kernel, out-of-tree moduly, glibc, util-linux, iproute.. nebo tam bude navíc ještě GNU Coreutils, klidně tam můžu přibalit i ty věci, co vyloženě nemusím (sudo, ntpd, OpenLDAP s permissive licencemi).
To je třeba z pohledu výrobce routeru, embedded zařízení, aplikace co se distribuuje s VM, kde mám systém from scratch.
Jinak ještě častější budou nejspíš případy, kdy je systém, příp. kontejner s proprietární aplikací založený na nějaké existující hotové distribuci. Pak bych měl zrcadlo se zdrojovými balíčky od toho, co je tam použité. A zas by mě nevytrhlo, jestli tam bude jeden z nich s GPL, BSD nebo MIT licencí.
Takže to je důvod, proč to osobně rozlišuju a spíš bych měl o licenci starost, kdyby se jednalo o produkt, co by se dal snadno uzavřít a monetizovat.
Plus samozřejmě pokud už se chce někdo vyloženě vyhnout copyleft licencím pro podobné multicall nástroje v userspace a má třeba nějaký uzavřený embedded systém, tak už roky může použít např. toybox (jako busybox pod MIT, používá se třeba v Androidu), nemusí čekat, až to někdo přepíše v Rustu. Stejně jako může svoje proprietární nástroje staticky linkovat s MUSL, který je také s MIT licencí.
Já to beru podle toho čí svobodu zohledňujeme. Pokud svobodu vývojáře, je určitě svobodnější BSD / MIT a podobné.
Pokud svobodu software, přijde m isvobodnější GPL a spol. Protože mu poskytuje ochranu před uzavřením.
Pokud o někom řeknu že je "svobodný člověk", taky tím nemyslím svou svobodu kdykoliv ho omezit.
25. 4. 2026, 11:23 editováno autorem komentáře