Ogre Forums

/* This topic is a split from ShowCase - wxOgreMVC open sourced */

stealth977 wrote:

dermont wrote:Which would appear to prohibit commercial license users for including/modifying the ogitor source as part of a commercial product.

dermont really has a point there. Although there is no problem for using Ogitor GUI Frontend in a LGPL project, there may be issues raised when and if the Ogitor GUI Frontend code is desired to be used in a commercial product since the commercial license of Qt has a vague restriction (of course LPGL is LGPL and there is no confusion there, but when user wants to use Commercial Qt, there seems to be a vague restriction).

So, I contacted Qt Support and Licensing to make it clear and waiting for an answer. Till then there is no need to argue about it, since LGPL usage has no problems and about Commercial usage of Qt, no matter what we say here, its Nokia who can decide.

Yep.
That's true.
I couldn't believe it at first, but it's insanely true:

Qt’s commercial license agreement contains a restriction that prohibits customers from initially beginning development with the LGPL licensed version of Qt and then transitioning to a commercial version of Qt.

So, that basically means that we're screwed.

Probably a good reason to use wxWidgets.

jacmoe wrote:

Qt’s commercial license agreement contains a restriction that prohibits customers from initially beginning development with the LGPL licensed version of Qt and then transitioning to a commercial version of Qt.

So, that basically means that we're screwed.
Probably a good reason to use wxWidgets.

The main reason I used wxWidgets for my OGEd editor

But if you want to permit commercial use you should consider a dual-license like OGRE or OGE.
This would permit commercial entities to keep their changes private if they want to.
Of course you already need to contact all the contributors to have a signed agreement... or you need to remove their code.

We already DO have a dual license, and an OUL.
Everyone has signed their copy of our contributor agreement.
We are linking to Qt dynamically, of course.

The problem lies in the fact that a user of our library, who happen to have a commercial Qt license, cannot use it.
Because it wasn't developed using a commercially licensed Qt from the start.
Totally ridiculous.
Even if we wanted to shell out over €5000 for a commercial Qt license, which we dont , and then being unable to use the same code base under a LGPL license, we would have to 'forget' all Qt related code we've written, because one cannot switch to a commercial Qt license mid-project. D'oh!

Looking at our old wxWidgets code and our new Qt code, I don't want to go back..
So, maybe I'll just toss in an empty comment-ridden place-holder project with lot's of 'insert Qt code here' comments.

Call me stupid, but how is this LGPL/Commercial dual licensing a concern to Ogitor? Even when you use a commercial license, you can still use a LGPL licensed Qt version too. So use the LGPL licensed Qt version to develop your commercial Ogitor extension or whatever, as it is dynamically linked to Ogitor and dynamically linked to Qt there is no need to release source code of the plugin code. Or do I understand something terribly wrong? I guess I just don't see the problem here.

The problem is that one of our users cannot use it
Because they have a commercial Qt license, which prevents them from using our Qt front end code.
Simply because one cannot switch licenses on Qt.

We are totally free to do whatever we want, since we adhere to the terms of the LGPL, of course.
So, for us, it's not a problem.

Even when you use a commercial license, you can still use a LGPL licensed Qt version too.

Nope.
That does not mix. Because you cannot go from LGPL to commercial.
So, no: I wouldn't call you stupid at all.
These Qt license terms are so stupid that you wouldn't believe it.

Even though it doesn't really concern Ogitor, in a way it does.

And, besides: these ridiculous terms puts me off Qt.
What do they gain from it?
Nothing at all. I bet they'll sell more commercial licenses if one were allowed to get your feet wet first, but no.
It's even more ridiculous after their license change than it was before.

Sorry for the hi-jacking - I am painfully aware that this is a wxWidgets topic - but I didn't start the off-topic-ness!

jacmoe wrote: Sorry for the hi-jacking - I am painfully aware that this is a wxWidgets topic - but I didn't start the off-topic-ness!

Sorry it was probably me that started this. As haffax says I think this is a non-issue for your commercial license user.

If you providing your front end code under a dual license and wan't users to be able to ship their own version of your editor then, as hafax points out, your user should be able to build against the LGPL licensed Qt version. If the front end code is LGPL only there is no issue.

Exactly.
No issue, unless the user happens to have a commercial Qt license.
The docs clearly states that you cannot incorporate a work developed with a LGPL licensed Qt into your commercially licensed Qt based work, which is utterly ridiculous IMO.
The alternative for them is to switch to LGPL Qt, in which case they would have to fork their development, because there's no way they can touch or even think of using that work of theirs in their commercial Qt based code base after the fact..
If I were them, I'll feel royally screwed.
I am still waiting for them to get back to us - but no answer yet, of course.

So back to topic:
In this light, wxWidgets is still a viable option, as it doesn't suffer from this brain-dead restriction.

dermont wrote:I think this is a non-issue for your commercial license user.

If you providing your front end code under a dual license and wan't users to be able to ship their own version of your editor then, as hafax points out, your user should be able to build against the LGPL licensed Qt version. If the front end code is LGPL only there is no issue.

The only problem is that the user paid for the commercial Qt license to be able to link statically to Qt.
They cannot use our front-end code because it's developed using the LGPL'ed Qt.
This is not dual-licensing, it is separate licensing.

Even if they chose to go the LGPL way, with Qt, they would not be able to use their exsisting Qt framework with it - because it's based on the commercial licensed Qt.
Well, yeah: they can. But that would make it LGPL.
And as we all know, you cannot use LGPL'ed code with the commercial licensed Qt.

Anyway: If we decide to port Ogitor to a console, and thus need to statically link, we cannot do it.
We would have to start developing our front-end from scratch.

Probably a simple matter of copy and paste in the night, and clever renaming?
We would have to pretend that we start the whole thing from scratch.

Sorry about this - but since I split it out from the original topic and moved it to the Off-Topic forum - I can have my rant!

Here it is:

If Licensee has, at any
time, developed all (or any portions of) the Application(s) using a
version of one of these Products licensed under the LGPL or the GPL,
Licensee may not combine such development work with the Licensed
Software and must license such Application(s) (or any portions derived
there from) under the terms of the GNU Lesser General Public License
version 2.1 (Qt only)

jacmoe wrote:
..
Anyway: If we decide to port Ogitor to a console, and thus need to statically link, we cannot do it.
We would have to start developing our front-end from scratch.

Probably a simple matter of copy and paste in the night, and clever renaming?
We would have to pretend that we start the whole thing from scratch.

@jacmoe, if all the above is applicable could there not also be ramifications for the base ogitor source code? For example the front-end is developed using Qt/LGPL. You, as the developers, decide to move part of the source to the base code. Would a commercial user not encounter the same license restrictions using the base code in their Qt application.

Our base code would not be licensed under the LGPL, then.
We have the right to license the library any way we see fit.
Besides, that clause in the Qt license does only pertain to Qt itself.
The only thing we need to do, is tell them that they cannot use the Qt interface, but need to re-implement it.
It's clearly separated from the rest of the Ogitor library.
Just how they re-implement it, is not a concern of ours.
Just something to be aware of. A strange quirk in the Qt license terms.

dermont wrote:
@jacmoe, if all the above is applicable could there not also be ramifications for the base ogitor source code? For example the front-end is developed using Qt/LGPL. You, as the developers, decide to move part of the source to the base code. Would a commercial user not encounter the same license restrictions using the base code in their Qt application.

Base code was always neutral and will always be so, so its out of question, the parts using Qt is Qt is concerned about... Since bas never been anywhere near qt, or never used any of its libraries or functionality, its none of their concern unless the base code includes anything directly related to Qt, if it were so, you wouldnt even be using the std library with Qt

ismail,

You can use Ogitor under the LGPL in your commercial project just fine.
Just look it up: the Gnu Lesser Library license permits you to use it in a commercial project if you adhere to the LGPL terms, ie dynamically link to it, and make available any changes you do to the Ogitor source.
Nokias interpretation of the LGPL license is not any different.

The only issue is mixing Qt LGPL with Qt commercial: they don't go together.

Which makes me realise that qtOgitor, our Qt based front-end, cannot be licensed under an unrestricted license.
That is forever a prisoner of the LGPL

jacmoe wrote: The only issue is mixing Qt LGPL with Qt commercial: they don't go together.

So in theory if a commercial application also used LGPL Qt, there would be no problem. The problem occurs however if the commercial application uses commercial Qt, which means it can't use Ogitor stuff (because it uses LGPL Qt). Correct?

That's correct.
That only pertains to our front-end, of course. The rest of Ogitor is not touched by Qt in any way.
But, that's true.
The license terms for Qt commercial clearly states that you need to acquire the license before any development takes place. No exceptions.
Even if they obey the LGPL, which would be folly (they bought the license from Nokia for a reason), they cannot do that. Not because of the LGPL, but because of the licensing terms of the Qt license.
Which says that they cannot incorporate LGPL'ed Qt work..

More generally, given that a LGPL library can be used in a commercial appliation, what is the incentive for anyone to choose the Qt commercial license? Why do Nokia even bother to offer it?

Probably to be able to statically link to hide what third-party libraries they're using?
Or, if they hold any UI patents, or did some modifications to Qt itself, giving them a competitive advantage?
The reasons are many.

But generally: I don't know. If you can just dynamically link, there's no reason at all.

PolyVox wrote:what is the incentive for anyone to choose the Qt commercial license?

Support. Useful or not, a lot of corporate users feel better about it as an "insurance policy".

jacmoe wrote: Even if they chose to go the LGPL way, with Qt, they would not be able to use their exsisting Qt framework with it - because it's based on the commercial licensed Qt.
Well, yeah: they can. But that would make it LGPL.
And as we all know, you cannot use LGPL'ed code with the commercial licensed Qt.

Well, there's no prohibition on moving code from commercial to LGPL, only the reverse. So, for example, if we call their existing framework Framework-C (for Commercial), they should be able to create a Framework-L that's a direct copy of Framework-C except licensed under the LGPL (and following all the LGPL restrictions of course).

So if they need to use an LGPLd Qt for some reason, they could use Framework-L in that particular project, and if they didn't, they could use Framework-C. As long as they didn't propagate any changes to Framework-L into Framework-C (though the inverse is fine) it should be kosher.

IANAL so YMMV.

xavier wrote:

PolyVox wrote:what is the incentive for anyone to choose the Qt commercial license?

Support. Useful or not, a lot of corporate users feel better about it as an "insurance policy".

That is not an argument here: Qt offers paid support for their LGPL'ed Qt.

*shrug* there must be something more you get with the commercial version then, otherwise they wouldn't still offer it.

Goilveig wrote:Well, there's no prohibition on moving code from commercial to LGPL, only the reverse. So, for example, if we call their existing framework Framework-C (for Commercial), they should be able to create a Framework-L that's a direct copy of Framework-C except licensed under the LGPL (and following all the LGPL restrictions of course).

So if they need to use an LGPLd Qt for some reason, they could use Framework-L in that particular project, and if they didn't, they could use Framework-C. As long as they didn't propagate any changes to Framework-L into Framework-C (though the inverse is fine) it should be kosher.

Not exactly super-kosher, but close. That's probably how it works in the real world.
God invented copy and paste for a reason.
Still, I find it odd that they insist on that clause. They would probably sell more commercial licenses if they allowed people to switch mid-project?

xavier wrote:*shrug* there must be something more you get with the commercial version then, otherwise they wouldn't still offer it.

Static linking, Xavier.
And keeping their modifications of Qt code to themselves.

jacmoe wrote: Still, I find it odd that they insist on that clause. They would probably sell more commercial licenses if they allowed people to switch mid-project?

"If you are going to be worried every time the universe doesn't make sense, you are going to be worried every moment of every day for the rest of your natural life."

jacmoe wrote:

xavier wrote:*shrug* there must be something more you get with the commercial version then, otherwise they wouldn't still offer it.

Static linking, Xavier.

Not enough of a reason for the amount of money that is charged, IMO. Ogre's OUL (which had no per-developer structure) was relatively cheap -- Qt licenses cost twice as much for just a single developer license.