ralexander-phi
commented
1 month ago Hi James,
Thanks for the comment! This is an interesting example, I'm not previously familiar with the details.
Collecting some background info
Qt has a couple different licensing options. The code is mostly LGPL, but some parts are GPL. Commercial licenses are offered for anyone who isn't able to abide by the LGPL/GPL terms. There are some "professional features", but this doesn't look "open core" to me.
The Qt CLA has a copyright and patent grant, so there's a centralization of rights to "The Qt Company". This makes sense as the Qt Company wants to commercially sell the software under different license terms and they need these rights to do so. The centralization of rights also gives The Qt Company the ability to change the license without coordinating with others.
The "KDE Free Qt Foundation" agreements provide a license grant to KDE Free Qt Foundation which they can use only if The Qt Company was to stop releasing Qt under an open source license. Interestingly the grant allows permissive licenses like the BSD license, which are more permissive than the current LGPL/GPL licenses. The Qt Company has a trademark for "Qt". I don't see a trademark grant, so I think any version of Qt released by KDE Free Qt Foundation would need to use a different name.
Current Handling
Qt is using an OSI license, so it's in-scope for Relicensing Monitor. The current behavior of RM would rate Qt as "high risk" because a single company has sufficient copyright grants to unilaterally change the license.
My thoughts
A score of "high risk" for Qt feels incorrect.
Even though The Qt Company is a for-profit, publicly traded company who would have strong profit incentives and the CLA grants them all the rights they need to unilaterally change the license, the agreement makes re-licensing unfavorable. In particular, The Qt Company currently has the exclusive right to sell Qt under a commercial license. If they re-licensed Qt, the agreement would trigger, and everyone would be able to use the last LGPL/GPL release of Qt for free. It's possible that they could make large, closed source improvements to Qt after a re-licensing, and try to out-compete the BSD fork, but this is clearly risky as existing paying customers can switch to the BSD fork.
How RM can handle this
I haven't come across another project that uses this approach, so I'd like to treat Qt as a corner case. If we find more examples, I'll need to adjust.
I'd like to keep the ratings based on objective measures that are quick to measure and validate. If I put in too many subjective measures then this simply becomes a list of my opinions. I don't want to manually override the risk ratings.
I'd also like to keep the burden of adding a project low. Determining the license, finding CLAs/DCOs, and doing a trademark search is currently pretty quick. This lets me add new projects efficiently, and there's a lot of projects worthy of adding. Review of legal agreements (like those Qt uses) feels too high burden and subjective, so I'd like to avoid it.
I think I'll mark Qt as "High Risk (with comments)". The high risk is based on the objective measure that a single company has sufficient copyright grants to unilaterally change the license. But visibly call out that Qt has a unique approach to licensing that breaks the RM risk model and may actually have lower risk.
One of the reasons I'm working on this project is to encourage discussion and understanding of license dynamics among software developers. Rating Qt as "High Risk (with comments)" calls attention to the unique approach Qt is using, so it accomplishes that goal.
I'd love your thoughts on this approach and thanks again for reaching out.
Example: Qt will likely remain in its current licensing state, as KDE effectively has agreements to that effect: https://kde.org/community/whatiskde/kdefreeqtfoundation/ https://www.qt.io/faq/3.2.-why-do-you-have-an-agreement-with-kde-about-your-licensing-what-kde-is-and-whats-the-history-of-qt-and-kde