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 |