Názor k článku SUSE, Oracle a Rocky Linux zakládají Open Enterprise Linux Association od Miroslav Šilhavý - Historický výklad je považovaný za nespolehlivý. Moc se...

  • Článek je starý, nové názory již nelze přidávat.
  • 12. 8. 2023 23:13

    Miroslav Šilhavý

    Historický výklad je považovaný za nespolehlivý. Moc se nedbá na to, co bylo tehdejším účelem textu, ale co má text plnit dnes. Příkladem může být český zákon směnečný a šekový, který je prakticky beze změn používán od padesátých let, a v nich byl de facto převzat bez větších úprav z první republiky. Zákon výslovně stanoví, že do lhůt se započítávají i soboty - protože tenkrát byly soboty pracovním dnem. Teprve ÚS musel judikovat, že v dnešní době je nutné z počítání času soboty vynechat - protože doba je jiná a soboty už pracovní nejsou.

    Zákon se samozřejmě nedá vykládat tak, jak se to komu hodí, ale musí se najít způsob, který nejlépe vyjadřuje chráněný zájem. Někdy dochází k posunu prostředků, jimiž se chrání stále stejný zájem. Ale někdy dochází i k tomu, že se samotný chráněný zájem změní, posune v době. Proto může být tentýž zákon (nebo i text smlouvy) uplatňován v různé době jinak.

    Proto tvrdím, že je docela možné, že je jen málo podstatné, proč GPL vznikla a co měla chránit. Je docela dobře možné, že v dnešní době je potřeba vyvážení práv mezi autorem, následovníky a uživatelem upravovat jinak. Je to dokonce dost pravděpodobné, protože IT svět je od 1990 (kdy byla vydána GPL v2) diametrálně jiný, a v diametrálně jiné pozici je autor, uživatel a program vůči sobě.

    Proto jsem svůj vůbec první příspěvek v této diskusi začal úvahou, jaká práva je potřeba chránit a na jaké straně, a že určité výklady vedou k absurdním - a tedy zjevně nesprávným - závěrům. Abych to v krátkosti zopakoval:

    1. GPL nevyžaduje zveřejnění kódu, ale zpřístupnění uživateli; pokud by bylo myšleno, že se smí GPL využít k bohapustému zveřejnění, pak bych očekával, že to bude GPL přímo vyžadovat. Toto může znamenat dvojí: buďto je právo zveřejnění už extenzivním výkladem, nebo GPL ve své době nepočítala s možnostmi zveřejňování (které je dnes jednodušší, než něco adresně předávat).

    2. Samotné sestavení distribuce podle mě není autorským dílem, ale dovedností (know how). GPL však vyžaduje, aby byl kód sestavitelný. To může znamenat dvojí: buďto musí být zveřejněn plný postup ke stejnému sestavení, nebo požadavek na sestavitelnost není tak rigidní, aby vyžadoval úplně totožný build. Pokud by byl požadován totožný build, má být přímo reproducible k binárce? Pokud je nějaká část podepisována, má být zveřejněn i klíč? (Což by popíralo podpisování - absurdní.)

    3. GPL připouští a počítá s komerčními aktivitami i s ochranou proprietárních práv. Výklad umožňující 1:1 klonování RHEL ale de facto tuto ochranu vylučuje - tj. i v tomto bode se zdá, že jen ražený výklad nesprávný.

    4. Není jasné, jestli zveřejněním (zpřístupněním) novějšího kódu plníte GPL. Tím nemyslím zásadně změněný kód (např. mezi major verzemi), ale dílčí změny, kroky vpřed. Pokud zákazníkovi dám binárku a k tomu zdroják o patch vylepšený, splnil jsem tím GPL, nebo porušil? (Z hlediska logiky porušil, z hlediska ducha ustanovení neporušil.)

    5. Musím kód dodat už se zahrnutými patchi, nebo mohu dodat např. autorský balík + své patche odděleně? (Pokud vím, tak druhá možnost je široce využívána.)

    6. V době repozitářů, ve kterých mohu zahrnovat či vyřazovat jednotlivé commity, splním svoji GPL povinnost předáním repozitáře? Zákazník má v tu chvíli přístup ke své verzi, jakožto i ke starším a novějším. Je to pro něj možná trochu pracnější, pokud chce udělat 1:1 klon, ale pro praktickou práci (kterou GPL zamýšlela - už jsme u historického výkladu, heh) je přístup do repo praktičtější

    To jsou namátkou otázky, které mě k tématu napadají, a které je potřeba skloubit v jeden fungující celek. Místo toho se setkávám (i od Vás) s vytrženými větami a absurdními závěry (např. že předat zákazníkovi je defacto totéž, jako povinnost zveřejnit).