Proč mám rád LGPL

9.11.2005 19:02 | Přečteno: 1264× | Rouhání největší

Programové knihovny se často šíří pod licencí LGPL, není to však pravidlem. Někdy to bývá GPL, což nepovažuji za úplně nejlepší nápad - i když má každý samozřejmě právo zvolit si licenci dle svého uvážení. Každopádně považuji LGPL za jednoznačně nejlepší licenci pro knihovny, ať si kdo chce co chce říká...

Licence LGPL vznikla jako obdoba GPL určená pro knihovny. Na jednu stranu zachovává svobodu kódu knihovny na úrovni GPL, současně ale umožňuje dynamické linkování s programy pod jinými licencemi. Někdo to nazývá "menší svobodou" (proto se také změnil význam LGPL - z Library GPL na Lesser GPL, což má značit "slabší, menší GPL"). Vychází to z logiky, že takovou knihovnu mohou používat i nesvobodné programy, a proto tato knihovna netlačí na vznik GPL programů.

Lze to ale i obrátit - LGPL zajišťuje větší svobodu, protože kromě svobody á la GPL poskytuje také svobodu na výběr licence, pod níž se bude šířit program, který knihovnu používá. Tento program může být jak pod GPL, tak pod jinou licencí, podle volby autora. Samotná knihovna je stále chráněna proti tomu, aby někdo s jejím kódem naložil v rozporu s principy svobodných programů. Na tom nic nemění ani fakt, že ji lze použít i v nesvobodných programech.

Lidé z projektu GNU doporučují pro většinu knihoven používat GPL; LGPL pouze výjimečně (pro knihovny obecnějšího charakteru). Domnívám se ale, že použití GPL může být významnou brzdou při vytváření programů (zejména konkrétních řešení), u kterých z nějakých důvodů nelze použít GPL (např. kvůli použití součástí pod jinými licencemi, nebo kvůli požadavkům zákazníka). Výsledkem pak bývá, že se použije ryze proprietární řešení (často i včetně OS), případně horší varianta dostupná pod LGPL, a velmi dobrá knihovna zůstane nevyužita.

V souvislosti s tím je nepříjemné, že je např. Qt pod GPL, a nikoli pod LGPL. To obvykle vyúsťuje v používání GTK+, což je podle mého názoru hůře použitelná a pomalejší knihovna - má však licenční výhodu. Proto si myslím, že lepší volbou téměř pro všechny případy knihoven je právě použití LGPL, i když samozřejmě nezatracuji jiné licence (včetně GPL).

       

Komentáře

[Abraxis]

Zrovna Qt si myslim, ze ma velmi rozumne udelanou politiku. Trolltech je proste firma a jako takova musi z neceho zit. Qt je proste unikatni sada nastroju pro komplexni tvorbu aplikaci a je cim dal tim lepsi. Takze - chces psat GPL program - pak ti nic nebrani, dokonce si klidne udelej vlastni fork Qt. Chces pouzit Qt v komercnim programu - pak zaplat rozumnou sumu a mas non-GPL verzi.

Proste se mi to zda perfektni vybalancovani toho, ze OSS komunita z Trolltech muze "tezit", ale nelze jeji praci vyuzit zdarma pro komercni projekty. A naopak - pises-li komercni produkt, tak muzes klidne zacit s GPL verzi a az to mas napsane a vis, ze je Qt pro tebe to prave, tak proste si koupis licenci.

[Jiří (BoodOk) Kadeřávek]

Souhlas.

[Luk]

Samozřejmě, že z pohledu Trolltechu je tohle mnohem lepší řešení (jinak by si asi málokdo koupil komerční licenci), a každý má plné právo si takový model zvolit. Ale z hlediska vývoje aplikací je to brzda. Jinak z hlediska vývoje mi než GTK+ připadá mnohem slibnější např. použití wxWidgets - přestože může zapouzdřovat GTK+, je to mnohem příjemnější vývoj, než používat GTK+ (podobnost wxWidgets s Qt je čistě náhodná ).

[Abraxis]

Podle mne je to lepsi reseni i pro komunitu. Prave jak pises - kdyby to bylo LGPL, tak si licenci koupi malokdo a to zakonite bude mit za dusledek mene kvalitni produkt.

Pokud vim, tak wxWidgets je "pouze" knihovna. Qt je neco mnohem vic - je to opravdu ucele prostredi pro vyvoj strednich az velkych aplikaci - pocinaje qmakem, pres signaly a sloty, podporu vicejazycnych verzi az po naprosto oddelenou tvorbu GUI (ukladaneho v XML) od kodu. Kdo fakt v tom nepsal vetsi projekt (tzn. vic jak par tisic radku kodu), tak nepochopi.

Nechapu opet, proc by to, ze Qt mela byt brzda pro vyvoj aplikaci - uvazuj takhle:

- chci psal GPL aplikaci - pak to problem neni, pouziji GPL verzi

- chci psat komercni aplikaci - pak to problem take neni, koupim licenci

- chci psat aplikaci jen pro sebe a poslepovanou z ruznych knihoven s ruznymi licencemi - opet neni problem, pouziji GPL verzi, coz je OK, protoze vysledny produkt nedistribuuji

- chci psat aplikaci s jinou nez GPL licenci - netusim, ale myslim, ze i k tomu ze komercni licence opravnuje, nicmene v zajmu (Linuxove) komunity je, aby co nejvice aplikaci bylo s GPL nebo BSD (nebo kompatibilnimi) licencemi

[Miloslav Ponkrác]

No jo, připadá mi, že tento scénář byl třeba důvodem pro zavedení BitKeeperu, a nakonec se od toho stejně ustoupilo. BitKeeper byl určitě lepším řešením, než mnohé jiné správce verzí, takže se přimhouřilo očko nad licencí.

Osobně si myslím, že Qt je skutečně brzda pro komunitu. Jasně, jako vývojové prostředí to má něco do sebe. Ale myslím si, že právě využívání Qt odrazuje od toho, aby komunita vytvořila něco srovnatelného s Qt a musí bohužel akceptovat podmínky trolltechu. Osobně nebudu nikdy nic nad Qt stavět, pokud to budu chtít dát komunitě, protože bych si připadal, že bych komunitě škodil.

wxWindows má oproti Qt jednu velkou výhodu, můžu prostě používat svoje oblíbené vizuální prostředí pro vývoj aplikací. Nemusím zápasit s preprocesingem zdrojáků, které se v různých IDE dost špatně řeší, a pokud ladím zdroják, tak ladím svůj zdroják v C++ a ne nějaký poloprodukt co prolezl přes prográmek moc.

Navíc kolem wxWindows narůstá podpora a je pro něj dostupné už kde co, takže dnes už neplatí, že je to holá knihovna. Co oceňuji ve wxWindows je jeho poctivé hlášení chyb, zatímco Qt chyby dost často polyká a nemáte se šanci dozvědět, že došlo k chybě. I když upřímně řečeno, práce s chybami je na pendrek jak v wxWindows, tak Qt, protože já preferuji výjimky, které zde bohužel nenajdu.

Ostatně myslím si, že Qt, ani wxWindows není zdaleka jediné vhodné vývojové prostředí. Myslím si, že třeba velmi zajímavá alternativa je .NET, které je komplexním vývojovým prostředím řešícím daleko více problémů. Přesto, že .NET vyvinula komerční firma, neklade použití takové licenční překážky, jako klade trolltech.

Nemyslím si, že zájmem komunity je mít všechno s GPL licencí. Naopak, přehnané používání GPL licencí okmunitě často škodí. Má-li se třeba Linux stát dobrou alternativou i pro vývoj komerčního software, je třeba základní knihovny mít alespoň pod LGPL.

[honza]

mate pravdu, preprocesor konzept Qt je slabina a jeste vetsi je ten-slot-signal konzept, ktery vyzaduje stanovit jeste pred kompilaci, kdo prijima a kdo vysila. Navic je Qt oproti jednodussim toolkitum 3 x pomalejsi.

Co me ale zarazi je vase pripominka ohledne .NET. Ja dnes vyrobim nejakou clientskou aplikaci jako staticky slinkovane binary, zkopiruju to uzivateli na plochu (bud ve win nebo na slack 9.0) a je vyrizeno. Nemohl by jste mi rici, jak se to dela v .NET. (kdyz chci moji klientskou aplikaci jet treba pod tim slackem). Ja doufam, ze neprijdete s tim, ze si ten uzivatel nahraje nejake Mono??

[Abraxis]

Nechapu - v Qt nemusis pred kompilaci rict "kdo s kym bude provazany". Ty jen reknes "tohle je prijimac" a "tohle je vysilac" a kdo kdy a komu bude co vysilat (tzn. vytvoreni te vazby) se provadi az v runtimu. Opravdu si doporucuji precist (pokud se chce dozvedet PROC je to takhle udelano a proc ne jinak - ver tomu, ze v Trolltechu nepracuji blbci a netrapili by se s tvorbou nejakeho moc pre-kompileru, kdyby k tomu nemeli fakt duvod):

http://doc.trolltech.com/4.0/signalsandslots.html

http://doc.trolltech.com/4.0/metaobjects.html

Co se tyka rychlosti - nemuzu srovnavat, nikdy jsem to nemeril. Vuci jakym jednodussim toolkitum? A v cem? Mluvis o rychlosti vykreslovani widgetu, o praci se stringy, streamy, sokety, o predavani zprav, o praci s databazi nebo o cem?

[Abraxis]

Ach jo. Prosim nemichej pate pres devate.

a, NELZE srovnavat BitKeeper a Qt. BitKeeper NIKDY nebyl open source, natoz GPL. Od pouzivani BK se odstoupilo pote, co autor BK hrozne rval, ze se nekdo (autor Samby) snazil napsat GPL BK klient

b, musí bohužel akceptovat podmínky trolltechu - znovu a znovu - JE TO GPL! Nelibili se ti COKOLIV, tak proste vezmes z FTPka aktualni verzi, prejmenujes si to na "Wt" a muzes si s tim delat CO CHCES!

c, wxWindows má oproti Qt jednu velkou výhodu, můžu prostě používat svoje oblíbené vizuální prostředí - je opravdu videt, ze jsi Qt nikdy opravdu nevidel. Ja jsem zacal Qt vyuzivat za pomoci vi a presel jsem na kdevelop - proste pouzivam to, co mi vyhovuje. Ladeni pak normalne pomoci gdb nebo cehokoliv podobneho.

d, NET nelze s wxWindows ani s Qt srovnavat, natoz tvrdit Přesto, že .NET vyvinula komerční firma, neklade použití takové licenční překážky - chces mi snad rict, ze se na internetu daji stahnout zdrojaky k .NET platforme (pod libovolnou licenci)?

e, Jasne, ze glibc apod. je vhodne mit pod LGPL. Ale Qt je natolik odlisny projekt, ze proste zde dual-licence nicemu nevadi, naopak je pro komunitu prinos, protoze komercni projekty v podstate financuji vyvoj i GPL verze

f, Co se tyka Qt a signalu - to uz je dost o necem jinem, nez o cem byla puvodni debata. Nicmene - tuto vlastnost naprosto nemusis vyuzivat a muzes vse psat jako standardni C++ a nepoznas, ze neco jako signaly/sloty existuji. Jakmile ale zacnes psat vetsi aplikaci, tak pochopis, jake ma tato filozofie programovani vyhody. Pisu a ladim netrivialni projekt (6000 radku, 5 naprosto ruznych threadyu delajicich ruzne cinnosti a komunikujici prave pres signaly, mutexy apod. a zatim jsem nemel zadne problemy s ladeni ani necim jinym)

[Miloslav Ponkrác]

Začnu tímto, jestli 6000 řádků je netriviální projekt, tak promiň, ale podle mě jo maximálně malá čudla, co nestojí za řeč.

Co se týká Qt a threadů, tak já osobně bych si to nedovolil. Když jsem studoval zdrojáky Qt, našel jsem tam synchronizační chyby, které by mě osobně nedovolovaly Qt věřit při nasazení v threadech. Evidentně tam podpora threadu byla později dolepená, ale neošetřili všechno. Nicméně jsou to chyby takového rázu, že se projeví velmi velmi zřídka, ale v pořádku to není.

Co se týká .NETu, tak mám pocit, že si trochu nerozumíme. .NET je platforma, ne program. Když se ptáš na zdrojáky k .NET, ptáš se asi na stejnou blbost, jako kdybys chtěl zdrojáky k IP protokolu. Nenech se prosím Tě unášet Tvojí touhou po zdrojákách a trochu rozlišuj. K dispozici jsou specifikace a standardy pro platformu .NET a to bohatě stačí.

Co se týká vývoje Qt pod integrovaným prostředím. Poraď mi tedy, jak můžu v integrovaném prostředí pod Windows, řekněme pod Visual C++ vyvíjet pod Qt a jak tedy budu prohánět zdrojáky preprocesorem. O tom, že gdb nechci ani vidět Ti nebudu povídat. Nástroje typu make a gdb používám až tehdy, když integrované prostředí nestačí.

Není pravda, že můžu vzít zdrojáky Qt, přejmenovat si to na Wt a dělat si s tím co chci. Nemohu z toho třeba udělat dílo pod LGPL licencí, protože mi to prostě není dovoleno.

BitKeeper jsem do toho zapletl z toho důvodu, že mi to přijde podobné. Prostě Ty argumentuješ, že Qt je hlavně skvělý nástroj, a proto je vše v pořádku. U BitKeeperu se taky argumentovalo, že je skvělý, takže je to v pořádku. Uznávám, že Qt je GPL, ale podle mě to není v pořádku. Vzhledem k tomu, že se velmi často používá pro vývoj základních věcí v Linuxu, mělo by to být LGPL.

[Luk]

Poraď mi tedy, jak můžu v integrovaném prostředí pod Windows, řekněme pod Visual C++ vyvíjet pod Qt a jak tedy budu prohánět zdrojáky preprocesorem

Úplně normálně. Qt nástroje se totiž do Visual Studia integrují (objeví se tlačítka na liště, položky v menu atd.) a při kompilaci zdrojáku se prostě před kompilátorem zavolá preprocesor. Jedná se ovšem o komerční balík Qt pro Windows (verze 3 se pro Win ani v GPL neposkytovala, verze 4 sice ano, ale do VS se neintegruje).

[Miloslav Ponkrác]

Jinak řečeno, musím si připlatit. Prostě to klasickou cestou nejde. A to se pro jistotu neptám, když použiji jiné IDE, třeba Dev-Cpp, jestli i tam je nějaké řešení. Prostě je to zbytečně komplikované a přináší to jenom problémy.

[Luk]

Je řešení, ale spočívá v ručních nastaveních (nebo v naprogramování nástroje, který to zajistí). Vyvíjel jsem programy s Qt pomocí Eclipse + CDT (pod Linuxem i Windows), preprocessing jsem měl zajištěn přes speciální makefile. Nebylo to úplně triviální, ale danému účelu to plně posloužilo.

[Abraxis]

No, myslim, ze 6000 radku v C++ pro jednoho programatora je fakt netrivialni projekt (jedna se o rizeni duplikatoru CD/DVD, kdy je po kazdou mechaniku spusten thread, pro tiskarnu zvlast, pro GUI zvlast a pro reportovani a je to funkcni pod Mac OS a Linuxem), COCOMO odhad byl pokud si naposledy pamatuji cca. 1.2 clovekrok prace s naklady kolem 180 t.$. Nerikam, ze je to velky projekt, ale zase to neni vec, kterou napises doma za par vikendu.

Jo, ja vim, ze NET je platforma. Problem s NETem je ten, ze vlastne nikdo poradne nevi, co je to. Muzes mi to prosim vysvetlit? Co je vlastne NET? Programovaci jazyk? Ne. Knihovna? Taky ne. Aplikacni server? Taky ne. API? Ne. Protokol pro komunikaci mezi procesy? Ne. Co to teda vlastne je? (mozna se totalne mylim a je to neco nebo vsechno z toho, co jsem napsal!).

Ale pokud se budeme bavit treba o C#, tak sice mas specifikaci jazyka volne dostupnou (ostatne - co na tom vymyslet - proste objektovy jazyk s C-like syntaxi jako je Java nebo treba i Perl) ALE treba uz zakladni knihovny sice popsany, ale Microsoft kdykoliv muze tuto specifikaci uzavrit a projekt Mono se muze jit zahrabat. Zatimco Qt je postavene nad standardnim C++ (pokud nepouzijes signaly a sloty, tak naprosto)...

Jeste k jedne veci - PRAVE PROTO, ze se to pouziva pro vyvoj zakladnich veci v Linuxu, tak neni sebemensi duvod, aby to bylo LGPL. Ja rozhodne nechci, aby kdykoliv v budoucny byly (opet cituji) "zakladni veci v Linuxu" pod jinou, nez GPL licenci (rozumej - aby byly uzavreny a zkomercionalizovany)

[Miloslav Ponkrác]

Ok, omlouvám se, máš pravdu. Nedá se soudit jen podle počtu řádků. Chtěl jsem jen říct, že se určitě na Tvém projektu neprojeví vyspělost Qt pro velké projekty, protože pro pejekt takového rozsahu vyhoví kde co.

.NET framework je naprosto přesně definovaný. Hodně zjednodušeně je to jakési běhové prostředí nazvané CLI, u kterého je definován formát souborů, IL (jakýsi virtuální assembler), způsob přístupu k API a základní knihovny. Dá se to trochu přidobnit k virtuální mašině v Javě. Jako nadstavba je standardizován C#.

Pokud budou základní věci v Linuxu GPL, pak platforma Linuxu nebude brána výrobci komerčního softu vážně a Linux zůstane jako hračka v rukou nadšenců. Právě proto vidím vážný důvod pro LGPL, kde máš zajištěno, že konkrétní knihovna nebude uzavřena, ale zároveň to nebude bránit komerčním aplikacím.

[Abraxis]

Ohledne NETu - je to teda neco jineho, nez virtualni masina s relativne strojove nezavislym bytekodem a standardni sadou definovanych knihoven?

S LGPL nemas jistotu, ze projekt, ktery takovou knihovnu vyuziva, nebude uzavren. Ty mluvis o knihovne, ja o projektu. Hromada knihoven je urcite v Linuxu je GPL a pritom Linux berou nejvetsi svetovi vyrobci komercniho SW vazne (Microsoft, SUN, IBM, Oracle...)

[podlesh]

Ohledne NETu - je to teda neco jineho, nez virtualni masina s relativne strojove nezavislym bytekodem a standardni sadou definovanych knihoven?

No, asi tam je ještě vyžadován minimálně C#, ale nejsem si zcela jist. V případě Javy je jazyk (Java) neoddělitelnou součástí platoformy (Java).

Jinak to ale je tak - virtuální mašina a standardní sada knihoven. Která ovšem (!!) neobsahuje (!!) grafické GUI, takže vlastně debatujete zcela off-topic. Nelze QT nahradit pomocí .NET.

Microsoft a Mono dodávají ve svých frameworcích ještě mnoho nestandardních knihoven, jako je například grafické gui (windows forms, GTK binding) nebo ASP.NET (to je zase pro změnu jiná sada knihoven).

[Marek 'marx' Grác]

Ach jo. Prosim nemichej pate pres devate.

a, NELZE srovnavat BitKeeper a Qt. BitKeeper NIKDY nebyl open source, natoz GPL. Od pouzivani BK se odstoupilo pote, co autor BK hrozne rval, ze se nekdo (autor Samby) snazil napsat GPL BK klient

BK BOL open source, akurát nikdy nebol free softvér. BK prestal byť open-source kvôli dvom konkrétnym udalostiam. Podľa pôvodnej zmluvy mal BK logovať metadata na verejný server s tým, že budú prístupné každému. A tí, čo vyvíjajú closed-source produkty, resp. im to vadí nech si ho kúpia. Lenže kým to bol open source, tak to nebol problém zakomentovať (a robilo to tak príliš veľa ľudí). Druhým problém bolo kopírovanie niektorých fn do podobných free nástrojov. Autori sa vyjadrili, že nie sú proti free konkurencii, ale nech nevykrádajú ich kód. A pár mesiacov na to sa stal z BK closed-source.

[Abraxis]

OK, mas pravdu, bylo to fakt asi open source. Ohledne toho uzavreni to ale tak neni, jak pises doporucuji precist si: http://www.theregister.co.uk/2005/04/22/tridgell_releases_sourcepuller/

To s tim, ze kdo BK pouziva, tak nesmi po par dalsich let vyvijet jakykoliv jiny (open nebo closed) system na spravu verzi, bylo v licenci od zacatku...

[Marek 'marx' Grác]

Teraz sa mi to hladat nechce, ale podla mna to tam nebolo od sameho zaciatku (pocitaj, tak 2-3 roky nez na neho presiel linus). Obmedzenia urcite pribudali postupne to som si isty. Ked tak pozri moje clanky na toto tema, ci uz na abclinuxu (koniec BK v jadre), alebo na rootovi (prechod na BK v jadre) :)

[Daniel Kvasnička ml.]

jj, je to tak

[Miloslav Ponkrác]

Ano, to zní rozumně, alespoň na první pohled. Myslím, že není těžké pochopit motivaci trolltechu.

Na druhé straně já osobně dávám přednost LGPL knihovnám. Existují knihovny založené na Gtk s LGPL. Existuje třeba wxWidgets, které má ještě volnější licenci, než LGPL. Atd.

Přiznám se, že důvody, proč se snažím ignorovat Qt knihovnu není jen jejich licence, ale také nutnost naprosto zbytečného preprocesingu zdrojáků, který dělá problémy ve vizuálních vývojových nástrojích a ztěžuje ladění (ano, trolltech ještě nepochopil význam direktivy #line, když už chce přechroustávat zdroják).

Preprocesing, který je zaveden u Qt knihovny je naprosto zbytečný, protože práci se signály a sloty zvládne C++ svými prostředky, aniž by bylo nutné zdroják nějak upravovat jak to ukazuje příklad Gtk knihoven.

Pak bych měl ještě určité další výhrady k Qt, ale ty jsou jen podružného rázu.

[Michal Karas]

To obvykle vyúsťuje v používání GTK+, což je podle mého názoru hůře použitelná a pomalejší knihovna - má však licenční výhodu.

Nicméně GTK+ je IMHO přijímána lidmi upřednostňujicími Qt/KDE kladněji, než je tomu naopak, takže je dobře, že to tak je.

[Luboš Doležel (Doli)]

Pomalejší ano, ale hůře použitelná - tak to ani náhodou. Už jen práce s jednoduchým Glade mi přijde snažší než s QtDesignerem a s GTKmm jsem nadmíru spokojen.

[Luboš Doležel (Doli)]

Jinak pardon, strčil jsem to pod špatný příspěvěk.

[alblaho]

Přesně tak. Politika Trolltechu je logická a pochopitelná. Přináší komunitě toolkit "komerčních kvalit".

Ale něco se za to platí. Jako nezávislý vývojář občas potřebuji ještě jedno právo. Právo uzavřít svůj program a vydat pod jinou licencí, než GPL. Což nutně neznamená, že ho musím rovnou prodávat a mít tak "důvod" koupit si Qt. Proto potřebuju LGPL knihovny a proto má u mě Qt lehkou diskriminaci.

Prostě vždy je to něco za něco.

Tato vlastnost Qt se projevuje i v boji KDE vs GNOME.

[Abraxis]

Budu fakt hnusnej - to pravo mas, ale musi ssi koupit licenci.

K cemu jinemu, nez ke komercnimu prodeji ci nasazeni, potrebujes uzavrit kod? Udej jeden jediny priklad.

[Miloslav Ponkrác]

Koukni se kolem sebe, kolik je freeware software s uzavřeným kódem, které jsou k dispozici zcela zdarma, tedy ne ke komerčnímu prodeji a ne výhradně ke komerčnímu nasazení. Pokud si myslíš, že všechny volně a zadarmo dostupné programy jsou open source, tak máš klapky na očích. Pravděpodobně jsi se seznámil s internetem teprve před pár dny, když jsi na takový program ještě nenarazil.

A proč někdo uzavírá kód? Třeba se koukni na případ programu Nessus, jehož autor se rozhodl uzavřít kód.

[Abraxis]

Hele, ja s Internetem delam od 1995 a s Linuxem od 1998, takze tusim, o cem je rec.... (zlate FIDO )

Nicmene - ano, priklad Nessus je idealni. Predstav si, ze by autor Nessusu mel integrovano GUI v Qt. Co by nastalo v pripade, ze chce uzavrit kod (protoze potrebuje ziskat vic penez prodejem komerni licence) - proste by si koupil jednorazove za 1420 az 5260 Euro (dle edice a poctu podporavnych OS) licenci Qt a klidne by projekt uzavrel.

[Miloslav Ponkrác]

Ta poznámka s internetem byla za to hloupé prohlášení, že si neumíš představit jiný důvod k uzavření kódu, než je komerční využití )

Jenomže autor Nessusu neuzavřel kód proto, že by na něm vydělával. On ho dokonce dál jako program poskytuje zdarma. Nijak na tom programu neprofituje a cena za Qt je v tomto případě dost vysoko. Upřímně řečeno zrovna u tohoto projektu, kde grafické rozhraní není to hlavní a asi bude i jednoduché by mě cena za Qt licenci vyprovokovala k tomu, že bych prostě přepsal grafické rozhraní do jiné knihovny. U složitějšího grafického rozhraní bych měl asi smůlu.

Já se prostě osobně rozhodl, že Qt využívat pro free projekty nebudu, a to jednak z důvodů pro mě nepřijatelné licence a jednak z důvodů zbytečných obstrukcí s preprocesorem na místě, kde preprocesor není vůbec potřeba. Implementace signálů a slotů se dá zvládnout v pohodě standardními prostředky jazyka C++, jak ukazuje LGPL knihovna libsig, která právě toto realizuje.

Qt knihovna bohužel vytváří spoustu problémů. Chce přechroustávat moje zdrojáky, nespolupracuje se standardními knihovnami C++, zejména s STL a zavádí si svoje pseudonáhrady za různé listy a vektory z STL knihovny. Namísto používání standardních řetězců z STL knihovny tu mám zase pseudonáhradu typu QString. Atd. Nejspíš jsem si s Qt nepadli do oka.

[Abraxis]

Zrovna QString mi nepomlouvej - to je proste nadherna vec Ja jako vyvojar proste nemusim premyslet, zda dane knihovny na Mac OSu, Windows nebo Linuxu umi proste to, co od objektu na praci s retezci potrebuju a vsude mam jeden jediny objekt, ktery umi naprosto vse, co jsem kdy od prace s retezci potreboval (a to jsem si s nimi v PHPecku a Perlu uzil veci ))

Co se tyka signalu/slotu - jak jsem psal v jednom jinem prispevku, precti si dokumentaci Trolltechu, PROC nejdou signaly/sloty standardnimi prostredky a proc vymysleji nejaky vlastni preprocessor (je to tam fakt docela podrobne popsano - argumentaci si uz presne nepamatuju, ale opravdu mne to presvedcilo, ze ti lidi vi, co mluvi). V podstate se jedna o "late - binding" podobne Cocoa (nebo jaxe to v Mac OSu jmenuje - mozna Objective C) - proste typova kontrola se provadi az v run-time, zatimco libsig ma typovou kontrolu v compile time. Konkretni debata je na: http://doc.trolltech.com/4.0/templates.html (Why Doesn't Qt Use Templates for Signals and Slots?)

Co se tyka Nessusu - uzavreni bylo motivovano PRAVE komercionalizaci projektu: Gula said, however, that the company's new business model was based on an "increase in demand from our customers who want a fully supported, commercially licensed version of the product." - zdroj: http://software.newsforge.com/article.pl?sid=05/10/24/1821209

[Miloslav Ponkrác]

Co Ti prosím Tě chybí na STL třídách typu string/wstring? Funguje to na všech platformách stejně.

A proč nepoužívají třídy typu vector, list, apod.. z STL, které jsou určitě na vyšší úrovni, než náhražky v Qt a jsou také přenositelné?

Tak proč si Trolltech nenapsal svojí vlastní knihovnu na dynamické signály? Proč rovnou hurá na to s preprocesorem? Ani čtení mě nepřesvědčilo, že musel Trolltech použít preprocesor. Jediné, co jsem pochopil, že řešení pomocí statických šablon není pro ně to pravé ořechové, ale to chápu. Koneckonců i článek se jmenuje "Proč nepoužívá Qt šablony pro signály a sloty?". Ale C++ nejsou jen šablony a celkem chápu, že šablony se hodí spíše pro statičtější věci. Ale proč to tedy nenapsali v C++ jiným způsobem?

Pokud chtěli mít dokonalé vlastnosti Objective C, tak proč celou knihovnu Qt nenapsali přímo v Objective C?

Co se týká Nessusu, tak se mi nechce vyhledávat relevantní informace, ale co jsem četl, tak primárním důvodem bylo to, že jiní komerčně využívali a upravovali jeho kód, aniž by on z toho cokoli měl. Ovšam je to jen co si pamatuji, takže styl JPP.