Gentoo Archives: gentoo-dev

From: Mart Raudsepp <leio@g.o>
To: gentoo-dev@l.g.o
Cc: licenses@g.o, qa <qa@g.o>
Subject: Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]
Date: Sun, 26 Aug 2018 10:54:17
Message-Id: 1535280838.4490.16.camel@gentoo.org
In Reply to: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23] by "Michał Górny"
1 Ühel kenal päeval, P, 26.08.2018 kell 12:39, kirjutas Michał Górny:
2 > Hi,
3 >
4 > It seems that we suffer a major problem of developers wrongly
5 > attributing *GPL-[23] licenses to ebuilds, when the correct variant
6 > is
7 > *GPL-[23]+. In proxy-maint, every second new package with
8 > LICENSE=GPL-
9 > [23] is plain wrong. I suspect part of the problem is that GitHub
10 > has
11 > poor man's license recognition that does not distinguish between 'vN
12 > only' and 'vN or newer' license variants, and similarly that a number
13 > of
14 > contributors don't bother checking the license beyond COPYING/README.
15 >
16 > Another part of the problem is that we don't have a really good way
17 > of
18 > distinguishing verified correct uses of *GPL-[23]. So in the end, I
19 > end
20 > up verifying the same packages over and over again unless I remember
21 > that I've verified them.
22 >
23 > Therefore, I would like to suggest the following:
24 >
25 > 1. introducing additional *-only licenses that explicitly indicate
26 > that
27 > a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
28 >
29 > 2. annotating the unsuffixed licenses with a warning that they may
30 > mean
31 > either x-only or x+ due to frequent mistake.
32 >
33 > 3. make repoman warn whenever non-specific variant is used, telling
34 > developers to verify whether it's x-only or x+.
35 >
36 > 4. start migrating packages to x-only or x+ appropriately.
37 >
38 > 5. eventually, remove the non-specific licenses and make repoman
39 > error
40 > out with clear explanation.
41 >
42 > What do you think?
43
44 The common issue here is that upstream COPYING files really do only
45 talk about one of the versions. And then you get to validate or source
46 files to be sure that they do have a "or later" clause in them. And
47 then on each bump you ideally should validate it again, etc, that no
48 sources without "or later" allowance are in there...
49 In many cases you can trust upstreams that do make it explicit
50 somewhere though (toplevel meson.build, README.md, CONTRIBUTING.md,
51 etc).
52 Otherwise good idea, but I'm not sure how we are supposed to keep up
53 with monitoring non-"or later" sources creeping in in new upstream
54 versions.
55
56 There are plenty of wrong LICENSE tags in this regard under my co-
57 maintenance too, and it's a pain to validate all the source files, and
58 it's just a best effort of "hopefully my grep magic covered it and they
59 haven't used a non-standard file copyright header".
60
61
62 Mart

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies