4

I am commercial software developer, and my piece of software dynamically calls the LGPL v2.1/LGPL v3 library. Am I allowed to notarize my installation package that includes LGPL dynamic loaded library binary? Addidional Option b) To protect my software from replacing dynamic loaded library with some malicious code is it allowed with LGPL to verify library code sign? Veryfing checksum I believe is strictly not allowed with LGPL.

thirty
  • 41
  • 1

1 Answers1

4

The LGPL v3, Section 4(d)(1)(b) requires that your program

will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

(Very similar language exists in Section 6(b)(2) of the LGPL v2.1)

Verifying the checksum of the library will mean your program will not operate properly, so you are correct you are not allowed to do this; the LGPL is explicitly designed to allow users to replace the LGPL code when it is combined into a larger work.

The details of notarization are not entirely clear to me but the same principle applies: the user must be able to replace the LGPL code with an interface-compatible version and still run the software (and in the case of LGPL v3 software, still install the software as well). If as you say in comments it is possible to enable this with one simple command, I believe that would be acceptable.

Philip Kendall
  • 19,156
  • 1
  • 57
  • 82
  • Thank you for your reply. How about notarization/code sign of the binary file? Is this considered as a modification of the original binary file? – thirty May 07 '23 at 13:46
  • If your program checks the code signature and refuses to work with one that you didn't sign, that also means your program won't operate properly with a modified, but interface-compatible version. The point of the (L)GPL is to give the recipient of the software the freedom to do whatever they want, outside anyone's control. – John Dallman May 07 '23 at 20:38
  • Is there a distinction between code signing which blocks functionality, versus code signing which is used to allow people who aren't interested in modifying a program to confirm it hasn't been tampered with? If someone substitutes their own version of a library, then by nature the author of an application that uses it would not be able to offer any guarantees about the overall application functionality; someone wanting to change the functionality of a program would have to accept responsibility for ensuring that the alternative library didn't do anything undesirable. – supercat May 07 '23 at 22:20
  • 2
    I think I/we would need more information on exactly what the effect of notarizing an app is. If it just means a warning is skipped the first time the app is run, that's probably fine. If it means the app can't be run, that's obviously not fine. If you have to invoke an arcane command line ritual, I think that's a grey area - while that may be beyond "the average user", the average user won't be replacing LGPL components either. – Philip Kendall May 08 '23 at 07:08
  • Hi. Some more info here: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution and https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow tbh Ive never check the behavior of non signed dynamic libraries on MacOS. Regarding bundles, MacOS may check the sign of the bundle and don't allow to run them out of the box but you can run from command line sudo xattr -rd com.apple.quarantine /path/to/bundle and it'll work – thirty May 08 '23 at 18:51
  • There might be a way to do it LGPL-compliant if you can include instructions on how an end-user can re-notarize the app using a custom version of the LGPL library. See the phrase "Installation Information" in the LGPL itself for the details. – Brandin May 09 '23 at 07:41
  • @Brandin I believe notarization involves being a paid up Apple dev at $99/year. While that may be "acceptable" Tivoization under LGPL v2.1, I'd say it's ruled out by the requirement to provide installation instructions in LGPL v3. – Philip Kendall May 09 '23 at 07:47
  • Hello, thanks for reply. I believe that notarization is only required if you publish the software and your package needs to be installed on multiple Macs. sudo xattr -rd com.apple.quarantine command should work on a local computer, but I don't know the same process goes for dylibs. AFAIK Adobe and Avid uses LGPL libraries (I checked in legal informations) so notarization probably should not be a problem I think – thirty May 09 '23 at 07:59
  • @thirty Well, just because someone else is doing something and apparently getting away with it, obviously does not mean it's allowed by the license. – Brandin May 09 '23 at 08:02
  • @Brandin Yes, I agree with you. – thirty May 09 '23 at 08:09
  • Seemingly it's possible to exclude some data from notarization. Perhaps that's an easy option here? See https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow Anyway, this option is more of a SE or Software Development topic at this point, not a license issue. I have no experience with those Apple tools, but the documentation seems to be good enough. – Brandin May 09 '23 at 08:21
  • I've added a (slightly hand-waving) paragraph addressing the notarization issue. – Philip Kendall May 09 '23 at 08:22
  • I found few similar questions: https://opensource.stackexchange.com/questions/6177/gnu-lesser-general-public-license-with-signed-c-assembly https://opensource.stackexchange.com/questions/11677/lgpl-3-vs-code-signing-gmp-mpir – thirty May 09 '23 at 08:33