Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.
Nedávno, při diskusích na téma LGPL, tu zazněla důležitá myšlenka - totiž, že najít hranice dosahu GPL (ve smyslu "co všechno je odvozené dílo") není vůbec jednoduché. Co člověk, to názor. A někdy ty rozdílné názory pěkně komplikují práci.
Licence GPL je známa svou nakažlivostí. Pokud někdo chce použít ve svém díle něco, co je licencováno (pouze) pod GPL, musí být toto dílo licencováno stejně. Už jsme tu řešili, jaké dopady to má při používání knihoven. Ale ono to není zdaleka tak jednoduché, jak by se mohlo zdát. Význam pojmu "odvozené dílo" může totiž každý chápat jinak.
Někdo to chápe tak, že ke vzniku odvozeného díla je nutné těsné propojení, kdežto jiný člověk by do toho zahrnul jakoukoli vazbu na GPL-licencované dílo (tedy i to, když jeden program spouští jiný - pod GPL šířený - samostatný program). Že to není jednoduché, můžeme se dočíst i na stránkách Free Software Foundation - a případné spory by mohly dopadat velmi různě.
Specifickým případem je samotné linuxové jádro. Jádro je, jak známo, licencováno pod GPL. A právě výklad pojmu "odvozené dílo" zde hraje klíčovou roli. Vývojáři jádra na to mají různý názor. Obecně jakékoli volání jádra z programu by mohlo být považováno za vytvoření odvozeného díla - to je naštěstí přímo vyloučeno explicitní deklarací Linuse Torvaldse ve zdrojových kódech.
Něco jiného je ovšem tvorba ovladačů pro Linux. User-space ovladače můžeme pustit z hlavy, s těmi problém není. Ovšem ovladače v podobě modulů do jádra jsou komplikovanější případ. Jsou lidé, kteří je považují za odvozená díla, a jiní, kteří je mají za samostatné programy (protože není příliš velkého rozdílu mezi používáním jádra přímo nebo přes syscally). Právní souvislosti nechme právníkům, nás jako techniky zajímají spíše technické aspekty. A v tom je zakopaný pes.
Dokud byl jmenný prostor jádra přístupný bez omezení v rámci celého jádra, byly tyto úvahy bezpředmětné. Nyní se ale symboly exportují explicitně - a zde si může každý autor určit, zda příslušný symbol vyexportuje bez omezení, anebo vynutí použití GPL-kompatibilní licence. To by samo nebylo až tak ukrutné, horší je, že symboly exportované bez omezení mohou být (a často také bývají) v pozdějších verzích exportovány jen pro GPL. To se (zatím) netýká oblasti "core functionality", ale třeba tak podstatná věc, jako je SYSFS, prošla právě tímto procesem.
Zásadní problém pak nastává, když někdo musí (ať už z jakýchkoli důvodů) napsat ovladač, který pod GPL být nemůže. Resp. když už je ovladač napsán, funguje, a pak se v další verzi jádra změní export na GPL-only. Co může člověk v takové situaci učinit?
Ptáme-li se, proč podpora HW v Linuxu není taková, jakou bychom si přáli, musíme část odpovědi hledat i zde. Jádra 2.6 sice přinesla (oproti těm starším) lepší a hlavně systematičtější API pro vývoj ovladačů, ale současně se tu objevil uvedený problém. Těžko s tím něco naděláme, ale je potřeba si uvědomit, že snaha fanaticky bojovat za svobodu softwaru se může projevit velmi nepříjemnými efekty.
Tiskni Sdílej:
I personally consider anything a "derived work" that needs special hooks in the kernel to function with Linux (ie it is _not_ acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs "help" from the main kernel. Similarly, I consider anything that has intimate knowledge about kernel internals to be a derived work. What is left in the gray area tends to be clearly separate modules: code that had a life outside Linux from the beginning, and that do something self-containted that doesn't really have any impact on the rest of the kernel. A device driver that was originally written for something else, and that doesn't need any but the standard UNIX read/write kind of interfaces, for example. Linus Torvalds
I personally consider anything a "derived work" that needs special hooks in the kernel to function with Linux (ie it is _not_ acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs "help" from the main kernel.Tohle mi připomíná někdejší debaty vývojářů, zda ponechat v hlavním stromě nějaký takový hook pro konkrétní proprietární ovladač. Mám dojem, že zvítězilo odebrání.
Similarly, I consider anything that has intimate knowledge about kernel internals to be a derived work.No jo, ale to už je právě záležitost subjektivního pohledu. Ostrou dělicí čáru nelze udělat.
What is left in the gray area tends to be clearly separate modules: code that had a life outside Linux from the beginning, and that do something self-containted that doesn't really have any impact on the rest of the kernel. A device driver that was originally written for something else, and that doesn't need any but the standard UNIX read/write kind of interfaces, for example.O to tu právě jde. Předpokládejme, že ovladač byl původně pro Windows a dělá se verze pro Linux. Nepotřebuje prakticky nic víc, než "standardní" věci (I/O operace, obsluha přerušení, DMA apod.). Na tohle může mít každý jiný názor. Ale je tu ještě ten "další krok". Aby byl ovladač rozumně použitelný, měl by být schopen spolupracovat s udev - a to nelze bez použití SYSFS. Proto ano, samotnou funkcionalitu ovladače zajistit lze, ale jeho rozumné použití v praxi už nikoliv. Muselo by se použít nestandardní řešení.
Tohle mi připomíná někdejší debaty vývojářů, zda ponechat v hlavním stromě nějaký takový hook pro konkrétní proprietární ovladač. Mám dojem, že zvítězilo odebrání.Zvítězilo. Ale v tomto případě to IMO bylo dobré rozhodnutí. Vyžaduje-li ovladač pro svou funkci háčky v jádře, nechť je otevřený. Pokud si vystačí sám, pak ať si má licenci jakou chce. Jde jen o to, jakým způsobem ovladač napíšeš. nVIDIA dělá poměrně úspěšné uzavřené ovladače a žádné spory kvůli tomu vedeny nejsou. Ovladač nevyžaduje, aby kvůli němu bylo jádro jakkoliv jiné. Vystačí si sám, a proto má plné právo být uzavřený. Ostatně je to s tou nVIDIA zároveň příkladem toho, co zmiňuješ dále:
Předpokládejme, že ovladač byl původně pro Windows a dělá se verze pro Linux.To je přesně ten případ. Zatím jsem neslyšel, že by si někdo stěžoval na licenci nVIDIA -- tím myslím s ohledem na to, jestli není GPL porušována, ne že by si nikdo nestěžoval na jejich uzavřenost z praktických důvodů.