bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[ludo@gnu.org (Ludovic Courtès)]

Heya!

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Marius Bakke <mbakke@fastmail.com> skribis:
>>
>>> * gnu/packages/linux.scm (userspace-rcu): New variable.
>>
>> [...]
>>
>>> +    (license
>>> +     ;; This library is distributed under LGPL2.1+, but includes some files
>>> +     ;; covered by other licenses. The LICENSE file has full details.
>>> +     (list license:lgpl2.1+
>>> +           license:gpl3+                         ; most tests are gpl2+; tap.sh is gpl3+
>>> +           license:bsd-2                         ; tests/utils/tap/tap.[ch]
>>> +           license:expat                         ; urcu/uatomic/*
>>> +           ;; A few files use different variants of the MIT/X11 license.
>>> +           (license:x11-style "file://LICENSE"
>>> +                              "See LICENSE in the distribution for details.")))))
>>
>> It’s a case where it’d be enough to put lgpl2.1+ and gpl3+ IMO, since
>> that’s what effectively applies to the resulting work.
>
> Is this also true for the source code archive itself? As an end user,
> looking at the license list and deciding to `guix build -S`, I would
> expect the contents to match what's in the package definition.
>
> Is this a distinction we should make? I.e. "source" license vs "product"
> license. For Ceph, this would be the current license list in the first
> instance and just lgpl2.1 and gpl2 for the built product.

The intent was that ‘license’ would be the license that applies to the
combined work (the thing that you install), IOW the license that “wins”,
omitting build-time programs like ‘install-sh’ and similar scripts.

This is similar to what the Free Software Directory does but coarser
than what Debian does, for instance.

However that has always been under-specified, and a number of packages
list all the licenses that apply to various parts of the source, as you
did above.

> Tricky! Moving the other licenses to the comments for this package, but
> something to think about.

Yeah, tricky!

Ludo’.