7 ms·

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 linki

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.
_jal 5y ago
I don't think it matters that it is impractical. It isn't the FSF's job to write Rust tooling, it is to write licenses. 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.
- cormacrelf 5y ago
  At no point did I suggest it requires dynamic linking. Again, I understand how the license works. I’m talking about why you would choose it if it were this difficult for someone to use your technology. In many projects, ensuring the freedom to replace a copy of the library just isn’t worth all this trouble. If I make my code LGPL, I’m mostly shifting that burden onto other people who want to use it, not myself, and so there are presumably very few LGPL authors who are actually motivated to fix all these problems for someone else. Further, most corps will simply not use the LGPL software, because difficulty looks like license trouble. In that sense, this does look a bit like a job for the FSF, to be honest. At this rate, LGPL use will die out, and not in favour of GPL. In another sense, a proprietary product choosing to embed my component would be a massive victory for the ecosystem it is built to support. I think that is also true for Sequoia. I just straight up don’t care about the ability to replace my component within another proprietary program. If they are using it at all, they will presumably update it themselves, it would be a pretty central dependency; if they don’t want to, they can just build their own version. I'm just hoping to get anyone to pull the trigger and drop their commercial alternative in favour of the open standard my component implements. So is Sequoia; their livelihood depends on it. Will they hack on rustc to make it easier to use? Somehow I think they will not! This makes no sense to me. A lot of open source today cares less about LGPL-style replaceability and more about adoption of an open standard that is separate from the code itself. In this case it’s PGP-compatible encryption and signing, which has famously never really taken off and by some odd coincidence never had a project of Sequoia's quality with e.g. a BSD-style license that you could simply slap in a project and depend on. (Although much of the blame deservedly goes to GPG providing over a hundred intricate and one must presume deliberately hard-to-reproduce APIs.) In Kubernetes-land, the concept of being k8s-compatible and interoperable is arguably responsible for more freedom than the core software itself. This is simply true of so many things, and further you must admit: Sequoia as code is 100% replaceable by a motivated corporation, if only there were more demand for being compatible with PGP. If you’re still thinking in 2021 that if PGP were in demand the only reason Amazon would be shipping software without a user-serviceable Sequoia package is the LGPL, you haven’t seen how many hundreds of thousands of dev job ads they posted in the last month. Adoption of the open standard is just more important than anyone’s actual code, up until the codebase is so big it would be prohibitively difficult to replicate. If you think your code in particular is special, maybe you're right, or maybe it's just the rare piece of software whose existence is not entirely justified by an open standard.
jcelerier 5y ago
> 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.
- dathinab 5y ago
  > 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. 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.
pornel 5y ago
I assume requiring a very specific compiler version would still satisfy the letter of the license. The compiler is publicly available, so you could replace the LGPL part. You get no promises about being able to replace or even maintain anything else. BTW, Rust's objects/rlibs may contain bitcode and a high-level form of generic/inlineable code, so they should be much easier to reverse/decompile than an optimized binary. If the goal was to keep the non-LGPL part closed, it won't work well.

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.

_jal 5y ago

I don't think it matters that it is impractical. It isn't the FSF's job to write Rust tooling, it is to write licenses. 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.

cormacrelf 5y ago
At no point did I suggest it requires dynamic linking. Again, I understand how the license works. I’m talking about why you would choose it if it were this difficult for someone to use your technology. In many projects, ensuring the freedom to replace a copy of the library just isn’t worth all this trouble. If I make my code LGPL, I’m mostly shifting that burden onto other people who want to use it, not myself, and so there are presumably very few LGPL authors who are actually motivated to fix all these problems for someone else. Further, most corps will simply not use the LGPL software, because difficulty looks like license trouble. In that sense, this does look a bit like a job for the FSF, to be honest. At this rate, LGPL use will die out, and not in favour of GPL. In another sense, a proprietary product choosing to embed my component would be a massive victory for the ecosystem it is built to support. I think that is also true for Sequoia. I just straight up don’t care about the ability to replace my component within another proprietary program. If they are using it at all, they will presumably update it themselves, it would be a pretty central dependency; if they don’t want to, they can just build their own version. I'm just hoping to get anyone to pull the trigger and drop their commercial alternative in favour of the open standard my component implements. So is Sequoia; their livelihood depends on it. Will they hack on rustc to make it easier to use? Somehow I think they will not! This makes no sense to me. A lot of open source today cares less about LGPL-style replaceability and more about adoption of an open standard that is separate from the code itself. In this case it’s PGP-compatible encryption and signing, which has famously never really taken off and by some odd coincidence never had a project of Sequoia's quality with e.g. a BSD-style license that you could simply slap in a project and depend on. (Although much of the blame deservedly goes to GPG providing over a hundred intricate and one must presume deliberately hard-to-reproduce APIs.) In Kubernetes-land, the concept of being k8s-compatible and interoperable is arguably responsible for more freedom than the core software itself. This is simply true of so many things, and further you must admit: Sequoia as code is 100% replaceable by a motivated corporation, if only there were more demand for being compatible with PGP. If you’re still thinking in 2021 that if PGP were in demand the only reason Amazon would be shipping software without a user-serviceable Sequoia package is the LGPL, you haven’t seen how many hundreds of thousands of dev job ads they posted in the last month. Adoption of the open standard is just more important than anyone’s actual code, up until the codebase is so big it would be prohibitively difficult to replicate. If you think your code in particular is special, maybe you're right, or maybe it's just the rare piece of software whose existence is not entirely justified by an open standard.

jcelerier 5y ago

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

dathinab 5y ago
> 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. 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.

pornel 5y ago

I assume requiring a very specific compiler version would still satisfy the letter of the license. The compiler is publicly available, so you could replace the LGPL part. You get no promises about being able to replace or even maintain anything else. BTW, Rust's objects/rlibs may contain bitcode and a high-level form of generic/inlineable code, so they should be much easier to reverse/decompile than an optimized binary. If the goal was to keep the non-LGPL part closed, it won't work well.