On Mon, Mar 27, 2023 at 11:46:34AM +0100, Nick Alcock wrote: > On 24 Mar 2023, Luis Chamberlain spake thusly: > > > On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote: > >> Please put back the license bits that you removed, as it is not a good > >> idea to remove that if the file does not have a SPDX entry at the very > >> least. > > > > Nick, I've just dropped your series. > > Thanks, that's much easier than getting all those reverts in. > (Presumably the bits taken by other people can all stay.) > > > Please only re-submit only for > > files where the license is clear. The effort of clarifying licenses > > on files where one doesn't have an SPDX tag is welcomed but can take > > time and we'll need this anyway in the future to help later strive to > > see if we can automatically generate the MODULE_LICENSE() from the > > SPDX tags. > > For now, I have an alternative that might be acceptable. I did a bit of > an audit and it's all a right mess (see below), with wild divergence > even when SPDX is present, GPL versus -only or GPL-2.0+ apparently > applied almost at random and some things being completely different (in > some cases they were both committed simultaneously and were inconsistent > from the moment the module was written). So many things are inconsistent > that kallmodsyms would call a lot of things modules that really aren't: > there is enough error that there probably be noticeable mistakes in > quite a high percentage of kernels. As you have found out, there is a difference that matters in the SPDX lines vs the MODULE_LICENSE lines when it comes to GPL vs GPLv2+ stuff. The SPDX lines are correct for the code itself, while the MODULE_LICENSE lines are correct from a "this is the license of this binary" point of view. So don't get confused here, if you all can figure out a way to generate the MODULE_LICENSE() lines from SPDX, that would be great, but in my quick look I think it's going to be very difficult (think about how multiple files make up a single module binary...) good luck! > But... for our purposes, we don't actually *mind* if non-modules list > things like licenses inconsistently in two different places. Removing > MODULE_LICENSE was a means, not an end. What we're actually interested > in doing is removing .modinfo in things that can't possibly be modules, > and since a .modinfo in a guaranteed-non-module is at best entirely > useless I don't think anyone could reasonably be opposed to that end > goal (though they might reasonably be unhappy about all the churn > involved in getting there). They object to the removal of the visible > MODULE_LICENSE() argument text string, not to the useless compile-time > effect of a MODULE_LICENSE in a non-module. there are other things that create .modinfo lines, so I'm confused why you picked the license line to trigger all of this. > So how about, for the first three groups below (the groups where > MODULE_LICENSE and SPDX are inconsistent, or where a SPDX simply doesn't > exist), instead of removing the MODULE_LICENSE we replace it with an > identical call to a new macro named perhaps NONMODULE_LICENSE(), which > is defined in module.h as simply expanding to nothing, except possibly > emitting a compile-time error if it's ever used in a module? This more > clearly denotes what's going on, keeps the license string in the source > file on a nearly identical line (for whatever purpose it serves), drops > the spurious .modinfo that's causing trouble, and probably makes fewer > people unhappy? Again, no, why aren't you just stubbing out MODULE_LICENSE() in the build if it's not being built as a module like the other MODULE_*() macros are? Why is the license so special here yet the device list or module authors not? Don't treat this macro as somehow special where authors have to remember to not use it (or to use it), while the other MODULE_* macros do not have the issue? That's my main objection here. Don't get confused by the license stuff, that's secondary. thanks, greg k-h
