| 1 |
>>>>> On Sun, 22 Sep 2019, Matt Turner wrote: |
| 2 |
|
| 3 |
> We are all aware. But the point is to explicitly put "-only" in the |
| 4 |
> LICENSE metadata so that ebuild authors are less likely to confuse |
| 5 |
> GPL-2 vs GPL-2+. |
| 6 |
|
| 7 |
I don't see how renaming could possibly help with that. |
| 8 |
|
| 9 |
>> Plus, it would result in paradoxical entries like "|| ( GPL-2-only |
| 10 |
>> GPL-3-only )" for a package that can be distributed under GPL |
| 11 |
>> versions 2 or 3 but no later version. |
| 12 |
|
| 13 |
> That paradoxical entry is pretty clear to me. |
| 14 |
|
| 15 |
Not the same thing. "GPL-2-only+" might be clear as well, which doesn't |
| 16 |
imply that it isn't paradoxical. |
| 17 |
|
| 18 |
> It's not a one-time audit. Michał has a history of fixing things in |
| 19 |
> ways that does not allow the issue to return. I imagine that's what |
| 20 |
> he's doing here, and it would not surprise me at all if something |
| 21 |
> could be wired into CI to help ensure this. |
| 22 |
|
| 23 |
If it's not a one time audit, it implies that we will permanently have |
| 24 |
three variants. This would be a lot of effort, for a tiny gain. After |
| 25 |
all, there is absolutely no difference in ACCEPT_LICENSE filtering |
| 26 |
between GPL-2 and GPL-2+. |
| 27 |
|
| 28 |
> Trivial concern solved with a news item. |
| 29 |
|
| 30 |
As I've said before, if the intent is to do a tree-wide audit, then |
| 31 |
this should be done in a way that has no impact on users. For example, |
| 32 |
by adding a comment, instead of changing the LICENSE variable. |
| 33 |
|
| 34 |
Ulrich |
Archives