On Montag, 4. November 2024 03:47:52 CET Neal Gompa wrote: > On Sun, Nov 3, 2024 at 9:44 PM Darshan Phaldesai > <dev.darshanphalde...@gmail.com> wrote: > > On 03/11/24 7:18 pm, Neal Gompa wrote: > > > 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.
KDE's Licensing Policy (https://community.kde.org/Policies/Licensing_Policy) doesn't list the MPL(2.0) as allowed license for "source code and related data files in KDE repositories". This doesn't mean that we couldn't allow the MPL2.0 for Rust bindings, but it means that we should amend the KDE Licensing Policy before we start using the MPL. So, please, start by proposing an amendment for the KDE Licensing Policy if you want to use the MPL2.0 for the Rust bindings. I have no opinion about this except that I think it makes sense to use the Open Source license that is commonly used for Rust libraries. I do the same for Python code I write. Regards, Ingo
signature.asc
Description: This is a digitally signed message part.
