3 ms·

First of all, it's not just the LTS binaries, it's also the LTS source and license for it. Commercial-only. No FOSS. But it goes further: even for what is stil

First of all, it's not just the LTS binaries, it's also the LTS source and license for it. Commercial-only. No FOSS. But it goes further: even for what is still FOSS (i.e. the non-LTS), the licensing gets progressively more and more restrictive: * whereas Nokia made Qt available under the relatively permissive LGPL2.1, that since changed to a mixture of LGPL3 and GPL, with a clear shift towards the latter: that is: for new modules, you typically only have the choice between commercial and GPL. Unless you are content with that for all of your software projects, that's quite the problematic constraint.

midoridensha 4y ago
>for new modules, you typically only have the choice between commercial and GPL. Unless you are content with that for all of your software projects, that's quite the problematic constraint. For a FOSS project like KDE, why would this be problematic? I don't see how this is an issue at all.
- EntrePrescott 4y ago
  Well, first of all, while the GPL is one particular FOSS license (out of many), it's not as if it was compatible with all FOSS licenses, far from it. So while imposing GPL or commercial may not be a problem for a FOSS project that happens by chance to have chosen that one specific license anyways… it can be a huge problem for others that want to choose a different FOSS license. And that's just for projects that happen to be FOSS anyways. The thing is: very few software developers have the luxury of releasing ALL their software projects as FOSS. Something has to pay the rent and food. There are a few select domains where developing FOSS software can be a the base for a business model that pays a sustainable living… but those tend to inherently have a very small intersection with the kinds of software typically developed with Qt. And huge complex frameworks aren't something a developer changes all the time like underwear. It's something devs tend to stick to, because it takes quite a significant time investment to master and to build your workflow, tooling etc. around. In other words: developers largely tend to do their FOSS projects in the same framework that they use for the work projects that pay their rent and food. If big framework A disqualifies itself for the latter and gets replaced with framework B for that, chances are that their FOSS projects will be centered around framework B as well and no longer around framework A. As long as Qt was a viable option for work, it made perfect sense to center one's FOSS efforts around Qt as well and thus around KDE, which is the primary Qt-based Desktop. But since the licensing situation of Qt deteriorated, that is no longer the case. So that's another factor where it impacts KDE.

midoridensha 4y ago

>for new modules, you typically only have the choice between commercial and GPL. Unless you are content with that for all of your software projects, that's quite the problematic constraint. For a FOSS project like KDE, why would this be problematic? I don't see how this is an issue at all.

EntrePrescott 4y ago
Well, first of all, while the GPL is one particular FOSS license (out of many), it's not as if it was compatible with all FOSS licenses, far from it. So while imposing GPL or commercial may not be a problem for a FOSS project that happens by chance to have chosen that one specific license anyways… it can be a huge problem for others that want to choose a different FOSS license. And that's just for projects that happen to be FOSS anyways. The thing is: very few software developers have the luxury of releasing ALL their software projects as FOSS. Something has to pay the rent and food. There are a few select domains where developing FOSS software can be a the base for a business model that pays a sustainable living… but those tend to inherently have a very small intersection with the kinds of software typically developed with Qt. And huge complex frameworks aren't something a developer changes all the time like underwear. It's something devs tend to stick to, because it takes quite a significant time investment to master and to build your workflow, tooling etc. around. In other words: developers largely tend to do their FOSS projects in the same framework that they use for the work projects that pay their rent and food. If big framework A disqualifies itself for the latter and gets replaced with framework B for that, chances are that their FOSS projects will be centered around framework B as well and no longer around framework A. As long as Qt was a viable option for work, it made perfect sense to center one's FOSS efforts around Qt as well and thus around KDE, which is the primary Qt-based Desktop. But since the licensing situation of Qt deteriorated, that is no longer the case. So that's another factor where it impacts KDE.