Re: Qt, Open Source and corona
On Tuesday, 14 April 2020 06:01:47 CEST Nicolás Alvarez wrote: > I agree it's possible that "we're thinking about restricting ALL Qt > releases to paid license holders for the first 12 months" was just to > force our hand and make us give them other concessions, and that > they're not actually planning to do it. > > But that's what the fork discussion is about. As Nate said, "we are > thinking of forking Qt" and having credible ability to do so, might > force *their* hand and make them take a step back. If then > negotiations go well, we don't need to actually fork. *Worst* case, > negotiations don't go well, and we have a head start on the forking > work. I completely agree with this. Both "we will restrict releases for 12 months" and "we will fork Qt" are terrible decisions. But, I am in fact convinced that a potential KDE/KDAB/...-backed fork would quickly gain a *lot* of users and also contributors. I expect TQtC knows this as well. Planning how this fork could work out and saying "ok, if you do this, we do that" puts us in a position of power in this conflict, which makes it an important thing to do. Best, Sven
Re: Qt, Open Source and corona
El jue., 9 de abr. de 2020 a la(s) 09:01, Florian Bruhin (m...@the-compiler.org) escribió: > One possible reading of Olaf's original mail is that TQtC simply was bluffing > in order to force "negotiations" about some other part of the agreement they > don't like: > > The Qt Company says that they are willing to reconsider the approach only if > we offer them concessions in other areas. > > Indeed, they now released a (very brief) announcement[2] claiming that they, > apparently, never meant things that way: > > There have been discussions on various internet forums about the future of > Qt > open source in the last two days. The contents do not reflect the views or > plans of The Qt Company. > > The Qt Company is proud to be committed to its customers, open source, and > the Qt governance model. > > Needless to say, after more and more moves against the open-source side of Qt > recently, I place a lot more trust in statements coming from KDE rather than > those coming from TQtC... I agree it's possible that "we're thinking about restricting ALL Qt releases to paid license holders for the first 12 months" was just to force our hand and make us give them other concessions, and that they're not actually planning to do it. But that's what the fork discussion is about. As Nate said, "we are thinking of forking Qt" and having credible ability to do so, might force *their* hand and make them take a step back. If then negotiations go well, we don't need to actually fork. *Worst* case, negotiations don't go well, and we have a head start on the forking work. -- Nicolás
Re: Qt, Open Source and corona
Hopefully this email is put in the chain as intended, if not, my apologies. On Thu Apr 9 10:01:48 BST 2020 Boudewijn Rempt wrote: > * There needs to be a mailing list or two > * There needs to be a system like gerrit or gitlab to host development > * There needs to be CI -- the Qt project has its own thing for that, COIN. > * There needs to be a website > * There needs to be a committee or a way of making decisions: what to keep, > what to drop, how to handle relations with the Qt company, how to release, > whether Qt6 still makes sense, or whether Qt5 should be developed for the > next decade... The last point in particular is something I'm not seeing mentioned as much here. Part of the reason for using Qt is not just for the flexibility of its GUI system, but the underlying stack framework it provides. That, paired with the fact that it works reasonably well on the major platforms it supports, e.g. Windows, macOS, and Linux for the desktop space, makes it a very useful tool for creating consistently behaving cross platform applications. The discussions I've seen so far, and that's probably due to the user base here, seem to be focused on just the KDE and Linux community's needs. However, in the situation of a fork, would the community be willing to support the other platforms? Paul posted a bit of what I was talking to him about (thanks for that!), but I would like to expand upon it further. In our industry (feature VFX and animation) Qt has a significant role in the tools we make. Autodesk uses it for Maya and 3DS Max; Foundry uses it for Nuke, Mari, Katana, and I think they're transitioning Modo to it; SideFX uses it for Houdini; pretty much every in-house studio tool with a GUI is Qt based (or otherwise written in OpenGL), and a myriad of other products use Qt. Marcus Ottosson authored Qt.py[0], which is a "Minimal Python 2 & 3 shim around all Qt bindings - PySide, PySide2, PyQt4 and PyQt5" which has been helpful with transitions in our industry in accordance with our VFX Reference Platform[1]. Autodesk releases the source code for Qt and any of their modifications. Based on the Houdini docs[2], SideFX seems to be using the LGPL variant of Qt, though their built header files distributed have the commercial/LGPL/GPL statements in them (same with Autodesk). I'm not super familiar with building Qt itself as I'm not a dev so I don't know if that's to be expected. And as an industry we typically stick to LTS releases, which is going to be changing for the free edition of Qt with 5.15... When I heard about the forking possibility, here's what ran through my head first: What kind of impact would a fork have on the ecosystem community if there is a significant divergence from the commercial offering? Would the community be up for maintaining their own Qt for Python (or other language) bindings and documentation? What about groups that write plugin tools for other host applications that use the commercial offering but also have their own open-source standalone application? What impact will this have on the agreement between the KDE Foundation and the Qt Company? What resources do we actually have to support the huge multi-platform offering that is Qt? There are a lot of questions that a fork opens up and not a lot of answers right now as it's all unknown. I think laying out a plan for a potential community fork is a smart move considering the Qt Company's recent behavior, even if a fork is the least desirable option. However, I think determining fundamental resources, specifically developers willing to partake in this venture is the first step that needs to happen. Then working on the base goals of the project with those resources in mind to decide what is feasible and a priority to support. Determining CI/hosting/naming, to me, are more after-the-fact details that do matter but don't accomplish or mean much unless the previous points are solved. Hopefully this all makes some form of sense :) Cheers, Mike [0] https://www.github.com/mottosso/Qt.py [1] https://vfxplatform.com [2] https://www.sidefx.com/docs/houdini/licenses/index.html
Re: Qt, Open Source and corona
On Fri, Apr 10, 2020 at 4:10 PM Ivan Čukić wrote: > > > want use KDE as the "open version of Qt" shop then we should probably > > first look at the number of fixes to upstream actually made through > > KDE mirrors directly. I.e. count how many people use KDE repos to > > I think I agree with your sentiment, but: > > Not sure what you meant here - patches can not go from KDE mirror to Qt > directly: > - CLA > - It is a mirror - all development is done in Qt's GIT repository. > I probably expressed myself poorly there. :) FWIW: the first idea I had was to simply count the activity of private "qt" repositories on invent.kde.org which kind of presupposes that people use invent.kde.org as a convenient backup of their local work as well (kind of the default Gitlab/Github mindset). That might not hold, especially not if people have 'direct' committer access to repos hosted by the Qt project itself. The main thing is that before deciding to jump in we should probably first figure out how many contributions and how many contributors we can currently sustain and then re-asses our options. Regards, - Johan
Re: Qt, Open Source and corona
Am 2020-04-10 18:25, schrieb Philippe Cloutier: Hi Sebastian, thanks everyone for your contribution to discussion on this important albeit unfortunate topic, Let's discuss a name if and only if we decide to fork. Thank you for not needlessly derail this discussion. Kind regards Martin Flöser
Re: Qt, Open Source and corona
Hi Sebastian, thanks everyone for your contribution to discussion on this important albeit unfortunate topic, Le 2020-04-09 à 10:06, Sebastian Kügler a écrit : On donderdag 9 april 2020 15:29:22 CEST Noah Davis wrote: I've seen a lot of people on Reddit and various chat rooms who are a fan of Kt as a name. I'd advise against this discussion at this point, it doesn't belong here, it's a topic that can quickly explode, lead to bike-shedding and distracts from the very serious topic of "what is a good strategy to move forward in this situation?". Let's not throw the baby out with the bathwater. I don't see how discussing a name throws anything out. Coming from a Debian background, I know from the Iceweasel debacle that forks do not have to be seen as pure waste and can lead to great results. Unless the situation is less bad than it seemed in Olaf's report, I don't find it too early to discuss a name. In fact, if there is concern about distraction, finding a name early can be strategic to facilitate creating dedicated infrastructure. Until a dedicated forum is created, I do not see what forum other than this one would be better for such a discussion. Of course, in no way does that prevent usual discussion hygiene - if a reply in a thread which has reached this one's size focuses on naming, better adjust the Subject to reflect that. As for Noah's suggestion, thanks Noah, I find the name interesting. I find it short though. It's great if "KT" is not a popular acronym, but 2-letter names unavoidably remain quite ambiguous, and even search engines themselves may ignore 2-letter words. As a prominent example, MySQL FULLTEXT requires 3 or 4 by default: https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_ft_min_word_len https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_ft_min_token_size [...] Sincerely hoping to see this discussion remain nothing more than a not-so-Qt discussion, -- Philippe Cloutier http://www.philippecloutier.com
Re: Qt, Open Source and corona
> want use KDE as the "open version of Qt" shop then we should probably > first look at the number of fixes to upstream actually made through > KDE mirrors directly. I.e. count how many people use KDE repos to I think I agree with your sentiment, but: Not sure what you meant here - patches can not go from KDE mirror to Qt directly: - CLA - It is a mirror - all development is done in Qt's GIT repository. Cheers, Ivan -- dr Ivan Čukić i...@cukic.co, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
Re: Qt, Open Source and corona
On vrijdag 10 april 2020 15:41:39 CEST Johan Ouwerkerk wrote: > On Thu, Apr 9, 2020 at 9:04 PM Jens wrote: > > > > I can’t make any calls since the work isn’t on my shoulders but if the Qt > > company are ready to pull this stunt AND then lie about it in the vaguest > > most awkward way of saying “KDE and Qt Free are lying” they will do this > > again and forking, even though Qt Company cowered out now, might be better > > in the long run. > > > > I think forking is premature. The existing FOSS releases of Qt are not > going away just yet. Negotiations are still ongoing and have not yet > broken down irretrievably. > Sure, but figuring out what would need to be done, who it could be done with, and what would need to be in place would be the smart thing to do. Being prepared is always good. -- https://www.krita.org
Re: Qt, Open Source and corona
On Thu, Apr 9, 2020 at 9:04 PM Jens wrote: > > I can’t make any calls since the work isn’t on my shoulders but if the Qt > company are ready to pull this stunt AND then lie about it in the vaguest > most awkward way of saying “KDE and Qt Free are lying” they will do this > again and forking, even though Qt Company cowered out now, might be better in > the long run. > I think forking is premature. The existing FOSS releases of Qt are not going away just yet. Negotiations are still ongoing and have not yet broken down irretrievably. While there's plenty of stakeholders we could enumerate (and not just companies like e.g. Bosch, think government as well), if we really want use KDE as the "open version of Qt" shop then we should probably first look at the number of fixes to upstream actually made through KDE mirrors directly. I.e. count how many people use KDE repos to develop Qt and then push for upstreaming their work (and encourage people and other partners to do so as well). Because ultimately the real work is not a mailing list, hosting or even CI: it is about keeping the project moving forward with new graphical stacks/technologies, OSes, form-factors, C++ standards and bindings, and for that reason alone it is better to know that you can actually pull it off before creating another Copperspice. That is not trivial, and even *many* fixes don't compare to a full time job of keeping the platform relevant and up to date. Regards, -Johan
Re: Qt, Open Source and corona
It's important to differentiate things we know and things we don't know, especially in situations that invite speculation. What we do know: - There's a contract. It's a vital document that has served everyone well for a long time. - Parties to a contract can change in all sorts of ways over time, but contracts remain binding. - There's a body maintaining that contract. - Contracts can be improved. That's not a small thing! Cheers, Eike - KDE e.V. Vice President April 9, 2020 9:04 PM, "Jens" wrote: > I can’t make any calls since the work isn’t on my shoulders but if the Qt > company are ready to pull > this stunt AND then lie about it in the vaguest most awkward way of saying > “KDE and Qt Free are > lying” they will do this again and forking, even though Qt Company cowered > out now, might be better > in the long run. > > Again since I wouldn’t be pulling the load this should be treated as “random > dude talking”. > > Sent from Phone, hence short mail > >> On 9 Apr 2020, at 16:27, Eike Hein wrote: >> >>> Let's not throw the baby out with the bathwater. >> >> This is very true. >> >> The KFQF with all representatives remains actively >> working on the issues with the same mission state- >> ment, too. >> >> Cheers, >> Eike >> - >> KDE e.V. Vice President Best regards, Eike Hein - KDE e.V. vice president, treasurer
Re: Qt, Open Source and corona
I can’t make any calls since the work isn’t on my shoulders but if the Qt company are ready to pull this stunt AND then lie about it in the vaguest most awkward way of saying “KDE and Qt Free are lying” they will do this again and forking, even though Qt Company cowered out now, might be better in the long run. Again since I wouldn’t be pulling the load this should be treated as “random dude talking”. Sent from Phone, hence short mail > On 9 Apr 2020, at 16:27, Eike Hein wrote: > > >> >> Let's not throw the baby out with the bathwater. > > This is very true. > > The KFQF with all representatives remains actively > working on the issues with the same mission state- > ment, too. > > > Cheers, > Eike > - > KDE e.V. Vice President
Re: Qt, Open Source and corona
> Let's not throw the baby out with the bathwater. This is very true. The KFQF with all representatives remains actively working on the issues with the same mission state- ment, too. Cheers, Eike - KDE e.V. Vice President
Re: Qt, Open Source and corona
On donderdag 9 april 2020 15:29:22 CEST Noah Davis wrote: > I've seen a lot of people on Reddit and various chat rooms who are a > fan of Kt as a name. I'd advise against this discussion at this point, it doesn't belong here, it's a topic that can quickly explode, lead to bike-shedding and distracts from the very serious topic of "what is a good strategy to move forward in this situation?". Let's not throw the baby out with the bathwater. I certainly didn't want to start such a discussion, just answer a question that tries to draw a line between "what is the part of Qt that can be taken into a fork, and what is not?", the trademark (just like infrastructure and quite a few other things) are owned by Qt, not freely licensed and thus outside of the scope of a fork (so would require investing resources to replace). -- sebas http://vizZzion.org
Re: Qt, Open Source and corona
I've seen a lot of people on Reddit and various chat rooms who are a fan of Kt as a name. - It fits well in a square, which makes it great for logos. - It's unusual, but not weird looking. - It looks kind of like an element on a periodic table. - In Google and DuckDuckGo searches for "kt", most things on the first page were pretty obscure and unrelated to software. - kT is used in a lot of plasma parameters. - The K-T extinction event was the end of a previous era and the beginning of our era. - Kt is tool kit backwards. - Katie could become the mascot for Kt. On Thu, Apr 9, 2020 at 8:55 AM Sebastian Kügler wrote: > > On donderdag 9 april 2020 14:12:36 CEST Clemens Toennies wrote: > > On Apr 9, 2020 11:34, "Jens" wrote: > > > > Hosting of the website also wouldn't be an issue (and if it ends up > > > > being high traffic, as long as the content is cacheable we can rely on > > > > Cloudflare). People would need to step up to write the content and > > > > produce any necessary graphics though :) > [...] > > > "I will happily make graphics" > > > > Regarding website/domain/url/graphics: > > What potential names would be allowed? > > Is anything with "Qt" in it legal or would everything need to be renamed? > > https://www.qt.io/trademark/ > > Qt's trademark policy is unsurprisingly strict, and it seems well managed on > top of that. A fork of Qt has to be make a clear distinction in its name, and > "anything with Qt in it" will be as misleading as marketing your os as "The > Windows Alternative". > > A fork of Qt would need a new name and its own branding. > -- > sebas > > http://www.kde.org | http://vizZzion.org > >
Re: Qt, Open Source and corona
On donderdag 9 april 2020 14:12:36 CEST Clemens Toennies wrote: > On Apr 9, 2020 11:34, "Jens" wrote: > > > Hosting of the website also wouldn't be an issue (and if it ends up > > > being high traffic, as long as the content is cacheable we can rely on > > > Cloudflare). People would need to step up to write the content and > > > produce any necessary graphics though :) [...] > > "I will happily make graphics" > > Regarding website/domain/url/graphics: > What potential names would be allowed? > Is anything with "Qt" in it legal or would everything need to be renamed? https://www.qt.io/trademark/ Qt's trademark policy is unsurprisingly strict, and it seems well managed on top of that. A fork of Qt has to be make a clear distinction in its name, and "anything with Qt in it" will be as misleading as marketing your os as "The Windows Alternative". A fork of Qt would need a new name and its own branding. -- sebas http://www.kde.org | http://vizZzion.org
Re: Qt, Open Source and corona
On 09.04.2020 10:57, Boudewijn Rempt wrote: On donderdag 9 april 2020 10:19:00 CEST Paul Brown wrote: To further this list, a friend in the VFX industry pointed out that all these non-KDE projects use the Free version of Qt (thanks Mike): * Appleseed: https://appleseedhq.net/ --- https://github.com/appleseedhq/ appleseed * Gaffer (by Image Engine): https://gafferhq.org/ --- https://github.com/ gafferHQ/gaffer * Olive Editor: https://olivevideoeditor.org/ --- https://github.com/olive-editor/olive * OpenCue (Python): https://www.opencue.io/ -- https://github.com/ AcademySoftwareFoundation/OpenCue * Autodesk Maya-USD: https://github.com/autodesk/maya-usd ... and from Pixar: * Pixar USD (Python): https://graphics.pixar.com/usd/docs/index.html --- https://github.com/PixarAnimationStudios/usd * Pixar OpenTimelineIO (Python): http://opentimeline.io/ --- https:// github.com/PixarAnimationStudios/opentimelineio The Foundry also uses Qt for its insanely expensive Mari application. + about the whole -except Phosh- of "Linux on Mobile" ecosystems depend on Qt: - Plasma Mobile - Unity 8 (UBPorts) - Luna Next (LuneOS) - Glacier - Sailfish - Asteroid It's a pity that all this happens at the same time that PinePhone has made the Linux smartphone dream come true.
Re: Qt, Open Source and corona
On Apr 9, 2020 11:34, "Jens" wrote: > > > Hosting of the website also wouldn't be an issue (and if it ends up > > being high traffic, as long as the content is cacheable we can rely on > > Cloudflare). People would need to step up to write the content and > > produce any necessary graphics though :) > > > > Graphics? > > ... you have my bow / I volonteer as tribute / and other references that mean > "I will happily make graphics" Regarding website/domain/url/graphics: What potential names would be allowed? Is anything with "Qt" in it legal or would everything need to be renamed? Greetings, Clemens.
Re: Qt, Open Source and corona
Hi, (Apologies for not answering to the original mail in this thread, I only subscribed after it was sent and can't find a Message-ID in the web archives.) As the maintainer of a web browser[1] using QtWebEngine, I find this deeply concerning. A year delay in security updates would be unacceptable for my project (and I suspect KDE Falkon as well), so, realistically I'd need to take a decision between: a) Switching to something different like Chromium Embedded Framework, which means months of work on top of an ever-growing backlog; b) Buying a Qt Startup License with all that it entails (probably including qutebrowser not being a proper FOSS project anymore), which is pretty much not an option given the licensing terms; c) Throwing the towel after 6.5 years (which also means losing a donation-funded part-time job, not to mention abandoning a project and community which is of immense importance to me personally). Needless to say, that wouldn't be a decision I want to make, and this announcement from KDE really wasn't an easy thing to digest. One possible reading of Olaf's original mail is that TQtC simply was bluffing in order to force "negotiations" about some other part of the agreement they don't like: The Qt Company says that they are willing to reconsider the approach only if we offer them concessions in other areas. Indeed, they now released a (very brief) announcement[2] claiming that they, apparently, never meant things that way: There have been discussions on various internet forums about the future of Qt open source in the last two days. The contents do not reflect the views or plans of The Qt Company. The Qt Company is proud to be committed to its customers, open source, and the Qt governance model. Needless to say, after more and more moves against the open-source side of Qt recently, I place a lot more trust in statements coming from KDE rather than those coming from TQtC... Still, their announcement seems to claim that they have not made the statements (or at least, don't commit to them) as quoted in Olaf's original mail. Could someone from the KDE Free Qt Foundation please clarify? Some quick thoughts regarding forks: I do not think a community fork of QtWebEngine would be realistic in any sense. As far as I remember, in a Qt talk it was mentioned that it takes around two man-months to rebase their APIs on top of a new Chromium release (which often means *millions* of changed lines, in the subset of Chromium code QtWebEngine imports!). However, I suppose most projects could somehow live with the delay, even if inconvenient (as they're not using QtWebEngine to display untrusted web content). Thanks for all the work you do - this is yet another example showing how important it is. (Note: I plan to send a similar mail to the Qt Interest list. I hope it won't attract too many trolls, and will instead result in the Qt Company clarifying their position on this whole thing. Wish me luck...) Florian [1] https://qutebrowser.org/ [2] https://www.qt.io/blog/qt-and-open-source -- m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ signature.asc Description: PGP signature
Re: Qt, Open Source and corona
On donderdag 9 april 2020 11:31:52 CEST Ben Cooksley wrote: > Gerrit on the other hand is a completely different matter - it doesn't > even know how to send email properly... I guess a community fork of Qt can work just as well with gitlab :-) > CI for Qt sounds like Pandora's box though, and a complete nightmare - > that is the hard one in that list (whether you would want to use their > system is another matter, given the number of severe regressions it > hasn't caught in the past few releases) Yes... -- https://www.krita.org
Re: Qt, Open Source and corona
Am 08.04.20 um 20:03 schrieb Nate Graham: > On 4/8/20 9:32 AM, Christoph Cullmann wrote: >> On 2020-04-08 15:39, Boudewijn Rempt wrote: >>> On woensdag 8 april 2020 13:13:41 CEST Jens wrote: > It's heartening that KDAB has already indicated willingness to support > such a thing should it become necessary. Are there other Qt-using > companies who we could reach out to? Maybe also linux distro packagers? There are many small companies with a few crafters building Qt apps for all kind of devices. I can imagine that many of them would be willing to contribute small pieces as well if that would be a benefit for them. Even if they can not use Qt under a free license, a benefit could also be things like a vibrant developer community, blogs etc. that are strongly Qt related. Needed for that would be some kind of community management for this kind of community. I am, tbh, not sure if the KDE is the right organization to do that, maybe that is something that should go on a parallel track initiated through KDAB & friends? If so (and probably there are already thoughts), this should go hand in hand with the KDE initiatives to build a strong ecosystem. > Perhaps the KDE e.V. could look into hiring people to help maintain the > fork, given the importance of Qt's code to our software. Well yes, all in all this is a huge task. It will be hard to keep a free Qt fork the leading technology without a paid developer group. I myself, with my own fork experiences, very much hope that all this can still be avoided. Klaas
Re: Qt, Open Source and corona
> Hosting of the website also wouldn't be an issue (and if it ends up > being high traffic, as long as the content is cacheable we can rely on > Cloudflare). People would need to step up to write the content and > produce any necessary graphics though :) > Graphics? ... you have my bow / I volonteer as tribute / and other references that mean "I will happily make graphics" /Jens
Re: Qt, Open Source and corona
On Thu, Apr 9, 2020 at 9:02 PM Boudewijn Rempt wrote: > > On woensdag 8 april 2020 23:20:34 CEST Jens wrote: > > > > > Is there any vague calculations concerning the work that would be needed > > being > > done? > > > > * There needs to be a mailing list or two > * There needs to be a system like gerrit or gitlab to host development > * There needs to be CI -- the Qt project has its own thing for that, COIN. > * There needs to be a website > * There needs to be a committee or a way of making decisions: what to keep, > what to drop, how to handle relations with the Qt company, how to release, > whether Qt6 still makes sense, or whether Qt5 should be developed for the > next decade... > > From what I see, gerrit and coin are using serious amounts of sysadmin time, > and that needs money. Creating a decision-making process is going to be the > hardest thing. I'm guessing that hosting another couple of mailing lists and > having Qt on KDE's download mirror network isn't going to be a problem. We > already mirror Qt's git repos. > > (Of course, I might have forgotten some things...) > I can confirm that the cost of hosting additional mailing lists would be insignificant (as long as the new lists follow KDE policies surrounding how email is handled). The same also applies for hosting source code tarballs and binaries on our mirror networks. I suspect you could probably adjust Craft relatively easily enough to produce installers for binary distribution of Qt should someone be inclined to do so, at which point you can leverage our existing Binary Factory without too much issue (we plan to add capacity to this anyway as part of the move to Gitlab and KDE switching from Jenkins to Gitlab CI) Hosting of the website also wouldn't be an issue (and if it ends up being high traffic, as long as the content is cacheable we can rely on Cloudflare). People would need to step up to write the content and produce any necessary graphics though :) The same can be said for Git repositories, as long as they use our Gitlab instance to do it (as hosting additional repositories on it represents practically no additional cost aside from the resources utilised by them, and storage is cheap these days) Gerrit on the other hand is a completely different matter - it doesn't even know how to send email properly... CI for Qt sounds like Pandora's box though, and a complete nightmare - that is the hard one in that list (whether you would want to use their system is another matter, given the number of severe regressions it hasn't caught in the past few releases) > -- > https://www.krita.org > > Cheers, Ben
Re: Qt, Open Source and corona
On woensdag 8 april 2020 23:20:34 CEST Jens wrote: > > Is there any vague calculations concerning the work that would be needed > being > done? > * There needs to be a mailing list or two * There needs to be a system like gerrit or gitlab to host development * There needs to be CI -- the Qt project has its own thing for that, COIN. * There needs to be a website * There needs to be a committee or a way of making decisions: what to keep, what to drop, how to handle relations with the Qt company, how to release, whether Qt6 still makes sense, or whether Qt5 should be developed for the next decade... >From what I see, gerrit and coin are using serious amounts of sysadmin time, >and that needs money. Creating a decision-making process is going to be the >hardest thing. I'm guessing that hosting another couple of mailing lists and >having Qt on KDE's download mirror network isn't going to be a problem. We >already mirror Qt's git repos. (Of course, I might have forgotten some things...) -- https://www.krita.org
Re: Qt, Open Source and corona
On donderdag 9 april 2020 10:19:00 CEST Paul Brown wrote: > To further this list, a friend in the VFX industry pointed out that all > these > non-KDE projects use the Free version of Qt (thanks Mike): > > * Appleseed: https://appleseedhq.net/ --- https://github.com/appleseedhq/ > appleseed > * Gaffer (by Image Engine): https://gafferhq.org/ --- https://github.com/ > gafferHQ/gaffer > * Olive Editor: https://olivevideoeditor.org/ --- > https://github.com/olive-editor/olive > * OpenCue (Python): https://www.opencue.io/ -- https://github.com/ > AcademySoftwareFoundation/OpenCue > * Autodesk Maya-USD: https://github.com/autodesk/maya-usd > > ... and from Pixar: > > * Pixar USD (Python): https://graphics.pixar.com/usd/docs/index.html --- > https://github.com/PixarAnimationStudios/usd > * Pixar OpenTimelineIO (Python): http://opentimeline.io/ --- https:// > github.com/PixarAnimationStudios/opentimelineio > The Foundry also uses Qt for its insanely expensive Mari application. -- https://www.krita.org
Re: Qt, Open Source and corona
On miércoles, 8 de abril de 2020 23:20:34 (CEST) Jens wrote: > On onsdag 8 april 2020 kl. 20:11:47 CEST Paul Brown wrote: > > On miércoles, 8 de abril de 2020 20:03:37 (CEST) Nate Graham wrote: > > > On 4/8/20 9:32 AM, Christoph Cullmann wrote: > > > > On 2020-04-08 15:39, Boudewijn Rempt wrote: > > > >> On woensdag 8 april 2020 13:13:41 CEST Jens wrote: > > > >>> The issue is for KDE is that we can't prepare ourselves. We can't > > > >>> fork Qt, > > > >>> because we lack the manpower to safely do so currently. > > > >> > > > >> But if we work together with other participants in the Qt community, > > > >> then it might be feasible. In fact, I think it's necessary to start > > > >> bringing together a group of stakeholders and start preparing for a > > > >> fork. > > > > > > > > Actually, at least as the last possible option, if any further > > > > cooperation breaks down, I agree with this. > > > > > > I strongly agree. I think the sooner we demonstrate that we are capable > > > of credibly maintaining a fork with other stakeholders in the FOSS Qt > > > ecosystem, the stronger of a bargaining chip it will be in our > > > negotiations with TQtC, so we don't have to. And in case the > > > negotiations break down and we are forced to move forward with the fork, > > > our prior preparation will ensure continuity so we won't have to > > > scramble at the last minute. > > > > > > It's heartening that KDAB has already indicated willingness to support > > > such a thing should it become necessary. Are there other Qt-using > > > companies who we could reach out to? > > > > * Autodesk: > > https://www.autodesk.com/company/legal-notices-trademarks/open-source-dist > > r > > ibution > > > > * MBition (Daimler/Mercedes company -- Eike may be able to give mor > > information that). > > VLC? I mean its not a large company exactly but its Qt, it's ballsy and > would probably be pro a fork. > To further this list, a friend in the VFX industry pointed out that all these non-KDE projects use the Free version of Qt (thanks Mike): * Appleseed: https://appleseedhq.net/ --- https://github.com/appleseedhq/ appleseed * Gaffer (by Image Engine): https://gafferhq.org/ --- https://github.com/ gafferHQ/gaffer * Olive Editor: https://olivevideoeditor.org/ --- https://github.com/olive-editor/olive * OpenCue (Python): https://www.opencue.io/ -- https://github.com/ AcademySoftwareFoundation/OpenCue * Autodesk Maya-USD: https://github.com/autodesk/maya-usd ... and from Pixar: * Pixar USD (Python): https://graphics.pixar.com/usd/docs/index.html --- https://github.com/PixarAnimationStudios/usd * Pixar OpenTimelineIO (Python): http://opentimeline.io/ --- https:// github.com/PixarAnimationStudios/opentimelineio Some are community-originated and others are company-originated projects, but, either way, my guess is that they would all prefer things remained the way they were. Cheers Paul -- Promotion & Communication www: http://kde.org Mastodon: https://mastodon.technology/@kde Facebook: https://www.facebook.com/kde/ Twitter: https://twitter.com/kdecommunity LinkedIn: https://www.linkedin.com/company/kde
Re: Qt, Open Source and corona
On onsdag 8 april 2020 kl. 20:11:47 CEST Paul Brown wrote: > On miércoles, 8 de abril de 2020 20:03:37 (CEST) Nate Graham wrote: > > On 4/8/20 9:32 AM, Christoph Cullmann wrote: > > > On 2020-04-08 15:39, Boudewijn Rempt wrote: > > >> On woensdag 8 april 2020 13:13:41 CEST Jens wrote: > > >>> The issue is for KDE is that we can't prepare ourselves. We can't > > >>> fork Qt, > > >>> because we lack the manpower to safely do so currently. > > >> > > >> But if we work together with other participants in the Qt community, > > >> then it might be feasible. In fact, I think it's necessary to start > > >> bringing together a group of stakeholders and start preparing for a > > >> fork. > > > > > > Actually, at least as the last possible option, if any further > > > cooperation breaks down, I agree with this. > > > > I strongly agree. I think the sooner we demonstrate that we are capable > > of credibly maintaining a fork with other stakeholders in the FOSS Qt > > ecosystem, the stronger of a bargaining chip it will be in our > > negotiations with TQtC, so we don't have to. And in case the > > negotiations break down and we are forced to move forward with the fork, > > our prior preparation will ensure continuity so we won't have to > > scramble at the last minute. > > > > It's heartening that KDAB has already indicated willingness to support > > such a thing should it become necessary. Are there other Qt-using > > companies who we could reach out to? > > * Autodesk: > https://www.autodesk.com/company/legal-notices-trademarks/open-source-distr > ibution > > * MBition (Daimler/Mercedes company -- Eike may be able to give mor > information that). VLC? I mean its not a large company exactly but its Qt, it's ballsy and would probably be pro a fork. Is there any vague calculations concerning the work that would be needed being done? As non-programmer I don't want to be too gung-ho here, but I am feeling the feels out of this whole situations and when a lot of clever people say its possible to fork, I am all for. What would be required by us as a community, how - IF a fork is coming - do we support with action and not words if it happens is also a critical detail.
Re: Qt, Open Source and corona
Hi, just one quick question about this part: But last week, the company suddenly informed both the KDE e.V. board and the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice. I have seen no mails regarding this plan at all on the qt-interest/development list, was that discussed/announced anywhere else beside in the discussions about this contract? (or did I just miss that on the other lists?) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Qt, Open Source and corona
On Wednesday, 8 April 2020 21:06:12 CEST Eike Hein wrote: > That is to say to others -- Qt Open Governance has been a > collaborative and coordinated effort with close > communication and will continue to be. KDE e.V. has a statement about it as well, https://ev.kde.org/2020/04/06/changes-in-qt-and-the-kde-free-qt-foundation/ with this closing paragraph: === Regardless of the future developments in this area, KDE continues to move forward with the guarantee that the KDE Free Qt Foundation will defend the rights of Free Software developers and Open Source software with regards to the Qt tool set. === [ade] -- Adriaan de Groot, board member, KDE e.V. signature.asc Description: This is a digitally signed message part.
Re: Qt, Open Source and corona
Hello Till, I'd like to affirm what others in the community have already done and thank KDAB for its support and participation in the open Qt ecosystem and Qt Open Governance, and also KDE e.V. in particular, over many years and today. I'm very confident that KDE e.V., KDAB and others will continue to do what we do best - work closely together in the open for the benefit of Qt and its users. That is to say to others -- Qt Open Governance has been a collaborative and coordinated effort with close communication and will continue to be. Best regards, Eike Hein - KDE e.V. Vice President April 8, 2020 2:27 PM, "Till Adam" wrote: > Hi Olaf, > > thank you for sharing your perspective and for your important work on > the KDE Free Qt Foundation. Some comments inline below. For the > avoidance of doubt, I am speaking here as a representative of KDAB. > > On 08/04/2020 12:53, Olaf Schmidt-Wischhöfer wrote: > >> Our goals in negotiations: >> * helping the company increase their revenue without harming the Qt project >> or >> the KDE community >> * strengthening the protection of the Qt project and of the KDE community >> * avoiding a parting of ways between The Qt Company and the Qt+KDE >> communities > > All of these, including the first one, are worthy and important goals. > >> Concrete areas included in the negotiations are: >> >> * Fixing the incompatibility between paid Qt license terms and using or >> contributing to Open Source >> (“Prohibited Combination” in https://www.qt.io/terms-conditions/ ) > > This is very important for commercial license holders (including KDAB) > who have a grey area of potential breaches of their commercial license > terms through the development or use of Free Software alongside their > commercially licensed use of Qt. > >> One setback in the negotiations has been an announcement of The Qt Company in >> January: https://www.qt.io/blog/qt-offering-changes-2020 >> They announced that LTS releases of Qt will only be available for paid >> license >> holders. It is still unclear what this implies for contributions to Qt and >> for >> the sharing of security fixes between the various parties (including The Qt >> Company, the many Qt experts contributing, the KDE community, and Linux >> distributions). > > It is very disappointing to us (KDAB) that there has been no further > clarification on this since the announcement. > >> But last week, the company suddenly informed both the KDE e.V. board and the >> KDE Free QT Foundation that the economic outlook caused by the Corona virus >> puts more pressure on them to increase short-term revenue. As a result, they >> are thinking about restricting ALL Qt releases to paid license holders for >> the >> first 12 months. They are aware that this would mean the end of contributions >> via Open Governance in practice. > > The existance and functioning of the Open Governance model of Qt is > critical to KDAB's business and critical to the continued success of Qt > as a technology and a business. If Qt Company were to delay Free > Software releases by the maximum allowed by the Free Qt Agreement, KDAB > would be prevented from contributing under the Open Governance process > to the Qt Company maintained Qt tree and would thus contribute to, > support and sustain any community-driven Qt repository that follows the > Open Governance process and spirit. > > KDAB would also ensure that releases of this repository of Qt, developed > under Open Governance, would be available freely, in source and binary > installer format for the modules and platforms with sufficient interest > to sustain such activities. Additionally, we would work with our > customers and partners as well as the rest of the ecosystem to ensure > that these releases are commercially supported globally for an extended > period of time. > >> Obviously, it cannot be in the middle- and long-term health of The Qt Company >> to separate itself from the very strong Qt + KDE communities. > > Obviously not. KDAB has always considered itself, and still considers > itself, a part of both these communities. Their health and sustained > access to Qt under Free Software terms is a corner stone of our business > and our 20 year success. We will protect it as best we can. > >> We hope The Qt Company will reconsider. > > We also hope so. > >> I invite The Qt Company to stay with us. It will be worthwhile. > > Indeed. > > Cheers, > > Till > > -- > Till Adam > Chief Commercial Officer KDAB Group > Managing Director KDAB Germany > > KDAB (Deutschland) GmbH, Reuchlinstr. 10/11, 10553 Berlin > Tel: +49 30 521325470 Best regards, Eike Hein - KDE e.V. vice president, treasurer
Re: Qt, Open Source and corona
Even in the best of times, it's always a good idea for stakeholders in the open Qt ecosystem to maintain open lines of communication. The KDE e.V. board can be reached at kde-ev-bo...@kde.org and is happy to receive meeting inquiries. Best regards, Eike Hein - KDE e.V. Vice President
Re: Qt, Open Source and corona
On miércoles, 8 de abril de 2020 20:03:37 (CEST) Nate Graham wrote: > On 4/8/20 9:32 AM, Christoph Cullmann wrote: > > On 2020-04-08 15:39, Boudewijn Rempt wrote: > >> On woensdag 8 april 2020 13:13:41 CEST Jens wrote: > >>> The issue is for KDE is that we can't prepare ourselves. We can't > >>> fork Qt, > >>> because we lack the manpower to safely do so currently. > >> > >> But if we work together with other participants in the Qt community, > >> then it might be feasible. In fact, I think it's necessary to start > >> bringing together a group of stakeholders and start preparing for a > >> fork. > > > > Actually, at least as the last possible option, if any further > > cooperation breaks down, I agree with this. > > I strongly agree. I think the sooner we demonstrate that we are capable > of credibly maintaining a fork with other stakeholders in the FOSS Qt > ecosystem, the stronger of a bargaining chip it will be in our > negotiations with TQtC, so we don't have to. And in case the > negotiations break down and we are forced to move forward with the fork, > our prior preparation will ensure continuity so we won't have to > scramble at the last minute. > > It's heartening that KDAB has already indicated willingness to support > such a thing should it become necessary. Are there other Qt-using > companies who we could reach out to? * Autodesk: https://www.autodesk.com/company/legal-notices-trademarks/open-source-distribution * MBition (Daimler/Mercedes company -- Eike may be able to give mor information that). -- Promotion & Communication www: http://kde.org Mastodon: https://mastodon.technology/@kde Facebook: https://www.facebook.com/kde/ Twitter: https://twitter.com/kdecommunity LinkedIn: https://www.linkedin.com/company/kde
Re: Qt, Open Source and corona
On 4/8/20 9:32 AM, Christoph Cullmann wrote: On 2020-04-08 15:39, Boudewijn Rempt wrote: On woensdag 8 april 2020 13:13:41 CEST Jens wrote: The issue is for KDE is that we can't prepare ourselves. We can't fork Qt, because we lack the manpower to safely do so currently. But if we work together with other participants in the Qt community, then it might be feasible. In fact, I think it's necessary to start bringing together a group of stakeholders and start preparing for a fork. Actually, at least as the last possible option, if any further cooperation breaks down, I agree with this. I strongly agree. I think the sooner we demonstrate that we are capable of credibly maintaining a fork with other stakeholders in the FOSS Qt ecosystem, the stronger of a bargaining chip it will be in our negotiations with TQtC, so we don't have to. And in case the negotiations break down and we are forced to move forward with the fork, our prior preparation will ensure continuity so we won't have to scramble at the last minute. It's heartening that KDAB has already indicated willingness to support such a thing should it become necessary. Are there other Qt-using companies who we could reach out to? Maybe also linux distro packagers? Perhaps the KDE e.V. could look into hiring people to help maintain the fork, given the importance of Qt's code to our software. Nate
Re: Qt, Open Source and corona
On 2020-04-08 15:39, Boudewijn Rempt wrote: On woensdag 8 april 2020 13:13:41 CEST Jens wrote: The issue is for KDE is that we can't prepare ourselves. We can't fork Qt, because we lack the manpower to safely do so currently. But if we work together with other participants in the Qt community, then it might be feasible. In fact, I think it's necessary to start bringing together a group of stakeholders and start preparing for a fork. Actually, at least as the last possible option, if any further cooperation breaks down, I agree with this. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Qt, Open Source and corona
Hello Olaf, and also Martin, First of, thank you very much for posting this update to our community. We are very lucky to benefit from your experience and commitment acting as our representatives in the KDE Free Qt Foundation. The KDE e.V. board of directors has been working closely with you to navigate this complex situation together. We've had opportunities to be invited to some of the KFQF meetings and participate directly, which we would like to thank the entire KFQF for. The update reflects our shared view on the subject. Best regards, Eike Hein - KDE e.V. Vice President, Treasurer
Re: Qt, Open Source and corona
On woensdag 8 april 2020 13:13:41 CEST Jens wrote: > The issue is for KDE is that we can't prepare ourselves. We can't fork Qt, > because we lack the manpower to safely do so currently. But if we work together with other participants in the Qt community, then it might be feasible. In fact, I think it's necessary to start bringing together a group of stakeholders and start preparing for a fork. -- https://www.krita.org
Re: Qt, Open Source and corona
Hi Olaf, thank you for sharing your perspective and for your important work on the KDE Free Qt Foundation. Some comments inline below. For the avoidance of doubt, I am speaking here as a representative of KDAB. On 08/04/2020 12:53, Olaf Schmidt-Wischhöfer wrote: > Our goals in negotiations: > * helping the company increase their revenue without harming the Qt project > or > the KDE community > * strengthening the protection of the Qt project and of the KDE community > * avoiding a parting of ways between The Qt Company and the Qt+KDE communities All of these, including the first one, are worthy and important goals. > Concrete areas included in the negotiations are: > > * Fixing the incompatibility between paid Qt license terms and using or > contributing to Open Source > (“Prohibited Combination” in https://www.qt.io/terms-conditions/ ) This is very important for commercial license holders (including KDAB) who have a grey area of potential breaches of their commercial license terms through the development or use of Free Software alongside their commercially licensed use of Qt. > One setback in the negotiations has been an announcement of The Qt Company in > January: https://www.qt.io/blog/qt-offering-changes-2020 > They announced that LTS releases of Qt will only be available for paid > license > holders. It is still unclear what this implies for contributions to Qt and > for > the sharing of security fixes between the various parties (including The Qt > Company, the many Qt experts contributing, the KDE community, and Linux > distributions). It is very disappointing to us (KDAB) that there has been no further clarification on this since the announcement. > But last week, the company suddenly informed both the KDE e.V. board and the > KDE Free QT Foundation that the economic outlook caused by the Corona virus > puts more pressure on them to increase short-term revenue. As a result, they > are thinking about restricting ALL Qt releases to paid license holders for > the > first 12 months. They are aware that this would mean the end of contributions > via Open Governance in practice. The existance and functioning of the Open Governance model of Qt is critical to KDAB's business and critical to the continued success of Qt as a technology and a business. If Qt Company were to delay Free Software releases by the maximum allowed by the Free Qt Agreement, KDAB would be prevented from contributing under the Open Governance process to the Qt Company maintained Qt tree and would thus contribute to, support and sustain any community-driven Qt repository that follows the Open Governance process and spirit. KDAB would also ensure that releases of this repository of Qt, developed under Open Governance, would be available freely, in source and binary installer format for the modules and platforms with sufficient interest to sustain such activities. Additionally, we would work with our customers and partners as well as the rest of the ecosystem to ensure that these releases are commercially supported globally for an extended period of time. > Obviously, it cannot be in the middle- and long-term health of The Qt Company > to separate itself from the very strong Qt + KDE communities. Obviously not. KDAB has always considered itself, and still considers itself, a part of both these communities. Their health and sustained access to Qt under Free Software terms is a corner stone of our business and our 20 year success. We will protect it as best we can. > We hope The Qt Company will reconsider. We also hope so. > I invite The Qt Company to stay with us. It will be worthwhile. Indeed. Cheers, Till -- Till Adam Chief Commercial Officer KDAB Group Managing Director KDAB Germany KDAB (Deutschland) GmbH, Reuchlinstr. 10/11, 10553 Berlin Tel: +49 30 521325470
Re: Qt, Open Source and corona
Hi Jens, > The Qt Company says that they are willing to reconsider the approach only if > we offer them concessions in other areas. I am reminded, however, of the > situation half a year ago. We had discussed an approach for contract > updates, which they suddenly threw away by restricting LTS releases of Qt > instead. > This is nonsense. What concessions are we to give them that would bump their revenue short term if that is their core problem right now? They explicitly ask for relicensing components from LGPL to GPL. Basically anything which increases short term revenue in the fiscal year 2020 by growing the sales of subscriptions (no perpetual license anymore!) the commercial Edition to existing Free Edition users. The changes during the last months with mandatory registrations showed them the potential. (Basically counting .com addresses...)It seems as if they are simply hounding for concessions and nothing else. The fact that they want to burn the field and still think they can harvest come spring is to me ridicilulous and seems to be done by someone who has no understanding of the process of work involved in their own project on the technical or social level. I think we shouldn't give them any concessions. I am always willing to negotiate concessions on good faith but quid pro quo applies!Cheers --martin
Re: Qt, Open Source and corona
On onsdag 8 april 2020 kl. 12:53:47 CEST Olaf Schmidt-Wischhöfer wrote: > But last week, the company suddenly informed both the KDE e.V. board and the > KDE Free QT Foundation that the economic outlook caused by the Corona virus > puts more pressure on them to increase short-term revenue. As a result, > they are thinking about restricting ALL Qt releases to paid license holders > for the first 12 months. They are aware that this would mean the end of > contributions via Open Governance in practice. > Also if Qt becomes more hostile to the Open Source community that would mean a slower pace of new contributors who learn the software and expand their software use professionally in the future. > We hope The Qt Company will reconsider. However, this threat to the Open > Source community needs to be anticipated, so that the Qt and KDE communities > can prepare themselves. > The issue is for KDE is that we can't prepare ourselves. We can't fork Qt, because we lack the manpower to safely do so currently. At the same time we can't afford them to be as openly hostile to Open Source as they have been these last months since that means that contributors to our project dries up as less and less people feel comfortable contributing to a project reliant on another project who is openly trying to divorce itself from that same community. What are our alternatives? > The Qt Company says that they are willing to reconsider the approach only if > we offer them concessions in other areas. I am reminded, however, of the > situation half a year ago. We had discussed an approach for contract > updates, which they suddenly threw away by restricting LTS releases of Qt > instead. > This is nonsense. What concessions are we to give them that would bump their revenue short term if that is their core problem right now? It seems as if they are simply hounding for concessions and nothing else. The fact that they want to burn the field and still think they can harvest come spring is to me ridicilulous and seems to be done by someone who has no understanding of the process of work involved in their own project on the technical or social level. I think we shouldn't give them any concessions. /jens
