undefined | Better HN

0 pointsadev_6y ago0 comments

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

It is even documented explicitly by the FSF:

https://softwareengineering.stackexchange.com/questions/3127...

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

0 comments

floatingatoll6y ago

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.

j / k navigate · click thread line to collapse