Doszły mnie słuchy, że programiści chcą zrobić fork Qt z tego względu, że firma która tym projektem zarządza ma zamiar udostępniać bibliotekę tylko dla klientów komercyjnych.
Pytanie jest takie. Jeżeli powstanie fork, to czy kod będzie w 100% kompatybilny z tym co jest obecnie ?
0
2
- link do źródeł plotki
- Qt zawsze pilnowało wstecznej kopatybiności na poziomie binarnym i źródeł.
- Już teraz Qt ma podwójna licencję. Na część podstawowa LGPL/komercyjną i na rozszerzone części (np Qt Chart) GPL/komercyjną.
- Rozwój i sukces Qt w dużej części jest oparty na otwartość licencji
- Już teraz licencjobiorcy komercyjni, mogą liczyć na dłuższy okres wsparcia.
- Możliwe, że są planowane jakieś zmiany, oparte na obserwacji jak z takimi samymi zmianami poradził sobie Oracle z Java, ale wątpię by odpuścili GPL. Bardziej by stawiał na to, że kolejne rozszerzenia Qt będą miały bardziej komercyjny charakter, a nie że dostęp do istniejących modułów zostałby ograniczony.
1
Fork na początku to jest dokładna kopia pierwotnego projektu. Dopiero w dalszej kolejności oryginał jest rozwijany osobno, a fork osobno.
W takim razie, jeżeli oba projekty będą identyczne, łącznie z nazwami i przestrzeniami nazw, to kod będzie kompatybilny.
5
Qt nie może się zamknąć, bo wymagałoby to zgody KDE Free Qt Foundation, w którym nie mają większości. Obecna umowa nakłada na nich kilka obowiązków, m.in:
- nie mogą zamknąć istniejącego kodu
- co roku muszą udostępniać jeden nowy moduł na licencji LGPL
- jeśli złamią umowę cały kod Qt przechodzi do public domain albo licencji o zbliżonym efekcie.
0
Z tych linków (i tego od kq) wynika, że będzie komercyjni klienci będą mieli wyłączność na nowe wersje przez 12 miesięcy (żeby umowa z KDE nie została naruszona). Potem umowa z KDE wymusza, że wszystko musi trafić do licencji LGPL/GPL.
Gadanie o forku jest ciekawe, bo co miało by się znaleźć w tym forku. Wątpię by miało to dotyczyć głównej części Qt. Utrzymanie kosztowało by za wiele.
Zgaduje, raczej, że pojawią się jakieś moduły, które będą dostępne tylko w wersji płatnej pod inną nazwą (Kt), by formalnie nie naruszać umowy z KDE, a sprzedawać komercyjnie nowe produkty. Najważniejsze jest jak to się przełoży na prace nad istniejącymi modułami.
Samym projektom OpenSource to nie zagraża, bardziej ograniczy to dopływ nowych funkcjonalności w dobrej jakości. Stawiam na to, że pojawią się jakieś chałupnicze rozwiązania, by zrekompensować dopływ nowych funkcjonalności.
0
Największym problemem tego forka będzie to, że nie będzie wymuszał akceptacji podwójnej licencji przez autorów patchy więc nie będzie można żadnych poprawek przenosić z powrotem do Qt. IMO jeśli coś takiego by się wydarzyło to byłby gigantyczny strzał w stopę ze strony Qt. Ale to było ponad pół roku temu i na razie o niczym takim nie słyszałem.
2
kq napisał(a):
- co roku muszą udostępniać jeden nowy moduł na licencji LGPL
To akurat głupi warunek bo wymusza feature bloat ;D
0
kq napisał(a):
Qt nie może się zamknąć, bo wymagałoby to zgody KDE Free Qt Foundation, w którym nie mają większości. Obecna umowa nakłada na nich kilka obowiązków, m.in:
- nie mogą zamknąć istniejącego kodu
- co roku muszą udostępniać jeden nowy moduł na licencji LGPL
- jeśli złamią umowę cały kod Qt przechodzi do public domain albo licencji o zbliżonym efekcie.
Dobrze, że autor Qt jest w Europie. Gdyby byli to Amerykanie, spodziewałbym się po pazernych trollach batalii sądowej o zmianę tej sytuacji. Jeśli jakimś cudem Amerykanie kupią właściciela praw do Qt, spodziewam się, że będą szli w stronę trzepania jak największej kasy kosztem... w sumie wszystkiego.
0
Chciałbym odgrzać tego kotleta...
Pobrałem dzisiaj najnowsze wydanie Qt6 i wychodzi na to, że społeczność jednak zrobi hard fork bo w najnowszej wersji brakuje np QtWebEngine
co o tym myślicie ?
1
Po kiego grzyba robić forka, bo czegoś brakuje?
To tworzy niepotrzebne problemy.
Jak czegoś brakuje, to się tworzy swoją bibliotekę.
Jedyna przyczyna jaka przychodzi mi do głowy to, która by to uzasadniała, to nowy feature wymaga zamian w starym kodzie.
Biorąc pod uwagę, że chodzi o QtWebEngine, to nie wydaje mi się, że tu występuje taka sytuacja.
0
wiem, że rozdrobnienie nie przyczynia się do poprawy sytuacji w open source (patrz linux) im więcej gównobibliotek i rozdrobnienia, tym gorzej i powstaje zamieszanie, a konkurencja nie śpi...
1
zkubinski napisał(a):
Chciałbym odgrzać tego kotleta...
Pobrałem dzisiaj najnowsze wydanie Qt6 i wychodzi na to, że społeczność jednak zrobi
hard forkbo w najnowszej wersji brakuje npQtWebEngine
co o tym myślicie ?
Że nigdy go nie użyłem, ale też nie wyszedłem w Qt z etapu hello worldów ;)
Był okres kiedy namiętnie kompilowałem kolejne wersje Qt bo coś mi nie pasowało w oficjalnych buildach (chyba brakowało 32-bitowego buildu pod konkretną wersję Visual Studio… czy coś tego typu) i ten web engine był zawsze udręką w skompilowaniu. Łatwiej było go po prostu pominąć.
0
zkubinski napisał(a):
Chciałbym odgrzać tego kotleta...
Pobrałem dzisiaj najnowsze wydanie Qt6 i wychodzi na to, że społeczność jednak zrobi
hard forkbo w najnowszej wersji brakuje npQtWebEngineco o tym myślicie ?
Po pierwsze jak byś poczytał to byś wiedział że qt 6.0 to de facto okrojony relase. W kolejnych wersjach będą dodawane kolejne funkcjonalności.
Z resztą, te całe silniki qtwebkit kiedyś czy qwebengine to potężny problem, nie zdajesz sobie sprawę szczególnie na platformach wbudowanych jaki qtwebkit a teraz webengine to problem. Dlatego że często qtwebkit czy engine był związany z konkretną wersją(grupą wersji) qt. I dostajesz(a dostałem takowego na jednej platformie wbudowanej) strzała. Są na qtwebkit/qwebengine po prostu bugi czy problemy z wydajnością. I taki update na platformie wbudowanej to nie nie musi być łatwa sprawa(eglfs, i inne zmiany w interfejsach). I ucieszyłbym się jak by to z qt wyleciało, albo po prostu nie polecam tego używać. Chyba że to ma być platforma w stylu sprzedać zrobić platformę raz i sprzedać.
Trzy nie wiem skąd masz jakieś pomysły ba na temat forka. Jedyne deklaracje jakie były w sprawie forka, to te z powodu kiedyś planowanych zmian licencyjnych o których na razie cisza. Także to co napisałeś nie ma sensu.
Podsumowując 6.0 należy traktować jak bete, z resztą patrząc na pierwsze wersje qt5 pod spodem to oni niech skupią się na refctoringu i poprawie błędów.