Earlier quoted context omitted.
> which seems incredibly problematic to manage with the Rust toolchain. I think this is very well intentional
Why would they write it in Rust if they somehow want to disadvantage Rust?
[deleted]
Sequoia PGP is now LGPL 2.0
21–30 of 69 posts
Re: Sequoia PGP is now LGPL 2.0
#22Earlier quoted context omitted.
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…
> 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 see that rustc has a "--emit obj" option, from there surely any decent build system would allow enough customization to do what you want but there's enough raw capability to write a user guide that says "build your stuff with rustc --emit obj lgpl_lib_1.rs -o lgpl_lib_1.o and link with our proprietary .o with lld" ; and you'd be good to go.
> * Edit: keep in mind that .rlib files are not stable across compiler versions.
sure, that's not an issue, just say that you used compiler version x.y ? the LGPL does not require that things work with any compiler version, only that there is a way to patch / rebuild the LGPL parts. e.g. if I ship a C++20 proprietary library with C++20-specific types in the API which interoperates with a C++20 LGPL lib, of course things won't work with GCC 2.95 and everyone will be fine with that.
Re: Sequoia PGP is now LGPL 2.0
#23Earlier quoted context omitted.
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…
While it's true that the LGPL doesn't specifically require dynamic linking, it requires something that is effectively dynamic linking. The way you'd have to do static linking isn't something that is easy to set up in most build systems, and deprives you of the ability to do certain post-build steps (such as signing the build) or certain build options (LTO) without some pain.
> The way you'd have to do static linking isn't something that is easy to set up in most build systems,
it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line
> and deprives you of the ability to do certain post-build steps (such as signing the build)
why would it ? I build my app as a set of static libs linked together in the end and there's no trouble signing it... and it does not make sense for people who will build their own custom version of your app to sign it.
here's a guide inspired by instructions given by Cisco to rebuild one of their proprietary apps for instance on iOS:
https://github.com/freedesktop/gstreamer/blob/master/README....
Re: Sequoia PGP is now LGPL 2.0
#24Earlier quoted context omitted.
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…
It would work the same way that it works for programs written in languages that aren't Rust. You're doing the classic thing where you're conflating a language with a given implementation. The free software advocate's take: You say the toolchain from rust-lang.org makes this difficult? Granted—I'll take your word for it. Go fix that toolchain. (And as a side note, the fact that rust-lang.org chose LLVM is likely to do…
To be clear, I'm not saying that the FSF has written a poor license. It's a fine license for many libraries, especially at the time it was written.
I'm saying it's a poor choice for a brand new library written in a language where the vast majority of the ecosystem utilizes static linking.
Re: Sequoia PGP is now LGPL 2.0
#25Earlier quoted context omitted.
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…
While it's true that the LGPL doesn't specifically require dynamic linking, it requires something that is effectively dynamic linking. The way you'd have to do static linking isn't something that is easy to set up in most build systems, and deprives you of the ability to do certain post-build steps (such as signing the build) or certain build options (LTO) without some pain.
If the source code for your application is available and buildable, that satisfies the LGPL’s definition of “Corresponding Application Code”, regardless of how it’s linked. You don’t need the object code if you have the source code; you can replace the library by rebuilding the application.
So this is only an inconvenience for proprietary closed-source applications. Making the library conveniently usable by closed-source applications is outside the stated objective in the blog post.
Re: Sequoia PGP is now LGPL 2.0
#26Earlier quoted context omitted.
It would work the same way that it works for programs written in languages that aren't Rust. You're doing the classic thing where you're conflating a language with a given implementation. The free software advocate's take: You say the toolchain from rust-lang.org makes this difficult? Granted—I'll take your word for it. Go fix that toolchain. (And as a side note, the fact that rust-lang.org chose LLVM is likely to do…
To be clear, I'm not saying that the FSF has written a poor license. It's a fine license for many libraries, especially at the time it was written. I'm saying it's a poor choice for a brand new library written in a language where the vast majority of the ecosystem utilizes static linking.
There’s a case to be made that Sequoia or another LGPL user should also invest in making it easier to comply with the LGPL with Rust tooling. But I doubt that will happen anytime soon.
Re: Sequoia PGP is now LGPL 2.0
#27Earlier quoted context omitted.
Static linking good for vendor, dynamic linking good for maintainers. Some distros already made exception from "no bundled libraries" rule for Rust. Now we need to add another exception just for Rust. Maybe, it's time for Rust to catch up and implement dynamic linking instead?
Rust's support for dynamic linking is entirely unrelated to how much of a pain LGPL makes static linking.
But it's entirely related to how much of a pain Rust makes dynamic linking.
Re: Sequoia PGP is now LGPL 2.0
#28From 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. 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.
yep, here's a list of GPL apps on iOS: https://en.wikipedia.org/wiki/List_of_free_and_open-source_i...
Re: Sequoia PGP is now LGPL 2.0
#29I 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 don’t need to provide special tooling, you only have to provide the source code of your own program so that the program can be recompiled with a different version of the LGPL-licensed library.
Your source code can be released under another license, even a proprietary license, provided that the user can physically undertake the necessary steps to produce a new executable that interoperates with an updated or modified version of the LGPL-licensed package. The idea is that the LGPL-licensed portion of the final runtime program should itself be open source in the sense of being modifiable in a useful way by the end user.
Re: Sequoia PGP is now LGPL 2.0
#30Earlier quoted context omitted.
While it's true that the LGPL doesn't specifically require dynamic linking, it requires something that is effectively dynamic linking. The way you'd have to do static linking isn't something that is easy to set up in most build systems, and deprives you of the ability to do certain post-build steps (such as signing the build) or certain build options (LTO) without some pain.
> The way you'd have to do static linking isn't something that is easy to set up in most build systems, it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line > and deprives you of the ability to do certain post-build steps (such as signing the build) why would it ? I build my app as a set of static libs linked together in the end and th…
> it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line
Building or using static libraries isn't hard. Doing so in a way that doesn't violate the LGPL's replacement requirement is. The document you yourself linked says this about developing statically-linked libraries with the GPL:
> 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.
If you're distributing an object format, you need a .o that could be linked with the user's custom version of the LGPLed library. Building such a .o file cannot be done easily with tools, and that is what I'm referring to.