Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules

On Mon, Mar 27, 2023 at 11:46:34AM +0100, Nick Alcock wrote:

On 24 Mar 2023, Luis Chamberlain spake thusly:

quoted

On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote:

quoted

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.)

quoted

                                     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