Sequoia PGP is now LGPL 2.0

Yes, but in practice it tend to not matter.

> (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

Now to get the "oh C objects" thing out of the way, GPLv3 defines:

> “Object code” means any non-source form of a work.

Still this means what you need is to distribute you application in a partial compiled state which can be relinked with the LGPL library (or a updated version) to re-produce the final application. (You also might need to provide the tools to do so if they are not freely available.)

Also let's not forgot the context, i.e. you don't want (or can't) provide the source code of the "main application" which links against the LGPL library.

Now if you program in C, providing a (set-of) pre-compiled pre-symbol stripped objects is feasible.

But most (new) programs are not in C anymore and most new languages do not have clear ABI boundaries at library level. Only clear API boundaries.

A good example are generics or template programming.

E.g. even in C++ if there is heavy use of template programming around the library boundary can make LGP infeasible for that use case. And we are still in C++ which is rather close to C in how it compiles stuff.

If we go a step further, e.g. into Rust it becomes even more of a mess. (It is possible, at least theoretically, with a lot of hacks and restrictions, but totally a nightmare not worth even considering. And again if generics are used a lot, all the generic code at the interface boundary leaks.)

Then there is the additional complexity this introduces to CI.

So possible yes, but for many projects not worth considering.

> What the LGPL requires is that the LGPL part can be replaced.

Not quite, they require you to provide intermediates which can be re-linked with a alternate version of the library.

Which means if you want to e.g. provide the functionality through binary patching it gets tricky, because you need to provide a binary without the LGPled library (1) which you then can "patch" the library into. Instead of being able to provide a binary with the LGPled library in it and allowing you to replace/update it. Which means various approaches around binary patching just became way more complex.

(1): The reason for it is that the object you provide falls itself under license terms.

So ya, no dynamic linking requirement. But for some modern languages still a major problem. And conceptually too closely bound to the concept of the C-compilation process IMHO.

But what does buildable mean, no-one but you has access to your CI (which also might likely not be public).

So do you need to provide another CI, a make-file you maintain additionally, etc.? Or is it good enough so that someone could run "the right CLI commands to build and link the project".

No, that is not how it works, like not at all.

Rust doesn't use the same concepts for building as C.

1. You don't build stuff with `rustc` in general. (You build it with cargo.)

2. You don't produce object files in general, sure rust can produce them and if you link something over the C-ABI it can make sense. What the compiler produces in general for linking libraries are rlibs.

3. rlibs are not just unstable in their format, they are more like a implementation details, don't expect to be able to link in a library as rlib. Like at all.

4. Rust widely uses generics similar to C++ templates this means part of the code which is not supposed to become public will leak if the libary interface involves templates/generics.

5. In rust (and somewhat in C) you normally don't link two "objects" to produce the final binary you build it with a number of "object" dependencies. But this doesn't work with what LGPL requires from you. It can be easy to make a public open-source skeleton you link in all LGPL libraries and your code then to make the linking magic work.

6. `rust --emit` is mainly meant for debugging, and some special use cases around embedding. Don't expect good integration with build tools.

And most important:

What is theoretically possible doesn't matter, what matters is what is practical. I.e. simple, and fast to setup and maintain.

Even for a C CI the requirements the static linking of a LGPL library puts up can make it easily not worth it.

> only that there is a way to patch

No, you need to be able to provide a non LGPL object which you can re-link with the LGPLed libary, so "just" binary patching isn't a legal option.

But it does matter, it practice it matters more then what is legal if we are honest.

> It isn't the FSF's job to write Rust tooling

Yes, but it doesn't mean that it's not a bad license for the given use-case.

If it's impractical, then in practice there is not much difference to the license simply forbidding the usage (iff the company cares about what is legal).

Through the question is is it a bad license for the given use-case? I.e. does Sequoia provide a rust API or do they provide a C-API written in rust.

Licensing a rust "for-rust" library as LGPL is in practice so close to GPL, that you just could have made it GPL. But a rust C-ABI library/program (e.g. a system library) is a different matter and binding in a LGPL C-ABI library into a rust project still somewhat practical doable (but still quite annoying).

Curious as to why LGPLv3 wasn't chosen though.