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 DC88A138334 for ; Fri, 31 Aug 2018 21:54:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1E9A2E0863; Fri, 31 Aug 2018 21:54:32 +0000 (UTC) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 C10EAE0841 for ; Fri, 31 Aug 2018 21:54:31 +0000 (UTC) Received: by mail-io0-x244.google.com with SMTP id w11-v6so11590507iob.2 for ; Fri, 31 Aug 2018 14:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=xVJLYEVaZMwhbvOpMCU0Ue2n6g2HCjy3SJdXgiIO/SM=; b=EwiV7aaOn6q+p6wjVok5WintIue9+7/fXy7F887flEb9GHdo28L9ytwhOrKfLuuXm8 GqSQxFKYANjSzD9jWu03P+D0HE8EJJ3r4GXnRoqu6chJtQlyfzRB5Q2s9u+dCHOtUNRG DDVAaKXNXAq8BbfyGNk4zB4bVpcZJrP7U7J8gpWgqDnEkAfoGwoehywLn0lmTcfb7oKJ OD1ve7oheVHy4Y2WNo/cTNuO7hHIQKunEZt8kS4kI7C+r3NoGuKBN0uEVE2xycX8PyWL khLQO9PBAU/eaxz9rMPQFp/qzpG0YFePOj5GGYsanuHdea46IcysEEPyD0dC5VxOINjQ jxew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=xVJLYEVaZMwhbvOpMCU0Ue2n6g2HCjy3SJdXgiIO/SM=; b=sP2FqrguEIB0CvTVJb69FrogXJqyUvSrr5rIPLHLlMsWtgM+s9c/HcKyfhjyeJ/VKN UvYEa5/5qc2SPTuiOjB9h3YYcJ+yrZYBDlwHzX5Xlk5jiWs9JKBnPt9Jn52WOze4y+8/ /HIwkVS/bt240EOsyqeGXp8dsn1ixy8cX91dyFx9ZXJBC/dOsQD0Res6jByuU0gAR2w2 qpzMwhAkphwut/O35QQk8zXE+zq1V3Nl/m5lfCVF9SpHLrxIc6D7+5YxNS6EYHZZGO9j 1kjgTv6eysg5E+PHkoV9/0BfBBq5QDAXmmQd6gs83GzM/4jE0mOMwp88YMFZso+16H9V z/Rw== X-Gm-Message-State: APzg51CGWG+BAUzoHseFjQqZLn4i5h8eJf4nEeKxASNxu1SOaOheUuzh ERiwbZUDrvf86N42blDtmfk8GguVKSI= X-Google-Smtp-Source: ANB0Vdbh0U3N7+wvAilO5A7vdt9DTATYCeDO+NxLxN1wnoAONEiOh37htSy5cjxwF/d/U5JoAIkFjg== X-Received: by 2002:a6b:3108:: with SMTP id j8-v6mr984936ioa.219.1535752470389; Fri, 31 Aug 2018 14:54:30 -0700 (PDT) Received: from saffron.localnet ([2601:403:0:6bd0:721f:21a4:3206:d6c0]) by smtp.gmail.com with ESMTPSA id g6-v6sm2431111iti.17.2018.08.31.14.54.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Aug 2018 14:54:29 -0700 (PDT) From: Michael Mol 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 Message-ID: <4004237.4pTCg0tAxr@saffron> In-Reply-To: <5bf34233-8740-44e2-e4d5-2f647a703584@gentoo.org> References: <1535279962.1066.24.camel@gentoo.org> <1535280838.4490.16.camel@gentoo.org> <5bf34233-8740-44e2-e4d5-2f647a703584@gentoo.org> 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 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 4cc1bab0-e9df-40cd-b75e-2055f18341da X-Archives-Hash: 763ef089cc05cd91a36902e88a76f575 On Sunday, August 26, 2018 7:09:41 AM EDT 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 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... >=20 > Yup, precise tracking of license metadata can be a pain. >=20 > 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. >=20 > Micha=C5=82, 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 us= e=20 Gentoo's portage tree in my job without extensive and ongoing revalidation = of=20 the license metadata. There are, in fact, automated tools for advising about the license disposit= ion=20 of these types of things, examining source files for unfortunate edits and= =20 variants and flagging them, etc. It might be an interesting task at some po= int=20 to point some of these tools at portage, look for incorrect metadata and fi= le=20 bug reports. Not suggesting this is a worthwhile approach up front, but it might be a=20 useful tool in the future for dealing with license metadata quality as a=20 chronic issue. (Which, in turn, is useful for commercial consumption and=20 participation.)