Nokia podjęła decyzję o „złagodzeniu” licencjonowania biblioteki Qt. Najbliższe wydanie oznaczone numerem 4.5 będzie dostępne także na licencji LGPL.
Rok temu, kiedy Nokia kupiła Trolltech, firmę rozwijającą Qt i czerpiącą zyski z jej wolno-komercyjnej licencji (Qt dostępne było za darmo na GPL, ale tylko dla niekomercyjnych projektów udostępnionych na tej samej licencji, firmy sprzedające software musiały zakupić komercyjną licencję biblioteki), wszyscy zastanawiali się w jakim kierunku nowy właściciel pokieruje rozwojem Qt. Teraz widać już, że ten kierunek to otwartość.
Nokia planuje wydanie Qt 4.5 na licencji LGPL, w celu zwiększenia zainteresowania tą biblioteką zarówno świata open source, jak i komercyjnego. Licencja LGPL umożliwia używanie kodu do komercyjnych celów bez opłat licencyjnych (choć zastosowanie dodatkowo biblioteki na GPL wymusza stosowanie dla projektu licencji GPL). Nokia nie musi aż tak zarabiać na Qt, jak musiał robić to Trolltech, lecz w jej interesie leży zwiększenie popularności platformy Qt. Zmiana licencji na pewno otworzy nowe segmenty rynku. Na zeszłorocznej KDE Akademy założono dziesięciokrotny wzrost liczby programistów i użytkowników związanych z Qt w najbliższym czasie, roku. Oficjalna informacja
"Teraz widać już, że ten kierunek to otwartość."
LGPL jest elastyczniejsze jako licencja, ale na pewno mniej otwarte niż GPL, bo dopuszcza tworzenie zamkniętego kodu, więc powyższe stwierdzenie jest nieprawdziwe.
A przepraszam ja cię bardzo, a np. w komercyjnej Mandrivie, to może KDE nie ma? No chyba, że masz na myśli co innego, a czego ja nie mogę się domyśleć?
Eclipse'owy SWT miał początkowo także implementacje nad QT, ale IBM się wycofał właśnie ze względu na GPL/komercyjną licencję – i tak pozostała implementacja SWT nad GTK i Motif (chyba). Oczywiście mówię tylko o wersjach dla GNU/Linux.
Właśnie znika ostatni powód, dla którego ludzie sięgali po Gtk i wxWidgets tworząc wieloplatformowe aplikacje. Z tą licencją, dokumentacją i architekturą Qt mnie do siebie przekonuje.
W przypadku wxWidgets język jest ten sam. W przypadku GTK: no cóż, programista znający tylko C to kiepski programista…
Odnośnie "dodatków" które wnosi do C++ Qt: są dobrze przemyślane, nie ma ich dużo, IMHO żaden problem.
A GTKMM, GTK+ ?
Poza tym pisząc pod GNOME używa się Objective C, a nie C. Gołe C++ bez RTTI, refleksji, brak obiektowych callbacków (domknięć), nie jest elastyczne i do dobrej biblioteki obiektowego C może mu sporo brakować.
Tu macie porównanie kawałka kodu w U++ i QT:
http://www.ultimatepp.org/www$uppweb$vsqt$en-us.h…
Pisałem w jednym i drugim, oczywiście U++ ma mniejsze możliwości, ale pisze się w nim bajecznie prosto.
adbebe: kiepski programista zapomina o innych jezykach, ktorych sam nie uzywa. do biblioteki napisanej w c bardzo prosto sie linkowac, tak wiec i latwo tworzyc bindingi do roznych jezykow (np. lisp, forth (w tym lubiana przezemnie reva 😉 ), czy chociazby java). w przypadku cpp tzw. "name mangling" mocno to utrudnia (co nie oznacza ze czyni niemozliwym – sip dobrym przykladem ze jednak da sie).
Przecież powszechnie wiadomo ze goły C++ jest niedopracowanym, wręcz zacofanym językiem jako całość wliczając w to standardowy runtime i bez rozwiązań jakie dają meta prekompilatory lub RTTI (reflektywność), metodyka w stylu COM/XPCOM (samo usuwaniem niepotrzebnych obiektów do których nie ma referencji [smartpointers takze] i komponentowość, wsparcie wersji implementacji), boost, lub dobry framework jak np.: QT, to lepiej do C++ nie podchodzić w dużych projektach, chyba że ma się 5 X więcej kasy.
Nawet taki wspaniały QT jest lekko skopany jako biblioteka dynamiczna, bo nie został zaimplementowany w podobny sposób jak robią to standardy COM/XPCOM, tylko wyeksportował (do linkowania) wszystkie klasy implementujące.
Mówię to mimo że, lubię C++. Siedziałem w C++ ponad 8 lat (od DOS, poprzez Windows, HP-UX, Linux, OS-390).
A jakoś mi się przypomniał.
Jeden i drugi jest językiem obiektowym i początkowo oba były prekompilowane do "kodu pośredniego" w C.
Rozpędziłem się mówiąc że GNOME używa Objective C – on używa koncepcji obiektowego C.
A ogólnie pisałem o słabej elastyczności języka C++ i tym, że trzeba się zawsze trzeba się posiłkować jakimiś niestandardowymi dodatkami (np.: Objective C jest reflektywny).
Właśnie dokładnie ze względu na licencje, olałem kilka lat temu QT 3 (3.1.1 w wersji "eval" pół nocy crack'owałem w wersji na Windows), ale wtedy Trolltech to była samowystarczalna firma, która żyła z licencji – Nokia może traktować QT na LGPL jako cześć swojej strategii i trochę do tego dołożyć.
Podobnie jak inni uważam, że może to być przełom nie tylko w popularyzacji KDE w komercyjnych dystrybucjach, ale dlatego, że ludzie związani z Gtk będą musieli się naprawdę wziąć do roboty aby ich biblioteka była nadal atrakcyjna dla małych komercyjnych projektów.
Jeśli news okaże się prawdziwy to oznacza, że Nokia zrozumiała starą prawdę o tym, że siła danej platformy w bardzo dużym stopniu zależy od ilości programistów.
Co mi się podobało zawsze w Qt to, że ta biblioteka cywilizowała język c++.
Tak wiem, to był pewien skrót myślowy, chodzi mi raczej o to wokół jakiej biblioteki dana dystrybucja rozwija swoje narzędzia, które środowisko jest domyślnym desktopem. Wiem, że można oczywiście się oto sprzeczać, ale wrażenie było takie, że Gtk miało przewagę.
to chyba bardzo osobiste odczucie, co dla kogo jest używalne, a co nie? dla jednych jest to Gnome z Gtk+, dla innych jest to KDE z Qt. Oba środowiska mają różne podejście do użyteczności – lepiej szanować wybór innych, niż pokazywać sztuczne zdziwienie i dezaprobatę.
Fan boye KDE/Qt chcieli by marginalizacji Gnome/Gtk, fan boye Gnome/Gtk chcieliby marginalizacji KDE/Qt – obie grupy fan boyów zapominają jednak, iż istnienie dwóch *różnych* środowisk daje użytkownikom wybór. Przecież dla tego wyboru niektórzy przenoszą się z Windows / Mac OS X, gdzie wyboru nie mają… więc po co ich od razu wciągać w wojny Gtk vs Qt? niech używają tego, co im bardziej pasuje.
A może ci dystrybucjo-twórcy po prostu kupili komercyjną licencję od Trolltech/Nokia i mogą tworzyć komercyjną dystrybucję w myśl reguły "ja zarabiam, to i ty zarobisz".
Nie. QT pod X11 już od dawna (blisko dekada) było dostępne na licencji (do wyboru) GPL i zamkniętej. GPL nigdy nie wykluczało zarabiania kasy w jakikolwiek sposób, tylko wymusza dzielenie się źródłami z użytkownikami. Dystrybucjo-twórca tworzy paczki tak, jak dla wszystkich innych programów na licencji GPL nie przejmując się tym, że inne firmy (np. skype) mogą z QT korzystać na innych warunkach.
@tkadlubo
O Qt (a nie QT ?) i GPL to ja wiem – wersje 1.x (chyba) i 2.x były też w GPL pod Windows (tylko 3.x, nie wiem czy cała, była wyłącznie komercyjna pod Windows).
Przeoczyłem jedynie fakt (o którym wiedziałem), że jeśli się publikuje źródła (a np.: RedHat publikuje), to przecież można zarabiać używając bibliotek GPL.
Ja bardzo powoli zaczynam programować, ale już napisałem Hello World w Qt4 😛
Tzn, z przyciskiem który coś robi jak się na niego kliknie i jest to bardzo proste i szybkie na dodatek.
A i dzięki QtDesigner można ładne okienka tworzyć 😉
Ale Glade to pół generator, z tego co pamiętam – generowanie kodu zawsze się kiedyś kończy i zaczyna się mozolna refaktoryzacja masy wygenerowanego kodu i szlif już bez wsparcia narzędzia.
Jak go czytałem pierwszy raz nie zauważyłem odnośnika "oficjalna informacja", a do tak znaczących informacji podchodzę sceptycznie dopóki nie ma oficjalnego potwierdzenia.
Mozna uzyc wielu slow na okreslenie tego co Qt zrobilo z C++, ale cywilizowanie nie jest jednym z nich. To co z nim zrobiono doskonale oddaje slowo moc(kery).
Przepraszam bardzo, ale o co wam chodzi?? Qt nie robi nic z C++. Po pierwsze nie trzeba używać sygnałów/slotów i reszty, choć wtedy programowanie z Qt nie miałoby większego sensu. A po drugie wszelkie 'dodatki' to są MAKRA a nie modyfikacje języka. Tak więc, zanim się wypowiecie proponuję zapoznać się faktami, a nie przekazywać dalej bzdety.
A można łączyć STL z QT C++? Ja tego nie wiem, bo zaporą dla mnie było właśnie cena komercyjnej wersji Qt (i dlatego się jej nie uczyłem). Moŋę np. używać std::sort dla napisów w Qt (bo chyna napisy w Qt to osobna klasa?)? Albo std::transform na std::list by np. zmienić tym widgetom tekst?
"[..] Then to continue using Qt signals and slots with the no_keywords flag, simply replace all uses of the Qt moc keywords in your sources with the corresponding Qt macros Q_SIGNALS, Q_SLOTS, and Q_EMIT"
Nie ma potrzeby "łączenia" STL z QT (ale można).
QT to nie tylko widgety, ale cała masa klas i funkcji zastępujących standardowy runtime C/C++ i przykrywający całkiem sporą ilość funkcji systemu operacyjnego. QT tworzy tym sposobem w miarę kompletną warstwę abstrakcji (jak Java, runtime Pythona, .NET'a, itd), tak że program napisany w czystym QT można przekompilować teoretycznie bez problemów na dowolną platformę, na którą jest wydane QT (pomaga w tym qmake, który wypluwa makefile dla większości kompilatorów). Ja pisałem w nim na Windows i Linux jednocześnie (nie było aż tak różowo z przenośnością, szczególnie przy niestatycznym linkowaniu pod Linux'em mającym już zainstalowane QT w ciut innej wersji).
W QT najbardziej denerwowały sposób na designowanie formatek i uzyskiwanie meta informacji w klasach: formatkę opisywały aż cztery pliki, które były traktowane jakimś sklejaczem/prekompilatorem – jak się używało designera to było OK, ale jak chciało zrobić się nieszablonowy komponent i uzyskać większą dynamikę spinania komponentów i sygnałów, to zaczynała się lekka rzeźnia.
Zobaczcie jak ładnie problem zasobów (ikonki, opis layoutu formatek) rozwiązali Czesi we frameworku U++. Po prostu perfekcja prostoty.
@JarekP: Z punktu widzenia użytkownika-programisty sygnały i sloty nie są realizowane poprzez MAKRA, a konwersję na czysty C++ zapewnia MetaObject Compiler. W związku z tym oryginalne źródła Qt bez poddania ich wstępnego przetworzenia przez MOC nie używają MAKR w celu implementacji sygnałów i slotów.
Trzeba wziac pod uwage to, kiedy tworzone bylo Qt. C++ w tamtych czasach dosc roznil sie od tego co mamy obecnie.
Dlatego tez zdecydowano sie na potworki w stylu makra (zasmiecanie przestrzeni nazw, brak kontroli typow, preprocesorowe swinstwo) i zalatwienie sygnalow/slotow poprzez generator kodu, bo nie bylo rozwiazan jakie mamy teraz.
To co oferuje Qt w ramach swojej biblioteki standardowej to przede wszystkim przenosnosc, kosztem wolnosci jaka daje C++.
A U++ to inna bajka, swieza krew, co zreszta widac.
Nie wiem jak w QT 4, ale w QT 3 trzeba było używać slotów i sygnałów, bo inaczej nie dało się powiązać zdarzenia w komponencie z metodą implementującą akcję. Nie pamiętam dokładnie, ale jak się wyklikiwało interfejs, to wiązania między slot a socket były generowane przez MOC.
Sloty i sygnały w QT to tak naprawdę wskaźniki na na metodę obiektu, czyli inaczej closure (domknięcie) – Borland stosował to powszechnie w C++ Builderze jako rozszerzenie kompilatora w postaci __closure.
O ile wskaźnik na zwykłą funkcje [tak zwany callback] w sensie C jest 4 bajtowy w systemie 32 bitowym, to closure jest z reguły 8 bajtowe.
Tu wychodzi właśnie skopanie standardowego C++ – nie ma on closure – trzeba to emulować [grrrr]. Ale to się chyba zmieni ? … kiedyś.
Wpierw powinni doprowadzić GTK+ do normalnego "wyglądania" na windowsie i działanie na MacOS X bez X11 (OK, dobra, nie jestem pewien co do X11 na MacOS X, ale np. gtk-demo z engine Windows na Viście.. OK, wygląda jak windows, ale nie działa jak windows. Nie ma płynnych przejść przy hoover, i czasami niektóre kontrolki wyglądają jak jakiś prehistoryczny motif)
Nie pamiętam czy było to na Roadmapie GTK3.
Póki co jestem bardziej skłonny używać C, a zatem również GTK, więc wiążę z GTK duże nadzieje…
Za już teraz nikt Ci nie broni użyć BSD(i wielu innych licencji) do swojego programu napisanego w Qt.
http://doc.trolltech.com/4.4/license-gpl-exceptio…
Trudno wymieniać kod w takich projektach… Qt 4.5 będzie miało QGtkStyle umożliwiające używanie dowolnego stylu GTK przez Qt (przez co pod GNOME aplikacje Qt będą wyglądały identycznie jak te napisane w GTK+)
A jak można wyczytać w wiadomości o Prism, GTK+ ma gtk-qt-engine, dzięki czemu aplikacje GTK+ także mogą wyglądać ładnie pod KDE.
Generalnie mówiąc jest to ruch we właściwą stronę.
Ja tam wolę jak się różnią, jest jakaś różnorodność na pulpicie, ale na pewno takie projekty są przydatne. Tylko czy Gtk ma wszystkie kontrolki, które oferuje Qt? Bo pod tym względem chyba jest znacznie prostsze?
Fajowo, bo ja np. chciałem kupić licencję na QT, wysłałem im mejla, dostałem odpowiedź z listą pytań, odpowiedziałem i czekam już ponad miesiąc na informacje na temat ceny, a skoro nie chcą mojej kasy i dadzą mi to za free, to tym lepiej dla mnie.
Z informacji, które posiadam jest dwóch partnerów QtSoftware w Polsce, z czego jednego z nich mam przyjemność reprezentować i nie wydaję mi się abyśmy otrzymali od Ciebie maila. Jeżeli wciąż jesteś zainteresowany uzyskaniem informacji proszę o kontakt.
www.arise.pl
Kontaktowałem się bezpośrednio z nokią, osoba, z którą rozmawiałem, pisała z adres @nokia.com.
A teraz już nie jestem zainteresowany skoro będziemy mieć LGPL.
Nie wiem czy LGPL/GPLowa wersja da ci to co płatna: dostęp do sterowników dla komercyjnych baz danych, wsparcie, dodatki itd. co wypisane na stronie Qt Software. 😉
Też tego nie pojmuję. Linkowanie dynamiczne do biblioteki na licencji GPL nie zmusza autora programu do stosowania licencji GPL. Teza, że wykorzystanie interfejsu stanowi "derived work" lub "combined work" jest ciężka do wybronienia. Patrz: sprawy MSFT odnośnie (nie)udostępniania informacji na temat stosowanych przez firmę interfejsów.
Biblioteki dynamiczne są dostarczane przez użytkownika systemu a nie przez programistę. Programista może mieć jedynie nadzieję, że jego program trafi na taki *interfejs* biblioteki, na który został przygotowany. Użycie młotka do wbicia gwoździa to nie jest "derived work" produktu z huty stali. Dopiero przetopienie tego młotka na śrubokręt będzie. Gdyby ktoś miał słabą wyobraźnię: uchwyt to interfejs.
Dla precyzji: w mojej opinii (żaden sąd chyba jeszcze tego nie rozpatrywał) plik nagłówkowy jest jedynie opisem interfejsu do kodu biblioteki. A nawet jeśli nie mam racji, zawsze można te pliki stworzyć samemu… Będzie ciężko, jak to zwykle przy reverse engineeringu bywa. Przeciętny prawnik wykarze jednak, że jest to możliwe.
Gdyby samo wykorzystanie upublicznionego interfejsu oznaczało konieczność stosowania tej samej licencji, na której udostępniono to coś, co ów interfejs dostarcza, komputery byłyby sprzedawane z równymi obostrzeniami co elektrownie atomowe. Obie te rzeczy korzystają przecież z tego samego interfejsu sieci energetycznej. Są po różnych jego stronach, czyli dokładnie tak, jak program i dynamiczna biblioteka. Oznaczałoby to też spore problemy dla zespołu Samby i OpenOffice'a, które korzystają z własnościowych rozwiązań w zakresie struktur danych (takich, jakie widzimy w plikach nagłówkowych).
Nokia przerabia qt na LGPL, gdyż ta licencja pozwala wprost na *każdego* typu łączenie programu z biblioteką, czyli tworzenie "combined work" bez konieczności przedstawiania kodu programu (sekcja 3 LGPL). Przydatne w budowaniu firmwaru telefonu.
> żaden sąd chyba jeszcze tego nie rozpatrywał
"Ludzie uwierzą we wszystko co boją się, żeby było prawdą." – z tego też powodu nikt nie wywołuje Stallmana z lasu i logiczna interpretacja "derived work" de facto nie obowiązuje. Mało kto ma czas i pieniądze procesować się po sądach.
Tak obecnie GPL interpretuje FSF. Jednak po wydaniu wyroku w sprawie FSF vs Cisco to sie zmieni. FSF przestanie byc instytucja, ktora ma moc tworzaca interpretacje GPL. Wszystkie pozniejsze zawilosci dotyczace tej licencji beda sie opierac o wyrok sadowy, jesli sie uprawomocni.
Obecnie FSF w wielu przypadkach interpretuje GPL na swoja korzysc. Nie wiadomo jak skonczy sie w sadzie?
btw. Brak polskich znakow = uklad klawiatury Dvorak.
Fakty nie podlegają ochronie praw autorskich. Plik nagłówkowy tylko wskazuje na sposób wywołania danej funkcji. Inna sytuacja jest już z programem, gdyż program nie tylko opisuje zasadę działania, ale też nie może być bezpośrednio często wykonany w postaci zrozumiałej dla człowieka. Przerabianie więc programów niezgodnie z licencją jest więc czymś innym niż dynamiczne linkowanie, gdyż powstaje utwór wytworzony z cudzego utworu.
"If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL or a GPL-compatible license?
Yes, because the program as it is actually run includes the library."
@borizm: gdyby PostgreSQL był na GPL to Twój program łączący się do tej bazy przez sieć, używający jaj jako silnika DB nie musi być na GPL, bo wtedy program nie zawiera kodu bazy w sobie. W przypadku gdybyś pisał moduł do PGSQLa, lub zmodyfikował PGSQLa, lub użył fragmentów PGSQLa w swoim kodzie, wtedy Twój kod musi być na GPL. Łączenie się przez sieć, czy komunikacja przez PIPE nie wymusza stosowania licencji GPL.
LGPL znosi wymóg licencyjny, tylko wtedy gdy użyta biblioteka na tej licencji jest dołączona do programu w taki sposób, że użytkownik programu ma możliwość wymiany tej biblioteki w programie (oczywiście na swoje ryzyko).
BTW. Popieram przejście Qt na LGPL. Oznacza to znacznie większą popularyzację tej biblioteki, oraz porty dla tak ważnych bibliotek jak SWT czy wxWidgets. Jak dobrze pójdzie, to pisząc program w wx'ach będziemy mieli natywną wersję dla KDE/GNOME, Windy i Maka.
Ale jak używasz jakiegoś RDBMS'a na GPL i linkujesz się z jego bibliotekami na LGPL'u, to wszystko jest cacy – możesz tworzyć produkt komercyjny, póki nie wpadniesz na pomysł, że chcesz dystrybuować także ten RDBMS wraz ze swoim produktem, który nie jest GPL jako całość.
Wyżej pisałem o dostarczaniu całego produktu wraz z RDBMS'em na GPL – jak dostarczasz taki produkt i najmniejszy jego kawałek jest na GPL'u (nie ważne jest wyłącznie z czym się linkujesz, ale dodatkowo co dystrybujesz), to on cały (produkt) musi być na GPL'u.
@LM: Umknal ci jeden kluczowy element – otoz traktowanie jako "derived work" zlinkowanej dynamicznie calosci rosci sobie wylacznie Free Software Foundation. Nikt inny – nawet Microsoft – tego nie robi. Wiec w przypadku ogolnym wykorzystanie interfejsu nie ma zwiazku z licencja calosci; ma zwiazek – wedlug FSF – tylko w przypadku licencji GNU. Na tym wlasnie polega caly myk – _zadna_ (znana mi) inna licencja nie ma tego obostrzenia.
Inna sprawa, ze w przypadku samego GPL ta kwestia tez jest mocno dyskusyjna.
@LM twierdzisz wiec ze jest blad w licencji GPL czy tez ze autor programu nie ma prawa do definiowania licencji na ktorej publikuje program i jego kod wg swojego widzimisie?
jeśli korzysta z linkowania do bibliotek na GPL, nie ma widzimisie i nie może definiować licencji niezgodnej z GPL – tak stracił wolność definiowania licencji swojego programu ;]
@LM: Plik nagłówkowy nie podlega ochronie prawnoautorskiej i jest to nawet explicite zapisane w ustawie (Art. 74 p. 2): "Idee i zasady będące podstawą jakiegokolwiek elementu programu komputerowego, w tym podstawą łączy, nie podlegają ochronie." (podkr. moje) W innych krajach prawo jest podobne.
Moim zdaniem FSF stosuje inną interpretację prawa: otóż ta "derived work" jest tworzona w momencie uruchomienia programu, bo linker dynamiczny ładuje biblioteki w ten sam obszar adresowy co program. W tym momencie to co jest w pamięci stanowi kombinację programu i biblioteki i według tego rozumowania powinno być objęte GPL. Czyli zgodnie z tym program powinien być objęty GPL.
Moim zdaniem jest to naciągane z trzech powodów:
1. Połączenia programu i biblioteki dokonuje użytkownik końcowy. Jeśli ktoś ma licencję na program i na bibliotekę, to nic nikomu do tego co on z czym linkuje.
2. Całe rozumowanie bierze w łeb jeśli użyjemy RPC. Można nawet teoretycznie napisać linker który zamiast ładować bibliotekę w obszar pamięci programu będzie ją ładować gdzie indziej, a wywołania funkcji zastąpi wywołaniami RPC. I teraz co — programista ma odpowiadać za to, jakiego linkera użyje użytkownik? Absurd.
3. Gdyby faktycznie tak było jak mówi FSF, to na napisanie każdego programu na Windows trzeba by mieć pozwolenie Microsoftu, bo na Windows każdy program linkuje się z kernel32.dll. W ten sposób dochodzimy do absurdu.
Pytanie brzmi: czy można stawiać takie restrykcje, jakie stawia FSF, wobec czyjegoś, niezależnego programu, względem operacji jakie ta aplikacja (po uruchomieniu jej przez użytkownika) wykonuje na sprzęcie (systemie plików i rejestrach/stosie procesora) należącym do jej użytkownika?
Czy linkowanie do IO pamięci masowych, które przecież też realizują jakieś procedury stanowi "derived work"? A linkowanie do mikrokodu procesora?
Chętnie poznam jakieś argumenty przemawiające za tym, że linkowanie dynamiczne stanowi "derived work". Jak na razie znam tylko opinię FSF, która wydaje mi się mało sensowna.
@joi: Nie "jakiejś tam", tylko na licencji Windowsa. A teraz znajdź mi w EULA do XP coś o linkowaniu. Nie ma. Co więcej, nie ma nic o instalowaniu oprogramowania ani o jego tworzeniu (za wyj. wzmianki o WMFSDK). Wniosek: na Windows nie wolno uruchamiać żadnych programów nie wchodzących w jego skład :->
Dokładnie. Wniosek jest, owszem, ale odwrotny do tego przedstawionego przez krzy2. Wypadałoby znać trochę choćby podstawowe zasady prawne, zanim zabierasz się do wyrażania opinii o tekstach licencji ;>
W licencji producent programu zezwala Ci na to, czego ustawodawca wcześniej zabronił. Czyli aby licencja mogła regulować linkowanie, to ustawa musiałaby najpierw linkowania zabronić (ściślej: włączyć do zbioru autorskich praw wyłącznych), albo też linkowanie musiałoby podpadać pod jakiś inny przepis ustawy. Ale gdyby tak było, to wtedy w EULA Windowsa musiałby znaleźć się zapis zezwalający na linkowanie, bo inaczej nikt legalnie nie mógłby używać Windows do uruchamiania obcych programów!
Nie jestem wielkim specem od prawa autorskiego. Wydaje mi się jednak, że określenie "wszystkie prawa zastrzeżone" odnosi się do tego, iż autor zabrania wszystkiego, co tylko można, a nie zostało ujęte w licencji.
@krzy2: za przeproszeniem, pieprzysz bzdury. Licencje obejmują masę rzeczy o których w ustawie nie ma słowa. Ustawodawca zabrania kilku rzeczy i robi to "by default", czyli producent w ustawie może to uchylić (zapis "nie wolno bez zgody autora…"). Jedynymi granicami zapisów licencyjnych są explicite wyrażone w ustawie prawa użytkownika (np. do wykonania kopii zapasowej). A jeśli przez chwilę przyjmiemy twoje rozumowanie, to być może EULA Windows zabrania usuwania Windowsa z dysku? Bo przecież ustawa tego nie reguluje a w licencji nie ma 😀
@Sławek: faktycznie, do bycia specem masz jeszcze dalej ode mnie. "Prawa" nie są wymyślane same, są określone w przepisach. "Wszystkie prawa zastrzeżone" oznaczało, że twórca z żadnego z tych praw nie rezygnuje, czyli przyjmuje prawną ochronę dzieła. Zwrot o dokładnie takiej treści był określony jako warunek formalny. Był, bo teraz zamiast regułki wystarczy (c) – albo i nic, bo nie dam głowy czy dzieła nie są obejmowane ochroną z automatu, chyba, że twórca z jednego lub więcej praw wyraźnie zrezygnuje.
> Ustawodawca zabrania kilku rzeczy i robi to “by default”, czyli producent w ustawie [licencji – krzy2] może to uchylić
W tym rzecz. Teraz uważaj: _gdyby_ ustawodawca zabraniał linkowania, to Microsoft musiałby to w EULA uchylić. Ponieważ EULA Microsoftu nie zawiera zapisu uchylającego zakaz linkowania, to mamy dwie możliwości: albo ustawodawca linkowania nie zabronił, albo używanie obcych programów na Windows jest nielegalne. To drugie jest absurdalne, czyli pozostaje to pierwsze.
Ergo GPL nie może regulować linkowania bo nie ma podstawy prawnej.
> nie dam głowy czy dzieła nie są obejmowane ochroną z automatu
Konwencja berneńska. Obecnie wszystko jest obejmowane ochroną z automatu i żadne (c) nie jest potrzebne.
Ergo GPL nie może regulować linkowania bo nie ma podstawy prawnej
GPL nie może regulować linkowania bo EULA Windows nie reguluje? Interesujący argument. Od kiedy inne licencje to u nas podstawa prawna?
Cytujesz wybiórczo, dla wygody przypomnę:
Licencje obejmują masę rzeczy o których w ustawie nie ma słowa. (…) Jedynymi granicami zapisów licencyjnych są explicite wyrażone w ustawie prawa użytkownika (np. do wykonania kopii zapasowej).
Czy ta prosta zasada – co nie zabronione jest dozwolone, ergo może znaleźć się w licencji – dociera do ciebie?
@Thar: Pytanie kontrolne – zdajesz sobie oczywiscie sprawe, ze w samej licencji GPL o linkowaniu nie ma ani slowa? Cala sprawa rozbija sie o wzieta z sufitu RMS-a definicje 'derived work'.
Ale jeśli ja dając/sprzedając ci młotek, w licencji określam na jakich warunkach możesz wbijać gwoździe. Np. że wbite tym młotkiem gwoździe muszą być objęte tą samą licencją. I tyle.
@AdamK: Czyli użytkownik, uruchamiając zamkniętą aplikację, która dynamicznie linkuje do bibliotek na GPL będzie łamał tenże GPL?
Druga opcja: GPL biblioteki będzie nienaruszona ale będzie też przenoszona na zamkniętą aplikację – tak jak jest to postulowane. Jednak będzie sie to działo bez wiedzy i zgody twórców tej, zamkniętej aplikacji, z tego tylko powodu, że ktoś podsunął programowi bibliotekę na GPL zamiast na licencji FOOBAR?
Pierwszy przypadek skłania mnie do zastanowienia się nad ochroną wolności użytkownika do uruchamiania na swoim komputerze czego tylko chce. Drugi przypadek to w ogóle jakiś bezsens, ale bezsens do zrealizowania. Trzecia możliwość?
jedyny mozliwy kierunek to jest! Po premierze andoida i po tym jak to smiga chocby na freerunnerze w porownaniu z QtEx (nie ma wiekszych roznic z tego co widze). Sa dwie drogi: albo swiat podzieli sie na 2 (ms mobile i android) albo na 3 (+QtEx) – torcik dzieli sie wlasnie teraz i jesli Nokia to przespi to beda musieli przyznac ze niepotrzebnie sie pakowali w trolltech bo i tak beda uzywac andoid jesli QtEx sie nie przyjmie. Zupelnie inna sprawa jest to ze ms mobile pojdzie do piachu bo ms bedzie musialo zrezygnowac z licencji a jak powszechnie wiadomo z licencji zyja wiec klops (nokia sprzedaje telefony a google reklamy wiec moga sobie rozwijac co tylko im sie podoba i tak z tego zysku bezposrednio nie maja).
QtExtended na Symbiana? Otwiera? Nie opowiadaj głupot.
Qt Extended (czyli Qtopia po zmianie nazwy) to środowisko graficzne i serwer GSM przeznaczony na telefony komórkowe działające pod kontrolą Linuksa – kiedyś Greenphone Trolltecha, a teraz FreeRunner Openmoko. Qtopia od początku była otwarta.
Śmiem twierdzić ze te bindingi nie są najwyższych lotów. Wystarczy spojrzeć na takie arcydzieło jak kiwi, żeby się przekonać jak może wyglądać wzorcowy moduł dla gui 😉
kiwi – ta… żeby to ładnie udokumentowali i włączyli do PyGTK (pygmozembed chyba też dałoby radę dodać do wieloplatformowego PyGTK/GTK+, a nie trzymać w ogólnie unix-only gnome-python-extras). IMHO PyQt4 jest jednym z najlepszych Pythonowych API na biblioteki C/C++.
Riklaunim: Z całym szacunkiem dla Twej dobrej działalności:
W GTK+ raczej należy się spodziewać WebKit. Jedynym wspólnym mianownikiem Mozilli i GTK jest obecnie chyba tylko Cairo (abstrahując od widgetu). Kiwi jest wystarczająco udokumentowane. Myślę nawet, że jest to poziom odpowiadający dokumentacji Django.
Co do Qt to nadal mam zdanie takie jakie miałem. To, że coś jest duże i opisane nie znaczy, że ładne i funkcjonalne.
Nie ma żadnego haczyka. Dla dużych zamknięto-źródłowych projektów możliwość zmiany samej biblioteki może być cenna, do tego w wersji komercyjnej masz suport i jak ktoś wyżej zauważył dostęp do większej ilości sterownik do baz.
Samo dodanie licencji LGPL ma przyciągnąć większą liczbę programistów do platform w których Qt stanowi centralną cześć.
Nie potrafię powiedzieć dlaczego kontynuowana jest licencja GPL, skoro pojawi się LGPL, może ktoś inny zna odpowiedź.
Natomiast jeśli chodzi o różnice między komercyjną a LGPL: oprócz standardowego supportu, wersja komercyjna to dodatkowe możliwości generalnie potrzebne jedynie firmom (jak np. ww. sterowniki do komercyjnych baz danych).
Natomiast jest jeden ciekawy myk odnośnie LGPL: biblioteki kde są wydane właśnie na LGPL, co oznacza że od tej pory będzie możliwe budowanie zamkniętych aplikacji z ich pomocą. Do tej pory jeśli ktoś chciał stworzyć taki program na bibliotekach KDE, musiał i tak wykupić komercyjną licencję Trolltecha
Ja tam na ftpie mozilli nic takiego nie widze. Znalazłem natomiast to http://hg.mozilla.org/users/vladimir_mozilla.com/…
na qt3 nie 4 i last change Fri, 15 Aug 2008 09:31:55 +0300
no faktycznie prace wrą za jakieś 5 lat może alfa będzie ;]
Powiedzcie mi czy dobrze myślę, że stworzy to cały dział aplikacji freeware/shareware zbudowanych przy użyciu Qt dla Windows (bo programowanie przy użyciu WinAPI łatwe nie jest, a przynajmniej nie jest przyjemne), co po pewnym czasie spowoduje pojawianie się również ich wersji na *nixy.
IMHO wydaje mi się to prawdopodobne
nie potrzebuja "pewnych fragmentow wine", uzywaja libwine, tak jak kword uzywa qt. libwine jesli chodzi o api/widgety mozna porownac do qt/gtk, ale tak samo jak qt i tak samo jak framework gnome – nie ogranicza sie tylko do dostarczania api do gui.
GEarth nie potrzebuje wine jest w pełni natywne z Picasa się zgodzę korzysta z bibliotek wine, ale co to szkodzi? Biblioteka taka sama jak każda inna, no chyba, że miejsce komuś zajmuje.
mnie zastanawia czy to oznacza ze w darmowej wersji beda zamieszczone niektore przydatne rzeczy z wersji komercyjnej, jak na wtyczka qt-sql-oci umozliwiajaca laczenie z bazami danych oracle, czy zostanie zachowany dotychczasowy podzial?
I am impressed, I ought to say. Truly hardly ever before do I encounter a blog site that is certainly both educative and entertaining, and let me let you know, you’ve got hit the nail around the head. Your considered is outstanding; the issue is something that not ample people are chatting intelligently about. I’m really blissful that I stumbled throughout this in my look for 1 thing referring to this
Excellent post. I was checking constantly this blog and I’m impressed! Very helpful info particularly the last part 🙂 I care for such info much. I was looking for this certain information for a long time. Thank you and good luck.
You actually make it seem so easy with your presentation but I find this topic to be actually something which I think I would never understand. It seems too complex and very broad for me. I am looking forward for your next post, I will try to get the hang of it!
Thanks for your recommendations on this blog. One thing I would wish to say is that purchasing electronic devices items from the Internet is nothing new. In reality, in the past ten years alone, the marketplace for online electronic products has grown a great deal. Today, you will find practically just about any electronic device and devices on the Internet, including cameras plus camcorders to computer pieces and video games consoles.
Dodaj komentarz