Including a MIT library that contains a statically linked LGPL library within a Mac app

Question

I'm building a Mac app that I'm planning to release on the Mac App Store. I would like to use a MIT library that contains a statically linked LGPL2.1 library. My understanding, is that in order to keep your application closed source, you must allow the user to replace the LGPL library in some way.

With that said, I have two questions regarding the above.

1. Since the MIT library statically links to the LGPL library, would I also need make the MIT library replaceable? The MIT library complies to a single binary when built. I assume this would be the best solution, but I'm not sure if this is correct.

2. Would putting the MIT library in the application resources folder (as apposed to the app binary itself) be enough to allow the user to replace the library and satisfy the LGPL license? Basically the user could open the .app package and replace the library without having to modify the apps executable. Alternatively, the app could look in it's application resource folder for the library, and if the user put an alternative version there, load it. The app would then include information on how to do this.

Would doing the above satisfy the LGPL license while also being able to be released on the App Store?

Answer 1

As you've correctly understood, the intent of the LGPL is that all recipients can modify and replace the LGPL-covered parts of the software. This typically either means linking the LGPL components dynamically, or providing object files or source code for your software so that recipients can re-link or re-compile your software with their modified LGPL components.

Your scenario seems slightly more complex because you only have an indirect dependency on the LGPL component via a library that is otherwise MIT-licensed. But instead of calling this

a MIT library that contains a statically linked LGPL2.1 library

it would probably be better to view this as

a library that statically links MIT-covered and LGPL-2.1-covered components.

From the viewpoint of your entire application, you should effectively treat this entire library as LGPL-2.1 covered. Your idea to use dynamic linking to make it possible for the recipient to replace the entire library (including the MIT components) is therefore appropriate.

From a viewpoint within this library that statically links the different components, you are only required to make it possible for the recipient to replace the LGPL-covered parts. However, given that the other parts are already Open Source as well, there doesn't seem to be any downside in providing the source code for the entire library and letting the recipient replace it entirely. This will likely be the simplest solution to achieve compliance, and will not raise additional security issues compared to just letting recipients replace the LGPL-covered parts.

The second part of your question asks about how to let the user provide their modified library. The LGPL is technology neutral and does not prescribe a particular mechanism – any way that lets the recipient exercise their rights is fine.

But I am not familiar with macOS development, and would expect your solutions to have different security implications. For example, loading executable code from a directory that is writeable by other processes would be a simple attack vector for malware. In contrast, modifying an .app might be impossible if there are write-protections, checksums, or app signatures involved. I am mentioning these concerns because your goal is not just to create software legally, but also to make it comply with the Apple App Store conditions (which are out of scope here). Without further constraints, I'd probably suggest that users directly modify the .app bundle as this seems conceptually simplest.