That's the equivalent of creative accounting for software developers.
Dick move.
Such behaviour just leaves the market to big corps who can afford to release such tools for free while extracting money from elsewhere.
Dick move.
Such behaviour just leaves the market to big corps who can afford to release such tools for free while extracting money from elsewhere.
There's nothing in the BSD license that prevents you from mixing in code. LGPL doesn't care if you link it against BSD code. Just that the LGPL code must stay under LGPL.
Also, LGPL is already problematic, because you cannot link statically with it.
Damn. I just wrote the whole top level comment to explain that you can link statically LGPL code and how to do it with details.
"If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application."
That's precisely what makes LGPL the LGPL. If it is a dick move, it is a FSF-endorsed, widely deployed, and widely used dick move.
"Creative accounting is what we want, since we didn't outlaw it."
It would mean however that if someone were to make a proprietary fork of your project, they would no longer be permitted to use the no-charge version of Qt. They would have to get a commercial licence. I don't see anything wrong with any of this though.
Edit: I wasn't clear here: Qt is also available under the LGPL, so the restrictions of the GPL aren't directly relevant.
However, using any GPL-code, no matter if linked statically or dynamically, requires the author to release the combined work under GPL.
I'm not sure where you're going with this.
Correct.
> using any GPL-code, no matter if linked statically or dynamically, requires the author to release the combined work under GPL.
Yes, the combined work itself ends up being GPL [0]. This is similar to making a fork of some BSD-licensed code and adopting the GPL for the fork. Your code, treated independently of the combination, may still be released under a (more permissive) GPL-compatible licence (like the BSD licence) if you so choose.
Put another way then, if Qt were only made available under the GPL, it would still be fine to release your Qt-powered application code under the BSD licence, but it wouldn't be possible to make a proprietary fork of that BSD-licensed application code, as you wouldn't then be permitted to link against libraries released only under the GPL. (I'm ignoring commercial licensing of Qt, of course.)
[0] https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
This is exactly what Nokia wanted when they made Qt available under the LGPL in 2009; they fully endorsed this kind of usage. All subsequent buyers and investors have been fully aware of what the LGPL means.
Just remember that some ancillary Qt software - such as Qt Virtual Keyboard - are only available under the GPLv3 and commercial licenses.