Isn't the issue with Qt exactly what the GPL intended?

In that case, any Qt fork would force him to also comply with the GPL, and supply the source code of his project.

LGPL. Which eliminates his requirement for a single executable. With LGPL you are only allowed to link dynamically.

The goal of this is so that end-users can modify or update Qt, the LGPL licensed component.

The LGPL is working as intended.

Yes. But the article states that they don’t care about that. They just want a single executable.

I never understood the need for a single executable on windows when folders, zip files, and 100% free installers exist if you don’t like zip files. Also nearly all of the gui kits he’s shooting down have ways to build custom components if that’s what you want to do.

No need for an installer when it's just one file you can run anywhere. And folders/zips are way too hard for the average user. Ask me how I know. My partner gave up an entire game platform because it was delivered as a .7z file they could not figure out.

But a .7z requires a custom expander, .zip is natively supported by windows, isn't it?

.7z recently got native support.

None of these help you if you are dealing with users that move executables for convenient access or think updating the sofware just involves dragging and dropping the new executable into the existing installation folder. Customer support had countless stories like that.

Does using something like APE by jart work? It's a single executable that's also a zipfile. (I assume a replaceable .dll inside the archive is LGPL compliant) I know it's a bit of a tangent, but on platforms like macos the "apps" are all directories with the .app extension, and that doesn't seem to cause issues.

Then pay for a license or make the object files available to users who want to relink the app.

Not true at all. The LGPL does not specify anything about mode of linking or anything like that.

What the LGPL requires is that the end user be able to take the source code for the LGPL part, modify it, recompile it, and then replace the functionality in your binary provided by that part with their new part.

Obviously with dynamic linking this is almist trivial, the end user replaces the so or DLL and done.

With normal static linking, it's only a bit harder. If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.

> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.

This is super clever, I love it! Does any software actually do this?

Yes. For instance some Cisco app on iOS that uses gstreamer (LGPL) does exactly this.

Do you mean iOS the iphone operating system, or cisco IOS the router operating system?

the iPhone operating system: https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/jabb...

The linked post does mention that:

> or distribute object files for recompilation

> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.

Do you need to ship it alongside or produce it on request or link to where they can fetch it? It's not like you need to ship source code alongside either for GPL binaries.

Cool!

Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.

I don't see why not. So long as the LGPL part can be modified and replaced, you're good.

I am not a lawyer.

I mean, if you're willing to do that why not just dynamically link?

The OP article is saying that static linking leads to size reduction. That's why asking.

You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.

Ok. I understood. Thanks for explaining.

> If you ship alongside your binary a bundle of eg .o files

You might even be able to use partial linking (ld -r) to ship a single .o file instead of a bunch of them.

CopperSpice is LGPL, not GPL.

It's not a problem.

Hmm. How could that be when it's based on Qt?

Qt is also available under the LGPL. There is no license advantage to using CopperSpice. I'm not sure what GP is referring to.

Some parts of Qt are GPL only.

True, but they are optional and are not the parts you need to create a GUI as per the requirements in the OP. I assume CopperSpice does not include these components.