[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: missing licence files and incomplete licence lists
From: |
Ludovic Courtès |
Subject: |
Re: missing licence files and incomplete licence lists |
Date: |
Sun, 10 Sep 2017 23:02:56 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Hi,
Dave Love <address@hidden> skribis:
> Ludovic Courtès <address@hidden> writes:
[...]
>> Guix is much less comprehensive than Debian. The ‘license’ field is
>> meant to list the license that applies to the combined work.
>>
>> For glibc, it’s LGPLv2+; glibc includes BSD-licensed work, but that
>> doesn’t matter from this perspective.
>
> Is that based on FSF legal advice?
No.
>>> Should bugs just be filed against each case, or can things be checked
>>> systematically?
>>
>> Given the meaning of ‘license’ above, if you find errors, you’re of
>> course welcome to report them. But keep in mind that ‘license’ is
>> looser than the info you’d fine in Debian ‘copyright’ files.
>
> Is it meant to be equivalent of the RPM License field in Fedora/SuSE?
> If not, exactly what does it mean?
I don’t know about Fedora/SuSE.
> Sorry if this seems too picky, but it's meant to be friendly advice from
> long observation! A GNU project should follow FSF legal advice, but I'd
> expect Debian and Fedora to be fairly good models in the areas they
> clearly agree.
Understood.
If you look at <https://directory.fsf.org/wiki/Libc#Details>, you’ll see
“License:LGPL”, which is already more vague than what we have (following
FSF legal advice?). If you look at GitHub repos (yack!), Pypi, CPAN,
Hackage, npm (doh!), well, that’s yet another level.
I’m interested in concrete proposals to improve the situation that take
into account the bigger picture as well as scalability considerations.
Thoughts?
Ludo’.