<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Nov 2024 at 09:51 Sune Vuorela <<a href="mailto:nospam@vuorela.dk">nospam@vuorela.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On 2024-11-03, Neal Gompa <<a href="mailto:ngompa13@gmail.com" target="_blank">ngompa13@gmail.com</a>> wrote:<br>
> It's not that simple. The reason I suggested MPL-2.0 is because<br>
> LGPL-2.1-or-later is effectively the same as GPL-2.0-or-later with<br>
> Rust because it's statically linked.<br>
></blockquote><div dir="auto"><br></div><div dir="auto">people lgpl does not forbids static linking.</div><div dir="auto">this is a common misconception but lets not spread it further.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
> MPL-2.0 preserves the copyleft at a per source file level, but allows<br>
> the binary artifact to have a composition of compatible licenses<br>
> (including the GNU ones). This is the least messy for Rust bindings to<br>
> LGPL libraries.<br>
<br>
On second thoughts, I'm not even sure we need the copyleft protections<br>
that much here, since<br>
 - The rust bindings is probably quite shallow shells<br>
 - The real 'important' things lives in already (l)gpl licensed<br>
   components.<br>
<br>
That also makes the usual Rust MIT/Apache2 dual license useful. We just<br>
also need to make sure that people knows the thing effectively is (l)gpl.<br>
<br>
I think I at least won't object to adding a snippet to licensing<br>
policies that Rust code can be MIT/Apache2<br>
<br>
/Sune<br>
<br>
</blockquote></div></div>