From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 881F9138334 for ; Sun, 26 Aug 2018 11:35:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E8989E0917; Sun, 26 Aug 2018 11:35:41 +0000 (UTC) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 971C3E0905 for ; Sun, 26 Aug 2018 11:35:41 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id t14-v6so6184260pgf.0 for ; Sun, 26 Aug 2018 04:35:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=IIlIpd2ur14KaMKt92vV1pftNIXE/1qpNeIte93TwJs=; b=olWBZiruuIa9Xzw+J2gOBpyzyt0GnBZ+g4FxlCpN0+Xke91LtTUn1kGRHySUqeSRnh q5z5IWGev24Rr8T6eiFFmeKELBLTJDtETQI/mif35OsRelrMR/XtmgX6za9jZKkaqXNK 1Kj631VxL6kORrEZr4q2HH7FmccnqjwRlP8taeNu6GSjc3ozytnezakT79cGlgGPTDgl 2W5e2ogvUCgWwvP/qZNZR300NprxwO0ObO8V5zpqp+OPrucVdW4XNbpEEdyb2eO/OVCf w8uCQS0WQzSfPcwSvcx1k2+2qFZIMOdBAx+B9Ze0tBjF8p0DyJ+8Q1MUDzxwu6ZMsHaO 7XLQ== X-Gm-Message-State: APzg51DcVs0ItrAndYKEUBi6aeQzqQ746+fTEc1w9Szl27QJ6uJrcV// 4hL/xoEz7S0GMAo44iRdAPF2v8FOF+eL/u28YdtUXM3G X-Google-Smtp-Source: ANB0VdZnh6BxrQYqcvoIzkttMEs9hIzQxHmSQ+jA7a155nDmc7YX3gPPbl+5yAF0Xc8Z85yTF3lcVZRtG/ySg1WQPVg= X-Received: by 2002:a65:5304:: with SMTP id m4-v6mr8601613pgq.250.1535283340221; Sun, 26 Aug 2018 04:35:40 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 References: <1535279962.1066.24.camel@gentoo.org> <1535280838.4490.16.camel@gentoo.org> <5bf34233-8740-44e2-e4d5-2f647a703584@gentoo.org> <1535282155.1066.27.camel@gentoo.org> In-Reply-To: <1535282155.1066.27.camel@gentoo.org> From: Rich Freeman Date: Sun, 26 Aug 2018 07:35:28 -0400 Message-ID: Subject: Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23] To: gentoo-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 5be2f3e5-9945-47d6-aba0-65779bcd0a73 X-Archives-Hash: 477f3d666e719a82b3ffc891d95f1b2b On Sun, Aug 26, 2018 at 7:15 AM Micha=C5=82 G=C3=B3rny = wrote: > > On Sun, 2018-08-26 at 13:09 +0200, Pawe=C5=82 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 sourc= e > > > 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. Fo= r > > _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=C5=82, could you elaborate on why not distinguishing more precise= ly > > 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'm not aware of any major implications. However, I think that if we > provide for the distinction, the distinction should be used correctly. > IMO QA policy ought to be that the license is correct. How much time/effort goes into policing the policy in the case of 2/3/2+/3+ is a different matter. If people want to do it, great, but IMO it isn't adding tremendous value. I doubt we have any users relying on license filtering to distinguish between GPL2/2+. If somebody files a bug pointing out an incorrect license it should be fixed as a matter of policy, but I'm not sure more than that is necessary in this particular case. If we were talking about nonfree licenses being missed that would be more critical. --=20 Rich