[toyg]

Qt is massive, I doubt small communities would rush to integrate it and make it their job to maintain it all...

I doubt anyone in OSS communities is seriously deterred from using Qt because of the LGPL. It’s just a very big and very complex project that requires a lot of manpower to “tame”.

[giancarlostoro]

I guess it depends on how much of Qt you need. If you just need the basics you can import mainly what you need[0]. In the case of D though one of it's focuses is to work well with C++ directly. I'm not talking about maintaining it all, I'm talking about embedding it directly into the standard library of a programming language.

I guess you do make a fair point in regards to the LGPL though.

[0]: Here's an example of someone building only a minimal amount of Qt: https://github.com/dirtycold/qt-minimal-build

[ori_b]

Already happened: https://www.copperspice.com

[Rochus]

Thanks for the hint. Didn't know it. As it seems it is no longer Qt. They once started with Qt (don't know which version) but they have "completely diverged" as they say. The goal is not to have a free Qt but to have "Extensive use of modern C++ functionality" (with all these buzzwords). Not even shure if their containers are still implicitly shared. Will even though continue to have a look at it.

[dev-il]

> don't know which version

apparently, they forked from Qt 4.8 and QML is disabled in Copperspice. Ref:

https://www.copperspice.com/docs/cs_overview/timeline.html#t...

https://news.ycombinator.com/item?id=9685022

https://forum.copperspice.com/viewtopic.php?f=11&t=1152

[jacobush]

But that is not BSD

[Rochus]

It's not as big as Linux, Chromium, Dart and others. All of my projects are still compatible with C++ Qt 4. I'm able to and I will maintain it as soon as someone is estabilshing a free fork; up to now I'm being held back by this outrageous Contributor Agreement. A lot of unnecessary complexity started with all the JavaScript stuff. This can be replaced by the other existing (and free) scripting language bindings. So yes, I don't see any problem to continue maintenance of the Qt framework without the Qt company at all.