> require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components.
You COULD make the changes, but you MUST keep the changes to the LGPL'd software made available in some way. This is not going to affect the rest of your project, only the LGPL'd library. I think not including any private keys or signed files will still satisfy the LGPL as long as any code changes you made are included. I don't think configuration that compromises your security is within scope, and I'd feel like RMS would agree there.
Its really interesting the goal of the LGPL is to allow for LIBRE libraries to exist where there's proprietary components that already do a solid job, so in order to convince people to use GPL / LGPL tools / libraries it was thrown in that umbrella.
The FAQ is worth a read every now and then, you get a feel for what is intended in plain English.
I believe the GP is referring to the LGPL requirement that users be able to replace LGPL components with modified versions.
Being able to replace subsystems of a signed application with arbitrary third party code adds complexity and is a security risk, but is a requirement of the LGPL.
I think modernity has complicated things. The proprietary vendor signing all the binary components to prevent tampering is different from the platform package manager and kernel requiring signed packages/pages. If you have the proprietary blob and a bunch of modified third party dynamically loaded components, you (or the platform) can re-generate your own signature over the modified composition to execute it in {context that requires signed code execution for security/integrity}. The LGPL is addressing the former. I don’t see a spirited problem with the latter.
I’m trying to work out if an app was distributed with a service that ran in a separate process, e.g via XPC service on Apple platforms, could LGPL libs be legally statically linked only to the service code, which would be open sourced. The service and main app would not be linked at compile time so LGPL wouldn’t apply to the main app, which could remain closed.
You COULD make the changes, but you MUST keep the changes to the LGPL'd software made available in some way. This is not going to affect the rest of your project, only the LGPL'd library. I think not including any private keys or signed files will still satisfy the LGPL as long as any code changes you made are included. I don't think configuration that compromises your security is within scope, and I'd feel like RMS would agree there.
Its really interesting the goal of the LGPL is to allow for LIBRE libraries to exist where there's proprietary components that already do a solid job, so in order to convince people to use GPL / LGPL tools / libraries it was thrown in that umbrella.
The FAQ is worth a read every now and then, you get a feel for what is intended in plain English.
https://www.gnu.org/licenses/gpl-faq.html