Hacker News Reader

Comment by Nokinside | Hacker News Reader

Unlike most other dual licensed software, Qt Company has legally binding agreement with KDE related to LGPL licensed version.

What they have done in last year is to retreat to the minimum they need to do to comply. They can't stop distributing the LGPL version or alter the deal anymore.

Unlike what you hear you can make commercial closed source software and link LGPL binaries dynamically or statically, makes no difference. You just need to have to provide linkable object files to comply. Just stuff them into some /gpl_comply/ directory and be done with it.

View on HN

Any idea where one could learn more about the legally binding agreement? Especially wondering (i don't expect you to answer these, just wondering if you happen to know or know where one could read about it):

1. When was this entered into

2. What there "good and valuable consideration" exchanged and what was it?

3. Are there any other projects in an agreement like this?

Edit: Great resource, still reading through it and the many links: https://kde.org/community/whatiskde/kdefreeqtfoundation/

Dealing with static linkage is a giant pita because you have to provide all the object files for your code basically. I don’t think anyone really bothers with statically linking LGPL Qt into a non-OSS executable.

> a giant pita

It's not hard at all. You can add them to some directory with your app, or they can be behind some url, or you can mail them physically in a USB stick to anyone who requests them by mail or phone.

You just have to be able to provide them if somebody wants them. In reality nobody ever wants them. It's just some directory with gpl-stuff/ you add to your software.

How hard it is to have some binaries lying around?

The complexity comes into getting that machinery going in your build system and hosting. Additional complexities arise very quickly once you start optimizing your build (cmake object targets, LTO). I’m not saying it’s infeasible. Just saying that usually it’s easier to ship the Qt DLL and be done with it. From my observation of the space I’ve not seen anyone really ship the “here’s the object file” approach (it had happened before I’m sure but it’s not the norm for a reason).

Just do your linking in a final build step that 1: Only reads in object files and resources (ie rejects source code); 2: Bundles up all the object files into an archive; 3: Outputs the final executable alongside the archive.

You mentioned LTO. Don't the LLVM and GCC LTO implementations currently involve outputting compiler IR to object files, then running the optimization passes against the full collection of object files prior to linking? So they inherently collect all the object files together in a linkable form.

(Of course, it's probably more efficient to just dynamically link Qt and pay for a license if you want to publish for iOS.)

It's actually quite simple: https://news.ycombinator.com/item?id=23321785

Reply on news.ycombinator.com