Re: The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?)

[Leo Prikler <leo.prikler@student.tugraz.at>]

Hi,

Am Freitag, den 07.05.2021, 11:31 -0700 schrieb Chris Marusich:
> 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.
I agree with both you and the other Leo, but I think we're getting a
little off-topic here.  The reason,why it's necessary to argue about
jam's license is because (as I see it) we don't have a jam package and
it is a necessary tool to build a package someone wants to contribute. 

The reason why we don't care about this when it comes to Autotools is
that we have Autotools packaged, and it is expected that all the stuff
generated by it exists in the package post the configure phase of a
package that uses gnu-build-system unmodified.  This makes it, so that
this question only ever arises for packages distributing `make dist`-
generated packages in the first place, and the question for those
should not be "Do we include those licenses", but "Do we trust, that
this was really generated with `make dist`"?

> 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.
I agree, that the main license (the one that appears first in the
license list, or the one that appears alone) should more or less cover
"the whole package", but if there's a range of *actual* source files
(including source files from which a bizarre compiler or build tool is
built, that is afterwards used by the package), that should imo be
included in that list with a suitable comment.  

I don't fault any packager, who misses one or two licenses in some
obscure hidden file, but if someone finds and adds them, I think that
patch should likely be accepted.

> 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.
I think this misses the point when it comes to stuff like the artwork
for a game.  Clearly, that artwork is a substantial part of the game
and deserves a place in the license field.  The other way around,
whenever you encounter some Creative Commons license with the comment
"artwork", this might not concern linkage (unless the artwork is baked
into the program itself, as might be the case in some GTK and Qt
applications, but those are rarely "linked" from other programs), but
rather redistribution.

> 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.
Just saw that debate.  I think the actual argument went somewhat like
"the transitive source closure *contains* whatever you might argue
constitutes a bill of materials", and I think that holds.  Every given
package should only need to consider what licenses itself brings into
the mix, not what some person upstream does (of course while complying
with the licenses of its dependencies).

However, compliance is not *that* simple.  If you're dealing with
copyleft, providing the source is not enough, you also need to license
your own work under that copyleft license, e.g. the GPL.  That said,
GNU Guix makes it fairly easy to check when you need to do that.  Have
a package with (license:gplN+?) in your inputs?  You probably need to
GPL it.

> 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.
For the record, what command gives you transitive source closure?  I
can see transitive binary closure with `guix pack`, but I don't think
we do source closure unless asked to `guix build --no-substitutes`. 
Maybe a missing feature?

Regards,
Leo