On Sun, Nov 3, 2024 at 6:23 PM Darshan Phaldesai <dev.darshanphalde...@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.darshanphalde...@gmail.com> wrote: > >> On 31/10/24 5:47 am, Sune Vuorela wrote: > >> > >>> On 2024-10-30, Darshan Phaldesai <dev.darshanphalde...@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. -- 真実はいつも一つ！/ Always, there's only one truth!
