Awebb wrote:

Qt is considering to withhold OSS releases for 12 months to make more money with licenses while still keeping the KDE community in check, which is prepared to fork Qt, should there be no community release in more than a year.

Why is this nice? I used to be heavily involved in some Qt based semi-commercial projects and don’t have to deal with that particular fallout.

Somehow i think this could be nice too.
So many long standing kde glitches depend on qt bugs.
Maybe they will be addressed/fixed earlier that way.

Maybe they will be addressed/fixed earlier that way.

This effectively shuts out OSS devs from contributing to Qt?

seth wrote:

Maybe they will be addressed/fixed earlier that way.

This effectively shuts out OSS devs from contributing to Qt?

You know what? Here are the sources. I’m too biased against Qt to be objective at this point.

https://mail.kde.org/pipermail/kde-comm … print=cGh4

 qt.io

Qt and Open Source
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...

seth wrote:

Maybe they will be addressed/fixed earlier that way.

This effectively shuts out OSS devs from contributing to Qt?

Not sure what you mean, but i think the time needed to review and approve Qt fixes/patches could be cut if the focus is on a particular project using Qt (kde).
I may be wrong.

-edit-
Oh, understood, sorry.,
I was referring to what could happen after a fork.

KDE is not allowed to fork Qt (unless digia screws it and misses the release cycle)
Releases will (arguebly, they open up and suggest this, but remain vague on non-denial denials - but this is the premise:) be only made source available w/ a 12 months delay
If you want to write a patch, you are working on 12 months old code, your patch will only be available on the GPL release up to 12 months later
seth wrote:

KDE is not allowed to fork Qt …
Can you elaborate on this? If the Qt company stops releasing new developments as OSS, that’s one thing, but they can’t retroactively change the GPL license on previously released code. Why couldn’t KDE fork a new project based on the currently GPL’ed qt code? Anyone can do this; you or I could fork it and make an AQT toolkit (Arch QT).

I’d just be worried if KDE fully takes over the open source QT (or whatever name it would then have) that it’d go the same way as GTK3. What I really like about qt, as a user, is that it is nicely modular. I don’t need to install countless packages which run several useless-to-me daemons just to show a push button or menu from the toolkit. GTK3 is so intertwined with gnome that one needs to run much of gnome to show a simple widget. If QT goes the same was with KDE, I’ll have to jump ship from that toolkit too and start writing my own web browser (as qutebrowser is the only reason I have qt installed).

There’s a special deal around the dual license model that allows KDE to BSD Qt in case there’s no OSS release for more than 12 months (hence the general assumption that this drives the proposed delay)
Qt is not released on a clean GPL, nokia added several exceptions to make it more close source friendly (you’ve ot use the framework unaltered)
Whether this only limits the LGPL parts of Qt and whether the LGPL parts could just be GPL’d and what impat that has on KDE or KDE-near software, you need to ask a lawyer to get 3-4 different answers.
But this is what everybody is upset about atm.

Just because it’s “closed-source friendly” doesn’t mean it can’t be forked. I have a copy of QT I downloaded under the GPL license. The fact that they licensed it to some other party under a closed/proprietary license doesn’t change the rights I have under the license they provided it to me under. KDE can fork the currently GPLed code - anyone can.

They just cannot get new developments made by the qt company under non-open licenses. That’s the issue: new stuff may not be open sourced. But existing GPL’ed releases are already GPL’ed and can be forked at any time.

Trilby wrote:

They just cannot get new developments made by the qt company under non-open licenses. That’s the issue: new stuff may not be open sourced. But existing GPL’ed releases are already GPL’ed and can be forked at any time.

Correct me if I’m wrong, but to my understanding basically for the “new stuff” to not be open sourced it should be separate from the original codebase, right? I mean, if they replace part of the code in something that has been GPL’ed that has to be GPL’ed too, but if they start a new project that uses GPL’ed stuff as linked library or whatever, they can release the new part under proprietary license but they have to still distribute the source code under GPL for the part that’s based on GPL’ed material.

TarsolyGer wrote:

Correct me if I’m wrong, but to my understanding basically for the “new stuff” to not be open sourced it should be separate from the original codebase, right? I mean, if they replace part of the code in something that has been GPL’ed that has to be GPL’ed too

No. They can license new versions however they wish. They don’t even need to change anything, they can simply stop offering it under the GPL and start offering what was previously GPL’ed under a closed license. They just cant stop anyone who previously downloaded/recieved it under the GPL from using/changing it.

If you make changes to code you received under the GPL, you have to release those changes under the GPL too (edit: that is if you release them at all). But they didn’t recieve the code under the GPL - they are the original owners.

Licenses don’t restrict the author of code. Licenses grant rights to those who receive the code/software.

https://www.copperspice.com/ is sometimes mentioned as having started out as a Qt fork.
Then there’s https://www.trinitydesktop.org/ which seems to have forked Qt3 after trolltech dropped support for it.

It does look like forking Qt is possible, but maybe KDE e.v. isn’t allowed to fork Qt unless specific circumstances occur ?

Trilby wrote:

If you make changes to code you received under the GPL, you have to release those changes under the GPL too.

I believe that is only true if you want to redistribute it. I think one can change it for ones own use to your heart’s content.

Indeed. That was not clear in my statement. I’ve editted.

Point being, the copyright holder can release new changes however they want, regardless of any license they’ve offered previously.

So… I’ve looked into the kde-community ML where discussions about a fork came up pretty fast, the concern being a lack of manpower to fork & maintain & govern that much code (let alone against a still actively developed competitor and since most institutional users seem to be more interested in maintaining the commercial license)

Then I looked at the legal mumbo-jumbo and IANAL!, but the 12 months deadline license problem only lies w/ digia because if they miss the deadline, KDE can unilaterally declare the code BSD, effectively killing digias commercial license - there does not seem to be any other restriction “protecting” the GPL license from the GPL terms.
The GPL exceptions seem to revolve around the meta object compiler etc. and the question how to treat its generations, but they only touch on “can this gpl code generate non-gpl code”
I also do not claim to have found all relevant legal documents but will claim that digia would have to had buried some legal bomb to come up with “haha, forking under GPL terms is still illegal” (even for the code generators) - there’s no prominent restriction.

tl;dr:
digia cannot keep their thumb on Qt by adhering to the 12 months deadline, but if they fail it, they lose their property entirely.
The challenge is whether a community-maintained version of Qt can attract enough manpower to successfully maintain Qt - with the same implications for the development process if the answer is “no”.