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

[Neal Gompa]

On Sun, Nov 3, 2024 at 9:44 PM Darshan Phaldesai
<dev.darshanphaldesai at gmail.com> wrote:
>
> 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.
>

Yes, it has a high degree of compatibility due to how it works as a license.


-- 
真実はいつも一つ！/ Always, there's only one truth!