It does not seem to do consensus to me, just speculations. And even if it would be a consensus, there is way to link statically with LGPL and still respect the license.
Could you please provide supporting evidence for your view that is a consensus? Where is the documentation explaining your “static link” proposal and why it’s been endorsed by lawyers as a permitted approach? What was the response from the GPL team when they were asked to comment on this circumvention of their license? Will they be patching GPLv3 to correct it?
> Could you please provide supporting evidence for your view that is a consensus?
Consensus is what is admitted by most actors, specially including the main interested actor: The FSF and the GNU project. And I do not remember reading any communication of the FSF or the GNU project saying it is forbidden.
Currently the license text is very explicit about what you can do and not do if you link statically.
> 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
Which means: You have to provide a way for your user to recompile statically their application with a new version of the library. Meaning, you have to provide a tarball with your object.o files if someone ask for it.
So, for macOS — where static executables aren't viable — you would need to ship all pre-linking components and then let the user assemble them.
You could ship those elements in a signed DMG, but it would be up to the user to assemble them, and so the user would not be able to codesign them under your developer ID.
Since they would not be able to compile and run the app as your developer ID — it would have to be theirs, since they're the ones linking it — the app won't have access to any ID-linked features such as iCloud syncing, Apple push notifications services, and so forth.
So that would imply that it's outright impossible to use this "static linking" bypass on MacOS when code signing is enabled, since you can't falsify the original signature's private key in order to sign the executable and gain access to signature-enforced platform capabilities.
I guess it would probably work fine for Linux folks, and you could always sign it with your own ID, but this certainly is not "compatible with signed executables" — to answer the original question asked upthread.
I'm gonna make enemies....
That's FUD and BSD bullshit.
LGPL is not GPL. You can link what the fuck you want to a LGPL library included your proprietary code as long as you link dynamically.
Gtk+ uses LGPL, GLib, uses LGPL, GNOME use LGPL, Qt uses LGPL, Cairo uses LGPL and millions of applications link into these ones without problems.
I'm not aware of any case in history where a company got attacked, or frightened to use a LGPL library in their codebase.
It would be good to stop the FUD excepted if you need to feed your lawyer.