Ühel kenal päeval, P, 26.08.2018 kell 12:39, kirjutas Michał Górny: > Hi, > > 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=GPL- > [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. > > 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. > > Therefore, I would like to suggest the following: > > 1. introducing additional *-only licenses that explicitly indicate > that > a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc. > > 2. annotating the unsuffixed licenses with a warning that they may > mean > either x-only or x+ due to frequent mistake. > > 3. make repoman warn whenever non-specific variant is used, telling > developers to verify whether it's x-only or x+. > > 4. start migrating packages to x-only or x+ appropriately. > > 5. eventually, remove the non-specific licenses and make repoman > error > out with clear explanation. > > 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
signature.asc
Description: This is a digitally signed message part
