Sequoia PGP is now LGPL 2.0
sequoia-pgp.org
Sequoia PGP is now LGPL 2.0
1–10 of 69 posts
Re: Sequoia PGP is now LGPL 2.0
#2Is Sequoia PGP a drop in replacement for GPG? How do I go about integrating with Git and what not?
Re: Sequoia PGP is now LGPL 2.0
#3I 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).
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.
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.
[0] www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
Re: Sequoia PGP is now LGPL 2.0
#4I 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). 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 agai…
SequoiaPGP provides a C FFI interface, which can be dynamically linked against from any C-compatible language. Though safe wrappers would have to be written around that to be able to use it from Rust, which is kind of going full circle. It'd be interesting if a Rust FFI interface could be defined (using abi_stable[0] or something).
Re: Sequoia PGP is now LGPL 2.0
#5I 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). 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 agai…
SequoiaPGP provides a C FFI interface, which can be dynamically linked against from any C-compatible language. Though safe wrappers would have to be written around that to be able to use it from Rust, which is kind of going full circle. It'd be interesting if a Rust FFI interface could be defined (using abi_stable[0] or something). [0]: https://crates.io/crates/abi_stable
I believe git just uses the gpg commandline; in a quick grep of the source I don't see it use any GnuPG includes/functions at all (and gpg-interface.c just runs pipe_command()), but maybe I missed it.
Re: Sequoia PGP is now LGPL 2.0
#6I 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). 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 agai…
Quite right. I contribute a Rust component to a larger AGPL-3.0 project and went with MPL-2.0 over LGPL for this reason.
A bit off-topic, but I wonder if the FSF's ideas about dynamic linking have been litigated yet. It has always seemed a pretty suspicious to me that a dynamically linked program, existing only in volatile memory, could really be a copyright work at all, let alone a derivative one. I found this LWN article that touches on this question[0] and links to some more discussion, which I will have to look into.
Re: Sequoia PGP is now LGPL 2.0
#7I 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). 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 agai…
SequoiaPGP provides a C FFI interface, which can be dynamically linked against from any C-compatible language. Though safe wrappers would have to be written around that to be able to use it from Rust, which is kind of going full circle. It'd be interesting if a Rust FFI interface could be defined (using abi_stable[0] or something). [0]: https://crates.io/crates/abi_stable
That's great, but it's a Rust library, which would be nice to use from Rust, without going through a C FFI layer for the sole purpose of license compliance.
It feels like the Rust ecosystem is a second class citizen due to this license. The GPL or MPL would at least enforce the same rules for everyone, but the LGPL gives a relative advantage to the C and C++ ecosystem over the Rust ecosystem in terms of actually using the library.
Re: Sequoia PGP is now LGPL 2.0
#8I 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). 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 agai…
You can static link your program and release your it under the GPL license. I don't see the problem there.
Re: Sequoia PGP is now LGPL 2.0
#9I 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). 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 agai…
Quite right. I contribute a Rust component to a larger AGPL-3.0 project and went with MPL-2.0 over LGPL for this reason. A bit off-topic, but I wonder if the FSF's ideas about dynamic linking have been litigated yet. It has always seemed a pretty suspicious to me that a dynamically linked program, existing only in volatile memory, could really be a copyright work at all, let alone a derivative one. I found this LWN a…
To think that I had entertained the thought for 6 months or so that I had did it enough a d would not have to post this link again: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
The LGPL text does not require dynamic linking. It's FUD.
What the LGPL requires is that the LGPL part can be replaced. That's possible with static linking, that's possible with other languages than the ones relying on a linker step, etc.
Re: Sequoia PGP is now LGPL 2.0
#10Earlier quoted context omitted.
Quite right. I contribute a Rust component to a larger AGPL-3.0 project and went with MPL-2.0 over LGPL for this reason. A bit off-topic, but I wonder if the FSF's ideas about dynamic linking have been litigated yet. It has always seemed a pretty suspicious to me that a dynamically linked program, existing only in volatile memory, could really be a copyright work at all, let alone a derivative one. I found this LWN a…
To think that I had entertained the thought for 6 months or so that I had did it enough a d would not have to post this link again: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn... The LGPL text does not require dynamic linking. It's FUD. What the LGPL requires is that the LGPL part can be replaced. That's possible with static linking, that's possible with other languages than the ones relying on a lin…
The parent comment literally posted the same link. I am aware of the replacement concept and how it is technically distinct from an outright ban on static linking.
> That's possible with static linking, that's possible with other languages than the ones relying on a linker step, etc.
We are talking about Rust, not languages other than Rust. Could you walk us through how you would offer a Rust binary with a statically linked LGPL Rust crate that is replaceable according to the license requirements (v2.0, 2.1, 3.0, pick your poison), without also releasing the binary's source code? I think it's technically possible, but how would you do it? * Edit: keep in mind that .rlib files are not stable across compiler versions. AFAIK very little about the target/ folder is stable at all, except the final product location.