I know that a few years ago there was some discussion about which license to choose, with LGPL and MPLv2 being two strong contenders, and it was noted (by Neal himself actually) that MPLv2 is much easier to use when static linking (as is the norm in the Rust community).<p>Why was LGPL chosen instead? The LGPL requires that all applications that consume it as a static library provide the tools to re-link the binary against modified forms [0], which seems incredibly problematic to manage with the Rust toolchain.<p>I like the idea behind the LGPL conceptually, but in practice the LGPL is strongly tied to the way Linux applications and libraries were developed in the 90s and 2000s - namely, in C, with dependencies that are generally dynamically linked, with C-like toolchains that directly expose all of the intermediate object files. It just doesn't make a whole lot of sense for any software outside of that bubble.<p>[0] www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
From the article:
> Delta Chat planned an iOS app, but because Apple does not allow GPL software in their App store, the Delta Chat developers couldn’t use Sequoia.<p>I don't think this is true in theory or in practice, for the iOS App store or the Mac App Store. Take the WordPress app for example.
This is an excellent UVP to have over GnuPG. I'll probably end up using sequoia for my app for this reason alone (amusing it's dependency graph is manageable).<p>Curious as to why LGPLv3 wasn't chosen though.
i’ve still not seen a good reason for going to a “more permissive” license for “pragmatic” reasons, when the language being cast off is the gpl, 2, 2+, 3, you choose. not many good results either.