On Mon, 4 Nov 2024 at 09:51 Sune Vuorela <nos...@vuorela.dk> wrote: > On 2024-11-03, Neal Gompa <ngomp...@gmail.com> wrote: > > 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. > >
people lgpl does not forbids static linking. this is a common misconception but lets not spread it further. > > 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. > > On second thoughts, I'm not even sure we need the copyleft protections > that much here, since > - The rust bindings is probably quite shallow shells > - The real 'important' things lives in already (l)gpl licensed > components. > > That also makes the usual Rust MIT/Apache2 dual license useful. We just > also need to make sure that people knows the thing effectively is (l)gpl. > > I think I at least won't object to adding a snippet to licensing > policies that Rust code can be MIT/Apache2 > > /Sune > >
