Vlákno názorů k článku Na webu se obchází GNU GPL, jde o peníze od SB - Strukturu redakčních systémů neznám, ale sám to chápu...
-
SB (neregistrovaný)
Strukturu redakčních systémů neznám, ale sám to chápu tak, že jde o výklad pojmů „odvozený“ a „závislý“/„využívající“/„navazující“/„rozšiřující“. Jestliže někdo vezme kód systému a upraví ho, vychází tedy z původního, svobodného, pak jde jednoznačně o dílo odvozené a tudíž opět svobodné. Autor úprav původní dílo dostal k užívání zdarma, proto je morálně i dle licence v pořádku, že svoje úpravy nabídne taky zdarma. Jestliže někdo vytvoří kód, který pouze využívá systém (odkazuje, volá), aniž by ho měnil/vycházel z něj, nejde o odvozené dílo (důkazem je, že jde takové dílo distribuovat nezávisle na původním systému). Jestliže doplácá obrázky a jiné informace, nejedná se o odvozeninu už vůbec, protože z původního systému nevychází, ale opět doplňuje jej nebo rozšiřující část (něco jiného by bylo, kdyby upravoval existující obrázky a data).
Nebo nechápu, jak to myslí GPL.
P.S.: Ten komiks je skvělý. -
pepak (neregistrovaný)
Jestliže někdo vytvoří kód, který pouze využívá systém (odkazuje, volá), aniž by ho měnil/vycházel z něj, nejde o odvozené dílo (důkazem je, že jde takové dílo distribuovat nezávisle na původním systému).
GPL FAQ tvrdí opak. Např. zde, zde a další otázky v sekci.
GPL je dobré pro uživatele, ale velmi špatné pro programátora.
-
Cohen (neregistrovaný)
To je trošku problematická otázka. Kdo co využívá? Ve skutečnosti totiž redakční systém využívá ona rozšíření, nikoliv naopak. Paradoxně bychom se tak mohli dostat do situace, že pokud uvolním kód svého rozšíření pod nějakou upravenou licencí, můžu tím nutit vývojáře změnit licenci redakčního systému ;-).
Můj názor je, že nejde o odvozené dílo. A vždy platilo, že pokud nedodávám své rozšíření včetně celého redakčního systému, mohu si zvolit licenci jakou chci. Ono "slinkování", které se řeší v GPL FAQ, bude totiž provádět až cílový uživatel.
-
SB (neregistrovaný)
Tak to je přinejmenším hodně divná podmínka nebo tvrzení, že program při spuštění zahrnuje (dynamicky linkovanou) knihovnu, to by pak snad vše, co se spustí v OS, muselo být GPL. Nehledě na to, že se zde odvození neuvažuje na úrovni zdrojáku, ale běhu aplikace(?). Divné. Nechci s tím polemizovat, ale překvapilo mě to a nevidím v tom smysl.
-
Cohen (neregistrovaný)
Je to divné, souhlasím. A není to ani v dnešní době vynutitelné. Příklad:
Napíšete program v ASP.NET, který zveřejňuje rozhraní pomocí WCF a uvolníte ho pod GPL. Následně někdo napíše opět v ASP.NET program pod jinou licencí a bude Váš kód volat. Dokud běží oba programy na jiných strojích, je vše v pořádku. Ale pokud obě části nainstalujete na jeden IIS server, můžete porušovat GPL. Oba programy mohou být totiž fyzicky spuštěny v rámci jednoho procesu prostřednictvím aplikačních domén. Programy pak mohou komunikovat i pomocí sdílené paměti, což je vysloveně považováno za slinkování. Tudíž i druhý program by měl být uvolněn pod GPL.
-
SB (neregistrovaný)
Nebo: Ten váš program bude muset mít licenci podle toho, zda vedle něj (sdílená paměť či jinak pofiderně definovaná oblast vlivu) běží nebo neběží nějaký kód s GPL. Jestli je to pravdou, tak je to naprosto úchylné, obzvláště za situace, kdy je výhodné jakýkoliv výkonný kód modularizovat do dynamicky načítaných knihoven (a tudíž možno oddělit kód s GPL a bez něj).
Měli zůstat u hranice licence na úrovni zdrojáku, na úrovni HW je to neřešitelné. -
Tak to taky funguje. Pokud ten software linkuje jiný software, musí používat jeho hlavičkové soubory a je na něm přímo závislý, považuje se to za odvozené dílo.
Pokud aplikace jen využívá otevřeného API a volá si jinou aplikaci, pak na sobě obvykle nejsou přímo založené a nejedná se o odvozená díla.
Knihovny jsou přímo vytvořeny pro linkování, takže tam je to jasné. Proto taky většina knihoven dnes používá GNU LGPL, která má na linkování výjimku a říká, že linkování se nepovažuje za tvorbu odvozeného díla. Naopak při modifikaci knihovny samotné platí stejná pravidla jako u klasické GNU GPL.
-
Tonda (neregistrovaný)
LGPL mi přijde férové, vemu si zdroják a nějak s ním pracuji, tak svoje odvození/vylepšení musím taky zveřejnit. Pracuji na úrovni rozhraní - nemusím. GPL chce více a díky různým technickým řešení se dostáváme na tenký led toho, která interakce je dostatečně "silná" aby se GPL nákaza přenesla.
-
j (neregistrovaný)
Presne takto to prave nefunguje, odvozene dilo je takove, ktere interne pouziva dilo puvodni, nikoli pouzivani jeho API.
=> pokud vemu knihovnu a zadratuju ji do svyho vytvoru, a NEBUDU pouzivat jeji API, tak mam dilo odvozene. Pokud pouzivam API, tak o odvozene dilo v zadnem pripade nejde a jit nemuze, nebot ja vubec nepotrebuju mit ani zdrojaky, me staci binarka.
Ostatne, muze pak prijit kdokoli a napsat knihovnu svoji se stejnym API. A jak bylo receno, ze je muj nazor spravny potvrzuje i to, ze i v linuxu se zcela bezne pouziva ne-GPL SW. A VSECHEN vyuziva GPL knihovny, bez toho by totiz nemohl fungovat.
Mimochodem, pojdme do sveta knizek ... pokud napisu svoji knizku ... a vepisu do ni trebas "A dopadl jako Robinson ..." tak zcela zjevne vyuzivam "API" neb linkuju jine, vseobecne zname dilo a vyuzivam toho, ze vsichni preci vedi, ze jde o zcela konkretniho Robinsona. Nejde ovsem o dilo odvozene - to by byl trebas film podle te zcela konkretni knihy.
-
„A jak bylo receno, ze je muj nazor spravny potvrzuje i to, ze i v linuxu se zcela bezne pouziva ne-GPL SW. A VSECHEN vyuziva GPL knihovny, bez toho by totiz nemohl fungovat.“
Tvůj sebekrásnější názor nepodporuje vůbec nic. Zaprvé spousta knihoven není GPL, zadruhé spousta GPL knihoven je distribuována se speciální výjimkou a zatřetí GPL speciálně dovoluje používání API operačního systému (přičemž je u linuxových distribucí někdy problém definovat, co je ještě součástí operačního systému a co nikoliv).
Nicméně můžeš v diskuzi vyřvávat cokoliv, ale těžko tím změníš realitu, ať už je tím myšlena realita soudní, skutečný názor tvůrců software, skutečný názor tvůrců licence nebo třeba i defenzivní postup podnikatele, který na tvůj názor nemůže spoléhat, protože jemu nejde jen o anonymní výkřiky do diskuze, ale o jeho byznys, případně i živobytí.
-
Tonda (neregistrovaný)
Pokud bych vyšel z té citace v článku, tak program dynamicky linkovanou knihovnu neobsahuje. Je odvozeno vnímám jako vzít zdroják a upravit, nikoliv použít nějaké API, které klidně může být i nějak standardní.
Nicméně podle těch FAQ i jen použití knihovny zakládá povinnost být kompatibilní s GPL. Pokud kolem GPL knihovny postavím Web Service či JSON rozhraní, bude se stále někdo snažit tvrdit, že program volající to rozhraní tu knihovnu obsahuje a že tedy musí být kompatibilní s GPL?
Když udělám pod GPL třeba Java Enterprise Edition aplikační server, znamená to nějaké dopady pro JEE aplikace, které tam poběží nebo snad dokonce pro všechny existující aplikace?
Osobně taky GPL nemám rád, je to jak mor.
-
Ano, GNU GPL je virální a to je vlastnost, s tím to bylo navrženo.
Ad linkování: psal jsem to někde výš nebo níž - volání API nestačí, tam vznikají de facto nezávislé aplikace. Asi jako by Firefox volal kvůli zmenšování obrázků ImageMagick. Jsou to nezávislé aplikace.
Ovšem při linkování už je to něco jiného, do svého kódu zahrneš hlavičkové soubory té knihovny a svůj kód na ní přímo založíš. Bez ní to nebude fungovat. Pak je to odvozené dílo. Stejně tak třeba u modulů do nějaké aplikace (třeba linuxového jádra). Alespoň takový je oficiální výklad věci.
-
Tonda (neregistrovaný)
A jaký je rozdíl mezi voláním API a linkováním knihovny? Volám API nějaké knihovny a tu musím mít nějak dostupnou a musím mít popis jejího API, což sou ony hlavičkové soubory (AFAIK, C-čku moc nehovím, ale pokud vím hlavičkové soubory jsou jen technický popis API). Je otázka, jestli samy o sobě vůbec podléhají autorské ochraně.
Jsem Javista, tam žádné hlavičky nejsou, abych mohl napsat, zkompilovat s spustit program, musím mít používané třídy dostupné binárně, zdrojáky nepotřebuji.
Někdo udělá knihovnu v Javě pod GPL. Já nad ní napíšu aplikaci podle dokumentace a ke kompilaci použiji binární verzi. Distribuovat budu bez knihovny, uživatel dostane instrukci si knihovnu dotáhnout, přípdaně se stáhne sama, tj. můj program tu knihovnu neobsahuje, odvozené dílo to není, protože zdrojáky sem ani neviděl. Musím být GPL kompatibilní nebo ne?
-
Problém je v tom, že technické řešení u soudu pravděpodobně neuspěje. Mluvilo o tom několik lidí na přednáškách mimo jiné na FOSDEMu. Soud přihlíží především k tomu, zda program jako takový nabízí dobře definované API. Pokud si sám uděláš mezivrstvou, kterou šíříš pod non-GPL, může to vnímat jako úmyslné obcházení a může to ztotožnit s případem, kdy linkuješ přímo.
Ideální je, když API daný software standardně nabízí, pak není pochyb.
-
Jirka (neregistrovaný)
> Pokud si sám uděláš mezivrstvou, kterou šíříš pod non-GPL, může to vnímat jako
> úmyslné obcházení a může to ztotožnit s případem, kdy linkuješ přímo.A kdyby si napsal mezivrstvu, kterou by šířil pod GPL? Prostě by se vytvořily dva "díla" jedno by zajišťovalo "mezivrstvu" která by byla dostupná pod GPL a druhé "dílo" by byla vlastní aplikace, která by byla uzavřena, a využívala GPL knihovnu přes GPL mezivrstvu. Takto by to šlo?
-
Asi jsem to nešťastně vyjádřil. Měl jsem obecně namysli mezivrstvu, která se licenčně řídí podle knihovny a která poskytuje toto veřejné API. Jde o to, že nemusíš uspět, pokud jsi tu mezivrstvu vytvořil za účelem zpřístupnění jinak neveřejného API a tudíž má soud důvod se chovat jako kdybys tento (z pohledu soudu čistě technický, tudíž nepodstatný) krok vůbec neudělal a posuzovat to, jako bys linkoval přímo.
Dotyční tvrdili, že minimálně u evropského soudu je značný rozdíl mezi případem, kdy to volné API vědomě nabídnou tvůrci aplikace a kdy si to API zpřístupníš sám. Netuším, jak do toho zapadá případ, kdy to API poskytne třetí strana.
Jde o to, že jedni technici chtějí vnutit své přání právu, druzí technici chtějí jednoznačnou binární odpověď, ale tím slabým článkem je samotné použití copyrightu a závislost na právnících a soudech.
-
Tonda (neregistrovaný)
Co je neveřejné API? Třídy/metody/funkce/procedury jsou buď public a tedy veřejné a nebo vůbec nejdou zavolat.
GPL prostě chce přenést licenci i při použití knihovny a tam prostě nejde dobře definovat hranici.
Uvažujme GPL operační systém. Musí aplikace volající jeho API být také GPL?
bash shell je GNU projekt pod GPL. Pokud napíši skript v bash, což lze těžko bez použití jeho funkcí, musí tento skript být pod GPL?
-
„Co je neveřejné API? Třídy/metody/funkce/procedury jsou buď public a tedy veřejné a nebo vůbec nejdou zavolat.“
V tomto kontextu mám namysli API, jehož využívání není licenčně volné. S technickou stránkou některých programovacích jazyků to nemá nic společného.
„GPL prostě chce přenést licenci i při použití knihovny a tam prostě nejde dobře definovat hranici.“
Přesněji řečeno autoři GPL chtějí a alespoň *někteří* tvůrci GPL kódu chtějí. Je velmi důležité vyhnout se nesmyslním tvrzením o přáních licence samotné.
„Uvažujme GPL operační systém. Musí aplikace volající jeho API být také GPL?“
To by mělo být v GPL napsáno. Operační systém samotný je z pohledu GPL důležitou výjimkou.
„bash shell je GNU projekt pod GPL. Pokud napíši skript v bash, což lze těžko bez použití jeho funkcí, musí tento skript být pod GPL?“
Dobrá otázka. Bash funkce mají přesně definované API ve formě předání seznamu řetězcových argumentů a jsou triviálně nahraditelné/reimplementovatelné. Navíc GPL pro jistotu vyčleňuje všechny podstatné systémové knihovny a nástroje, tedy podle mě i nástroje, které jsou součástí shellu.
-
> Jsem Javista, tam žádné hlavičky nejsou
V Javě je přeci interface, ne? To je podle mě analogie hlavičkových souborů. Rozhraní může být veřejné, implementace proprietární (může být dokonce několik různých implementací). A pokud si to dobře pamatuju, pro kompilaci mi stačí to rozhraní, pro běh ta implementace. Je to tak?
-
Tonda (neregistrovaný)
Ano, v Javě existuje jazykový konstrukt Interface, ale to je jen speciální zápis pro veřejnou abstraktní třídu co má všechny metody veřejné a abstraktní. Není vůbec nutné ji použít, klidně můžu prostě knihovnu napsat jako veřejnou třídu s veřejnými metodami, je to jen o hezkosti návrhu. V každém případě ale pro použití té třídy/interface/knihovny potřebuji jen binární podobu a vědět jak se třída/interface a metody jmenují. Pro kompilaci potřebuju binární podobu rozhraní (nikoliv ve smyslu java interfeca, ale prostě třídy a metody, které jsem ve svém kódu zmínil), žádný zdroják.
-
SB (neregistrovaný)
Myslím, že Tonda to píše správně. K volání jiné knihovny nepotřebujete hlavičkové soubory, ty jsou jen formou distribuce provedení rozhraní, nikde není psáno, že to nemůže být neformálním textovým popisem (takhle se to dělalo v Guptě, mimochodem neuvěřitelná sračka).
Pozor, javové(?) a Ckanálové interface určitě není „speciální zápis pro veřejnou abstraktní třídu co má všechny metody veřejné a abstraktní“. Interface je společným protokolem objektů, jejichž třídy se k němu hlásí. Toť vše. Používá se především k zmenšení virtual method table k volání funkcí v hybridních jazycích (nepoužívají zprávy, takže se nejedná o pravé metody). Ze stejného důvodu nic takového Smalltalk nemá. -
j (neregistrovaný)
V Ccku plati totez - Hcka jsou jen popisem API, a abys to moh pouzivat, tak vubec nepotrebujes zdrojaky knihovny. Staci ti binarka. Ostatne, to bych musel svoje gentoo kompilovat neustale cely, kdyby to tak nebylo, ze ...
=> hlavickovej soubor neni nic jinyho nez "tuhle mas takovouhle funkci s takovejhlema parametrama a takovymhle vystupem"
=> ty si muzes napsat kdykoli stejnou fuknci ktera bude uvnitr vypadat uplne jinak ale chovat se bude stejne.
-
321 (neregistrovaný)
GPL je postavena na myslence vytvoreni ekosystemu software (od operacniho systemu az po aplikace) pod touto licenci. Proto kombinace GPL softwaru s proprietarnim SW bude vzdy do jiste miry kontroverzni v tom smyslu, ze ruzni lide na to budou mit ruzne nazory. GPL puriste (Stallman) by zadnou takovou kombinaci nepripustili, jini lide jsou umirnenejsi.
Co tim chci rict: Kde je text licence nejednoznacny, je treba se optat autoru software (a ne autoru licence), jak to s poskytovanim jejich software je. Pro nektere autory je komercni poskytovani doplnku OK, pro jine ne.
Snad jsem tim prispevkem objasnil i co stoji za tim, ze komercne sirene programy nemohou dynamicky linkovat knihovny pod GPL. Krome GPL ale existuje i LGPL, takze situace neni tak cernobila.
