linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: J Lovejoy <opensource@jilayne.com>
To: John Sullivan <johns@fsf.org>
Cc: linux-spdx@vger.kernel.org
Subject: Re: Meta-question on GPL compliance of this activity
Date: Wed, 22 May 2019 19:19:51 -0600	[thread overview]
Message-ID: <0D762992-918F-4901-8355-F258DAAB88EA@jilayne.com> (raw)
In-Reply-To: <871s0qyz3z.fsf@wjsullivan.net>



> 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

  reply	other threads:[~2019-05-23  1:19 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06 19:58 [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE Thomas Gleixner
2019-05-21 17:58 ` Meta-question on GPL compliance of this activity Richard Fontana
2019-05-21 18:59   ` J Lovejoy
2019-05-21 21:08   ` Bradley M. Kuhn
2019-05-22  9:40     ` Thomas Gleixner
2019-05-22 13:30     ` Greg KH
2019-05-23  4:41       ` Bradley M. Kuhn
2019-05-23  5:42         ` Thomas Gleixner
2019-05-22 16:14     ` J Lovejoy
2019-05-22 21:10       ` John Sullivan
2019-05-23  1:19         ` J Lovejoy [this message]
2019-05-23  6:06           ` Thomas Gleixner
2019-05-29 20:57           ` John Sullivan
2019-05-29 21:30             ` Greg KH
2019-06-01  3:22               ` John Sullivan
2019-06-01  9:31                 ` Greg KH
2019-06-01  4:21               ` Richard Fontana
2019-05-24  4:33       ` Richard Fontana
2019-05-24  5:20         ` Greg KH
2019-05-24 20:24           ` Allison Randal
2019-05-25  1:07             ` Richard Fontana
2019-05-27 21:23               ` Allison Randal
2019-05-25 16:56             ` Greg KH
2019-05-27 21:54               ` Allison Randal
2019-05-28  7:21                 ` Dominik Brodowski
2019-05-22 13:27   ` Greg KH
2019-05-22 14:16     ` Thomas Gleixner
2019-05-22 16:33       ` J Lovejoy
2019-05-22 16:52         ` Thomas Gleixner
2019-05-22 17:00           ` J Lovejoy
2022-06-06 20:11 ` [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE Richard Fontana
2022-06-06 20:17   ` Thomas Gleixner
2022-06-07 18:12     ` Bradley M. Kuhn
2022-06-07 23:05       ` Thomas Gleixner
2022-06-08  8:33         ` Allison Randal
2022-06-08 14:04           ` Bradley M. Kuhn
2022-06-08 14:59             ` Allison Randal
2022-06-08 17:18               ` Bradley M. Kuhn
2022-06-08 18:54                 ` Richard Fontana
2022-06-08 19:29                   ` Bradley M. Kuhn
     [not found]                     ` <02f4021f-63a5-4796-d790-2bacd37b90d2@jilayne.com>
2022-06-09  0:31                       ` Bradley M. Kuhn
2022-06-09  4:51                         ` J Lovejoy
2022-06-09 15:03                           ` Bradley M. Kuhn
2022-06-09  2:35                       ` Richard Fontana
2022-06-06 20:31   ` Bradley M. Kuhn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0D762992-918F-4901-8355-F258DAAB88EA@jilayne.com \
    --to=opensource@jilayne.com \
    --cc=johns@fsf.org \
    --cc=linux-spdx@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).