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

[christoph at cullmann.io]

On 2024-11-03 23:06, 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.

If upstream cxx-qt uses Apache-2.0+MIT I would propose to just follow 
that.

Greetings
Christoph