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

[Maxime Devos]

Leo Prikler schreef op zo 09-05-2021 om 01:04 [+0200]:
> >  and insteads prefers something with basically no licenses.
I meant to write

‘and instead prefers something with basically no restrictions at all’.

here.

> > I would find it interesting to know if some ‘legal people’ have
> > worked out this situation.
> Which ones?  The ones who tell you "you must form a bill of materials"
> or the ones who tell you "just provide the source"?  :)

The ones that don't simply tell ‘do this’ or ‘do that’ but explain their
reasoning carefully. E.g., I recently came across



which I'm now reading.

‘Just provide the source’ is a bit simplistic anyways. If APP derives
from GPL-LIB, then you can't release APP as $PROPIETARY even if you
provide the source code of APP and GPL-LIB.

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

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

[Leo Prikler]

Am Samstag, den 08.05.2021, 22:52 +0200 schrieb Maxime Devos:
> Leo Prikler schreef op za 08-05-2021 om 12:16 [+0200]:
> > [... something about dependencies and copyleft ...]
> > [...]
> > 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. [...]
> 
> Just checking if our understanding is the same, as I have seen a
> discussion on IRC where people the situation described below was
> _not_ legally acceptable.
Disclaimer: IANAL, but I'd argue the following.

> Suppose we have a GPLv3+ library, say guile-jwt.
> Suppose there is a (group of) developer(s) writing an application
> using guile-jwt. Let's call the application APP, and the developer(s)
> DEV.
At this point in time, I'd argue, that APP is "a work based on guile-
jwt", as defined in section 0 of the GPLv3.

> A hypothetical situation:
> 
>   * Suppose DEV is not very fond of licensing APP under a copyleft
> license,
> and insteads prefers something with basically no licenses.
>   * DEV wants to choose, say, license:expat.
>   * license:expat is not license:gpl3
>   * Would this be a problem? I would think not. While APP used 
> guile-jwt, it doesn't include or modify its source code.
I would think yes.  If what you said was true about Guile code, then
any proprietary code could just link against the GPL willy-nilly (well,
they'd have to take care to explicitly call dlopen, but you get the
point).  That obviously is not the case, the LGPL exists for a reason.

> So I would think DEV must still respect GPL for the combination 
> (e.g., if DEV provides binaries for APP, they must include source
> code for guile-jwt *and* APP), and theoretically someone may fork
> APP to replace guile-jwt with a hypothetical guile-jwt/expat, and
> at that point the GPL doesn't apply anymore to the combination
> APP-with-guile-jwt/expat.
I agree, that they'd at least have to provide the Corresponding Source
as laid out in section 6, but I also think they'd have to follow
section 4 and 5, in particular 5c.
The code within APP, that is not directly related to guile-jwt may very
well be Expat, and DEV might even go so far as to claim, that "just the
source" of the other stuff is Expat as well, but APP as a package must
be GPL'd (unless APP is only using public domain or Expat parts of
guile-jwt if they exist).

Once someone does have an expat-fork of guile-jwt and it's fair to no
longer assume APP to be based on guile-jwt, but rather guile-jwexpat,
the package as a whole can be distributed under the Expat license.

> I would find it interesting to know if some ‘legal people’ have
> worked out this situation.
Which ones?  The ones who tell you "you must form a bill of materials"
or the ones who tell you "just provide the source"?  :)

Regards,
Leo

PS: The above was written under the assumption, that you write your app
in a way, that it calls guile-jwt directly, not by forking guile and
communicating to it through pipes or sockets.

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

[Maxime Devos]

Leo Prikler schreef op za 08-05-2021 om 12:16 [+0200]:
> [... something about dependencies and copyleft ...]
> [...]
> 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. [...]

Just checking if our understanding is the same, as I have seen a discussion
on IRC where people the situation described below was _not_ legally acceptable.

Suppose we have a GPLv3+ library, say guile-jwt.
Suppose there is a (group of) developer(s) writing an application using
guile-jwt. Let's call the application APP, and the developer(s) DEV.

A hypothetical situation:

  * Suppose DEV is not very fond of licensing APP under a copyleft license,
and insteads prefers something with basically no licenses.
  * DEV wants to choose, say, license:expat.
  * license:expat is not license:gpl3
  * Would this be a problem? I would think not. While APP used guile-jwt,
it doesn't include or modify its source code.

So I would think DEV
must still respect GPL for the combination (e.g., if DEV provides binaries
for APP, they must include source code for guile-jwt *and* APP),
and theoretically someone may fork APP to replace guile-jwt with
a hypothetical guile-jwt/expat, and at that point the GPL doesn't
apply anymore to the combination APP-with-guile-jwt/expat.



I would find it interesting to know if some ‘legal people’ have worked out
this situation.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

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

[Leo Prikler]

Am Samstag, den 08.05.2021, 13:17 +0200 schrieb Ricardo Wurmus:
> Leo Prikler  writes:
> 
> > 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?
> 
> “guix build --sources=transitive hello” builds the source 
> derivations for hello and all its transitive inputs.
Documentation: N
Me: 0

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

[Ricardo Wurmus]

Leo Prikler  writes:

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?


“guix build --sources=transitive hello” builds the source 
derivations for hello and all its transitive inputs.


--
Ricardo

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

[Leo Prikler]

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 

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

[Chris Marusich]

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