Meta-question on GPL compliance of this activity

Meta-question on GPL compliance of this activity

[Richard Fontana]

I was at the LLW event in Barcelona last month but unfortunately did
not attend the workshop relating to this activity, so I apologize if
this is something that has already been considered.

GPLv2 section 1 says: "You may copy and distribute verbatim copies of
the Program's source code as you receive it, in any medium, provided
that you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep intact
all the notices that refer to this License and to the absence of any
warranty; and give any other recipients of the Program a copy of this
License along with the Program."

I have recently heard the argument that replacing a more or less
standard old-school GNU license notice, or any sort of nonstandard
pre-SPDX alternative human-oriented notice, with an SPDX license
identifier string, without explicit permission from the copyright
holder, complies with this condition, because in substance the SPDX
string embodies equivalent licensing information (and has benefits of
its own over the old-school notice). However, more conservative
interpreters of GPLv2, including some copyright holders, might argue
otherwise.

The discovery of GPL notices juxtaposed with warranty disclaimers
imported from non-GPL licenses, or warranty disclaimers that otherwise
go beyond what is called out in GPLv2 and the traditional GNU license
notice, also raises the question of whether this list's work is
strictly compliant with the quoted language from GPLv2 section 1.

Have other participants already thought about and addressed these
sorts of compliance issues?

Richard

Re: Meta-question on GPL compliance of this activity

[J Lovejoy]

Hi Richard,

Thanks for this comment. Yes, this is something that has been considered and is being considered. Some statement of the general guidelines we are applying for this work would be helpful for all involved and beyond.  We are working on that, please hold in the meantime.

Thanks,
Jilayne


> On May 21, 2019, at 11:58 AM, Richard Fontana <rfontana@redhat.com> wrote:
> 
> I was at the LLW event in Barcelona last month but unfortunately did
> not attend the workshop relating to this activity, so I apologize if
> this is something that has already been considered.
> 
> GPLv2 section 1 says: "You may copy and distribute verbatim copies of
> the Program's source code as you receive it, in any medium, provided
> that you conspicuously and appropriately publish on each copy an
> appropriate copyright notice and disclaimer of warranty; keep intact
> all the notices that refer to this License and to the absence of any
> warranty; and give any other recipients of the Program a copy of this
> License along with the Program."
> 
> I have recently heard the argument that replacing a more or less
> standard old-school GNU license notice, or any sort of nonstandard
> pre-SPDX alternative human-oriented notice, with an SPDX license
> identifier string, without explicit permission from the copyright
> holder, complies with this condition, because in substance the SPDX
> string embodies equivalent licensing information (and has benefits of
> its own over the old-school notice). However, more conservative
> interpreters of GPLv2, including some copyright holders, might argue
> otherwise.
> 
> The discovery of GPL notices juxtaposed with warranty disclaimers
> imported from non-GPL licenses, or warranty disclaimers that otherwise
> go beyond what is called out in GPLv2 and the traditional GNU license
> notice, also raises the question of whether this list's work is
> strictly compliant with the quoted language from GPLv2 section 1.
> 
> Have other participants already thought about and addressed these
> sorts of compliance issues?
> 
> Richard

Re: Meta-question on GPL compliance of this activity

[Bradley M. Kuhn]

Richard, glad to see you on this list!

Richard Fontana wrote:
> I have recently heard the argument that replacing a more or less standard
> old-school GNU license notice, or any sort of nonstandard pre-SPDX
> alternative human-oriented notice, with an SPDX license identifier string,
> without explicit permission from the copyright holder, complies with this
> condition, because in substance the SPDX string embodies equivalent
> licensing information (and has benefits of its own over the old-school
> notice). However, more conservative interpreters of GPLv2, including some
> copyright holders, might argue otherwise.

I think we do have to worry about more conservative interpreters, esp. given
that copyright holders are not giving their consent for these notice changes.

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?

--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/

Re: Meta-question on GPL compliance of this activity

[Thomas Gleixner]

On Tue, 21 May 2019, Bradley M. Kuhn wrote:
> Richard Fontana wrote:
> > I have recently heard the argument that replacing a more or less standard
> > old-school GNU license notice, or any sort of nonstandard pre-SPDX
> > alternative human-oriented notice, with an SPDX license identifier string,
> > without explicit permission from the copyright holder, complies with this
> > condition, because in substance the SPDX string embodies equivalent
> > licensing information (and has benefits of its own over the old-school
> > notice). However, more conservative interpreters of GPLv2, including some
> > copyright holders, might argue otherwise.
> 
> I think we do have to worry about more conservative interpreters, esp. given
> that copyright holders are not giving their consent for these notice changes.
> 
> 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.

The only issue with that are the filenames. They tend to change by renames,
moves etc. And we know from other stuff (e.g. Documentation) that nobody
ever cares about updating these things.

> 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?

It's not too late to do that. Though, can we please avoid having all the
explicit patterns and use one 'normalized' pattern instead, i.e. something
more readable than the normalized pattern which we use in the changelog
right now. The point is that if I just take a single patch which matches
100 files with the normalized pattern, then I'd end up with at least 50
variants due to formatting (comment style, line breaks, whitespace, ...),
which is not really helpful either.

Thinking about the volatile nature of filenames, we could be smart about
that and provide a generator for that 'documentation'. Git allows me to
follow the renames and moves and extract the exact point where the
boilerplate/reference was replaced. That way the information can be
retrieved on demand and does not get subject to bitrot. Arguably the
information is still in place, right?

Thanks,

	tglx

Re: Meta-question on GPL compliance of this activity

[Greg KH]

On Tue, May 21, 2019 at 01:58:04PM -0400, Richard Fontana wrote:
> I was at the LLW event in Barcelona last month but unfortunately did
> not attend the workshop relating to this activity, so I apologize if
> this is something that has already been considered.
> 
> GPLv2 section 1 says: "You may copy and distribute verbatim copies of
> the Program's source code as you receive it, in any medium, provided
> that you conspicuously and appropriately publish on each copy an
> appropriate copyright notice and disclaimer of warranty; keep intact
> all the notices that refer to this License and to the absence of any
> warranty; and give any other recipients of the Program a copy of this
> License along with the Program."
> 
> I have recently heard the argument that replacing a more or less
> standard old-school GNU license notice, or any sort of nonstandard
> pre-SPDX alternative human-oriented notice, with an SPDX license
> identifier string, without explicit permission from the copyright
> holder, complies with this condition, because in substance the SPDX
> string embodies equivalent licensing information (and has benefits of
> its own over the old-school notice). However, more conservative
> interpreters of GPLv2, including some copyright holders, might argue
> otherwise.

Wonderful, let's debate that with any copyright holder who argues
otherwise.  Right now, we have all companies and developers who have
seen these lines removed in their files, agree with the removal of the
text.  If there are any objections, we will gladly leave their files
alone.

Note, we can trivially change back any such file if someone objects in
the future as well.  Remember, we have the whole history of "the world"
at our fingertips here, nothing we do is ever immutable.

thanks,

greg k-h

Re: Meta-question on GPL compliance of this activity

[Greg KH]

On Tue, May 21, 2019 at 02:08:33PM -0700, Bradley M. Kuhn wrote:
> Richard, glad to see you on this list!
> 
> Richard Fontana wrote:
> > I have recently heard the argument that replacing a more or less standard
> > old-school GNU license notice, or any sort of nonstandard pre-SPDX
> > alternative human-oriented notice, with an SPDX license identifier string,
> > without explicit permission from the copyright holder, complies with this
> > condition, because in substance the SPDX string embodies equivalent
> > licensing information (and has benefits of its own over the old-school
> > notice). However, more conservative interpreters of GPLv2, including some
> > copyright holders, might argue otherwise.
> 
> I think we do have to worry about more conservative interpreters, esp. given
> that copyright holders are not giving their consent for these notice changes.
> 
> 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.

Note that we have over 700 instances of how "GPLv2" was described in the
kernel tree.  We have over 90 thousand different files in the kernel
source tree today, with thousands more added every 3 months.  There is
no way any single file would ever be able to track this type of history.

So that's just not going to be possible, or usable, by anyone.

Just use git history, we have it, why ignore it?

thanks,

greg k-h

Re: Meta-question on GPL compliance of this activity

[Thomas Gleixner]

On Wed, 22 May 2019, Greg KH wrote:
> On Tue, May 21, 2019 at 01:58:04PM -0400, Richard Fontana wrote:
> > I was at the LLW event in Barcelona last month but unfortunately did
> > not attend the workshop relating to this activity, so I apologize if
> > this is something that has already been considered.
> > 
> > GPLv2 section 1 says: "You may copy and distribute verbatim copies of
> > the Program's source code as you receive it, in any medium, provided
> > that you conspicuously and appropriately publish on each copy an
> > appropriate copyright notice and disclaimer of warranty; keep intact
> > all the notices that refer to this License and to the absence of any
> > warranty; and give any other recipients of the Program a copy of this
> > License along with the Program."
> > 
> > I have recently heard the argument that replacing a more or less
> > standard old-school GNU license notice, or any sort of nonstandard
> > pre-SPDX alternative human-oriented notice, with an SPDX license
> > identifier string, without explicit permission from the copyright
> > holder, complies with this condition, because in substance the SPDX
> > string embodies equivalent licensing information (and has benefits of
> > its own over the old-school notice). However, more conservative
> > interpreters of GPLv2, including some copyright holders, might argue
> > otherwise.
> 
> Wonderful, let's debate that with any copyright holder who argues
> otherwise.  Right now, we have all companies and developers who have
> seen these lines removed in their files, agree with the removal of the
> text.  If there are any objections, we will gladly leave their files
> alone.

And there is precedence:

 https://github.com/u-boot/u-boot/commit/cb3761ea995ca2699db19f54e7c5f7e463381459

plus a few dozen of similar commits which converted the u-boot tree into a
SPDX clean state. They had a simpler task as the number of crude licenses
was smaller, but they had to fight odd cases as well. AFAIK nobody went
berserk on the u-boot folks and they did that 6 years ago...

> Note, we can trivially change back any such file if someone objects in
> the future as well.  Remember, we have the whole history of "the world"
> at our fingertips here, nothing we do is ever immutable.

I just hacked up a trivial script.

  # spdxhist.py kernel/delayacct.c

  SPDX identifier added with:
  commit 7170066ecd289cd8560695b6f86ba8dc723b6505
  Author: Thomas Gleixner <tglx@linutronix.de>
  Date:   Sun May 19 15:51:55 2019 +0200

  // SPDX-License-Identifier: GPL-2.0-or-later

  Lines removed:

  *
  * This program is free software;  you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  *
  * This program is distributed in the hope that it would be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
  * the GNU General Public License for more details.

Now for a file where we just added one (had no license ref at all):

  # spdxhist.py kernel/irq/chip.c 

  SPDX identifier added with
  commit 52a65ff5603e685e9b19c2e108b3f0826dc7a86b
  Author: Thomas Gleixner <tglx@linutronix.de>
  Date:   Sun May 19 15:51:55 2019 +0200

  // SPDX-License-Identifier: GPL-2.0

So we can expose that information with tooling or generate even full
documentation for the whole kernel tree at any given time.

Picking some random other one:

  # spdxhist.py drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c

  SPDX identifier added with
  commit 4c450f056cae111a48bb33c3ddb33296a206faad
  Author: Jonathan Gray <jsg@jsg.id.au>
  Date:   Mon Oct 15 15:45:49 2018 +1100

  // SPDX-License-Identifier: MIT

  Lines removed:

  // SPDX-License-Identifier: GPL-2.0

So fixups happen when people notice and it's not the end of the world.

We rather spend some time on tooling to find out the exact point of change
and deal with it after the fact rather than trying to solve all theoretical
lawyerese issues upfront. You know exactly that this won't ever be
possible.

TBH, we are talking about cleaning up this mess for at least a decade and
the lawyers while promising to help just came up with new fancy licenses or
did not prevent their engineers from creating these zombies which just
cause headache.

We need a pragmatic approach and I'm surely aware that there might be
dragons lurking, but we spent a lot of time on thinking about a sane
approach and with the review process we are able to filter out the
problematic cases upfront and then we just need to find a way to deal with
them in a sensible way.

Just leaving them around is not a solution as explained already in that
other thread.

We need quick help from the SPDX/lawyer camp to handle these cases proper,
unless the copyright holders are willing to remove the magic disclaimers
and modifications. Surely the latter would be the preferred solution, but
that's nothing engineers can solve. That's something we happily delegate to
a lawyer to lawyer conversation. :)

Thanks,

	tglx

Re: Meta-question on GPL compliance of this activity

[J Lovejoy]

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?

thanks,
Jilayne

> On May 21, 2019, at 3:08 PM, Bradley M. Kuhn <bkuhn@ebb.org> wrote:
> 
> Richard, glad to see you on this list!
> 
> Richard Fontana wrote:
>> I have recently heard the argument that replacing a more or less standard
>> old-school GNU license notice, or any sort of nonstandard pre-SPDX
>> alternative human-oriented notice, with an SPDX license identifier string,
>> without explicit permission from the copyright holder, complies with this
>> condition, because in substance the SPDX string embodies equivalent
>> licensing information (and has benefits of its own over the old-school
>> notice). However, more conservative interpreters of GPLv2, including some
>> copyright holders, might argue otherwise.
> 
> I think we do have to worry about more conservative interpreters, esp. given
> that copyright holders are not giving their consent for these notice changes.
> 
> 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?
> 
> --
> Bradley M. Kuhn
> 
> Pls. support the charity where I work, Software Freedom Conservancy:
> https://sfconservancy.org/supporter/

Re: Meta-question on GPL compliance of this activity

[J Lovejoy]

> On May 22, 2019, at 8:16 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Wed, 22 May 2019, Greg KH wrote:
> 
> And there is precedence:
> 
> https://github.com/u-boot/u-boot/commit/cb3761ea995ca2699db19f54e7c5f7e463381459
> 
> plus a few dozen of similar commits which converted the u-boot tree into a
> SPDX clean state. They had a simpler task as the number of crude licenses
> was smaller, but they had to fight odd cases as well. AFAIK nobody went
> berserk on the u-boot folks and they did that 6 years ago...
> 
>> Note, we can trivially change back any such file if someone objects in
>> the future as well.  Remember, we have the whole history of "the world"
>> at our fingertips here, nothing we do is ever immutable.
> 
> I just hacked up a trivial script.
> 
>  # spdxhist.py kernel/delayacct.c
> 
>  SPDX identifier added with:
>  commit 7170066ecd289cd8560695b6f86ba8dc723b6505
>  Author: Thomas Gleixner <tglx@linutronix.de>
>  Date:   Sun May 19 15:51:55 2019 +0200
> 
>  // SPDX-License-Identifier: GPL-2.0-or-later
> 
>  Lines removed:
> 
>  *
>  * This program is free software;  you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * (at your option) any later version.
>  *
>  * This program is distributed in the hope that it would be useful, but
>  * WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
>  * the GNU General Public License for more details.
> 
> Now for a file where we just added one (had no license ref at all):
> 
>  # spdxhist.py kernel/irq/chip.c 
> 
>  SPDX identifier added with
>  commit 52a65ff5603e685e9b19c2e108b3f0826dc7a86b
>  Author: Thomas Gleixner <tglx@linutronix.de>
>  Date:   Sun May 19 15:51:55 2019 +0200
> 
>  // SPDX-License-Identifier: GPL-2.0
> 
> So we can expose that information with tooling or generate even full
> documentation for the whole kernel tree at any given time.
> 
> Picking some random other one:
> 
>  # spdxhist.py drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c
> 
>  SPDX identifier added with
>  commit 4c450f056cae111a48bb33c3ddb33296a206faad
>  Author: Jonathan Gray <jsg@jsg.id.au>
>  Date:   Mon Oct 15 15:45:49 2018 +1100
> 
>  // SPDX-License-Identifier: MIT
> 
>  Lines removed:
> 
>  // SPDX-License-Identifier: GPL-2.0
> 
> So fixups happen when people notice and it's not the end of the world.
> 
> We rather spend some time on tooling to find out the exact point of change
> and deal with it after the fact rather than trying to solve all theoretical
> lawyerese issues upfront. You know exactly that this won't ever be
> possible.
> 
> TBH, we are talking about cleaning up this mess for at least a decade and
> the lawyers while promising to help just came up with new fancy licenses or
> did not prevent their engineers from creating these zombies which just
> cause headache.

I’m sorry, but this is an unhelpful comment and that I personally take offense to. While I’m sure you have had bad experience with lawyers in the course of this project (and others) - I have my own set of war stories as well and have often been vocal about criticizing my fellow lawyers (in the vain hope I might actually make a difference), placing blame is just unhelpful.

Please understand that, for example off the top of my head, ONE (open source) lawyer in a company with hundreds (or thousands?) of software developers/engineers cannot control what those engineers do in terms of licensing information  - We can give the best advice and document best practices until we are blue in the face and people (aka our clients) still won’t always listen.

And, we make mistakes and learn along the way, as Greg said in another thread. 

We are in this together and we all feel the pain of this mess in our given roles, which is why we can all come together here and try to fix it as best we can, which includes, us lawyers making sure we have covered any potential risks as best we can as well. 

> 
> We need a pragmatic approach and I'm surely aware that there might be
> dragons lurking, but we spent a lot of time on thinking about a sane
> approach and with the review process we are able to filter out the
> problematic cases upfront and then we just need to find a way to deal with
> them in a sensible way.
> 
> Just leaving them around is not a solution as explained already in that
> other thread.

I think everyone agrees here. 

> 
> We need quick help from the SPDX/lawyer camp to handle these cases proper,
> unless the copyright holders are willing to remove the magic disclaimers
> and modifications. Surely the latter would be the preferred solution, but
> that's nothing engineers can solve. That's something we happily delegate to
> a lawyer to lawyer conversation. :)
> 

in terms of efficiency of process on this: my thinking is that we are bound to have files that need cleaning up (for one reason or another) from the same copyright holders, as well as files that have similar patterns of cleaning up. When it comes to reaching out to people to get them to help clean stuff up, I think we’ll get a better response if we collect similar things and send one (or minimal #) of correspondence, rather than one here, one there, etc. 

And, yes, we may not be able to get the copyright holders to help in all cases where it would be ideal for a number of reasons (can’t find them, too many people, etc) - but I think we all agree that is ideal and the first point to try for the messy files. There seems to be plenty of low-hanging fruit to work on in the meantime and that’s GREAT progress - so let’s not lose sight of that either :)

For whatever we can’t get copyright holders to clean up, we will look at adding SPDX identifiers for. But it’s not worth doing that first and then having someone clean up the 


> Thanks,
> 
> 	tglx
> 
> 
> 
> 

Re: Meta-question on GPL compliance of this activity

[Thomas Gleixner]

[-- Attachment #1: Type: text/plain, Size: 4543 bytes --]

Jilayne,

On Wed, 22 May 2019, J Lovejoy wrote:
> > On May 22, 2019, at 8:16 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > TBH, we are talking about cleaning up this mess for at least a decade and
> > the lawyers while promising to help just came up with new fancy licenses or
> > did not prevent their engineers from creating these zombies which just
> > cause headache.
> 
> I’m sorry, but this is an unhelpful comment and that I personally take
> offense to. While I’m sure you have had bad experience with lawyers in
> the course of this project (and others) - I have my own set of war
> stories as well and have often been vocal about criticizing my fellow
> lawyers (in the vain hope I might actually make a difference), placing
> blame is just unhelpful.

I defintely did not want to offend you or anyone else on this list and I'm
really sorry that it ended up this way. My apologies.

> Please understand that, for example off the top of my head, ONE (open
> source) lawyer in a company with hundreds (or thousands?) of software
> developers/engineers cannot control what those engineers do in terms of
> licensing information - We can give the best advice and document best
> practices until we are blue in the face and people (aka our clients) still
> won’t always listen.

I understand that, but I saw new license variants crop up in the past years
which clearly originated from $corp laywers as they were suddenly used in
every new file of that $corp. So yes, there are both ways.

> And, we make mistakes and learn along the way, as Greg said in another thread. 
>
> We are in this together and we all feel the pain of this mess in our
> given roles, which is why we can all come together here and try to fix it
> as best we can, which includes, us lawyers making sure we have covered
> any potential risks as best we can as well.

I'm grateful for that and I truly appreciate that you and the other lawyers
have their eyes on it.

> > We need a pragmatic approach and I'm surely aware that there might be
> > dragons lurking, but we spent a lot of time on thinking about a sane
> > approach and with the review process we are able to filter out the
> > problematic cases upfront and then we just need to find a way to deal with
> > them in a sensible way.
> > 
> > Just leaving them around is not a solution as explained already in that
> > other thread.
> 
> I think everyone agrees here. 
> 
> > 
> > We need quick help from the SPDX/lawyer camp to handle these cases proper,
> > unless the copyright holders are willing to remove the magic disclaimers
> > and modifications. Surely the latter would be the preferred solution, but
> > that's nothing engineers can solve. That's something we happily delegate to
> > a lawyer to lawyer conversation. :)
> > 
> 
> in terms of efficiency of process on this: my thinking is that we are
> bound to have files that need cleaning up (for one reason or another) from
> the same copyright holders, as well as files that have similar patterns of
> cleaning up. When it comes to reaching out to people to get them to help
> clean stuff up, I think we’ll get a better response if we collect similar
> things and send one (or minimal #) of correspondence, rather than one
> here, one there, etc.

> And, yes, we may not be able to get the copyright holders to help in all
> cases where it would be ideal for a number of reasons (can’t find them,
> too many people, etc) - but I think we all agree that is ideal and the
> first point to try for the messy files. There seems to be plenty of
> low-hanging fruit to work on in the meantime and that’s GREAT progress -
> so let’s not lose sight of that either :)

Sure. I already started to categorize the disclaimer infected files and one
category of the first batch is bound to create headache. That's the stuff
which came (probably) from TI via RidgeRun Ltd. and then got copied into
random places. There are more of those.

> For whatever we can’t get copyright holders to clean up, we will look at
> adding SPDX identifiers for. But it’s not worth doing that first and then
> having someone clean up the

I think we really should do things in parallel.

  1) Contact the copyright holders where possible.

  2) Prepare some SPDX solution for the cases which are not going to be
     resolved. See the other mail for a proposal.

That way we won't create roadblocks which prevent us to reach a clean state
in a timely manner. If crap gets removed, great. If not, we have to deal
with it no matter what.

Thanks,

	tglx

Re: Meta-question on GPL compliance of this activity

[J Lovejoy]

> On May 22, 2019, at 10:52 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> 
> 
> I understand that, but I saw new license variants crop up in the past years
> which clearly originated from $corp laywers as they were suddenly used in
> every new file of that $corp. So yes, there are both ways.

*AHHHHHH*  
ok, good to know. Will add this to my list of drums to bang on when talking to other lawyers… 
> 
>>> 
>>> 
>>> 
>> 
>> in terms of efficiency of process on this: my thinking is that we are
>> bound to have files that need cleaning up (for one reason or another) from
>> the same copyright holders, as well as files that have similar patterns of
>> cleaning up. When it comes to reaching out to people to get them to help
>> clean stuff up, I think we’ll get a better response if we collect similar
>> things and send one (or minimal #) of correspondence, rather than one
>> here, one there, etc.
> 
>> And, yes, we may not be able to get the copyright holders to help in all
>> cases where it would be ideal for a number of reasons (can’t find them,
>> too many people, etc) - but I think we all agree that is ideal and the
>> first point to try for the messy files. There seems to be plenty of
>> low-hanging fruit to work on in the meantime and that’s GREAT progress -
>> so let’s not lose sight of that either :)
> 
> Sure. I already started to categorize the disclaimer infected files and one
> category of the first batch is bound to create headache. That's the stuff
> which came (probably) from TI via RidgeRun Ltd. and then got copied into
> random places. There are more of those.
> 
>> For whatever we can’t get copyright holders to clean up, we will look at
>> adding SPDX identifiers for. But it’s not worth doing that first and then
>> having someone clean up the
> 
> I think we really should do things in parallel.
> 
>  1) Contact the copyright holders where possible.
> 
>  2) Prepare some SPDX solution for the cases which are not going to be
>     resolved. See the other mail for a proposal.
> 
> That way we won't create roadblocks which prevent us to reach a clean state
> in a timely manner. If crap gets removed, great. If not, we have to deal
> with it no matter what.
> 

got it. I think we have some good ideas starting on the other thread!

J.

Re: Meta-question on GPL compliance of this activity

[John Sullivan]

J Lovejoy <opensource@jilayne.com> writes:

> 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 was late to subscribe and am just catching up on the conversation
here, so apologies if I missed earlier explanation, but I remember
discussing this issue a while back on either -legal or -general (I'll
look when I have a few more moments). On https://spdx.org/ids-how it
currently says:

> When a license defines a recommended notice to attach to files under
> that license (sometimes called a "standard header"), the SPDX project
> recommends that the standard header be included in the files, in
> addition to an SPDX ID.

> Additionally, when a file already contains a standard header or other
> license notice, the SPDX project recommends that those existing notices
> should not be removed. The SPDX ID is recommended to be used to
> supplement, not replace, existing notices in files.

> Like copyright notices, existing license texts and notices should be
> retained, not replaced ‐ especially a third party's license notices.

-john

-- 
John Sullivan | Executive Director, Free Software Foundation
GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B
https://status.fsf.org/johns | https://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
<https://my.fsf.org/join>.

Re: Meta-question on GPL compliance of this activity

[J Lovejoy]

> On May 22, 2019, at 3:10 PM, John Sullivan <johns@fsf.org> wrote:
> 
> J Lovejoy <opensource@jilayne.com> writes:
> 
>> 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 was late to subscribe and am just catching up on the conversation
> here, so apologies if I missed earlier explanation, but I remember
> discussing this issue a while back on either -legal or -general (I'll
> look when I have a few more moments). On https://spdx.org/ids-how it
> currently says:
> 
>> When a license defines a recommended notice to attach to files under
>> that license (sometimes called a "standard header"), the SPDX project
>> recommends that the standard header be included in the files, in
>> addition to an SPDX ID.
> 
>> Additionally, when a file already contains a standard header or other
>> license notice, the SPDX project recommends that those existing notices
>> should not be removed. The SPDX ID is recommended to be used to
>> supplement, not replace, existing notices in files.
> 
>> Like copyright notices, existing license texts and notices should be
>> retained, not replaced ‐ especially a third party's license notices.
> 
> -

John, 

that text is from the SPDX website and is very generalized, conservative and non-contextual. The reality we live in today is that people are choosing to use the SPDX identifiers in their files instead of the full license text (for MIT) or the standard license notice (for Apache-2.0 or GPL), etc. - this is good because SPDX identifiers are more concise and easier for tooling to parse. Even when there is a standard license header recommended, like the GPL has done, it doesn’t get faithfully reproduced which causes headaches for tooling to parse even when the intent is clear. This is what Thomas is dealing with and you can see the many examples of this on the many other emails on this list. 
 
The question Richard was posing (if I may paraphrase) if someone would have a viable argument for non-compliance with section 1 just for replacing a messy, but clear (in terms of what license variant applies) with an SPDX identifier. Considering that Stallman encouraged the use of the SPDX identifiers we adopted based on his concern for lack of clarity, I can hardly think that the FSF is now going to go back on that sentiment?

Thanks,
Jilayne

Re: Meta-question on GPL compliance of this activity

[Bradley M. Kuhn]

Greg KH wrote:
> Just use git history, we have it, why ignore it?

How do we reconcile the "keep intact all the notices" requirement with "the
info is in the Git history"?

Specifically:

Fontana and I are both worried about downstream users and their
susceptibility to license compliance infractions.  GPLv2 says: "keep intact
all the notices that refer to this License".

From my perspective, I'd prefer if GPLv2 said instead something like: "ensure
that downstream recipients are informed of the all notices that referred to
this License and are able to request them somehow".  But it doesn't, and we
can't change the text of GPLv2 (obviously).  I suspect that's one reason why
LF's SPDX project advises the text that John kindly brought to our attention.

Linux is not (usually) distributed with its full Git history passed along for
the distribution ride; i.e., most Linux distribution recipients *don't*
receive a copy to the Git repository with the copy of Linux they receive.

The requirement to keep the notices intact is an inconvenient truth we must
deal with before we move Thomas' patches upstream.
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/

Re: Meta-question on GPL compliance of this activity

[Thomas Gleixner]

On Wed, 22 May 2019, Bradley M. Kuhn wrote:
> Linux is not (usually) distributed with its full Git history passed along for
> the distribution ride; i.e., most Linux distribution recipients *don't*
> receive a copy to the Git repository with the copy of Linux they receive.

That's what tools are for. We can generate that list when generating the
tarball..

That has the advantage that it's matching the actual tree structure and is
not subject to bitrot. The bitrot part is important if you are worried
about this simply because there is no valid information once the list and
the file names/locations get out of sync. That's bound to happen and nobody
will ever do the whack a mole game of keeping it up to date.

Thanks,

	tglx

Re: Meta-question on GPL compliance of this activity

[Thomas Gleixner]

[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]

On Wed, 22 May 2019, J Lovejoy wrote:
> > On May 22, 2019, at 3:10 PM, John Sullivan <johns@fsf.org> wrote:
> >> When a license defines a recommended notice to attach to files under
> >> that license (sometimes called a "standard header"), the SPDX project
> >> recommends that the standard header be included in the files, in
> >> addition to an SPDX ID.
> > 
> >> Additionally, when a file already contains a standard header or other
> >> license notice, the SPDX project recommends that those existing notices
> >> should not be removed. The SPDX ID is recommended to be used to
> >> supplement, not replace, existing notices in files.
> > 
> >> Like copyright notices, existing license texts and notices should be
> >> retained, not replaced ‐ especially a third party's license notices.
> > 
> 
> that text is from the SPDX website and is very generalized, conservative
> and non-contextual. The reality we live in today is that people are
> choosing to use the SPDX identifiers in their files instead of the full
> license text (for MIT) or the standard license notice (for Apache-2.0 or
> GPL), etc. - this is good because SPDX identifiers are more concise and
> easier for tooling to parse. Even when there is a standard license
> header recommended, like the GPL has done, it doesn’t get faithfully
> reproduced which causes headaches for tooling to parse even when the
> intent is clear. This is what Thomas is dealing with and you can see the
> many examples of this on the many other emails on this list.

Just to add some more context why we are doing this:

The first and most important reason is that - as demonstrated with this
work already - the tools are lost on identifying the correct meaning of all
the 700+ variations of expressing just GPL licensing terms. We're not
talking about the other 80+ license variants (some of them are of dubious
nature) yet.

Right now as things stand it is simply _impossible_ for SMBs to do proper
license compliance on the kernel. That's a situation which we cannot
proliferate forever and waiting for everyone and his dog to clean that up
on their own will take at the current rate and interest 10 years plus. In
fact it will never finish because people are not longer reachable,
companies are gone ...

As long as that persists any company who cannot afford to pay the price for
wading through that mess manually is going to be an easy target for
licensing trolls.

But even companies who can afford it win a nice excuse why they did not
comply as its possible for them to demonstrate that they did all what they
could, but the unholy mess is responsible for them to fail. That has been
used as an argument successfully already :(

If we keep all the silly variants of license references/notices around and
just add SPDX identifieres then we are back to square one with this. For
compliance you have to scan EVERYTHING which looks like license
information. So then you end up with the same heuristic guesswork to figure
out whether the SPDX identifiers are matching the random mess we left in
place. IOW, we just kept the status quo and the SPDX identifier degenrated
to a hint.

I appreciate that lawyers are trying to minimize the risk, but can we
pretty please be pragmatic and keep the priority on making compliance
possible in the first place? That serves everyone, the contributors and the
down stream users.

FWIW, the same procedure (smaller scale) has been conducted on the u-boot
project a few years ago already and to the best of my knowledge nobody has
come forth and made a fuzz about that approach.

Thanks,

	Thomas

Re: Meta-question on GPL compliance of this activity

[Richard Fontana]

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

Re: Meta-question on GPL compliance of this activity

[Greg KH]

On Fri, May 24, 2019 at 12:33:22AM -0400, Richard Fontana wrote:
> > > 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.

It's not practical in any way at all.  Again, please realize the size of
our code base.

thanks,

greg k-h

Re: Meta-question on GPL compliance of this activity

[Allison Randal]

On 5/24/19 1:20 AM, Greg KH wrote:
> On Fri, May 24, 2019 at 12:33:22AM -0400, Richard Fontana wrote:
>>>> 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.
> 
> It's not practical in any way at all.  Again, please realize the size of
> our code base.

From what I can tell so far:

- everyone agrees that it's fine for the original copyright holder to
add an SPDX identifier instead of a messy text license notice and disclaimer

- everyone agrees that it's fine for the project to add SPDX identifiers
to existing files, with appropriate efforts to match whatever license(s)
would have applied to the files anyway

- everyone is pretty keen to remove the messy, inconsistent text license
notices and disclaimers, not just because they're trivially ugly, but
because they're actually a barrier to compliance

The lingering question is just how to satisfy the GPL's requirement to
"keep intact all the notices that refer to this License and to the
absence of any warranty", while avoiding horrible hacks and
unmaintainable manual effort.

I entirely sympathize with the idea that the git history alone should be
sufficient. But, I've dealt with enough lawyers, judges, and users over
the years to know that git history doesn't make much sense to people
outside our circle of developers, so it's better if whatever we do is
discoverable from a web search without any use of git tooling.

Out of everything discussed so far, I prefer the options that were:

- automatically generated from git history

- not checked into git

Which seems to leave the options of generating a condensed list of
historical notices from the git history and either:

- adding the generated file to the release tarball, or

- posting the generated file on some kernel.org domain (updated with
each release), and linking to it from some sensible doc file in the git
repo, possibly: Documentation/process/license-rules.rst


In my experience, Kernel teams for Linux distros tend to pull their
Kernel source from git rather than the tarballs anyway, so the second
method of posting the generated file is probably a more reliable way to
get the information passed through to the distros. Posting the generated
result outside the release tarball also means we can regenerate it at
any time, if we improve the tooling or find errors, instead of being
stuck forever with whatever generated file was inserted into each release.

Not a strong opinion, just what seems most effective and least horrible
to me.

Allison

Re: Meta-question on GPL compliance of this activity

[Richard Fontana]

On Fri, May 24, 2019 at 4:25 PM Allison Randal <allison@lohutok.net> wrote:

> From what I can tell so far:
>
> - everyone agrees that it's fine for the original copyright holder to
> add an SPDX identifier instead of a messy text license notice and disclaimer
>
> - everyone agrees that it's fine for the project to add SPDX identifiers
> to existing files, with appropriate efforts to match whatever license(s)
> would have applied to the files anyway
>
> - everyone is pretty keen to remove the messy, inconsistent text license
> notices and disclaimers, not just because they're trivially ugly, but
> because they're actually a barrier to compliance

Not to sidetrack discussion but I don't see how they're a barrier to
*true* compliance specifically for Linux. If you have the complete
corresponding source code for the Linux kernel, and you just assume
(as some of us do) it's licensed under GPLv2 and provide the source
code and chances are you'll be in compliance. And most noncompliant
Linux distributors are noncompliant because they aren't distributing
the source code (and thus they have nothing to run scanning tools on
or whatever).

Nevertheless I see a more general (beyond the Linux kernel) benefit to
adoption of legal notices in source code that can more easily be
understood by tools, and GPL-licensed projects in particular pose a
challenge to changing practices around source code license notices.
Which is partly why I am interested in and helping out a bit with this
work.

I know full well that "compliance" is being redefined by some
companies to mean "tabulating and cataloging detailed information
about licenses and copyrights covering open source software,
preferably in Excel spreadsheets", but I refuse to join in that
redefinition.

> The lingering question is just how to satisfy the GPL's requirement to
> "keep intact all the notices that refer to this License and to the
> absence of any warranty", while avoiding horrible hacks and
> unmaintainable manual effort.
>
> I entirely sympathize with the idea that the git history alone should be
> sufficient. But, I've dealt with enough lawyers, judges, and users over
> the years to know that git history doesn't make much sense to people
> outside our circle of developers, so it's better if whatever we do is
> discoverable from a web search without any use of git tooling.
>
> Out of everything discussed so far, I prefer the options that were:
>
> - automatically generated from git history
>
> - not checked into git
>
> Which seems to leave the options of generating a condensed list of
> historical notices from the git history and either:
>
> - adding the generated file to the release tarball, or
>
> - posting the generated file on some kernel.org domain (updated with
> each release), and linking to it from some sensible doc file in the git
> repo, possibly: Documentation/process/license-rules.rst
>
> In my experience, Kernel teams for Linux distros tend to pull their
> Kernel source from git rather than the tarballs anyway, so the second
> method of posting the generated file is probably a more reliable way to
> get the information passed through to the distros. Posting the generated
> result outside the release tarball also means we can regenerate it at
> any time, if we improve the tooling or find errors, instead of being
> stuck forever with whatever generated file was inserted into each release.
>
> Not a strong opinion, just what seems most effective and least horrible
> to me.

Sounds like a good suggestion. Perhaps alternatively or in addition, a
good faith effort can be undertaken to attempt to get licensor (more
specifically, nominal-copyright-holder) consent for these changes. It
doesn't have to be perfect or rushed. Was this idea considered but
abandoned? Not long ago Thomas asked me about a number of source files
with Red Hat copyrights, such as the ones that said "GPL'd" which
seemed particularly to irk him :) It seems like at this point you are
all giving up on the idea of checking with nominal copyright holders
... out of frustration or impatience I guess?

Richard

Re: Meta-question on GPL compliance of this activity

[Greg KH]

On Fri, May 24, 2019 at 04:24:25PM -0400, Allison Randal wrote:
> Which seems to leave the options of generating a condensed list of
> historical notices from the git history and either:
> 
> - adding the generated file to the release tarball, or

As the person who generates the release tarballs these days, this is
going to be tough.  It's an automated process that generates it directly
from the git tree itself so that anyone else can also do the same thing
and verify that what we released is identical to what the git tree has.

Reproducable builds are good to have :)

If I have to have the servers run some other script that magically
injects it into the tarball, that's going to be a big problem as it
makes verification of the tarball _much_ more difficult :(

> - posting the generated file on some kernel.org domain (updated with
> each release), and linking to it from some sensible doc file in the git
> repo, possibly: Documentation/process/license-rules.rst

We can do this, again, if it is something that is actually workable.

Again, remember we have over 65 thousand files in the kernel source
tree.  Any single file that tries to reference them all, in any form, is
going to be unworkable.  As a simple experiment, has anyone tried to run
something like 'reuse' on the kernel source tree today and seen what the
output is?  Good luck with that :)

thanks,

greg k-h

> In my experience, Kernel teams for Linux distros tend to pull their
> Kernel source from git rather than the tarballs anyway, so the second
> method of posting the generated file is probably a more reliable way to
> get the information passed through to the distros.

Why would a distro kernel package suck in a random file off of the web
that could change at any point in time and isn't obviously related to
the kernel tree itself (i.e. part of it?)

And wouldn't they really need to post their _OWN_ file as everyone who
ships a kernel changes it in some way (for good reasons.)  So
individuals would need to be able to generate their own file somehow.

Anyway, I'm trying to say that a "single file" is going to be a major
pain in the rear with almost no benefit that I can see.

Again, has anyone demanded such a thing from any other project that has
switched to only SPDX tags (like uboot?)

thanks,

greg k-h

Re: Meta-question on GPL compliance of this activity

[Allison Randal]

On 5/24/19 9:07 PM, Richard Fontana wrote:
> 
> Not to sidetrack discussion but I don't see how they're a barrier to
> *true* compliance specifically for Linux. If you have the complete
> corresponding source code for the Linux kernel, and you just assume
> (as some of us do) it's licensed under GPLv2 and provide the source
> code and chances are you'll be in compliance. And most noncompliant
> Linux distributors are noncompliant because they aren't distributing
> the source code (and thus they have nothing to run scanning tools on
> or whatever).
> 
> Nevertheless I see a more general (beyond the Linux kernel) benefit to
> adoption of legal notices in source code that can more easily be
> understood by tools, and GPL-licensed projects in particular pose a
> challenge to changing practices around source code license notices.
> Which is partly why I am interested in and helping out a bit with this
> work.

Sure, by "barrier" I didn't mean "impossible", just that it's more
difficult to comply if you aren't sure what licenses apply, and your
scanning tools are giving you garbled results.

> Sounds like a good suggestion. Perhaps alternatively or in addition, a
> good faith effort can be undertaken to attempt to get licensor (more
> specifically, nominal-copyright-holder) consent for these changes. It
> doesn't have to be perfect or rushed. Was this idea considered but
> abandoned? Not long ago Thomas asked me about a number of source files
> with Red Hat copyrights, such as the ones that said "GPL'd" which
> seemed particularly to irk him :) It seems like at this point you are
> all giving up on the idea of checking with nominal copyright holders
> ... out of frustration or impatience I guess?

I've seen enough projects waste years of human-hours on this, that it
seems reasonable to me to limit this activity to the really questionable
notices.

Allison

Re: Meta-question on GPL compliance of this activity

[Allison Randal]

On 5/25/19 12:56 PM, Greg KH wrote:
> 
> Again, remember we have over 65 thousand files in the kernel source
> tree.  Any single file that tries to reference them all, in any form, is
> going to be unworkable.

Yeah, we wouldn't be looking to track every single license notice change
throughout history, that wouldn't be reasonable. We want to narrow it
down to specific sets of changes that removed license notices and
replaced them with SPDX identifiers. And, ideally, display those with
the most minimal amount of information possible. It might even be
reasonable to generate the page as a list of links to the pretty diff
displays of the relevant commits, like:

https://github.com/torvalds/linux/commit/fd534e9b5fdcf9bab33c03cb3ade1a1ae5b23c20

That's the most faithful capture of the removed license notices we could
possibly provide, and is more accessible than simply saying that they're
in the git history. But, it might not satisfy the most conservative
definitions of "keep intact".

It seems like we're weighing effort against effectiveness here, but
without a clear definition of what effective means, other than our best
guess at how "keep intact" might be interpreted by someone, somewhere,
sometime.

Allison

Re: Meta-question on GPL compliance of this activity

[Dominik Brodowski]

On Mon, May 27, 2019 at 05:54:05PM -0400, Allison Randal wrote:
> On 5/25/19 12:56 PM, Greg KH wrote:
> > 
> > Again, remember we have over 65 thousand files in the kernel source
> > tree.  Any single file that tries to reference them all, in any form, is
> > going to be unworkable.
> 
> Yeah, we wouldn't be looking to track every single license notice change
> throughout history, that wouldn't be reasonable. We want to narrow it
> down to specific sets of changes that removed license notices and
> replaced them with SPDX identifiers. And, ideally, display those with
> the most minimal amount of information possible. It might even be
> reasonable to generate the page as a list of links to the pretty diff
> displays of the relevant commits, like:
> 
> https://github.com/torvalds/linux/commit/fd534e9b5fdcf9bab33c03cb3ade1a1ae5b23c20
> 
> That's the most faithful capture of the removed license notices we could
> possibly provide, and is more accessible than simply saying that they're
> in the git history. But, it might not satisfy the most conservative
> definitions of "keep intact".
> 
> It seems like we're weighing effort against effectiveness here, but
> without a clear definition of what effective means, other than our best
> guess at how "keep intact" might be interpreted by someone, somewhere,
> sometime.

Might it help (and reduce risks) to involve those who clearly hold copyrights
to a file, or who at least claim that they hold a copyright? In other words:
should these patches be CC'ed / BCC'ed (at least!) to those explicitly listed
as copyright holders in the files changed by each of these patches?

Thanks,
	Dominik

Re: Meta-question on GPL compliance of this activity

[John Sullivan]

Jilayne,

J Lovejoy <opensource@jilayne.com> writes:

>> On May 22, 2019, at 3:10 PM, John Sullivan <johns@fsf.org> wrote:
>> 
>> J Lovejoy <opensource@jilayne.com> writes:
>> 
>>> 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 was late to subscribe and am just catching up on the conversation
>> here, so apologies if I missed earlier explanation, but I remember
>> discussing this issue a while back on either -legal or -general (I'll
>> look when I have a few more moments). On https://spdx.org/ids-how it
>> currently says:
>> 
>>> When a license defines a recommended notice to attach to files under
>>> that license (sometimes called a "standard header"), the SPDX project
>>> recommends that the standard header be included in the files, in
>>> addition to an SPDX ID.
>> 
>>> Additionally, when a file already contains a standard header or other
>>> license notice, the SPDX project recommends that those existing notices
>>> should not be removed. The SPDX ID is recommended to be used to
>>> supplement, not replace, existing notices in files.
>> 
>>> Like copyright notices, existing license texts and notices should be
>>> retained, not replaced ‐ especially a third party's license notices.
>> 
>> -
>
> John, 
>
> that text is from the SPDX website and is very generalized,
> conservative and non-contextual. The reality we live in today is that
> people are choosing to use the SPDX identifiers in their files instead
> of the full license text (for MIT) or the standard license notice (for
> Apache-2.0 or GPL), etc. - this is good because SPDX identifiers are
> more concise and easier for tooling to parse. Even when there is a
> standard license header recommended, like the GPL has done, it doesn’t
> get faithfully reproduced which causes headaches for tooling to parse
> even when the intent is clear. This is what Thomas is dealing with and
> you can see the many examples of this on the many other emails on this
> list.
>
> The question Richard was posing (if I may paraphrase) if someone would
> have a viable argument for non-compliance with section 1 just for
> replacing a messy, but clear (in terms of what license variant
> applies) with an SPDX identifier. Considering that Stallman encouraged
> the use of the SPDX identifiers we adopted based on his concern for
> lack of clarity, I can hardly think that the FSF is now going to go
> back on that sentiment?
>

I totally get that nonstandard notices that have already been accepted
are a problem. It's an annoying problem to deal with and I'm not trying
to take anything away from the effort Thomas and others here are putting
into this -- it's in the category of thankless work that we need a lot
more of.

I do think removing notices raises GPL compliance questions, for the
same reasons Allison outlined.

Project copyrightholders can as always make their own decisions about
questions like this. What Linux does will be looked to by others as a
practice to model, so I'm interested to participate in the conversation
here for that reason (I see there are also a few cases of actual FSF
copyrighted materials up for consideration, so will try to watch for
those but would also appreciate a ping if anyone can spare one as they
come up).

As for FSF's overall recommendation for SPDX -- I wasn't raising any
issue there. I'm assuming that SPDX isn't going back on the public
recommendation to keep notices intact that's been there throughout our
conversations; I know that SPDX doesn't control how projects may decide
to use parts of the system. FSF recommends SPDX because it is a very
useful and consistent addition to our set of licensing best practice
recommendations -- which also include file-level notices.

-john

-- 
John Sullivan | Executive Director, Free Software Foundation
GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B
https://status.fsf.org/johns | https://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
<https://my.fsf.org/join>.

Re: Meta-question on GPL compliance of this activity

[Greg KH]

On Wed, May 29, 2019 at 04:57:20PM -0400, John Sullivan wrote:
> Project copyrightholders can as always make their own decisions about
> questions like this. What Linux does will be looked to by others as a
> practice to model, so I'm interested to participate in the conversation
> here for that reason (I see there are also a few cases of actual FSF
> copyrighted materials up for consideration, so will try to watch for
> those but would also appreciate a ping if anyone can spare one as they
> come up).

To help address any issues that you might have with your own files being
modified, could you please just submit a patch to add the proper SPDX
header and place whatever text you feel is "correct" in them?  That way
you know your files are fine.

I'll gladly review and submit any patches you create for this, it would
be most helpful.  Same offer to any other copyright holder (Richard,
want to do this for all Red Hat owned files?)

Note, other copyright holders have already done this, you will note that
there are many subsystems/areas of the kernel that are already cleaned
up because of this.

thanks,

greg k-h

Re: Meta-question on GPL compliance of this activity

[John Sullivan]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Wed, May 29, 2019 at 04:57:20PM -0400, John Sullivan wrote:
>> Project copyrightholders can as always make their own decisions about
>> questions like this. What Linux does will be looked to by others as a
>> practice to model, so I'm interested to participate in the conversation
>> here for that reason (I see there are also a few cases of actual FSF
>> copyrighted materials up for consideration, so will try to watch for
>> those but would also appreciate a ping if anyone can spare one as they
>> come up).
>
> To help address any issues that you might have with your own files being
> modified, could you please just submit a patch to add the proper SPDX
> header and place whatever text you feel is "correct" in them?  That way
> you know your files are fine.
>
> I'll gladly review and submit any patches you create for this, it would
> be most helpful.  Same offer to any other copyright holder (Richard,
> want to do this for all Red Hat owned files?)
>

Yes, that is reasonable and I'll arrange for that.

I'd like to avoid the race condition though, so also asking for any
patches that may get circulated here to be flagged and held.

-john

-- 
John Sullivan | Executive Director, Free Software Foundation
GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B
https://status.fsf.org/johns | https://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
<https://my.fsf.org/join>.

Re: Meta-question on GPL compliance of this activity

[Richard Fontana]

On Wed, May 29, 2019 at 5:31 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> To help address any issues that you might have with your own files being
> modified, could you please just submit a patch to add the proper SPDX
> header and place whatever text you feel is "correct" in them?  That way
> you know your files are fine.
>
> I'll gladly review and submit any patches you create for this, it would
> be most helpful.  Same offer to any other copyright holder (Richard,
> want to do this for all Red Hat owned files?)

Sure, I can do that.

Richard

Re: Meta-question on GPL compliance of this activity

[Greg KH]

On Fri, May 31, 2019 at 11:22:44PM -0400, John Sullivan wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Wed, May 29, 2019 at 04:57:20PM -0400, John Sullivan wrote:
> >> Project copyrightholders can as always make their own decisions about
> >> questions like this. What Linux does will be looked to by others as a
> >> practice to model, so I'm interested to participate in the conversation
> >> here for that reason (I see there are also a few cases of actual FSF
> >> copyrighted materials up for consideration, so will try to watch for
> >> those but would also appreciate a ping if anyone can spare one as they
> >> come up).
> >
> > To help address any issues that you might have with your own files being
> > modified, could you please just submit a patch to add the proper SPDX
> > header and place whatever text you feel is "correct" in them?  That way
> > you know your files are fine.
> >
> > I'll gladly review and submit any patches you create for this, it would
> > be most helpful.  Same offer to any other copyright holder (Richard,
> > want to do this for all Red Hat owned files?)
> >
> 
> Yes, that is reasonable and I'll arrange for that.

Great!

> I'd like to avoid the race condition though, so also asking for any
> patches that may get circulated here to be flagged and held.

If you happen to notice them and flag them, that's fine.  But kernel
development is very much not "don't touch my file!" type of methodology.
That is what killed other open source projects, it is "first in-first
applied".

If you happen to miss any such file in these huge cleanups, that's fine,
just go back later and send a patch fixing it up to be whatever you
want, but we can't special-case anyone here, it's just not going to be
viable.

Just take an hour or so today and knock them out, you all already have
the list of all of your copyrighted files, so this shouldn't be much
work at all.  I'll be glad to queue that up with the rest of these types
of changes.

thanks,

greg k-h

[Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Thomas Gleixner]

Folks!
References: <20220606194042.428568932@linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Based on the normalized pattern:

    this program is free software you can redistribute it and/or modify it
    under the terms of version 2 of the gnu general public license as
    published by the free software foundation  this program is distributed
    in the hope that it will be useful all express or implied conditions
    representations and warranties including any implied warranty of
    merchantability fitness for a particular purpose or non-infringement
    are disclaimed except to the extent that such disclaimers are held to
    be legally invalid see the gnu general public license for more details
    a copy of which can be found in the file copying included with this
    package

extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

has been chosen to replace the boilerplate/reference.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/scsi/be2iscsi/be_mgmt.c    |   14 +-------------
 drivers/scsi/lpfc/Makefile         |   12 +-----------
 drivers/scsi/lpfc/lpfc.h           |   12 +-----------
 drivers/scsi/lpfc/lpfc_attr.c      |   12 +-----------
 drivers/scsi/lpfc/lpfc_attr.h      |   12 +-----------
 drivers/scsi/lpfc/lpfc_bsg.c       |   12 +-----------
 drivers/scsi/lpfc/lpfc_bsg.h       |   12 +-----------
 drivers/scsi/lpfc/lpfc_compat.h    |   12 +-----------
 drivers/scsi/lpfc/lpfc_crtn.h      |   12 +-----------
 drivers/scsi/lpfc/lpfc_ct.c        |   12 +-----------
 drivers/scsi/lpfc/lpfc_debugfs.c   |   12 +-----------
 drivers/scsi/lpfc/lpfc_debugfs.h   |   12 +-----------
 drivers/scsi/lpfc/lpfc_disc.h      |   12 +-----------
 drivers/scsi/lpfc/lpfc_els.c       |   12 +-----------
 drivers/scsi/lpfc/lpfc_hbadisc.c   |   12 +-----------
 drivers/scsi/lpfc/lpfc_hw.h        |   12 +-----------
 drivers/scsi/lpfc/lpfc_hw4.h       |   12 +-----------
 drivers/scsi/lpfc/lpfc_ids.h       |   12 +-----------
 drivers/scsi/lpfc/lpfc_logmsg.h    |   12 +-----------
 drivers/scsi/lpfc/lpfc_mbox.c      |   13 +------------
 drivers/scsi/lpfc/lpfc_mem.c       |   12 +-----------
 drivers/scsi/lpfc/lpfc_nl.h        |   13 +------------
 drivers/scsi/lpfc/lpfc_nportdisc.c |   12 +-----------
 drivers/scsi/lpfc/lpfc_nvme.c      |   12 +-----------
 drivers/scsi/lpfc/lpfc_nvme.h      |   12 +-----------
 drivers/scsi/lpfc/lpfc_nvmet.c     |   12 +-----------
 drivers/scsi/lpfc/lpfc_scsi.c      |   12 +-----------
 drivers/scsi/lpfc/lpfc_scsi.h      |   13 +------------
 drivers/scsi/lpfc/lpfc_sli.c       |   12 +-----------
 drivers/scsi/lpfc/lpfc_sli.h       |   12 +-----------
 drivers/scsi/lpfc/lpfc_sli4.h      |   12 +-----------
 drivers/scsi/lpfc/lpfc_version.h   |   12 +-----------
 drivers/scsi/lpfc/lpfc_vmid.c      |   12 +-----------
 drivers/scsi/lpfc/lpfc_vport.c     |   12 +-----------
 drivers/scsi/lpfc/lpfc_vport.h     |   12 +-----------
 35 files changed, 35 insertions(+), 390 deletions(-)

--- a/drivers/scsi/be2iscsi/be_mgmt.c
+++ b/drivers/scsi/be2iscsi/be_mgmt.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * This file is part of the Emulex Linux Device Driver for Enterprise iSCSI
  * Host Bus Adapters. Refer to the README file included with this package
@@ -6,21 +7,8 @@
  * Copyright (c) 2018 Broadcom. All Rights Reserved.
  * The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.
  *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of version 2 of the GNU General Public License as published
- * by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful. ALL EXPRESS
- * OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY
- * IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
- * OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH
- * DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
- * See the GNU General Public License for more details, a copy of which
- * can be found in the file COPYING included with this package.
- *
  * Contact Information:
  * linux-drivers@broadcom.com
- *
  */
 
 #include <linux/bsg-lib.h>
--- a/drivers/scsi/lpfc/Makefile
+++ b/drivers/scsi/lpfc/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
 #/*******************************************************************
 # * This file is part of the Emulex Linux Device Driver for         *
 # * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
 # * EMULEX and SLI are trademarks of Emulex.                        *
 # * www.broadcom.com                                                *
 # *                                                                 *
-# * This program is free software; you can redistribute it and/or   *
-# * modify it under the terms of version 2 of the GNU General       *
-# * Public License as published by the Free Software Foundation.    *
-# * This program is distributed in the hope that it will be useful. *
-# * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
-# * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
-# * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
-# * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
-# * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
-# * more details, a copy of which can be found in the file COPYING  *
-# * included with this package.                                     *
 # *******************************************************************/
 ######################################################################
 
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <scsi/scsi_host.h>
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/ctype.h>
--- a/drivers/scsi/lpfc/lpfc_attr.h
+++ b/drivers/scsi/lpfc/lpfc_attr.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #define LPFC_ATTR(name, defval, minval, maxval, desc) \
--- a/drivers/scsi/lpfc/lpfc_bsg.c
+++ b/drivers/scsi/lpfc/lpfc_bsg.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/interrupt.h>
--- a/drivers/scsi/lpfc/lpfc_bsg.h
+++ b/drivers/scsi/lpfc/lpfc_bsg.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 /* bsg definitions
  * No pointers to user data are allowed, all application buffers and sizes will
--- a/drivers/scsi/lpfc/lpfc_compat.h
+++ b/drivers/scsi/lpfc/lpfc_compat.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 /*
--- a/drivers/scsi/lpfc/lpfc_crtn.h
+++ b/drivers/scsi/lpfc/lpfc_crtn.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 typedef int (*node_filter)(struct lpfc_nodelist *, void *);
--- a/drivers/scsi/lpfc/lpfc_ct.c
+++ b/drivers/scsi/lpfc/lpfc_ct.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 /*
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/blkdev.h>
--- a/drivers/scsi/lpfc/lpfc_debugfs.h
+++ b/drivers/scsi/lpfc/lpfc_debugfs.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #ifndef _H_LPFC_DEBUG_FS
--- a/drivers/scsi/lpfc/lpfc_disc.h
+++ b/drivers/scsi/lpfc/lpfc_disc.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #define FC_MAX_HOLD_RSCN     32	      /* max number of deferred RSCNs */
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 /* See Fibre Channel protocol T11 FC-LS for details */
 #include <linux/blkdev.h>
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/blkdev.h>
--- a/drivers/scsi/lpfc/lpfc_hw.h
+++ b/drivers/scsi/lpfc/lpfc_hw.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #define FDMI_DID        0xfffffaU
--- a/drivers/scsi/lpfc/lpfc_hw4.h
+++ b/drivers/scsi/lpfc/lpfc_hw4.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <uapi/scsi/fc/fc_fs.h>
--- a/drivers/scsi/lpfc/lpfc_ids.h
+++ b/drivers/scsi/lpfc/lpfc_ids.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/pci.h>
--- a/drivers/scsi/lpfc/lpfc_logmsg.h
+++ b/drivers/scsi/lpfc/lpfc_logmsg.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #define LOG_ELS		0x00000001	/* ELS events */
--- a/drivers/scsi/lpfc/lpfc_mbox.c
+++ b/drivers/scsi/lpfc/lpfc_mbox.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/blkdev.h>
@@ -2668,4 +2658,3 @@ lpfc_resume_rpi(struct lpfcMboxq *mbox,
 	bf_set(lpfc_resume_rpi_ii, resume_rpi, RESUME_INDEX_RPI);
 	resume_rpi->event_tag = ndlp->phba->fc_eventTag;
 }
-
--- a/drivers/scsi/lpfc/lpfc_mem.c
+++ b/drivers/scsi/lpfc/lpfc_mem.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/mempool.h>
--- a/drivers/scsi/lpfc/lpfc_nl.h
+++ b/drivers/scsi/lpfc/lpfc_nl.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 /* Event definitions for RegisterForEvent */
@@ -178,4 +168,3 @@ struct temp_event {
 	uint32_t event_code;
 	uint32_t data;
 };
-
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/blkdev.h>
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  ********************************************************************/
 #include <linux/pci.h>
 #include <linux/slab.h>
--- a/drivers/scsi/lpfc/lpfc_nvme.h
+++ b/drivers/scsi/lpfc/lpfc_nvme.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  ********************************************************************/
 
 #include <linux/nvme.h>
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  ********************************************************************/
 #include <linux/pci.h>
 #include <linux/slab.h>
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 #include <linux/pci.h>
 #include <linux/slab.h>
--- a/drivers/scsi/lpfc/lpfc_scsi.h
+++ b/drivers/scsi/lpfc/lpfc_scsi.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <asm/byteorder.h>
@@ -150,4 +140,3 @@ struct lpfc_scsicmd_bkt {
 
 /* For sysfs/debugfs tmp string max len */
 #define LPFC_MAX_SCSI_INFO_TMP_LEN	79
-
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/blkdev.h>
--- a/drivers/scsi/lpfc/lpfc_sli.h
+++ b/drivers/scsi/lpfc/lpfc_sli.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #if defined(CONFIG_DEBUG_FS) && !defined(CONFIG_SCSI_LPFC_DEBUG_FS)
--- a/drivers/scsi/lpfc/lpfc_sli4.h
+++ b/drivers/scsi/lpfc/lpfc_sli4.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/irq_poll.h>
--- a/drivers/scsi/lpfc/lpfc_version.h
+++ b/drivers/scsi/lpfc/lpfc_version.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -7,17 +8,6 @@
  * EMULEX and SLI are trademarks of Emulex.                        *
  * www.broadcom.com                                                *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #define LPFC_DRIVER_VERSION "14.2.0.3"
--- a/drivers/scsi/lpfc/lpfc_vmid.c
+++ b/drivers/scsi/lpfc/lpfc_vmid.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/interrupt.h>
--- a/drivers/scsi/lpfc/lpfc_vport.c
+++ b/drivers/scsi/lpfc/lpfc_vport.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #include <linux/blkdev.h>
--- a/drivers/scsi/lpfc/lpfc_vport.h
+++ b/drivers/scsi/lpfc/lpfc_vport.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*******************************************************************
  * This file is part of the Emulex Linux Device Driver for         *
  * Fibre Channel Host Bus Adapters.                                *
@@ -8,17 +9,6 @@
  * www.broadcom.com                                                *
  * Portions Copyright (C) 2004-2005 Christoph Hellwig              *
  *                                                                 *
- * This program is free software; you can redistribute it and/or   *
- * modify it under the terms of version 2 of the GNU General       *
- * Public License as published by the Free Software Foundation.    *
- * This program is distributed in the hope that it will be useful. *
- * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND          *
- * WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,  *
- * FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE      *
- * DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD *
- * TO BE LEGALLY INVALID.  See the GNU General Public License for  *
- * more details, a copy of which can be found in the file COPYING  *
- * included with this package.                                     *
  *******************************************************************/
 
 #ifndef _H_LPFC_VPORT

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Richard Fontana]

On Mon, Jun 6, 2022 at 3:58 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Folks!
> References: <20220606194042.428568932@linutronix.de>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
>
> Based on the normalized pattern:
>
>     this program is free software you can redistribute it and/or modify it
>     under the terms of version 2 of the gnu general public license as
>     published by the free software foundation  this program is distributed
>     in the hope that it will be useful all express or implied conditions
>     representations and warranties including any implied warranty of
>     merchantability fitness for a particular purpose or non-infringement
>     are disclaimed except to the extent that such disclaimers are held to
>     be legally invalid see the gnu general public license for more details
>     a copy of which can be found in the file copying included with this
>     package

I forget how we dealt with things like this in the initial large batch
some years ago but I remember raising the concern that some bespoke
license notices contained disclaimer language that was arguably
materially different in some way from what is found in GPLv2 itself.
This might be another example. I think in some such cases we at least
considered preserving the nonstandard disclaimer language.

Richard

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Thomas Gleixner]

On Mon, Jun 06 2022 at 16:11, Richard Fontana wrote:
> On Mon, Jun 6, 2022 at 3:58 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> Based on the normalized pattern:
>>
>>     this program is free software you can redistribute it and/or modify it
>>     under the terms of version 2 of the gnu general public license as
>>     published by the free software foundation  this program is distributed
>>     in the hope that it will be useful all express or implied conditions
>>     representations and warranties including any implied warranty of
>>     merchantability fitness for a particular purpose or non-infringement
>>     are disclaimed except to the extent that such disclaimers are held to
>>     be legally invalid see the gnu general public license for more details
>>     a copy of which can be found in the file copying included with this
>>     package
>
> I forget how we dealt with things like this in the initial large batch
> some years ago but I remember raising the concern that some bespoke
> license notices contained disclaimer language that was arguably
> materially different in some way from what is found in GPLv2 itself.
> This might be another example. I think in some such cases we at least
> considered preserving the nonstandard disclaimer language.

IIRC, there was no real conclusion aside of dealing with this later :)

One way would be to talk to the original author (if still reachable) and
ask for clarification/permission to remove it. In this case Broadcom.

Thanks,

        tglx

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Bradley M. Kuhn]

> On Mon, Jun 6, 2022 at 3:58 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> > Based on the normalized pattern:
> >     this program is free software you can redistribute it and/or modify it
> >     under the terms of version 2 of the gnu general public license as
> >     published by the free software foundation  this program is distributed
> >     in the hope that it will be useful all express or implied conditions
> >     representations and warranties including any implied warranty of
> >     merchantability fitness for a particular purpose or non-infringement
> >     are disclaimed except to the extent that such disclaimers are held to
> >     be legally invalid see the gnu general public license for more details
> >     a copy of which can be found in the file copying included with this
> >     package

Richard Fontana replied today:
> I forget how we dealt with things like this in the initial large batch some
> years ago but I remember raising the concern that some bespoke license
> notices contained disclaimer language that was arguably materially
> different in some way from what is found in GPLv2 itself.

I'm not surprised this is coming up again.  This is a critical bug in the
linux-spdx approach that Karen and I had raised early on — regarding the
GPLv2§1 requirement that one must “keep intact all the notices that refer to
this License and to the absence of any warranty”.

There are various approaches to resolving this that perhaps we should discuss
again?


 -- bkuhn

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Bradley M. Kuhn]

On Mon, Jun 06 2022 at 16:11, Richard Fontana wrote:
> > I forget how we dealt with things like this in the initial large batch
> > some years ago but I remember raising the concern that some bespoke
> > license notices contained disclaimer language that was arguably
> > materially different in some way from what is found in GPLv2 itself.

Thomas Gleixner replied last night:
>>>> IIRC, there was no real conclusion aside of dealing with this later :)

A solution was found, and agreed to in Barcelona in April 2019, but then
wasn't implemented.  Then, you (Thomas) and Allison suggested a useful
alternative, but AFAIK that too was tabled.  That leaves most Linux
distributions out of compliance with GPLv2 in the meantime.  Details below:

 * * *

Fontana started a linux-spdx thread on 2019-05-19 with the subject line of
“Meta-question on GPL compliance of this activity”, saying:
>> I was at the LLW event in Barcelona last month but unfortunately did not
>> attend the workshop relating to this activity …
>> GPLv2 section 1 says: "… keep intact all the notices that refer to this
>> License and to the absence of any warranty; and give any other recipients
>> of the Program a copy of this License along with the Program."… 

>> I have recently heard the argument that replacing a more or less standard
>> old-school GNU license notice … with an SPDX license identifier string,
>> without explicit permission from the copyright holder, complies with this
>> condition …  However, more conservative interpreters of GPLv2, including
>> some copyright holders, might argue otherwise.

>> The discovery of GPL notices juxtaposed with warranty disclaimers
>> imported from non-GPL licenses, or warranty disclaimers that otherwise go
>> beyond what is called out in GPLv2 and the traditional GNU license
>> notice, also raises the question of whether this list's work is strictly
>> compliant with the quoted language from GPLv2 section 1.

On 2019-05-21, I replied summarizing the decision from the 2019-04 meeting:
> 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.

Note that was a full consensus — and it included the opinion of many
prominent FOSS lawyers (who were attending under the Chatham House Rule
imposed on that meeting) — that keeping the notices intact somewhere in the
tree (not just in the Git repository) was essential.

Greg KH was the only objector to the solution, replying on 2019-05-22:
>>> So that's just not going to be possible … 
>>> Just use git history, we have it, why ignore it?

Given that linux-spdx now uses that approach (i.e., the Git history is the
only place that these notices can be found), under GPLv2§1, it now means
that all downstream redistributors of Linux must include the entire Git
repository as part of the complete, corresponding source (CCS).  That seems
like it is actually more inconvenient to more people than writing the tool
to generate the notice file (see below).

In response to Greg's concerns, Thomas made this excellent suggestion:
>>>> That's what tools are for. We can generate that list when generating the
>>>> tarball.. 
(… and Allison Randal endorsed this idea in on 2019-05-24)

The thread continued on, with Greg raising concerns that putting the notices
in the release tarball would still be difficult, and Thomas and Allison made
a counter-proposal that the list of notices (as described above) could go on
a stable kernel.org URL for each release, and that just the URL is noted as
the place to find full notices in the tarball itself.

*But*, until (a) that tool exists to auto-generate the notices, and (b) the
tarballs contain that URL in them, the Git repository as a whole *is now
required* as part of the CCS for Linux per GPLv2§1.

Fontana followed up later in the 2019 thread, (after work began) to say:
>> I believe this group needs to address [this notice issue] head-on and
>> openly, …  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.

I'm glad Fontana is doing the latter, and that he brought up this issue
again now.  As can be seen from the list archives and Git history, neither I
nor anyone from Software Freedom Conservancy has signed-off any linux-spdx
patches.  We can't in good conscience sign-off on patches that currently
cause *more* GPLv2 violations (even if they are minor infractions).  This
problem needs attention for linux-spdx to achieve its goals.


    -- bkuhn

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Thomas Gleixner]

Bradley,

On Tue, Jun 07 2022 at 11:12, Bradley M. Kuhn wrote:
> Fontana started a linux-spdx thread on 2019-05-19 with the subject line of
> “Meta-question on GPL compliance of this activity”, saying:
>>> I was at the LLW event in Barcelona last month but unfortunately did not
>>> attend the workshop relating to this activity …
>>> GPLv2 section 1 says: "… keep intact all the notices that refer to this
>>> License and to the absence of any warranty; and give any other recipients
>>> of the Program a copy of this License along with the Program."… 
>
>>> I have recently heard the argument that replacing a more or less standard
>>> old-school GNU license notice … with an SPDX license identifier string,
>>> without explicit permission from the copyright holder, complies with this
>>> condition …  However, more conservative interpreters of GPLv2, including
>>> some copyright holders, might argue otherwise.
>
>>> The discovery of GPL notices juxtaposed with warranty disclaimers
>>> imported from non-GPL licenses, or warranty disclaimers that otherwise go
>>> beyond what is called out in GPLv2 and the traditional GNU license
>>> notice, also raises the question of whether this list's work is strictly
>>> compliant with the quoted language from GPLv2 section 1.

What we have done so far is:

  1) Add SPDX license identifiers to files which have no license
     reference/notice/... at all

  2) Replace bog standard boilerplates

     Quite some of these replacements have been reviewed by Richard as
     documented in the changelogs and the mailing list archive.

     So far I haven't seen any complaint from more conservative
     interpreters or from copyrights holders which disagreed with that
     approach and requested any of those changes to be reverted.

     All I have seen so far is handwaving worryguts.

We did _not_ remove/replace any of the oddball GPLv2 plus magic
disclaimer parts or any other non-standard license boilerplate yet.

The fact that I resent some of those match patterns now does not change
that. The whole purpose of this exercise is to have enough eyeballs on
these patches to catch those cases, sort them out and decide how to deal
with them.

> On 2019-05-21, I replied summarizing the decision from the 2019-04 meeting:
>> 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.
>
> Note that was a full consensus — and it included the opinion of many
> prominent FOSS lawyers (who were attending under the Chatham House Rule
> imposed on that meeting) — that keeping the notices intact somewhere in the
> tree (not just in the Git repository) was essential.

Note that the full consensus of all these prominent lawyers becomes only
useful when they agree on something pragmatic which is actually
resolving the situation. Having full consensus on unactionable solutions
is a pointless exercise.

There was also full consensus many years before 2019 that the licensing
situation has to be cleaned up along with the conclusion that this needs
to be done with the help of those companies and their respective lawyers
who inflicted the mess in the first place. This has been discussed and
concluded to death with no outcome.

I surely can count the number of lawyers who actually helped with this
effort on _one_ hand. The number of corporate developers who were
involved in cleaning this up is not impressive either.

I've got promised access to a full audited license database for the
kernel way before 2019 from the very same crowd attending the legal
workshop in Barcelona. That still has not materialized as of today.

What I've got are a couple of private mails from corporate lawyers
asking why the SPDX efforts have been stalled since summer 2019. When I
told them that I ran out of copious spare time they never answered back.
I'm pretty confident that some of those lawyers were part of the full
consensus you mentioned.

> Greg KH was the only objector to the solution, replying on 2019-05-22:
>>>> So that's just not going to be possible … 
>>>> Just use git history, we have it, why ignore it?

Greg was not the only objector. There was no need to repeat the obvious
and the resulting discussion clearly showed that.

> Given that linux-spdx now uses that approach (i.e., the Git history is the
> only place that these notices can be found), under GPLv2§1, it now means
> that all downstream redistributors of Linux must include the entire Git
> repository as part of the complete, corresponding source (CCS).  That seems
> like it is actually more inconvenient to more people than writing the tool
> to generate the notice file (see below).

That's not a problem the Linux kernel introduced.

U-Boot did a wholesale SPDX conversion back in 2013 which removed every
boilerplate including non-standard disclaimers and obscure license
notices/references.

As a matter of fact, none of these changes in the U-Boot tree has been
reverted or challenged since 2013.

How is the industry dealing with that?

   1) Not having noticed within 9 years?

   2) Simply ignoring the problem?

   3) Shipping the git repository?

   4) Using the magic tool which nobody is willing to write?

Whatever the answer is, it's going to be very conclusive and I'm really
looking forward to it.

> In response to Greg's concerns, Thomas made this excellent suggestion:
>>>>> That's what tools are for. We can generate that list when generating the
>>>>> tarball.. 
> (… and Allison Randal endorsed this idea in on 2019-05-24)
>
> The thread continued on, with Greg raising concerns that putting the notices
> in the release tarball would still be difficult, and Thomas and Allison made
> a counter-proposal that the list of notices (as described above) could go on
> a stable kernel.org URL for each release, and that just the URL is noted as
> the place to find full notices in the tarball itself.
>
> *But*, until (a) that tool exists to auto-generate the notices, and (b) the
> tarballs contain that URL in them, the Git repository as a whole *is now
> required* as part of the CCS for Linux per GPLv2§1.

We all discussed options for solving this, but that does not mean that
the task to create such a tool has been assigned to anyone or that
anyone volunteered to take it on.

There was plenty of time for all involved parties, especially those who
are complaining most to sit down themself or pay someone to get it done.

> Fontana followed up later in the 2019 thread, (after work began) to say:
>>> I believe this group needs to address [this notice issue] head-on and
>>> openly, …  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.
>
> I'm glad Fontana is doing the latter, and that he brought up this issue
> again now.

What's the point? Richards objections were expected.

As I said above: This is the purpose of this list. I'm just providing
coarse filtered data to analyse. If problems are detected and pointed
out the changes are put aside and have to be dealt with seperately.

We've been very consistent with this since this effort started as can
be seen from the list archives and git history.

> As can be seen from the list archives and Git history, neither I
> nor anyone from Software Freedom Conservancy has signed-off any linux-spdx
> patches.  We can't in good conscience sign-off on patches that currently
> cause *more* GPLv2 violations (even if they are minor infractions).  This
> problem needs attention for linux-spdx to achieve its goals.

Duly noted.

Thanks,

        tglx

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Allison Randal]

On 6/7/22 19:05, Thomas Gleixner wrote:
> On Tue, Jun 07 2022 at 11:12, Bradley M. Kuhn wrote:
>>
>> Note that was a full consensus — and it included the opinion of many
>> prominent FOSS lawyers (who were attending under the Chatham House Rule
>> imposed on that meeting) — that keeping the notices intact somewhere in the
>> tree (not just in the Git repository) was essential.
> 
> Note that the full consensus of all these prominent lawyers becomes only
> useful when they agree on something pragmatic which is actually
> resolving the situation. Having full consensus on unactionable solutions
> is a pointless exercise.
> 
> There was also full consensus many years before 2019 that the licensing
> situation has to be cleaned up along with the conclusion that this needs
> to be done with the help of those companies and their respective lawyers
> who inflicted the mess in the first place. This has been discussed and
> concluded to death with no outcome.

My perspective here is shaped by my experiences with lawyers and 
contributor agreements. In the early 2000s, as a leader of a free 
software foundation, I was explicitly told by a number of lawyers that 
unless we had a signed contributor agreement from every contributor, the 
free software project had no right to distribute those contributions. 
Part of a lawyer's job is to advise their clients based on their best 
understanding of the law and common practice, and those lawyers were 
doing exactly that, based on their experience in corporate law, so to a 
certain extent I can't fault them for doing their job to the best of 
their ability. But, while they were giving their best assessment of what 
*could be* true at the time, what they weren't doing was thinking about 
what *should be* true, in the context of free software. Both the law and 
common practice evolve over time, and we need to be intelligent about 
evaluating both what *could be* true at the moment, and what *should be* 
true in the long term. The concepts of inbound=outbound, DCO, and 
signed-off-by are now common practice, but getting there required some 
clever insight by some lawyers who really understoond free software, and 
also consistent practice by projects over time.

With that context in mind: One reasonable interpretation of “keep intact 
all the notices that refer to this License and to the absence of any 
warranty” could be to say that the exact text must be preserved, exactly 
as it was typed at the dawn of time, including any typos, inaccurate 
street addresses, etc. Another reasonable interpretation is that the 
notices serve to link a license to the file, and declare that the legal 
terms of the entire GPL license govern that file, and so what must be 
preserved is the link. Current practice is closer to the second, people 
feel free to throw in whatever garbled variant of the notice text FSF 
recommends, because they know that what really matters is the text of 
the GPL, which is invariant and has been carefully reviewed by lawyers. 
We absolutely want to make sure that people don't strip off the link to 
the GPL license, and use the file or its contents under terms other than 
the GPL, that is the legal purpose we're trying to achieve.

For a new file, adding the FSF notice, or adding some garbled version 
that still has the same terms as the GPL and FSF notice, or adding the 
SPDX license identifier are all legally equivalent ways of declaring 
that the file is subject to the terms of the GPL license. In terms of 
common practice, the SPDX identifier is actually superior because it's 
clear, consistent, machine readable, and limits the scope of garbled 
variations introduced by humans. (Humans actually manage to garble even 
those few characters of the SPDX identifier, but since it's machine 
readable, it's also machine checkable, so easy to kick back an error and 
say "that's not a valid SPDX identifier, did you mean X or Y?")

If the full text notice and SPDX identifier are legally equivalent, then 
can they legally be substituted in an existing file? There is a 
reasonable interpretation to say that *could be* allowed, but a more 
important question here is whether that *should be* allowed. Allowing it 
does no harm, the full terms of the GPL apply to the file with either 
the full text notice or the SPDX identifier. Allowing it is good for the 
cause of free software and for GPL enforcement, because it cleans up 
confusing cruft from historical human inconsistencies, and clearly 
declares the legal terms that apply to the file. So, I would argue that 
substituting SPDX identifiers for text notices should be allowed (as 
long as the text notice has the same terms as the GPL itself). While 
substituting SPDX identifiers might not be common practice yet, the way 
we make it common practice is by practicing it repeatedly until it 
becomes common.

It's also worth noting that there's isn't any risk of a "point of no 
return" here. When Thomas and I say that the changes are all in git 
history, we aren't saying that we expect everyone to read the entire 
history. What we're saying is that it's easy to write a tool to scan the 
entire history, and generate a file that lists every file that had an 
SPDX identifier substituted under every match rule, if we decide that's 
actually necessary at some point. It really, really shouldn't be 
necessary (any more than contributor agreements are necessary), but it's 
reassuring to know have options.

Allison

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Bradley M. Kuhn]

Thomas Gleixner wrote:
> What I've got are a couple of private mails from corporate lawyers asking
> why the SPDX efforts have been stalled since summer 2019. When I told them
> that I ran out of copious spare time they never answered back.

Obviously they should fund the tool to make the proper notice file.  If you
want to introduce me and Fontana to the corporate lawyers asking why
linux-spdx is stalled, while I can't speak for Fontana, I think he'd be glad
to join me in talking to them about what needs to be funded to make the
replacement legally acceptable.

> I'm pretty confident that some of those lawyers were part of the full
> consensus you mentioned.

Note that it wasn't just lawyers at that meeting, and also, many of the
people there represented well-funded pro-SPDX budgets.

(As a side note, this is a good example of why CHR-governed meetings are a
bad place to make decisions.  It removes all accountability from those who
had input into the decision.)

> U-Boot did a wholesale SPDX conversion back in 2013 which removed every
> boilerplate including non-standard disclaimers and obscure license
> notices/references.

Another project making a questionable decision doesn't provide useful
evidence for Linux to make the same questionable decision.

> How is the industry dealing with that?
>    1) Not having noticed within 9 years?
>    2) Simply ignoring the problem?
>    3) Shipping the git repository?

When a compliance matter comes up — and it will — demanding (3) will be the
outcome.  I suspect the U-Boot project is probably ok with that.

> We all discussed options for solving this, but that does not mean that the
> task to create such a tool has been assigned to anyone or that anyone
> volunteered to take it on.

I understand.  The lawyers (and their wealthy allies) who want SPDX
identifiers in every file *should* be funding the tool that's needed for GPL
compliance (lest they face a situation where the Git repositories become part
of the CCS — but *maybe* they actually want that?).  Meanwhile, it's
definitely ironic that an effort like this (to ostensibly make license
compliance easier) is introducing license violations.

Allison Randal also replied:
>> With that context in mind: One reasonable interpretation of “keep intact
>> all the notices that refer to this License and to the absence of any
>> warranty” could be to say that the exact text must be preserved, exactly
>> as it was typed at the dawn of time, including any typos, inaccurate
>> street addresses, etc.

Just to be clear: the concerns Fontana raised weren't about preserving typos
or inaccurate street addresses.  Thus, I think that point is probably a red
herring here.  No one has said that preserving typos or inaccurate postal
addresses is important.

>> Another reasonable interpretation is that the notices serve to link a
>> license to the file, and declare that the legal terms of the entire GPL
>> license govern that file, and so what must be preserved is the link.

I think a link to the proper notice (as it originally appeared) was a good
proposal back in 2019 and just as good now.  We had consensus that it was a
way to go.  It was your idea, Allison, and I think it was useful and solves
the problem.

>> Current practice is closer to the second, people feel free to throw in
>> whatever garbled variant of the notice text FSF recommends,

If folks have changed the warranty disclaimer in a legally significant way —
which Fontana already noted is happening here — then it absolutely matters.

>> If the full text notice and SPDX identifier are legally equivalent, then
>> can they legally be substituted in an existing file?

I realize that many people *want* the "if" part of that statement to be true.
No one actually knows if it is true.  The fact that the SPDX project (which
has an obvious self-promotional interest here), declared it to be true
doesn't make it true, either.

>> When Thomas and I say that the changes are all in git history, we aren't
>> saying that we expect everyone to read the entire history. What we're
>> saying is that it's easy to write a tool to scan the entire history,

This part does concern me.  Are these patches going upstream in a way that
they can easily be found?  Is it easy to extract the specific notice that was
removed programatically?  At the very least, linux-spdx should make sure
that's true.

In the meantime, there is no actual harm, from my point of view, that the Git
repository is now part of the CCS for Linux.  In some ways, that's an upside
outcome from *my* perspective.   But, I realize that company's legal
departments might not fully understand that's a side-effect of the current
effort.

Indeed, I think *many* people will find that a surprising outcome, and it
will lead to more (infractional) violations.

  -- bkuhn

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Allison Randal]

On 6/8/22 10:04, Bradley M. Kuhn wrote:
> Allison Randal also replied:
>>> With that context in mind: One reasonable interpretation of “keep intact
>>> all the notices that refer to this License and to the absence of any
>>> warranty” could be to say that the exact text must be preserved, exactly
>>> as it was typed at the dawn of time, including any typos, inaccurate
>>> street addresses, etc.
> 
> Just to be clear: the concerns Fontana raised weren't about preserving typos
> or inaccurate street addresses.  Thus, I think that point is probably a red
> herring here.  No one has said that preserving typos or inaccurate postal
> addresses is important.

I'm making an explicit point that the exact text of the notice isn't 
actually all that useful. Those aren't red herrings, they're just 
specific examples where the exact text is actively unhelpful. To the 
extent that the exact text of the notice is a jumbled but equivalent 
paraphrase of the terms of the GPL it isn't actively unhelpful, but it 
also doesn't add any legal or informational value, does add confusion 
around the licensing, and means that every individual who encounters the 
file has to carefully check to make sure that the text doesn't deviate 
from the terms of the GPL. (Many of those people don't know the GPL as 
well as Fontanta, and won't actually make that judgement accurately.)

Where the exact text of the notice does deviate from the terms of the 
GPL, that's a different problem, and we aren't changing those files for now.

>>> Another reasonable interpretation is that the notices serve to link a
>>> license to the file, and declare that the legal terms of the entire GPL
>>> license govern that file, and so what must be preserved is the link.
> 
> I think a link to the proper notice (as it originally appeared) was a good
> proposal back in 2019 and just as good now.  We had consensus that it was a
> way to go.  It was your idea, Allison, and I think it was useful and solves
> the problem.

As you probably know, I've been negotiating compromises with lawyers 
around free software for decades, and I'm very good at it. That doesn't 
necessarily mean I believe the compromise is the best answer, only that 
it's the best I'm able to achieve at the time. Progress takes time, and 
I accept that. (I've negotiated a series of compromises with lawyers 
around contributor agreements over the decades down from "every 
contributor", to "only the most significant/prolific contributors", to 
"only corporate contributors", to "actually DCO and signed-off-by is fine".)

If an automatically generated file (outside of git) recording the 
historical full notice text for each changed file is as far as I can get 
the lawyers to agree at the moment, I accept that as good progress in 
the right direction.

But, in the long term, I predict that common legal practice will evolve 
to recognize that SPDX identifiers are legally equivalent to full text 
notices (as long as those full text notices don't deviate from the terms 
of the license). You can actively work toward that future or actively 
work against it, it really doesn't matter to me. Time will tell, and no 
one person will make that decision, it will be made for us by the 
collective actions of a massive number of people.

>>> If the full text notice and SPDX identifier are legally equivalent, then
>>> can they legally be substituted in an existing file?
> 
> I realize that many people *want* the "if" part of that statement to be true.
> No one actually knows if it is true.  The fact that the SPDX project (which
> has an obvious self-promotional interest here), declared it to be true
> doesn't make it true, either.

Publishing a legal text like the GPL doesn't make it true either. At 
some point we put a legal stake in the ground on what *should be* true 
for free software, and then take action over time to defend and prove it 
to be true. That's how the law works and evolves over time.

>>> When Thomas and I say that the changes are all in git history, we aren't
>>> saying that we expect everyone to read the entire history. What we're
>>> saying is that it's easy to write a tool to scan the entire history,
> 
> This part does concern me.  Are these patches going upstream in a way that
> they can easily be found?  Is it easy to extract the specific notice that was
> removed programatically?  At the very least, linux-spdx should make sure
> that's true.

Scan all historical commits since we started this clean up project for 
the ones that add SPDX identifiers (that's an easy machine pattern to 
match), and check if those patches also deleted any lines. Thomas has 
also been good about noting the exact rule that was applied in the 
commit message, so that gives us even more metadata for the generated 
output of the tool.

Allison

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Bradley M. Kuhn]

Allison Randal wrote:
> If an automatically generated file (outside of git) recording the historical
> full notice text for each changed file is as far as I can get the lawyers to
> agree at the moment, I accept that as good progress in the right direction.

Lawyers on this list have already raised concern (and even offense) about too
much “blame this on lawyers for wanting something unreasonable” — because
there was a lot of that on this thread back in 2019.  I want to be as fair as
possible to our lawyer colleagues.

Ultimately, lawyers don't deserve the blame for the problem linux-spdx seeks
to solve.  Lawyers advise clients and their clients make the call about how
to slap the GPL onto their work.  Some (even most) of the contributors
probably don't even consult lawyers before contributing.  Many ignore their
lawyers advice, too!

So, the problem we has is we really have no way of knowing for sure that
variance in (say) the warranty disclaimer was intentional or just goofy — and
if it was just goofy, did that goofiness end up being legally significant?
For all we know, minor changes were determined as very significant by some
contributor who has a lot of liability and fears a warranty claim.  Who are
we to judge — given that GPLv2 *does* allow you to vary your warranty
disclaimer (or remove it entirely)?

Using the example of the easily-solved pathological cases (e.g.,
misspellings, typos, Scrivener's errors) doesn't really help because Fontana
has already pointed out that there are examples that can't be explained away
as Scrivener's errors.

Since linux-spdx doesn't ask *every* contributor (I realize, some have been
asked), we don't really know (systematically) if having that notice there
was important to them.  One of the purposes of the GPL from its inception was
an advocacy component. (In fact, during GPLv3 drafting, one of the arguments
that some activists made against shortening the “How to Apply” section from
the version in GPLv2 was that shorter notices would mean less advocacy. I
didn't agree with that argument myself (I argued for shortening/removing “How
to Apply”), but given that some make that argument, we have to at least
consider that there *are* contributors who feel that way.)

Furthermore, one of the impetuses for linux-spdx *was* behavior by folks like
Patrick McHardy's (his bad actions now in the past, of course).  linux-spdx
was, in part, a response to fear that there would be more contributors who
would seek to monetize their Linux copyrights through inappropriately
captious enforcement.  Well, removing notices without a clear plan and
mitigation strategy to handle the “keep intact all the notices that refer to
this License and to the absence of any warranty” perfectly “sets up” a
captious and annoying copyright claim.  Why would linux-spdx want to do that
— on purpose? 😲

Which, BTW, leads to another key point: SPDX identifiers do *not* indicate
whether a standard warranty claim, or no warranty claim, or anything else was
present.  Without this external file, how is anyone to know without digging
through Git logs *whether* a warranty disclaimer used to be there or not?  I
hadn't thought about this before, but this is actually a huge bug in SPDX.
Part of the reason we're struggling with this is that SPDX *should have*
provided identifiers for the items that GPLv2 allows to vary in presentation
and terms of the licenses!

> I'm making an explicit point that the exact text of the notice isn't
> actually all that useful. Those aren't red herrings, they're just specific
> examples where the exact text is actively unhelpful. To the extent that the
> exact text of the notice is a jumbled but equivalent paraphrase of the
> terms of the GPL it isn't actively unhelpful, but it also doesn't add any
> legal or informational value, does add confusion around the licensing,

I don't think anyone has disagreed that *some* of the notices have variance
that is unhelpful and may in fact be legally insignificant.  One problem is:
is linux-spdx (collectively) really qualified to make that call on behalf of
all contributors?

Second problem is: Fontana revived this 2019 thread specifically because
we're now talking about examples where the notices vary and *do* seem legally
different in the warranty disclaimer department, at least to Fontana.

> Where the exact text of the notice does deviate from the terms of the GPL,
> that's a different problem, and we aren't changing those files for now.

I realize that as of, like, "now" as in "the last 24 hours", that's true,
because Thomas indicated that he updated/is-updating his patch set to exclude
the ones Fontana identified (IIUC).  But I have two concerns: (a) Thomas
already indicated that tabling this issue in 2019 led to slow down on the
project, and I presume it will do so again if it's tabled again and (b) the
number of lawyers reviewing these patches is minimal, and they're also human
beings and they may miss stuff (and/or may disagree about the legal
significance).  As such, I think there are already no certainty that some
items that the patch-reviewers believed were legally insignificant are
actually legally significant.

It also leads me to ask Fontana, since he seems to be the only lawyer
watching this issue: are you *sure* there weren't other patches that drifted
through already that had legally-significant variance in warranty disclaimer?

 * * *

Anyway, it's good we're having this conversation because it's the precise
conversation that was had under CHR in the “room where it happened” in April
2019.  The outcome of that conversation is what led to complete in-the-room
consensus that the easiest thing was just to make a simple file that had
every variation of notices and where they previously appeared.  The next
month, when it was discussed this on the list, the conversation did not
include as many diverse participants and the conclusion was reversed with a
“table all the notice worries and full steam ahead!”

I was frankly surprised that such important decisions were being made
under CHR and without a plan to report them back to the Linux community
(ISTR I even pointed this out at the time), so it's good that we have
a broad, public discussion about the topic here.

> Publishing a legal text like the GPL doesn't make it true either. At some
> point we put a legal stake in the ground on what *should be* true for free
> software, and then take action over time to defend and prove it to be true.
> That's how the law works and evolves over time.

Obviously I have a lot of views on this subject, but a lot of what you raise
in your email about “how do we move the thinking about what is legally
necessary/advisable in FOSS” really is beyond the scope of the narrow problem
that linux-spdx was chartered for, so let's have the "how do we evolve the
legal mechanisms of FOSS" discussion in another forum.

  -- bkuhn

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Richard Fontana]

On Wed, Jun 8, 2022 at 1:24 PM Bradley M. Kuhn <bkuhn@ebb.org> wrote:

> So, the problem we has is we really have no way of knowing for sure that
> variance in (say) the warranty disclaimer was intentional or just goofy — and
> if it was just goofy, did that goofiness end up being legally significant?
> For all we know, minor changes were determined as very significant by some
> contributor who has a lot of liability and fears a warranty claim.  Who are
> we to judge — given that GPLv2 *does* allow you to vary your warranty
> disclaimer (or remove it entirely)?

To be a little clearer about why this bothers me a little bit. I know
that in the past the FSF gave public guidance to companies that it was
okay to tack on materially different warranty and liability disclaimer
language to GPL notices (or, say, in global product license
agreements). (GPLv3 codifies this in its section 7.) Also, earlier in
my time at Red Hat I went through a period where I was recommending to
developers to include some disclaimer language that differed from what
you have in the traditional GPL boilerplate. The point is that there
are cases where the materially different language is deliberate and
reflected the legal preferences of the contributor (or contributor's
employer) in question

> Which, BTW, leads to another key point: SPDX identifiers do *not* indicate
> whether a standard warranty claim, or no warranty claim, or anything else was
> present.  Without this external file, how is anyone to know without digging
> through Git logs *whether* a warranty disclaimer used to be there or not?  I
> hadn't thought about this before, but this is actually a huge bug in SPDX.
> Part of the reason we're struggling with this is that SPDX *should have*
> provided identifiers for the items that GPLv2 allows to vary in presentation
> and terms of the licenses!

This is an interesting point. SPDX identifiers were I think originally
meant to refer to license texts, not license notices, except for the
"or-later" vs. "only" issue found in the GPL family.

If you had a GPLv2 license file altered so that the warranty
disclaimer section had some additional language, SPDX would say this
is not "GPL-2.0-only" anymore because the matching criterion fails. It
would need a LicenseRef- or a new standard SPDX identifier. I am not
sure why a GPLv2-only license *notice* containing nonstandard, legally
significant language shouldn't be treated as distinct from what SPDX
means by "GPL-2.0-only" if what you're doing is removing the
historical license notice from the source file.

I wonder if "SPDX-License-Identifier:" isn't sufficiently well defined.

> I realize that as of, like, "now" as in "the last 24 hours", that's true,
> because Thomas indicated that he updated/is-updating his patch set to exclude
> the ones Fontana identified (IIUC).  But I have two concerns: (a) Thomas
> already indicated that tabling this issue in 2019 led to slow down on the
> project, and I presume it will do so again if it's tabled again and (b) the
> number of lawyers reviewing these patches is minimal, and they're also human
> beings and they may miss stuff (and/or may disagree about the legal
> significance).  As such, I think there are already no certainty that some
> items that the patch-reviewers believed were legally insignificant are
> actually legally significant.
>
> It also leads me to ask Fontana, since he seems to be the only lawyer
> watching this issue: are you *sure* there weren't other patches that drifted
> through already that had legally-significant variance in warranty disclaimer?

No, because I didn't have that much time to focus on this in 2019 and
less time now. If I have some time soon I will try to go through
Thomas's recent patchsets but I only looked at a small number of them.

 Richard

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Bradley M. Kuhn]

On Wed, Jun 8, 2022 at 1:24 PM Bradley M. Kuhn <bkuhn@ebb.org> wrote:
> > Without this external file, how is anyone to know without digging through
> > Git logs *whether* a warranty disclaimer used to be there or not?  …
> > Part of the reason we're struggling with this is that SPDX *should have*
> > provided identifiers for the items that GPLv2 allows to vary in
> > presentation and terms of the licenses!
>
Richard Fontana replied later that day:
> This is an interesting point. SPDX identifiers were I think originally
> meant to refer to license texts, not license notices, except for the
> "or-later" vs. "only" issue found in the GPL family.

Thanks, Fontana, you've stated the problem clearly and succinctly.  IOW (if
I'm following you correctly), the fundamental issue here is that linux-spdx
project is using license *text* monikers to replace license *notices*, but
GPLv2 permits variance in license *notices* that *are* legally significant.
(And, GPLv2 compliance requires keeping such notices in tact.)

 * * *

Meanwhile, if you at Red Hat were (at least at one time) encouraging a
legally different warranty disclaimer notice for employees to use upstream …

> To be a little clearer about why this bothers me a little bit. I know that
> in the past the FSF gave public guidance to companies that it was okay to
> tack on materially different warranty and liability disclaimer language to
> GPL notices (or, say, in global product license agreements). (GPLv3
> codifies this in its section 7.) Also, earlier in my time at Red Hat I went
> through a period where I was recommending to developers to include some
> disclaimer language that differed from what you have in the traditional GPL
> boilerplate. The point is that there are cases where the materially
> different language is deliberate and reflected the legal preferences of the
> contributor (or contributor's employer) in question

… then, odds are, other companies did (or even still do) as well.

   -- bkuhn

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Bradley M. Kuhn]

J Lovejoy wrote today:
>  a second question of: and then how does "capturing it in some way" get
> practically implemented?)

> We are NOT answering the second question at this point in time.

Nor did I expect you to have an answer for that question this quickly!  (But,
hopefully we agree it's a really important question!)

I think Fontana and I just for the first time stated clearly the root cause —
namely: the inability for SPDX identifiers to capture non-standard
disclaimers.  (I suspect this is something that no one noticed when this
issue was debated previously [0].)

Nevertheless, the flaw is big enough that it calls into question whether one
*can* effectively use SPDX identifiers *alone* to mark licensing information
for anything other than a brand-new project that has no license notices yet.

> SPDX makes clear that if there is a standard license notice (which GPL is one
> of the few license that has one), then the matching guidelines apply there too.
> That is not really helpful here, though, where we are talking about
> non-standard license notices.

Indeed — not only that, but if, as you say, the presentation of an SPDX
identifier at the top of a copyrighted work always means “the license with
its standard and recommended permission notice as recommended by the license
steward”, then *any* replacement of a notice that deviates in any way (even
trivially) from the standard is pretty clearly an infraction of the “keep
notices in tact” requirement of GPLv2§1.

> #1 QUESTION: How much deviation from the language in the text of the
> standard header for GPL rises to the level of being legally significant to
> warrant capturing it in some way?

If anyone but the copyright holder and/or original placer of the warranty
disclaimer makes this determination, there is increased risk of McHardy-style
lawsuit.  So, while I agree with your other point that it's a risk
assessment, the stakes are presumably rather high here.

OTOH, if everyone is cool with the idea of the Git repository being part of
the CCS, I think that's a fine solution from my perspective.

   -- bkuhn

[0] Historically, as John Sullivan pointed out in the 2019 thread on this
    list, the SPDX project (from its inception until recently) discouraged
    replacing license notices with SPDX identifiers.  (As some on this list
    know, the SPDX project changed its position to be silent on that topic
    recently.)  Here's the context from this list on that:

    John Sullivan <johns@fsf.org> wrote on Wed, 22 May 2019:
    >> On https://spdx.org/ids-how it currently says:

    [ Which can be confirmed with
      https://web.archive.org/web/20191019153514/https://spdx.org/ids-how ]

    >>>>  [W]hen a file already contains a standard header or other license
    >>>>  notice, the SPDX project recommends that those existing notices
    >>>>  *should not* be removed. The SPDX ID is recommended to be used to
    >>>>  supplement, not replace, existing notices in files. …
    >>>>  [E]xisting license texts and notices should be retained, not
    >>>>  replaced ‐ especially a third party's license notices.

    That text has since been removed from the URL in question.  IIUC SPDX has
    no recommendation on how to solve the problem we have at hand, which is
    certainly consistent with their position, since SPDX now officially stays
    neutral on the question of whether one should or should not replace
    existing license notices with merely SPDX identifiers.

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Richard Fontana]

On Wed, Jun 8, 2022 at 7:16 PM J Lovejoy <opensource@jilayne.com> wrote:
>
> On the topic of comparison - the warranty in the standard license notice states, "This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details."
> It is a truncated version of what is actually in the license, which (I take) as the reason for "see ... license for more details". Thus, the overall comparison of these variations we are finding should look to the full text of the disclaimer of warranty in the license, not just the standard notice.

Agreed. The cases I was trying to flag (both now and in ~2019)
generally involve ones where the author is adding disclaimers of
implied warranties not explicitly found in GPLv2.

Richard

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[J Lovejoy]

On 6/8/22 6:31 PM, Bradley M. Kuhn wrote:
> J Lovejoy wrote today:
>>   a second question of: and then how does "capturing it in some way" get
>> practically implemented?)
>> We are NOT answering the second question at this point in time.
> Nor did I expect you to have an answer for that question this quickly!  (But,
> hopefully we agree it's a really important question!)
I agree it is something that deserves attention and careful thought, yes.
("really important" is relative and at this time of night, other things 
that have nothing to do with
licensing of software may be really important. like going to sleep! :)
>
> I think Fontana and I just for the first time stated clearly the root cause —
> namely: the inability for SPDX identifiers to capture non-standard
> disclaimers.  (I suspect this is something that no one noticed when this
> issue was debated previously [0].)
>
> Nevertheless, the flaw is big enough that it calls into question whether one
> *can* effectively use SPDX identifiers *alone* to mark licensing information
> for anything other than a brand-new project that has no license notices yet.
*sigh* I am well aware that you are not a fan of SPDX (nor me, 
probably), but let's please not over-state this.
SPDX identifiers are used, have been used, and will continue to be used 
effectively for many open source project
as a way to express the license in a source file. Whether you like it or 
not! :)

As for non-standard disclaimers in a license notice - this is not a huge 
problem as it seems you are making it.
Let me put some numbers to that:
- of the ~400 (I've lost track) licenses currently on the SPDX License 
List, only about 46 of them even have a
standard license notice (defined in the SPDX License List as, "text 
intended to be put in the header of source
files or other files as specified in the license or license appendix 
when specifically delineated")
- of those approx 46, about 30 have some form of disclaimer type 
language (I was being generous here)
- of those 30:
- - 9 of them are GNU licenses (GPL - all 3 versions, LGPL - 2 versions, 
AGPL, and GFDL - all 3 versions)
- - then there's Apache-2.0
- - and the rest are old (e.g. SISSL, CPAL), rarely used, and/or 
entity-specific licenses (APSL, W3C).
So that's really only 10 licenses that are in use.

I have not seen this be an issue with Apache-2.0 and I doubt it's so 
much an issue with GFDL, so we are really only talking about this 
potentially being an issue with GPL and LGPL.

So, here we are - I suppose the Linux kernel is the appropriate place to 
have it come up, given that!

>> #1 QUESTION: How much deviation from the language in the text of the
>> standard header for GPL rises to the level of being legally significant to
>> warrant capturing it in some way?
> If anyone but the copyright holder and/or original placer of the warranty
> disclaimer makes this determination, there is increased risk of McHardy-style
> lawsuit.  So, while I agree with your other point that it's a risk
> assessment, the stakes are presumably rather high here.
Whether this increases the risk or whether the stakes are considered 
high or not is all part of a risk assessment.
Assessing risk is not simply - could a bad thing happen, it's also looks 
at the likelihood of it happening and the impact, etc.

What would be helpful is if we (or I guess, really I) can try to ask 
lawyers versed in interpretation of these kinds of things and get some 
idea as to the scope of what changes we see here may or may not be 
likely to be consequential.
>
> OTOH, if everyone is cool with the idea of the Git repository being part of
> the CCS, I think that's a fine solution from my perspective.
That is answering the second question before we've answered the first. 
In any case, your position is heard on this part! ;)

Cheers,
Jilayne

Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

[Bradley M. Kuhn]

Jilayne, thanks for your response!

I'd written last night:
> > Nevertheless, the flaw is big enough that it calls into question whether
> > one *can* effectively use SPDX identifiers *alone* to mark licensing
> > information for anything other than a brand-new project that has no
> > license notices yet.

J Lovejoy replied:
> SPDX identifiers are used, have been used, and will continue to be used
> effectively for many open source project as a way to express the license in
> a source file. Whether you like it or not! :)

I am actually neutral on that part of the issue.  My goal here is to make
sure licensors' rights and choices are respected.  What Fontana and I are
mainly pointing out is that replacing license notices with SPDX identifiers
has surprising consequences that we've just realized.  For example, in this
project, it leads to the Git repository as a whole needing to be part of
the CCS under GPLv2.  That outcome is not necessarily bad — it's just an
implication of linux-spdx that will surprise most redistributors.

> As for non-standard disclaimers in a license notice - this is not a huge
> problem as it seems you are making it.

It's not a numbers issue; once there is *one* of those notices that varies,
it needs to be handled somehow.

Also, does SPDX have some clear documentation that the intention is that the
SPDX identifier means not just the license text, but *also* the standard
notice as recommended by the license steward?  Maybe that documentation
should be included/linked to somewhere in the Linux tree so that folks know
that?

(While I'm no longer an active SPDX contributor, I'm pretty well versed in
SPDX (more than the average FOSS person for sure), and I didn't know that,
so I suspect it's not well known.)

> Let me put some numbers to that:
> - of the ~400 (I've lost track) licenses currently on the SPDX License List,
> only about 46 of them even have a
…
> - - 9 of them are GNU licenses (GPL - all 3 versions, LGPL - 2 versions,
> AGPL, and GFDL - all 3 versions)

Your set of numbers seem mainly an argument of: “copyleft licenses are often
more complex than non-copyleft ones”.  Anyway, since, as you say, Linux's
overarching license is “GPL-2.0-only” (full stop — with no additional
permissions), the key issue for this project is that GPL-2.0-only *does*
allow variable warranty disclaimers and/or notice terms.

> So, here we are - I suppose the Linux kernel is the appropriate place to
> have it come up, given that!

I agree.  But it will come up in any project licensed under a GPL Agreement.

> What would be helpful is if we (or I guess, really I) can try to ask
> lawyers versed in interpretation of these kinds of things and get some idea
> as to the scope of what changes we see here may or may not be likely to be
> consequential.

That's a useful data point to be sure, but what matters most is that
representatives of the licensors / copyright holders consent to modifying
their license notices and/or agree to switch to the standard one.

Fontana has already said that if we find a Red Hat copyright with a
non-standard warranty notice, that it *was* likely intentional and is
meaningful (though I expect in retrospect, IBM's Red Hat would be willing to
relicense with a more standard warranty disclaimer).  For linux-spdx to
be successful, it seems, it will either (a) need to contact copyright
holders of non-standard license notices to change them, (b) keep
the file in the manner designed at the April 2019 meeting, or (c)
the Git repsoitory stays part of the CCS.

All of the solutions seem workable to me.  Bugs can be fixed. :)

  -- bkuhn