On 04/08/24 at 05:45am, Ryan Petris wrote: > 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:* > > • signature.asc > > 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. I would argue the exact opposite. The package is a separate product from the software it packages. If multiple projects are being bundled into the package, the license of the package is not as simple as just the license of the primary upstream project. If a user is actually concerned about the license of the software they install on their machine, omitting relevant licenses because they don't apply directly to the primary upstream obfuscates that information. apg
