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 ?
Darshan Phaldesai
