11–20 of 69 posts
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.
Earlier 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…
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). 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…
I think this is very well intentional
Earlier 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…
Earlier quoted context omitted.
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 usin…
Earlier quoted context omitted.
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 usin…
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?
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). 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…
> which seems incredibly problematic to manage with the Rust toolchain. I think this is very well intentional
Is Sequoia PGP a drop in replacement for GPG? How do I go about integrating with Git and what not?
[0]: https://git-scm.com/docs/git-config#Documentation/git-config...
Earlier 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…
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 the opposite of cultivating sympathy.) It's a lot like the saying that goes something like, "poor planning on your end does not automatically make for an emergency on my end."
Earlier 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…
I do agree that that the concern is becoming much more orthogonal both to the FSF's goals and to the way software is built. But that doesn't change the fact that the license works the way it does, nor does it let you insert the words 'dynamic linking' in it.