unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* missing licence files and incomplete licence lists
@ 2017-08-23 13:13 Dave Love
  2017-09-04 14:36 ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Dave Love @ 2017-08-23 13:13 UTC (permalink / raw)
  To: guix-devel

I realize that a lot of packages don't include licence files
(e.g. glibc).  I'd mistakenly assumed that was automated according to
the "license" fields.

Also, some license fields aren't complete -- compare glibc's lgpl with
the contents of Debian's libc6 "copyright" file, which includes gpl,
bsd, and others, not just lgpl.

Should bugs just be filed against each case, or can things be checked
systematically?

Related to that, licensecheck doesn't seem to be packaged.  If it was,
could it be used by "lint" (or something else)?  I don't know whether
lint is supposed only to process the package description or could look
at the package contents the way Fedora's review tool does, for instance.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: missing licence files and incomplete licence lists
  2017-08-23 13:13 missing licence files and incomplete licence lists Dave Love
@ 2017-09-04 14:36 ` Ludovic Courtès
  2017-09-07 16:32   ` Dave Love
  0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2017-09-04 14:36 UTC (permalink / raw)
  To: Dave Love; +Cc: guix-devel

Hi,

Dave Love <fx@gnu.org> skribis:

> I realize that a lot of packages don't include licence files
> (e.g. glibc).

You mean ‘COPYING’ & co.?

> I'd mistakenly assumed that was automated according to the "license"
> fields.

Nope.  Outside of GNU there are no real conventions for license file
names anyway.

> Also, some license fields aren't complete -- compare glibc's lgpl with
> the contents of Debian's libc6 "copyright" file, which includes gpl,
> bsd, and others, not just lgpl.

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.

> 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.

> Related to that, licensecheck doesn't seem to be packaged.  If it was,
> could it be used by "lint" (or something else)?  I don't know whether
> lint is supposed only to process the package description or could look
> at the package contents the way Fedora's review tool does, for instance.

A package for ‘licensecheck’ would be welcome.

I don’t think we should implement something like this in ‘guix lint’
because (1) there are already several tools doing that, and it’s only
ever going to be an approximation anyway, and (2) ‘guix lint’ is meant
to run fast.

HTH!

Ludo’.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: missing licence files and incomplete licence lists
  2017-09-04 14:36 ` Ludovic Courtès
@ 2017-09-07 16:32   ` Dave Love
  2017-09-10 21:02     ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Dave Love @ 2017-09-07 16:32 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Dave Love <fx@gnu.org> skribis:
>
>> I realize that a lot of packages don't include licence files
>> (e.g. glibc).
>
> You mean ‘COPYING’ & co.?

Yes.

>> I'd mistakenly assumed that was automated according to the "license"
>> fields.
>
> Nope.  Outside of GNU there are no real conventions for license file
> names anyway.

Debian and SuSE both specify SPDX ones.  (There's been discussion about
using that for Fedora.)

That's orthogonal to the semantics of the field, though; if it's
misleading, that might be worse than not having it at all.

>> Also, some license fields aren't complete -- compare glibc's lgpl with
>> the contents of Debian's libc6 "copyright" file, which includes gpl,
>> bsd, and others, not just lgpl.
>
> 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?  I think it needs to be if you want
to ignore what BSD licences say.  I'm afraid I'm old enough to remember
the BSD licence in a court case, without which the free software
landscape might be rather different, and the FSF campaigned against the
"obnoxious" advertising condition of original BSD.

>> 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?

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: missing licence files and incomplete licence lists
  2017-09-07 16:32   ` Dave Love
@ 2017-09-10 21:02     ` Ludovic Courtès
  2017-09-12 22:21       ` Dave Love
  0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2017-09-10 21:02 UTC (permalink / raw)
  To: Dave Love; +Cc: guix-devel

Hi,

Dave Love <fx@gnu.org> skribis:

> Ludovic Courtès <ludo@gnu.org> 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’.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: missing licence files and incomplete licence lists
  2017-09-10 21:02     ` Ludovic Courtès
@ 2017-09-12 22:21       ` Dave Love
  2017-09-21 14:23         ` Ricardo Wurmus
  0 siblings, 1 reply; 6+ messages in thread
From: Dave Love @ 2017-09-12 22:21 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès <ludo@gnu.org> writes:

> 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.

Yes, but...  To package something for Debian or Fedora with a
problematic (or missing) licensing, you have to resolve that, typically
with "upstream", too get it into the distribution.

> I’m interested in concrete proposals to improve the situation that take
> into account the bigger picture as well as scalability considerations.
>
> Thoughts?
>
> Ludo’.

I'd say consult FSF legal eagles initially, and see whether you can
piggy-back off the work the other distributions have done.  Once you
have the legal constraints, you can consider a concrete proposal.  I
think the package license field also needs generalizing somehow to allow
conjunctions and disjunctions.  I fully realize the pain of all this
from experience...

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: missing licence files and incomplete licence lists
  2017-09-12 22:21       ` Dave Love
@ 2017-09-21 14:23         ` Ricardo Wurmus
  0 siblings, 0 replies; 6+ messages in thread
From: Ricardo Wurmus @ 2017-09-21 14:23 UTC (permalink / raw)
  To: Dave Love; +Cc: guix-devel


Dave Love <fx@gnu.org> writes:

> I think the package license field also needs generalizing somehow to
> allow conjunctions and disjunctions.

I don’t think this will be necessary; explanatory comments surely would
be sufficient.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-09-21 14:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-23 13:13 missing licence files and incomplete licence lists Dave Love
2017-09-04 14:36 ` Ludovic Courtès
2017-09-07 16:32   ` Dave Love
2017-09-10 21:02     ` Ludovic Courtès
2017-09-12 22:21       ` Dave Love
2017-09-21 14:23         ` Ricardo Wurmus

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).