7 ms·

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 F

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. [0]: https://lwn.net/Articles/548216/ https://lwn.net/Articles/548216/

Avshalom 5y ago
https://en.wikipedia.org/wiki/MAI_Systems_Corp._v._Peak_Computer,_Inc https://en.wikipedia.org/wiki/MAI_Systems_Corp._v._Peak_Comp.... would suggest that a program that exists in volatile memory does count for copyright purposes.
jcelerier 5y ago
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#LGPLStaticVsDynamic 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.
- dathinab 5y ago
  > That's possible with static linking, 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.
  - jcelerier 5y ago
    > 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. ... You think people haven't solved this problem for literal decades in c++ ? If your LGPL lib uses a template : If it gets inlined the license says that it's fine and not breaking LGPL that you won't be able to change the call sites. All c++ compilers will still produce a non-inline version of the symbol with weak linkage that can be replaced in the cases where inlining did not happen. Surely rust does the same in order to comply with LD_PRELOAD semantics ? (Even MSVC does that inline symbol exporting afaik). Like, you think people who wrote the LGPL did not consider the case of macros in C for instance ? > 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.) If that's such a nightmare then don't depend on the work of people who wrote LGPL libs and find an alternative instead ?
- cormacrelf 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - cxr 5y ago
    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 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."
    - dralley 5y ago
      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.
      - cormacrelf 5y ago
        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.
- jcranmer 5y ago
  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.
  - jcelerier 5y ago
    > 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.static-linking#L109 https://github.com/freedesktop/gstreamer/blob/master/README....
    - jcranmer 5y ago
      > 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.
      - jcelerier 5y ago
dathinab 5y ago
Linking weather dynamic and static is basically connecting interfaces. Law is (in my understanding) normally based on concepts not technical implementation details. As such for me the idea that there is a difference legal between static linking, dynamic linking or "linking together by a unix-pipe" sounds strange and irritating. Instead I would argue weather or not something is a derivative of something else should depend on the conceptual usage of that thing, not some technical implementation detail.

Avshalom 5y ago

https://en.wikipedia.org/wiki/MAI_Systems_Corp._v._Peak_Computer,_Inc https://en.wikipedia.org/wiki/MAI_Systems_Corp._v._Peak_Comp.... would suggest that a program that exists in volatile memory does count for copyright purposes.

jcelerier 5y ago

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#LGPLStaticVsDynamic 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.

dathinab 5y ago
> That's possible with static linking, 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.
- jcelerier 5y ago
  > 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. ... You think people haven't solved this problem for literal decades in c++ ? If your LGPL lib uses a template : If it gets inlined the license says that it's fine and not breaking LGPL that you won't be able to change the call sites. All c++ compilers will still produce a non-inline version of the symbol with weak linkage that can be replaced in the cases where inlining did not happen. Surely rust does the same in order to comply with LD_PRELOAD semantics ? (Even MSVC does that inline symbol exporting afaik). Like, you think people who wrote the LGPL did not consider the case of macros in C for instance ? > 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.) If that's such a nightmare then don't depend on the work of people who wrote LGPL libs and find an alternative instead ?
cormacrelf 5y ago
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.
- deleted 5y ago
  [deleted]
- cxr 5y ago
  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 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."
  - dralley 5y ago
    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.
    - cormacrelf 5y ago
      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.
jcranmer 5y ago
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.
- jcelerier 5y ago
  > 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.static-linking#L109 https://github.com/freedesktop/gstreamer/blob/master/README....
  - jcranmer 5y ago
    > 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.
    - jcelerier 5y ago

dathinab 5y ago

Linking weather dynamic and static is basically connecting interfaces. Law is (in my understanding) normally based on concepts not technical implementation details. As such for me the idea that there is a difference legal between static linking, dynamic linking or "linking together by a unix-pipe" sounds strange and irritating. Instead I would argue weather or not something is a derivative of something else should depend on the conceptual usage of that thing, not some technical implementation detail.