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

[Darshan Phaldesai]

On 03/11/24 7:18 pm, Neal Gompa wrote:

> On Sun, Nov 3, 2024 at 6:23 PM Darshan Phaldesai
> <dev.darshanphaldesai at gmail.com> wrote:
>> On 03/11/24 3:06 pm, Neal Gompa wrote:
>>
>>> On Sun, Nov 3, 2024 at 4:30 PM Darshan Phaldesai
>>> <dev.darshanphaldesai at gmail.com> wrote:
>>>> On 31/10/24 5:47 am, Sune Vuorela wrote:
>>>>
>>>>> On 2024-10-30, Darshan Phaldesai <dev.darshanphaldesai at gmail.com> 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 ?
>>
> It does, because the *Rust parts* are statically linked, but the
> *C/C++ parts* are dynamically linked.
I see. I did some research online (found your thread as well :) ) and 
MPL2.0 makes sense to me.

Are most framework libraries compatible with MPL2.0? the ones included 
at the moment are LGPL2 and shouldn't have any problems.
If no one has issues with it, I will switch to it.

Darshan Phaldesai