MIT license text as ELF section?

Question

The MIT license says "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." where Software refers to the "software and associated documentation files".

If I use a MIT library in my statically linked application, is it OK to put the license text inside as an ELF section called "license" or similar? Or do I even need to include the license text at all if only parts of the library is used in my application?

I'm a bit confused since the musl library for example, which uses the MIT license, makes a big thing that applications can be easily statically linked and distributed as a single file. On https://www.musl-libc.org/intro.html we have:

Using musl maximizes application deployability. Its permissive MIT license is compatible with all FOSS licenses, static-linking-friendly, and makes commercial use painless too. Binaries statically linked with musl have no external dependencies, even for features like DNS lookups or character set conversions that are implemented with dynamic loading on glibc. An application can really be deployed as a single binary file and run on any machine with the appropriate instruction set architecture and Linux kernel or Linux syscall ABI emulation layer.

A separate license file would not make it a single file deployment.

The slides at https://elinux.org/images/e/eb/Transitioning_From_uclibc_to_musl_for_Embedded_Development.pdf written by the musl author says

Permissive license means you can make static-linked binaries without license-conformance concerns.

If I really need to include the license text somewhere, couldn't that be called a concern?

Answer 1

The MIT license doesn't introduce license concerns in the sense that the MIT license would introduce license incompatibilities or that it would disallow certain uses. But the MIT license does still include a condition for the license: precisely that requirement to keep the copyright & license notice intact.

An ELF section or similar embedded metadata would satisfy the letter of the license, and could theoretically be an appropriate mechanism in very very niche scenarios. However, the intent of this requirement seems to be that end users get to know about the MIT-licensed software. An ELF section is effectively invisible to users. For other binary file formats (e.g. images, fonts) embedded metadata might be more appropriate.

As a rule of thumb, open-source components should be attributed in the same place where the application's author asserts their copyright. This might be in a help message, in interactive elements, or in associated documentation. E.g. while your executable might be a single file (instead of using dynamic linking), you might still distribute that executable alongside a README which would provide ample space to provide attributions.

Do not interpret third party opinions about “single file deployments” too literally. If you want to be pedantic then everything could be a single-file deployment by deploying it via ZIP file, but that is not a useful approach for interpreting a license. You already understand that the Software in the sense of the MIT license is not just the software (which might be a single file) but also associated documentation. Thus, I see no contradiction between the MIT license requirements and third party observations about static linking.