public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Mol <mikemol@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]
Date: Mon, 27 Aug 2018 18:46:28 -0400	[thread overview]
Message-ID: <4004237.4pTCg0tAxr@saffron> (raw)
In-Reply-To: <5bf34233-8740-44e2-e4d5-2f647a703584@gentoo.org>

On Sunday, August 26, 2018 7:09:41 AM EDT Paweł Hajdan, Jr. wrote:
> On 26/08/2018 12:53, Mart Raudsepp wrote:
> > The common issue here is that upstream COPYING files really do only
> > talk about one of the versions. And then you get to validate or source
> > files to be sure that they do have a "or later" clause in them. And
> > then on each bump you ideally should validate it again, etc, that no
> > sources without "or later" allowance are in there...
> 
> Yup, precise tracking of license metadata can be a pain.
> 
> I'm not really sure if that level of it is worth for us as a distro. For
> _importing_ other project's source code directly into one's project
> precise license compatibility matters a lot. That's not the scenario
> we're in. I see LICENSES as mostly a mechanism for end users to accept
> or reject EULAs etc, and I'm curious what are other common scenarios.
> 
> Michał, could you elaborate on why not distinguishing more precisely
> between these GPL variants in LICENSES is a _problem_ ? I can certainly
> see the information is not always accurate, but it's not obvious to me
> how severe is the downside, what are the consequences in practice.

I can say that if the licenses are habitually misidentified, I could not use 
Gentoo's portage tree in my job without extensive and ongoing revalidation of 
the license metadata.

There are, in fact, automated tools for advising about the license disposition 
of these types of things, examining source files for unfortunate edits and 
variants and flagging them, etc. It might be an interesting task at some point 
to point some of these tools at portage, look for incorrect metadata and file 
bug reports.

Not suggesting this is a worthwhile approach up front, but it might be a 
useful tool in the future for dealing with license metadata quality as a 
chronic issue. (Which, in turn, is useful for commercial consumption and 
participation.)





  parent reply	other threads:[~2018-08-31 21:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 10:39 [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23] Michał Górny
2018-08-26 10:53 ` Mart Raudsepp
2018-08-26 11:09   ` Paweł Hajdan, Jr.
2018-08-26 11:15     ` Michał Górny
2018-08-26 11:33       ` Roy Bamford
2018-08-26 11:35       ` Rich Freeman
2018-08-26 17:03       ` Paweł Hajdan, Jr.
2018-08-27 22:46     ` Michael Mol [this message]
2018-08-31 22:31       ` Rich Freeman
2018-09-01  7:44       ` Paweł Hajdan, Jr.
2018-08-26 15:50 ` Ulrich Mueller
2018-08-26 17:14   ` Michał Górny
2018-08-26 18:14     ` Mart Raudsepp
2018-08-26 19:43       ` M. J. Everitt
2018-08-26 19:45       ` Francesco Riosa
2018-08-26 19:50         ` Francesco Riosa
2018-08-26 22:40   ` Jonas Stein
     [not found]   ` <3116195.kUm3yr6LE6@hermes>
2018-08-26 22:41     ` Robin H. Johnson
2018-08-27  2:55       ` Ulrich Mueller
     [not found]         ` <3623085.8soZgasqjt@hermes>
2018-08-27  7:35           ` Ulrich Mueller
2018-08-27  2:37     ` Ulrich Mueller

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=4004237.4pTCg0tAxr@saffron \
    --to=mikemol@gmail.com \
    --cc=gentoo-dev@lists.gentoo.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