From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-85779-garchives=archives.gentoo.org@lists.gentoo.org> 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 4F493138334 for <garchives@archives.gentoo.org>; Sun, 26 Aug 2018 10:54:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9338E08AA; Sun, 26 Aug 2018 10:54:13 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 59ED0E089B for <gentoo-dev@lists.gentoo.org>; Sun, 26 Aug 2018 10:54:13 +0000 (UTC) Received: from [192.168.2.51] (62.65.228.137.cable.starman.ee [62.65.228.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id 0DCA2335CA3; Sun, 26 Aug 2018 10:54:09 +0000 (UTC) Message-ID: <1535280838.4490.16.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23] From: Mart Raudsepp <leio@gentoo.org> To: gentoo-dev@lists.gentoo.org Cc: licenses@gentoo.org, qa <qa@gentoo.org> Date: Sun, 26 Aug 2018 13:53:58 +0300 In-Reply-To: <1535279962.1066.24.camel@gentoo.org> References: <1535279962.1066.24.camel@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-SrFdusS4RPp0DjLfjia2" X-Mailer: Evolution 3.24.6 Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Archives-Salt: 2f5f74ca-31fe-4ace-a282-c6aec481efbf X-Archives-Hash: 035d8e0366d2061d9176b19a05f311e4 --=-SrFdusS4RPp0DjLfjia2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C3=9Chel kenal p=C3=A4eval, P, 26.08.2018 kell 12:39, kirjutas Micha=C5=82= G=C3=B3rny: > Hi, >=20 > It seems that we suffer a major problem of developers wrongly > attributing *GPL-[23] licenses to ebuilds, when the correct variant > is > *GPL-[23]+. In proxy-maint, every second new package with > LICENSE=3DGPL- > [23] is plain wrong. I suspect part of the problem is that GitHub > has > poor man's license recognition that does not distinguish between 'vN > only' and 'vN or newer' license variants, and similarly that a number > of > contributors don't bother checking the license beyond COPYING/README. >=20 > Another part of the problem is that we don't have a really good way > of > distinguishing verified correct uses of *GPL-[23]. So in the end, I > end > up verifying the same packages over and over again unless I remember > that I've verified them. >=20 > Therefore, I would like to suggest the following: >=20 > 1. introducing additional *-only licenses that explicitly indicate > that > a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc. >=20 > 2. annotating the unsuffixed licenses with a warning that they may > mean > either x-only or x+ due to frequent mistake. >=20 > 3. make repoman warn whenever non-specific variant is used, telling > developers to verify whether it's x-only or x+. >=20 > 4. start migrating packages to x-only or x+ appropriately. >=20 > 5. eventually, remove the non-specific licenses and make repoman > error > out with clear explanation. >=20 > What do you think? 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... In many cases you can trust upstreams that do make it explicit somewhere though (toplevel meson.build, README.md, CONTRIBUTING.md, etc). Otherwise good idea, but I'm not sure how we are supposed to keep up with monitoring non-"or later" sources creeping in in new upstream versions. There are plenty of wrong LICENSE tags in this regard under my co- maintenance too, and it's a pain to validate all the source files, and it's just a best effort of "hopefully my grep magic covered it and they haven't used a non-standard file copyright header". Mart --=-SrFdusS4RPp0DjLfjia2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAluChsZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgY3kQ//avFQk27AOmbkQP0YRop2FjqdILsNcKsCJ3FcOhbPY/rDyJEvarYgh2W6 LglsuzVHgykXB3xoiyVCiQDAldpAZw14v1nHFYFQCoKQJIVCzlnPTVnYz8X8VyJt +hAb2jvGPVddWj7lUjBh+yRMcYpVrYyYchiXbk+gCpci6kaV10liCChggPaKkZ1v SZ73fIQH2amX80gAEnEBCVV2saaKZmoYJGTCMxbiwPCVTBufZcQFCZ5FP8Azoyop urxVlGUb0uGUFtLeAOXenP0X5dybKS7smZyAQ3XVIx+m53w0GJYmCXcJcLVtv22t dyFX/0Eu0UpEkSRLohZTUZzV1wgESPQDekM0A+vQ18BjAzibb/jedfmBBMhpA/vL g2UQ8C+/jSM8HFGrA5Yrdz89Ohi4IIXFvax+vqxkqKBYpP8VeBsCLYt/VZfHuZP2 vjP3OW+Syb1OA0xb13JtdH9wK4lptOfn+Mo4ThUwucAXJqvR9elIZ5iyukWlXVho mzozqsIUN55LkncGjt0rVKSVLSZbFp+DMFeNp6qGJ7ghORnhxBq2bnMZ6i14b3SY 8hEFWblX080YLoy0FYGyktYhkE8afaOHhNw9AcP83YqeDU76UR+yfJ9I2fypanQO 83dT/7Lh5druj5hpQuyUJkLYZ2HL/hmRbjKNja6EbeU5PsBivsQ= =YMRW -----END PGP SIGNATURE----- --=-SrFdusS4RPp0DjLfjia2--