Re: Licensing for cxx-kde-frameworks (Rust bridge for KF6)

On 03/11/24 3:06 pm, Neal Gompa wrote:

> On Sun, Nov 3, 2024 at 4:30 PM Darshan Phaldesai
> <[email protected]> wrote:
>> On 31/10/24 5:47 am, Sune Vuorela wrote:
>>
>>> On 2024-10-30, Darshan Phaldesai <[email protected]> wrote:
>>>> Few considerations:
>>>> First, I plan to include bridges for most libraries needed for
>>>> application development and so need to consider their licenses as well.
>>>> Second, This project will only hold the "bridge" code and thus users
>>>> will still need to install the libraries. I don't think this should
>>>> cause any license violations but the bridge code is based of the method
>>>> signatures of the original libraries.
>>>> Third, Upstream `cxx-qt` project uses Apache-2.0+MIT and I planned to do
>>>> the same but KDE's Licensing policy doesn't mention any thing about
>>>> Apache-2.0.
>>> I'd say just stick the same license on it as the KDE Frameworks in
>>> question.
>>> Given they are a directly derived work and also uses the KDE Frameworks
>>> underneath, giving any other license is just going to be confusing for
>>> the people involved.
>>>
>>> The app developers needs to deal with (l)gpl licenses anyway.
>>>
>>> /Sune
>> Now that I think about it, this might the best way to maintain license
>> compatibility. Individual bridges can be licensed depending on their
>> counterparts.
>>
>> I will make this change. Thank you.
> It's not that simple. The reason I suggested MPL-2.0 is because
> LGPL-2.1-or-later is effectively the same as GPL-2.0-or-later with
> Rust because it's statically linked.
>
> MPL-2.0 preserves the copyleft at a per source file level, but allows
> the binary artifact to have a composition of compatible licenses
> (including the GNU ones). This is the least messy for Rust bindings to
> LGPL libraries.

While most rust executables are statically linked, I am not sure whether 
this is the case when using `cxx-qt`. This is what running file command 
on `kontrast-rs` (a sample rust app that uses cxx-kde-frameworks) produces

 > kontrast-rs: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 4.4.0, BuildID[xxHash]=9e033617833656c9, not stripped.

`ldd` also confirms this. I might be totally wrong as I know very less 
about this.
If the final binaries are dynamically linked, the restrictions that you 
mention still apply ?

Darshan Phaldesai