Licensing problem for planned freeware

[marsoupilami]

High to all members!

I'm currently writing a tool for audio / language track "transplanting" eg. from your beloved TV/VHS/DVD into a high quality movie.
This project is now at a stage, where I consider to publish it for free in the near future - but I ended up in all this license crap.
I want to strictly avoid troubles caused by spreading freeware ... but I'm not a lawyer!

The tool is written in c++ using the Qt library which comes with Ubuntu, relies on a installed FFmpeg and FFprobe for analyzing, muxing, decoding & recoding audio.

The easiest way for me would be to pack the compiled prog into an appimage/deb-package using linuxdeployqt/cqtdeployer together with some short usage instructions and .. have fun!

What I have to do?

[microchip8]

What "license crap" did you end up in exactly? You don't mention

[marsoupilami]

The main thing are the qt "obligations": https://www.qt.io/licensing/open-source-lgpl-obligations#lgpl
do I have to to distribute tons of "qt library source code" and hundreds of license agreements which I don't understand?

[wswartzendruber]

I am not a lawyer, but I have spent a good deal of time reading their commentaries on this topic. Some things lawyers will comment on and other things they will not comment on.

How do you intend to distribute this thing? You could, for example, have a standalone installer...or you could make an Ubuntu PPA available...or it could all be wrapped up in a Docker container... Or are you only wanting to distribute the source?

I can't comment on what you "should" do, I can only tell you how I would go about this.

[marsoupilami]

As a first step I would prefer to pack it into an Appimage with "linuxdeployqt" (I think this is exactly the Docker container) and in parallel into an deb-package (standalone installer?). Both are expected to run on Ubuntu22. I am only hobbyist, thatfore I don't know how to create a PPA.
After a evaluation phase it would be nice to open source it - if this thing seems to be useful for others, someone could port it to Win or whatever.

[VoodooFX]

The easiest way for me would be to pack the compiled prog into an appimage/deb-package using linuxdeployqt/cqtdeployer together with some short usage instructions and .. have fun!

What I have to do?

As I understand you don't want to bother distributing the source code?
I would select MIT license in that case for simplicity, then users can do whatever they want with your tool.

In your "obligations" link it says that you need to link dynamically to Qt then you don't need to distribute its source code.

[marsoupilami]

First of all thanks for your answers!
As I understand (my English is not that great) it is sufficient to link dynamically (which does the free Qtcreator). The "deployer" packs the compiled output and the precompiled qt-libraries into an installer (this will keep the libraries still "changeable"). A written "Thanks to Qt company" and that's it?

[wswartzendruber]

First of all thanks for your answers!
As I understand (my English is not that great) it is sufficient to link dynamically (which does the free Qtcreator). The "deployer" packs the compiled output and the precompiled qt-libraries into an installer (this will keep the libraries still "changeable"). A written "Thanks to Qt company" and that's it?
The LGPLv3 license will still obligate you to "convey" the Qt source code in some way.

[LoRd_MuldeR]

The main thing are the qt "obligations": https://www.qt.io/licensing/open-source-lgpl-obligations#lgpl
do I have to to distribute tons of "qt library source code" and hundreds of license agreements which I don't understand?

If your project contains/uses any code or library that is released under GPL, then your project as a whole must be distributed under the GPL – which means that if you make binaries of your project available to anybody, then you must provide them with your source codes too! Also, they will be allowed to modify and share your source code, according to the terms of the GPL.

Things are quite a bit less restrictive with the LGPL: If your project uses a library that is released under the LGPL, then it is not necessary that your project as a whole is distributed under the (L)GPL. Instead, the LGPL allows your own code to remain proprietary, i.e. you don't need to share your own source code, provided that there is a clear separation between the proprietary and LGPL components.

The generally accepted understanding of this is that a proprietary executable is allowed to dynamically link against an LGPL library (DLL file), whereas statically linking an LGPL library into a proprietary executable is not allowed. Furthermore, even though you don't need to share the source code of the proprietary executable, the source code of the LGPL library still needs to made available, including any changes that you made to that library!

In the most simple case, when you just use the LGPL library "as-is" and you did not make any changes to the code of the LGPL library, providing a link to the Git repository of the LGPL library somewhere in your README will be sufficient ;)

────────────────

In general, you should add an "acknowledgement" section to your README and/or LICENSE file where all the third-party libraries that are used in your project are listed. For each library that you use in your project, you should also write down the original author, the license that applies to the library (a link to the license text should be sufficient) as well as the URL where the corresponding source code can be found. If you do all of this, truthfully, then you should be fine.

So, under normal circumstances, you do not need to "distribute tons of 'qt library source code' and hundreds of license agreements" :D

[marsoupilami]

I hope I got it partly.
Except e.g.: both the "xxx.deb" and the "xxx.appimage" package contain all shared libraries - unmodified binaries. This would be ok?
However I'll continue coding keeping in mind your answers. If ever the day will come to release it, you will tell me if it looks fine.
Thanks again!

[wswartzendruber]

The generally accepted understanding of this is that a proprietary executable is allowed to dynamically link against an LGPL library (DLL file), whereas statically linking an LGPL library into a proprietary executable is not allowed. Furthermore, even though you don't need to share the source code of the proprietary executable, the source code of the LGPL library still needs to made available, including any changes that you made to that library!
You are allowed to statically link against LGPL so long as you provide a way for your users to re-link against their own implementation of that LGPL component.

[LoRd_MuldeR]

I hope I got it partly.
Except e.g.: both the "xxx.deb" and the "xxx.appimage" package contain all shared libraries - unmodified binaries. This would be ok?
However I'll continue coding keeping in mind your answers. If ever the day will come to release it, you will tell me if it looks fine.
Thanks again!
deb packages usually do not contain dependencies, such as required libraries, but only the "main" program! The deb package also contains meta information, which specify any required dependencies (libraries). The required dependencies (libraries), if any, would then be installed either from separate deb packages, or (more commonly) via the APT package manager. This should mostly circumnavigate any LGPL issues ;)

AppImage files are "all in one" packages, i.e. they contain the application and all of the required libraries. Consequently, if you want to provide your proprietary application in the form of an AppImage, and if that AppImage package also contains an LGPL library, then you MUST provide the user with a way how they can replace the LGPL component, which is contained in your LGPL AppImage, with a different version of that LGPL component – and still be able to run the application.

And, of course, if you made any changes to the LGPL library that you are shipping, then you must make your modified sources of the LGPL library available to your users.

[marsoupilami]

deb packages usually do not contain dependencies, such as required libraries, but only the "main" program! The deb package also contains meta information, which specify any required dependencies (libraries). The required dependencies (libraries), if any, would then be installed either from separate deb packages, or (more commonly) via the APT package manager. This should mostly circumnavigate any LGPL issues ;)
This was obviously the most confusing point to me. The deb created by qtdeployer definitely contains all compressed ./bin ./lib/ ./icons ./plugins and subfolders. (For AppImage this is obvious) That's why I thought this was the most convenient installer solution.
One insight generates ten questions e.g. "will I ever understand the APT manager?"

[LoRd_MuldeR]

deb packages are used to install stuff (applications, libraries, etc.) on the system. Technically, it may be possible that a single deb package contains an application plus its required libraries, but that is not how things are usually done! The "best practice" is that each application and each library will be provided by a separate deb package! For example, if the applications "A" and "B" both require library "C", then the package that provides application "A" will simply depend on the package that provides library "C". And, similarly, the package that provides application "B" also will depend on the package that provides library "C". Consequently, if you install either package "A" or package "B" (or both), then package "C" will need to be installed too. But library "C" will be only be installed once, even if you install both applications, since it is a separate package. In other words, package "C" is a dependency that is shared by packages "A" and "B". If, instead, each of the packages "A" and "B" would contain their own copy of library "C", then this could easily result in conflicts! Another advantage of making library "C" a separate package is that library "C" can be easily updated independently of applications "A" and "B".

APT is the package manager used by Debian and other Debian-based distros (e.g. Ubuntu). Put simply, APT takes care of downloading and installing applications/libraries, in the form of deb packages. APT also automatically resolves dependencies when installing new packages. Consequently, if you ask APT to install application "A", but the application "A" depends on library "B", then APT takes care of installing library "B" too – in case that library "B" is not already installed.

Meanwhile, AppImage is not used to install stuff on the system. It's just an "all in one" package that runs completely on its own, mostly isolated from the rest of the system. Running an AppImage also won't modify the "base" system at all.

[marsoupilami]

AppImage is clear to me - a nice "portable" and for testing without impacting the system.
I didn't even think about creating conflicts by supplying usually shared libraries inside a deb - shame on me. Thanks!
With the APT manager I am somewhat familiar as a user. The other side - creating an APT installable package - looks more complicated. Even if I circumvent the APT stating in the README "needs libqt6core6, libqt6widgets6..." how could I know, what is needed? Looking inside my qtdeployer created deb I see e.g. "libQt6EglFSDeviceIntegration.so.6, libicui18n.so.70 ..." No idea how to find out where all this stuff is packed in. (But this might be answered at stackoverflow or somewhere)

[LoRd_MuldeR]

AppImage is clear to me - a nice "portable" and for testing without impacting the system.
I didn't even think about creating conflicts by supplying usually shared libraries inside a deb - shame on me. Thanks!
With the APT manager I am somewhat familiar as a user. The other side - creating an APT installable package - looks more complicated. Even if I circumvent the APT stating in the README "needs libqt6core6, libqt6widgets6..." how could I know, what is needed? Looking inside my qtdeployer created deb I see e.g. "libQt6EglFSDeviceIntegration.so.6, libicui18n.so.70 ..." No idea how to find out where all this stuff is packed in. (But this might be answered at stackoverflow or somewhere)

deb packages are usually built to target a specific distro. There is a reason why each Linux distro is maintaining their own separate package repository ;)

So, if you build a deb package that targets a specific distro, e.g. Debian 12 (Bookworm), then you would try to build upon the dependencies (libraries) that are already available in their package repo, as much as possible.

For example, if you build a GUI application that uses Qt 6.x, and thus it needs libQt6Gui.so.6, then you'd probably make your deb package depend on:
https://packages.debian.org/bookworm/libqt6gui6 (list of files (https://packages.debian.org/bookworm/amd64/libqt6gui6/filelist))

Hence, you would not need to ship your own copy of libQt6Gui.so.6 – either that library is already present on the user's system, or APT will take care of installing it (from the distro's package repo) when your deb is being installed.

Most Linux distributions have a website where the available packages are listed and where you can search for what you need, e.g.:
https://www.debian.org/distrib/packages#search_packages
https://packages.ubuntu.com/

Finally, if you do not want to target a specific distro, but instead you want something "portable" that can run on (pretty much) any distro, then AppImage or Flatpak (or Snap) is the way to go...

[marsoupilami]

First of all, thank you very much for your detailed explanations!
Creating one or a couple of deb sounds painful and complicated. I will consider whether to publish it as "open source" via github right from the start...
Meanwhile I'm trying to clean up the code & do some cosmetics - I hope to be finished in some weeks.
Thanks again!!!