The trouble with MODULE_LICENSE() in non-modules

The kernel's hierarchical maintainer model works quite well from the standpoint of allowing thousands of developers to work together without (often) stepping on each others' toes. But that model can also make life painful for developers who are trying to make changes across numerous subsystems. Other possible source of pain include changes related to licensing or those where maintainers don't understand the purpose of the work. Nick Alcock has managed to hit all of those hazards together in his effort to perform what would seem like a common-sense cleanup of the kernel's annotations for loadable modules.

Discovering potential modules

Alcock did not set out to make tree-wide changes; he is, instead, working on adding some improved tracing features to the kernel. In order to provide a consistent interface to users, he needs to be able to discover code that, as a result of the kernel configuration, is built into the kernel, but which could also have been configured as a loadable module. He described the motivation as:

The reason: if your tracer or whatever has a distinct notation used by users for things in named modules, then you'd usually like to keep that notation the same if you choose to build something into the kernel that might otherwise be a module. Things that cannot be built as modules could just use the in-the-core-kernel notation unconditionally, because there's no way they can ever be found anywhere else: and users are likely to expect that. At least, when I broke it in DTrace years ago, I got complaints!

In other words, he is trying to treat kernel symbols in possibly modular code consistently regardless of whether that code is configured as a module in any given kernel build. In theory, this determination should not be hard to make; the kernel build process produces a file called modules.builtin that is described as listing "all modules that are built into the kernel". This file exists for a specific purpose: allowing the modprobe command to recognize a request to load a module that is already built into the kernel, do nothing in response, and complete successfully. It would seem that modules.builtin is exactly what Alcock is looking for, except that the contents of this file are not exactly as described.

Prior to the 5.6 release in early 2020, the build system would pass through each subsystem's Kconfig file to generate a list of potentially modular code that had been configured to be built into the kernel image directly. This mechanism worked, but it required a pass over the source tree, slowing the build process. So the maintainer of the kernel build system, Masahiro Yamada, decided to find a way to simplify and accelerate the generation of modules.builtin.

The solution that emerged was this commit, which took out the old machinery. In its place was a modification to one of the macros used to describe loadable modules. These macros have names like MODULE_AUTHOR(), MODULE_DESCRIPTION(), and MODULE_LICENSE(); each of them adds information to a special section in the compiled module that can be used by tools like modprobe. MODULE_LICENSE(), in particular, declares the license under which the module can be distributed; it is used primarily to control whether the module will have access to the GPL-only symbols within the kernel when it is loaded.

The MODULE_LICENSE() declaration is mandatory; a kernel module cannot be loaded without it. Since this declaration must appear in code that can be built as a module, Yamada decided to overload it as an indication that, indeed, a modular build is possible. So, in kernels starting with the 5.6 release, MODULE_LICENSE() adds an extra line to the compiled code indicating that it is part of a module; the build process can then scan the resulting object files for that line and collate the results into the new modules.builtin file.

The problem with this approach was noted by Yamada in the commit message: there is code in the kernel that contains MODULE_LICENSE() declarations, but which cannot be built as a module. Each of those occurrences causes a misleading line to be added to modules.builtin, describing a "built-in" module that is not, in fact, a module. For the purpose of allowing modprobe to recognize built-in modules, these false lines are not a problem; modprobe will simply ignore them. But, if one is trying to generate an accurate list of subsystems that truly can be built as modules, those lines are a problem indeed.

The beginning of the cleanup

In November 2022, Alcock posted a patch series that attempted to detect possible modules by adding a new build-time pass to create a new file called modules_thick.builtin, which would contain information that his work needs. Luis Chamberlain, the maintainer of the kernel's module loader, suggested using an augmented version of modules.builtin instead. That, in turn, brought the problem described above to light. Alcock eventually asked whether he should go through the kernel tree and remove all of the MODULE_* declarations found in non-modular code; Chamberlain answered "100% yes" and offered to send the resulting changes upstream via the modules tree.

Thus began the journey to clean up the kernel's module annotations. In early December, Alcock showed up with a patch set performing the removals; it also added some machinery to the build process to detect and warn about spurious MODULE_* declarations in an attempt to prevent the problem from coming back. Neither of those efforts went well.

Geert Uytterhoeven complained about the removal of the non-license information, saying that it is "useful information, in an easy-to-parse format" that should remain. He also said that some of the affected code might be made modular in the future, at which time that information would be needed. Alcock quickly agreed that only the MODULE_LICENSE() lines really needed to be deleted. But Arnd Bergmann, perhaps not understanding the actual problem being addressed, said that the license information, too, should remain if it isn't actively wrong. Christoph Hellwig suggested that the SPDX identifiers found in the kernel source should be used to generate the license information directly — a potentially nice idea but not a small task.

Meanwhile, Yamada rejected the build-system changes, saying "Please do not come back with this again. NACK." He added that "false-positives in modules.builtin should be OK", ignoring the discussion of why those false positives are problematic.

As a result, Alcock gave up on the build-system changes, and reduced his other patches to commenting out the spurious MODULE_LICENSE() entries. The first set, a toe-in-the-water exercise restricted to PCI drivers, was sent in February. PCI maintainer Bjorn Helgaas promptly complained that the subject lines did not match the PCI subsystem's conventions (a problem frequently encountered in tree-wide patch sets, and one that Alcock would hear about from multiple maintainers), and asked that the MODULE_LICENSE() lines be removed entirely rather than just commented out. Alcock duly started removing those lines thereafter.

Greg Kroah-Hartman responded to the second set by saying that all of the MODULE_* declarations should be removed if any are — matching what Alcock had initially tried to do and contradicting the advice he had gotten from other maintainers. Kroah-Hartman reiterated the complaint in response to the fifth set of removals, saying also that the kernel build system should be fixed rather than taking out the license declarations. In response to the sixth set, Chamberlain also suggested removing all of the module declarations; Alcock answered that, beyond the complaints he had gotten from others, some of those declarations (such as MODULE_DEVICE_TABLE()) have side effects that prevent their removal.

Kroah-Hartman also showed up in response to the sixth set, arguing more forcefully against its inclusion. He once again complained about removing only the MODULE_LICENSE() statements, and said:

Just change the macros to work properly in both cases, I can't believe this is all that hard as obviously all of the other macros work both ways, right? That should not require any kbuild changes.

Once again, this statement suggests a failure to understand the real problem that is being solved or the special semantics that Yamada had given to MODULE_LICENSE() in 5.6. There are no "both cases" for code that cannot be built as a module, and simply disabling MODULE_LICENSE() for a non-modular build of a subsystem would break the generation of modules.builtin entirely.

The conversation did not stop there, though; Kroah-Hartman insisted that "some of us disagree that this should be done at all" and asked that the license information that had been deleted so far be restored: "it is not a good idea to remove that if the file does not have a SPDX entry at the very least". The idea that a MODULE_LICENSE() line might actually define the license for a source file raises a number of concerns of its own, of course; deleting license information is generally frowned upon. But it is far from clear, as we will see, that MODULE_LICENSE() fills that role.

Removals removed

Be that as it may, Chamberlain, who had asked for this work to be done in the first place, and who had been applying the removals to the modules tree, summarily dropped them all, telling Alcock to "only re-submit only for files where the license is clear". Alcock responded with a license audit for the files in question, concluding that the situation is "a right mess". Some files have SPDX tags; others do not. Some of them have SPDX tags that contradict the MODULE_LICENSE() declaration in the same file. A MODULE_LICENSE() declaration, it would seem, is not a particularly reliable guide to the actual license attached to the source containing that declaration.

Alcock suggested that, perhaps, for files with unclear licensing, MODULE_LICENSE() could be turned into a new NONMODULE_LICENSE() macro, essentially returning to commenting out the declaration and preserving the information.

Kroah-Hartman answered that, actually, the SPDX lines and MODULE_LICENSE() cover different things: the former describes the license for the file in which it is found, while the latter provides the license for the built binary module. But the "license stuff" is "secondary", he said; the real problem remains the removal of just the MODULE_LICENSE() lines. He suggested again that Alcock should be "just stubbing out MODULE_LICENSE()" for non-modular builds — a "solution" that misses the problem entirely.

That message also said: "I'm confused why you picked the license line to trigger all of this". Alcock answered, clearly frustrated, that Yamada had attached the special meaning to MODULE_LICENSE(), and that Kroah-Hartman was "really objecting to the consequences of a years-old commit that I didn't write". He explained the whole story once again. As of this writing, that is where things stand; Kroah-Hartman has not responded to Alcock's explanation.

How all of this will be resolved is far from clear. Chamberlain is now advising Alcock to take on the project of adding proper SPDX lines to the relevant files that lack them as a step toward automatic generation of the module license declaration. This is a significant and fraught task; assigning a license to somebody else's code is not something to be done lightly. It's worth noting that Chamberlain sees this as a path toward removing all MODULE_LICENSE() declarations, of which there are over 11,000 in the kernel; that is not a small number of SPDX tags to check. A lot of work is being requested here that is orthogonal to Alcock's actual objectives.

Tree-wide changes are always painful to make; they tend to run afoul of the differing expectations of subsystem maintainers and, in any case, it is always hard to get a group of kernel maintainers to agree on anything. But the task gets significantly harder when multiple maintainers obstruct things without, seemingly, understanding the problem that is being solved. The tendency of maintainers to add requirements, such as figuring out what the licensing of kernel subsystems should really be, also does not help. It all adds up to a frustrating experience for a developer who is just trying to fix a problem so that he can get back to work on his real project. The kernel development process, as a whole, works quite well, but there are clearly situations where significant room for improvement exists.

Index entries for this article
Kernel	Build system
Kernel	Modules/Licensing

---

to post comments