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. -- 真実はいつも一つ！/ Always, there's only one truth!
