6

Apple's documentation for notarization states that:

Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.

Apple doesn't require notarization by default at the time of this writing. If they do at some point, does that count as "Tivoization"? That is, is it incompatible with section 6 of the GPLv3?

5

I don't know MacOS development, but I assume there must exist some way of running a non-notarized executable, if only for development purposes. (Otherwise, you'd have to submit your binary for notarization each time you ran your compiler, which seems unlikely, even for Apple's possessive attitude toward Mac development.)

The "tivoization" requirement in GPLv3 section 6 requires "Installation Information" necessary to run modified versions of the source code:

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, [...] the Corresponding Source conveyed under this section must be accompanied by the Installation Information.

Importantly, Installation Information must be sufficient to "install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source". The significant question is: if you have the source and modify it, can you get your User Product (i.e., your Mac computer) to "install and execute" that modified version of the program from modified source?

As I assume in the first paragraph above (though I welcome clarification), Apple supports some way for a user to turn source code into a binary through normal use of the operating system and its associated development tools. No upstream key of any kind is required to accompany the GPL'd source code into to compile it locally into an executable that can be run on a user's machine. The user may need to acquire or generate a key of their own, but I assume this can be done through normal use of Apple's dev tools.

Insofar as a user may translate modified source code into a runnable binary without keys or secrets from the author(s) of the GPL'd program, this does not run afoul of tivoization requirements. It is true that the rendered binary might only be runnable on one user's machine (without sharing their secret key(s)), but this is not a problem for tivoization. Downstream recipients may repeat the process themselves to build their own local executables from source.

This isn't an ideologically surprising result, either. These terms in GPLv3 are intended to prevent GPLv3 code from running on device that will accept updates from a manufacturer but not the device's owner. Since a computer that runs MacOS is a general-purpose device that can compile and run arbitrary user-supplied code, this isn't an issue.


I suppose there's an argument to be made that if MacOS restricts execution of a binary prepared in such a development mode only to the machine that compiled it, that's a way it has "interfered with" the "continued functioning" of the binary, but I really don't find that argument convincing. The program functions in the context that the binary was prepared, and there is no limitation on preparing additional binaries for additional machines from the GPL'd source code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.