linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: J Lovejoy <opensource@jilayne.com>
Cc: John Sullivan <johns@fsf.org>, linux-spdx@vger.kernel.org
Subject: Re: Meta-question on GPL compliance of this activity
Date: Thu, 23 May 2019 08:06:54 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1905230751220.1770@nanos.tec.linutronix.de> (raw)
In-Reply-To: <0D762992-918F-4901-8355-F258DAAB88EA@jilayne.com>

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

  reply	other threads:[~2019-05-23  6:07 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
2019-05-23  6:06           ` Thomas Gleixner [this message]
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=alpine.DEB.2.21.1905230751220.1770@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=johns@fsf.org \
    --cc=linux-spdx@vger.kernel.org \
    --cc=opensource@jilayne.com \
    /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).