> "venomous"

More FUD! LGPL is the best license from what you call 'contribute back'.

While the OP shouldn't have used "venemous", calling it FUD, and then calling the target of the insult the "best" in some respect with nothing to back it up is only slightly better from the perspective use useful conversation. How about explaining your rationale behind why LGPL is the best solution and addressing the more rational concerns brought up, so we can move this conversation past the "No, mine is better!" stage?

Because there are other places to discuss this than this thread.

Sure, there are always other places to discuss something, but that doesn't mean this isn't a good place. Some of the best discussions I've seen or been part of here have been tangential to the original post, as discussions drift. I think the bar here is heavily weighted towards useful, instead of relevant, and relevance is almost always debatable.

To be clear, I don't think anyone minds a civil discussion on the LGPL vs BSD licenses, as long as it's also factual. I wouldn't.

FUD! It's a fine place.

I apologize for using a term that is derisive. I'd be fine if contributing back was the only requirement. The other terms however at the very least inconvenience developers in how they build and deploy applications, and at worst simply exclude entire platforms. Therefore, I disagree that LGPL is 'the best' for contributing back because the MPL maximizes utility and potential targets. On the other hand with the additional LGPL terms, I don't see how they improve the 'contributing back' part. They instead extend additional user level freedoms which in my opinion are orthogonal to contribution. I'm not starting a permissive/restrictive flamewar here, both the MPL and LGPL have a very similar flavor so I think its fair to compare them.

Most developers I know use the LGPL only because they want any improvements contributed back and not because they want to restrict linking or platforms. Plenty of LGPL libraries come with linking exceptions, and lots of devs don't even know about potential platform limitations.

> but mandating how code can be linked and excluding closed platforms (embedded, mobile) are horrible terms to have to adhere to.

Then you buy a commercial license. LGPL is serving it's purpose here just fine. Somebody has to pay for development. This is the incentive.

Sure, that's why I said "I wish". I'm well aware of the $50-300+/month commercial development license. Qt is a high quality product and often worth the price tag. I'm not sure that the original intent of releasing it under LGPL was to use it as a means to push people to go commercial for certain platforms.

In the original announcement for LGPL as a license option:

"Adding LGPL version 2.1 will greatly increase adoption of Qt across Windows, Linux, embedded Linux, Mac, S60, Windows CE, maemo, and Ovi web services. Having a larger number of users, including Nokia developers, providing feedback and contributions will help Qt remain a cutting edge, robust UI and application framework."

To me it seems like the intent was to increase adoption (including in embedded and mobile), but after the recent Digia/Qt Company corporate changes you can tell there's been a shift in the way the LGPL is interpreted. For example, before they had guidelines on their wiki (back when qt-project was still around) on LGPL compliance for mobile platforms that basically said 'Android was okay'... but now if you look at their new guidelines on qt.io after they changed everything, they are pushing for commercial license adoption. I'm pretty sure that was the motivation behind the LPGLv2 -> v3 change as well.

HN guidelines discourage classic flame war topics. The BSD (and similar) vs GPL license debate is one such topic.

The awesome, is it that this demonstrates a viable way to have a simpler toolchain?

More that I have something to point people that complain about the moc to :)

I think you can still buy a commercial license.