Re: Meta-question on GPL compliance of this activity

[Richard Fontana <rfontana@redhat.com>]

On Wed, May 22, 2019 at 12:14 PM J Lovejoy <opensource@jilayne.com> wrote:
>
> Richard,
>
> As you raised this concern and yet I’m noticing you continue to review the patches and sign off, am I correct to assume that you don’t think this is a big concern?

I have mixed feelings about this. I suppose "not a big concern" is
right; I'm not losing sleep over the GPL compliance issue, but I
believe this group needs to address it head-on and openly, which will
then benefit other projects, especially large and/or old projects with
large numbers of contributors, which may seek to follow the example of
Linux. The fact that I'm participating in these reviews should not be
taken to mean that I am 100% comfortable with this activity. Part of
why I'm doing so is to identify problems that might otherwise get
overlooked.

Bradley wrote:

> > There was consensus at the meeting in Barcelona that moving all the notices
> > to a single file to live inside the Linux tree "somewhere" with entries like:
> >
> >   Filenames: a.c, b.c, c.c contained this notice:
> >            NOTICE
> >      which was replaced with SPDX_IDENTIFIER on DATE.
> >
> > and that such was a fine and acceptable way to address even the most
> > disagreeable and litigious conservative interpreters, and that such
> > was a necessary step to avoid compliance infractions on this issue.
> >
> > Related to this, Allison noted on May 8th on this list:
> >>> Are you [Thomas] automatically logging which files were modified by each
> >>> pattern match, for the legally conservative hack we talked about,
> >>> preserving a historical record of altered license notices in a doc file?
> >
> > IIUC, Thomas indicated in that thread that he could generate that information
> > later, but given that we already have consensus on the idea, it seems to me
> > it would be better if the patches themselves contained the moving of the
> > notice text from the individual files into the single file, rather than
> > reconstructing it on the back-end.  Richard, what do you think about that?

If I've followed these threads rightly it seems that this may not be a
practical solution, but I think something like this would be
preferable.

Richard