> Changing the needed dynamic dependencies to point to absolute paths, especially when those paths are immutable and content-addressable, may have philosophical

> Changing the needed dynamic dependencies to point to absolute paths, especially when those paths are immutable and content-addressable, may have philosophical and legal considerations for certain open-source licenses such as LGPL. > LGPL specifically mentions that only in the case of dynamic linking is the license not propagated over. Although these dependencies go through the process of being dynamically linked, the library they are linked to is effectively fixed. If I understand, after running Shrinkwrap, only the pathname of the library is changed in the resulting binary. This is easy to reverse by removing the directory parts of all pathnames altogether (I can imagine an unshrinkwrap utility that does that) or by some interactive tool that can do that on a per-entry basis. Since detecting shrinkwrapped binaries is easy and so is inverting the process, I assume there is no violation of LGPL intent here. If anything, I can imagine that a user that wants to change the version of the dynamic library in question can take an existing Guix/Nix recipe, run the hypothetical unshrinkwrap/reshrinkwrap on its binaries, and therefore create a new Nix/Guix package with a new hash that new software packages can then depend upon. Still sounds LGPLish in nature - just with much stricter binary versioning, which is a technological requirement and not a legal one.