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