On Sun, Apr 7, 2024, at 12:42 PM, tippfehlr wrote:
Hi,

> Replying on the general mailing list since the dev list is staff only.

tried to reply to arch-dev-public earlier, that explains why it didn’t work.

> Personally I think having incomplete SPDX identifier in the pacman 
> package is not in itself a license violation as long as the individual 
> license files are shipped with the package. Although it would certainly 
> be nice for tooling if the package information is complete too.

I think having the licenses of all dependencies in the license field is
(1) a lot of clutter and (2) not what I would expect.

If I want to check under which license linux is released, the result

$ pacman -Si linux
...
Licenses        : GPL-2.0-only
...

is a lot more useful (to me) than

$ pacman -Si linux-lts
...
Licenses        : Apache-2.0 OR MIT  BSD-2-Clause OR GPL-2.0-or-later
                  BSD-3-Clause  BSD-3-Clause OR GPL-2.0-only
                  BSD-3-Clause OR GPL-2.0-or-later  BSD-3-Clause-Clear
                  GPL-1.0-or-later  GPL-1.0-or-later OR BSD-3-Clause
                  GPL-2.0-only  GPL-2.0-only OR Apache-2.0
                  GPL-2.0-only OR BSD-2-Clause  GPL-2.0-only OR BSD-3-Clause
                  GPL-2.0-only OR CDDL-1.0  GPL-2.0-only OR Linux-OpenIB
                  GPL-2.0-only OR MIT  GPL-2.0-only OR MPL-1.1
                  GPL-2.0-only OR X11  GPL-2.0-only WITH Linux-syscall-note
                  GPL-2.0-or-later  GPL-2.0-or-later OR BSD-2-Clause
                  GPL-2.0-or-later OR BSD-3-Clause  GPL-2.0-or-later OR MIT
                  GPL-2.0-or-later OR X11
                  GPL-2.0-or-later WITH GCC-exception-2.0  ISC
                  LGPL-2.0-or-later  LGPL-2.1-only
                  LGPL-2.1-only OR BSD-2-Clause  LGPL-2.1-or-later  MIT
                  MPL-1.1  X11  Zlib
...

(though I’m not sure why they differ)

Best regards,
tippfehlr


Attachments:

I agree with this.

The "license" of the package isn't the collection of licenses that make up the software along with all of its libraries, it's the license of the software itself. Including the license of all the libraries in the "license" field would just muddy the waters and make that field effectively useless.

What could be done, IMO, is that all of the relevant licenses and copyright notices be included in the licenses directory for that package, for instance:

/usr/share/licenses/<package name>/LICENSE_<library name>

Based on my knowledge and readings of open source licenses (I am not a lawyer and this is not legal advice), this should satisfy the majority if not all conditions of binary distribution of licenses.

However, I do think that the rust/cargo maintainers need to have some skin in the game here (along with go, nodejs, and similar languages) and have some way of dumping the licenses of dependencies. When you have a packaging system that makes it easy to pull in hundreds of dependencies, there should be an easy way of checking what those licenses are anyway because you could otherwise end up in a bad situation.