Hi, Leo Famulari writes: > On Sun, May 02, 2021 at 12:53:07AM -0400, Mark H Weaver wrote: >> My understanding is that the 'license' field of a package in Guix has >> _always_ been meant to summarize the license restrictions associated >> with the package source (the output of "guix build --source"), and >> *not* merely the package outputs. > > My understanding is that the license field describes the license that > the package is redistributed under, which is typically a single license, > but could be a dual (or multiple) license if that is the case. > > The manual section "package Reference" says: > > The license of the package; a value from (guix licenses), or a list of > such values. > > It's the license of the package, overall. Not of every single file in > the source code. > >> Really? Can you give some examples of this from our core packages? > > The 'hello' package is not core, but it is a typical Autotools-based > package, and the core packages will be similar. > > It is, overall, GPL3 or later. However, the component source files bear > these other licenses too: > > aclocal.m4: An unnamed permissive license > AUTHORS: An unnamed permissive license > configure: An unnamed permissive license > configure.ac: An unnamed permissive license > INSTALL: An unnamed permissive license > maint.mk: An unnamed permissive license > Makefile.am, Makefile.in: An unnamed permissive license > README, README-dev: An unnamed permissive license > THANKS: An unnamed permissive license > > build-aux/compile: GPL2+ > build-aux/config.rpath: An unnamed permissive license > build-aux/depcomp: GPL2+ > build-aux/install-sh: Expat license > build-aux/mdate-sh: GPL2+ > build-aux/missing: GPL2+ > build-aux/test-driver: GPL2+ > > doc: Some files bear the GFDL > > m4: Maybe unnamed permissive licenses (I'm getting tired) > > po/Makefile.in.in: The "GPL" with no version mentioned. I assume GPL1. > po/POTFILES.in: An unnamed permissive license > > tests/*: An unnamed permissive license > > Some of those unnamed permissive licenses are the same as each other, > some are different. > > It would be unhelpful if the package definition's license field said > "gpl3+ gpl2+ gpl1 non-copyleft expat gfdl". Nobody would be able to > answer the question "What is the license of the 'hello' package?" > >> The 'license' field can only mean one of these two things, and I think >> it's fairly clear which one it should be. Moreover, I think that this >> is what it has always meant in Guix. If not, that's a problem. > > My survey of the "hello" package shows that the license field in Guix is > about the overall license of the program, not an exhaustive list of the > many licenses used for various components of the source code. > > I don't think it's a problem to not mention those licenses in the > package definition. When the user acquires the source code, they still > get the benefits of the freely licensed components. Nothing is being > hidden. > > The suggestion that our package definitions' license field should > mention every license contain in the source code has no precedent in > Guix, at least since I joined. I don't there is a demonstrated benefit > to making that change. I agree with Leo. My understanding is that the intent of the "license" field (which can be a list) in a Guix package is to call out the "main" (deliberately vague here) licenses related to the code, not to provide an exhaustive or authoritative description of all the licenses affecting every file in every possible situation. As Leo has demonstrated, a package's license field (like probably most summaries of license information) is surely not exhaustive or authoritative; the licenses in the source code files themselves are authoritative. My understanding is that a packager is expected to audit the licenses in the files when adding the package. If an exhaustive audit is not feasible (which is often the case), they should perform a reasonable spot check and then list the "main" licenses in play in the licenses file. As in the GNU Hello case, there is clearly a judgment call regarding what goes into the Guix package's licenses list, since a simple list cannot describe everything. In general, even if hypothetically you did do an exhaustive audit of all files, it is not practical to try to describe all the licensing implications in the Guix package definition. I don't think that's the purpose of the license field. One more thing. I have always felt that the license field of a Guix package is intended to call out the licenses that apply to the built output of the package in particular. In other words, I think the license field is intended to call out the licenses that are most likely to apply in the situation where you "link" with the built output of the package. That is the purpose of many packages: to be "linked" from other source code. Since it is often the case that software you write will not be "linking" with the package's build scripts, but rather with the package's built output, the license of the build scripts are less relevant for that use case. In the end, I think a packager is expected to be operating in good faith, in accordance with the FSDG. This means that packagers look for freedom issues and address them when found. It does not mean that packagers are expected to provide a detailed "bill of materials" for every single package, although that is certainly something that some people think is important (and some people don't). This reminds me of the following fun debate from FOSDEM 2020: "Does Careful Inventory of Licensing Bill of Materials Have Real Impact on FOSS License Compliance?" https://archive.fosdem.org/2020/schedule/event/debate_license_compliance/ I think you might enjoy watching it. Basically, the "negative" argument (careful inventory of licensing bill of materials does NOT have a real impact on FOSS license compliance) is somewhat relevant here, and it went something like this: the transitive closure of required source code itself is a kind of "bill of materials", and if you only use free software, it is always easy to comply - just provide the source code. It was a fun debate. I happened to be in the audience, and I mentioned in a question at the end that Guix makes it easy to provide the transitive closure of source for any given piece of software. I don't know of any other tool that does this for all software in an operating system, except maybe Nix. -- Chris