Jam: which licence is this?

Jam: which licence is this?

[Jack Hill]

Hi Guix,

I'm working on packaging the Argyll Color Management System for Guix. To 
build, it uses the Jam tool, which has the following license:

```
This is Release 2.5 of Jam, a make-like program.

License is hereby granted to use this software and distribute it
freely, as long as this copyright notice is retained and modifications
are clearly marked.

ALL WARRANTIES ARE HEREBY DISCLAIMED.
```

Which license is this?

Best,
Jack

Re: Jam: which licence is this?

[Ricardo Wurmus]

Hi Jack,

> I'm working on packaging the Argyll Color Management System for
> Guix. To build, it uses the Jam tool, which has the following 
> license:

This is also used by Boost.

I don’t know what the license is called, but the build tool is not 
part of the built package, so I think it doesn’t end up in the 
license field.q

-- 
Ricardo

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

>> I'm working on packaging the Argyll Color Management System for
>> Guix. To build, it uses the Jam tool, which has the following 
>> license:
>
> This is also used by Boost.
>
> I don’t know what the license is called, but the build tool is not 
> part of the built package, so I think it doesn’t end up in the 
> license field.q

Are you saying that you believe that software included in a package's
source distribution that's used only during the build process should be
exempt from having its license(s) listed in the 'licenses' field?

If so, I strongly disagree.  I've been a Guix developer for over 8
years, and this is the first time I've heard any suggestion that the
meaning of the 'license' field should be defined in that way.

In general, I think that the license field of a package should include
all licenses that cover any files in its source distribution (by which I
mean the output of "guix build --source").

My rationale is that it is the source code, and not merely the build
outputs, where users will want to exercise the four freedoms of free
software.  For example, when a user wishes to study, modify, or
redistribute the software, they will want to be able to do those things
with the entire source distribution.

Does that make sense?  What do you think?

    Regards,
      Mark

-- 
Support Richard Stallman against the vicious disinformation campaign
against him and the FSF.  See <https://stallmansupport.org> for more.

Re: Jam: which licence is this?

[Leo Famulari]

On Sun, Apr 25, 2021 at 01:25:21PM -0400, Mark H Weaver wrote:
> In general, I think that the license field of a package should include
> all licenses that cover any files in its source distribution (by which I
> mean the output of "guix build --source").
> 
> My rationale is that it is the source code, and not merely the build
> outputs, where users will want to exercise the four freedoms of free
> software.  For example, when a user wishes to study, modify, or
> redistribute the software, they will want to be able to do those things
> with the entire source distribution.
> 
> Does that make sense?  What do you think?

It makes sense, but we've never done that.

For example, the autotools files such as configure.ac bear a simple
permissive license, but we do not mention that in the license field of
the 'hello' package.

Instead, we typically use the license that covers the overall program,
not the (sometimes dozens of) licenses of every single file in the
source distribution.

Can you clarify your expectations regarding which files' licenses should
be mentioned in the package definition?

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> On Sun, Apr 25, 2021 at 01:25:21PM -0400, Mark H Weaver wrote:
>> In general, I think that the license field of a package should include
>> all licenses that cover any files in its source distribution (by which I
>> mean the output of "guix build --source").
>> 
>> My rationale is that it is the source code, and not merely the build
>> outputs, where users will want to exercise the four freedoms of free
>> software.  For example, when a user wishes to study, modify, or
>> redistribute the software, they will want to be able to do those things
>> with the entire source distribution.
>> 
>> Does that make sense?  What do you think?
>
> It makes sense, but we've never done that.
>
> For example, the autotools files such as configure.ac bear a simple
> permissive license, but we do not mention that in the license field of
> the 'hello' package.
>
> Instead, we typically use the license that covers the overall program,
> not the (sometimes dozens of) licenses of every single file in the
> source distribution.

You're right, and that's a good point.  It's true that Guix has a
longstanding practice of omitting more lax licenses when there's also a
more restrictive license covering the same package.  I should have
mentioned that.

However, I think that longstanding practice is orthogonal to the
question of whether licenses covering build system components can be
omitted from the 'license' field.

> Can you clarify your expectations regarding which files' licenses should
> be mentioned in the package definition?

I haven't thought much about the aforementioned longstanding practice,
but that's not what I'm objecting to here.

Specifically, I'm objecting to the idea that the 'license' field need
only describe the files present in the build outputs.  For example, if a
hypothetical package is licensed under Expat but uses a build system
covered by the the Q Public License (QPL), I don't think we can omit
mention of the QPL just because those components are only used during
the build.

Does that make sense?

     Regards,
       Mark

-- 
Support Richard Stallman against the vicious disinformation campaign
against him and the FSF.  See <https://stallmansupport.org> for more.

Re: Jam: which licence is this?

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Sun, Apr 25, 2021 at 04:37:42PM -0400, Mark H Weaver wrote:
> However, I think that longstanding practice is orthogonal to the
> question of whether licenses covering build system components can be
> omitted from the 'license' field.
[...]
> Specifically, I'm objecting to the idea that the 'license' field need
> only describe the files present in the build outputs.  For example, if a
> hypothetical package is licensed under Expat but uses a build system
> covered by the the Q Public License (QPL), I don't think we can omit
> mention of the QPL just because those components are only used during
> the build.
> 
> Does that make sense?

I think I understand what you are suggesting.

However, there is no precedent in Guix for mentioning the licenses of
build system components in package definitions.

I'd guess that almost every single package in Guix would need several
new licenses added to its field, and that field would become useless for
conveying the license of the program itself.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Leo,

I took the liberty of adding a bit more context to your quotation of me
below, since I've added Ludovic to the CC list.

Leo Famulari <leo@famulari.name> writes:

> On Sun, Apr 25, 2021 at 04:37:42PM -0400, Mark H Weaver wrote:
>> It's true that Guix has a
>> longstanding practice of omitting more lax licenses when there's also a
>> more restrictive license covering the same package.  I should have
>> mentioned that.
>>
>> However, I think that longstanding practice is orthogonal to the
>> question of whether licenses covering build system components can be
>> omitted from the 'license' field.
> [...]
>> Specifically, I'm objecting to the idea that the 'license' field need
>> only describe the files present in the build outputs.  For example, if a
>> hypothetical package is licensed under Expat but uses a build system
>> covered by the the Q Public License (QPL), I don't think we can omit
>> mention of the QPL just because those components are only used during
>> the build.
>> 
>> Does that make sense?
>
> I think I understand what you are suggesting.
>
> However, there is no precedent in Guix for mentioning the licenses of
> build system components in package definitions.

I think you're mistaken, or at least this would be news to me.

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.

> I'd guess that almost every single package in Guix would need several
> new licenses added to its field,

Really?  Can you give some examples of this from our core packages?

> and that field would become useless for conveying the license of the
> program itself.

For most purposes, the relevant question is: which license(s) cover the
source code, because that's where users will want to exercise the four
freedoms of free software.  The license(s) that cover the package
outputs are of far less interest, because that's not where users will
exercise the four freedoms.

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.

Perhaps Ludovic would like to clarify?

      Thanks,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

Re: Jam: which licence is this?

[Leo Famulari]

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.

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

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 6629 bytes --]

Hi,

Leo Famulari <leo@famulari.name> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: The purpose of the "license" list of a Guix package

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

Chris Marusich <cmmarusich@gmail.com> writes:

> 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).

Another way of saying this is that, in my understanding, the license
field is "just a hint".  It should be a useful hint, of course, but it
is still just a hint, rather than an exhaustive or authoritative
description of all licensing implications for all use cases.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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 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

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

[Ricardo Wurmus]

Leo Prikler <leo.prikler@student.tugraz.at> 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]

Am Samstag, den 08.05.2021, 13:17 +0200 schrieb Ricardo Wurmus:
> Leo Prikler <leo.prikler@student.tugraz.at> 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?)

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

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.

    <insert standard IANAL disclaimer here>

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

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

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

<https://web.archive.org/web/20140427195428/http://rechten.eldoc.ub.rug.nl/FILES/root/Algemeen/Recht2/2007/GPLauteursrechtelijk/GPL.pdf>

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Jam: which licence is this?

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> For most purposes, the relevant question is: which license(s) cover the
> source code, because that's where users will want to exercise the four
> freedoms of free software.  The license(s) that cover the package
> outputs are of far less interest, because that's not where users will
> exercise the four freedoms.
>
> 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.
>
> Perhaps Ludovic would like to clarify?

I think Leo’s description reflects the initial intent (I believe this
was discussed a few times on the mailing lists in the early years).

The GNU Hello example Leo gave is a good one: we state the license that
applies to what gets installed and do not list licenses applicable to
auxiliary build scripts, say.

HTH!

Ludo’.

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Jack,

Jack Hill <jackhill@jackhill.us> writes:

> I'm working on packaging the Argyll Color Management System for Guix. To 
> build, it uses the Jam tool, which has the following license:
>
> ```
> This is Release 2.5 of Jam, a make-like program.
>
> License is hereby granted to use this software and distribute it
> freely, as long as this copyright notice is retained and modifications
> are clearly marked.
>
> ALL WARRANTIES ARE HEREBY DISCLAIMED.
> ```
>
> Which license is this?

Thanks very much for your diligence here.

I looked into it, and Debian calls this the "Perforce" license.  The
"copyright" file for Debian's 'boost' package includes the following
lines:

--8<---------------cut here---------------start------------->8---
License: Perforce
 License is hereby granted to use this software and distribute it
 freely, as long as this copyright notice is retained and modifications
 are clearly marked.
 .
 ALL WARRANTIES ARE HEREBY DISCLAIMED.
--8<---------------cut here---------------end--------------->8---

<https://metadata.ftp-master.debian.org/changelogs//main/b/boost1.67/boost1.67_1.67.0-13+deb10u1_copyright>

Maybe this should be added to (guix licenses) as 'perforce', or perhaps
'perforce-jam'?

Thoughts?

      Mark

-- 
Support Richard Stallman against the vicious disinformation campaign
against him and the FSF.  See <https://stallmansupport.org> for more.

Re: Jam: which licence is this?

[Maxim Cournoyer]

Hi Mark,

Mark H Weaver <mhw@netris.org> writes:

> Hi Jack,
>
> Jack Hill <jackhill@jackhill.us> writes:
>
>> I'm working on packaging the Argyll Color Management System for Guix. To 
>> build, it uses the Jam tool, which has the following license:
>>
>> ```
>> This is Release 2.5 of Jam, a make-like program.
>>
>> License is hereby granted to use this software and distribute it
>> freely, as long as this copyright notice is retained and modifications
>> are clearly marked.
>>
>> ALL WARRANTIES ARE HEREBY DISCLAIMED.
>> ```
>>
>> Which license is this?
>
> Thanks very much for your diligence here.
>
> I looked into it, and Debian calls this the "Perforce" license.  The
> "copyright" file for Debian's 'boost' package includes the following
> lines:
>
> License: Perforce
>  License is hereby granted to use this software and distribute it
>  freely, as long as this copyright notice is retained and modifications
>  are clearly marked.
>  .
>  ALL WARRANTIES ARE HEREBY DISCLAIMED.
>
> <https://metadata.ftp-master.debian.org/changelogs//main/b/boost1.67/boost1.67_1.67.0-13+deb10u1_copyright>
>
> Maybe this should be added to (guix licenses) as 'perforce', or perhaps
> 'perforce-jam'?

Unless that license is commonly used enough, I would rather not bloat
the licenses list in Guix and instead use the non-copyleft procedure to
define it on the spot, if needed.

Does that make sense?

Maxim

Re: Jam: which licence is this?

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On 2021-04-25, Jack Hill wrote:
> I'm working on packaging the Argyll Color Management System for Guix. To 
> build, it uses the Jam tool, which has the following license:
>
> ```
> This is Release 2.5 of Jam, a make-like program.
>
> License is hereby granted to use this software and distribute it
> freely, as long as this copyright notice is retained and modifications
> are clearly marked.
>
> ALL WARRANTIES ARE HEREBY DISCLAIMED.
> ```

Permission to use, check.
Permission to study, probably(?)
Permission to share, check.
Permission to modify, .... ?

Is it even free software? There is no mention of modification which
doesn't appear to be free by my layman's reading...


Which brings up an ugly bag of worms regarding boost...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Jam: which licence is this?

[Ricardo Wurmus]

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2021-04-25, Jack Hill wrote:
>> I'm working on packaging the Argyll Color Management System for 
>> Guix. To 
>> build, it uses the Jam tool, which has the following license:
>>
>> ```
>> This is Release 2.5 of Jam, a make-like program.
>>
>> License is hereby granted to use this software and distribute 
>> it
>> freely, as long as this copyright notice is retained and 
>> modifications
>> are clearly marked.
>>
>> ALL WARRANTIES ARE HEREBY DISCLAIMED.
>> ```
>
> Permission to use, check.
> Permission to study, probably(?)
> Permission to share, check.
> Permission to modify, .... ?
>
> Is it even free software? There is no mention of modification 
> which
> doesn't appear to be free by my layman's reading...
>
>
> Which brings up an ugly bag of worms regarding boost...

The jam build system in boost is also licensed under the Boost 
license:

The build system source is under tools/build/src/engine/, and the 
jam.cpp file has these notes:

--8<---------------cut here---------------start------------->8---
/*
 * /+\
 * +\   Copyright 1993-2002 Christopher Seiwald and Perforce 
 Software, Inc.
 * \+/
 *
 * This file is part of jam.
 *
 * License is hereby granted to use this software and distribute 
 it freely, as
 * long as this copyright notice is retained and modifications are 
 clearly
 * marked.
 *
 * ALL WARRANTIES ARE HEREBY DISCLAIMED.
 */

/* This file is ALSO:
 * Copyright 2001-2004 David Abrahams.
 * Copyright 2018 Rene Rivera
 * Distributed under the Boost Software License, Version 1.0.
 * (See accompanying file LICENSE_1_0.txt or copy at
 * http://www.boost.org/LICENSE_1_0.txt)
 */
--8<---------------cut here---------------end--------------->8---

FWIW I consider the Jam license to be free; it does mention 
modifications and only asks that they are “clearly marked” 
(whatever that means).  It’s much saner than the LaTeX license 
that asks that any modified file be renamed; it is only acceptable 
to the FSF license team because TeX has an aliasing mechanism, so 
it’s not a practical obstacle, merely a serious annoyance.

-- 
Ricardo

Re: Jam: which licence is this?

[Jack Hill]

[-- Attachment #1: Type: text/plain, Size: 2924 bytes --]

On Sun, 25 Apr 2021, Vagrant Cascadian wrote:

> On 2021-04-25, Jack Hill wrote:
>> I'm working on packaging the Argyll Color Management System for Guix. To
>> build, it uses the Jam tool, which has the following license:
>>
>> ```
>> This is Release 2.5 of Jam, a make-like program.
>>
>> License is hereby granted to use this software and distribute it
>> freely, as long as this copyright notice is retained and modifications
>> are clearly marked.
>>
>> ALL WARRANTIES ARE HEREBY DISCLAIMED.
>> ```
>
> Permission to use, check.
> Permission to study, probably(?)
> Permission to share, check.
> Permission to modify, .... ?
>
> Is it even free software? There is no mention of modification which
> doesn't appear to be free by my layman's reading...

I do see a mention of modification "…modifications are clearly marked." 
Compare with the gnuplot license, for which modifications can only be 
distributed as separate patch files

/*[
  * Copyright 1986 - 1993, 1998, 2004   Thomas Williams, Colin Kelley
  *
  * Permission to use, copy, and distribute this software and its
  * documentation for any purpose with or without fee is hereby granted,
  * provided that the above copyright notice appear in all copies and
  * that both that copyright notice and this permission notice appear
  * in supporting documentation.
  *
  * Permission to modify the software is granted, but not the right to
  * distribute the complete modified source code.  Modifications are to
  * be distributed as patches to the released version.  Permission to
  * distribute binaries produced by compiling modified sources is granted,
  * provided you
  *   1. distribute the corresponding source modifications from the
  *    released version in the form of a patch file along with the binaries,
  *   2. add special version identification to distinguish your version
  *    in addition to the base release version number,
  *   3. provide your name and address as the primary contact for the
  *    support of your modified version, and
  *   4. retain our contact information in regard to use of the base
  *    software.
  * Permission to distribute the released version of the source code along
  * with corresponding source modifications in the form of a patch file is
  * granted with same provisions 2 through 4 for binary distributions.
  *
  * This software is provided "as is" without express or implied warranty
  * to the extent permitted by applicable law.
]*/

ajam clearly marks its modifications by including this in its readme:

"""
This if "Argyll-Jam", a simple derivative of the "FT-Jam" build tool, based and
100% compatible with Jam 2.5. See http://www.freetype.org/jam/ for more
details about FT-Jam.

This is the "FT-Jam" 2.5.2 release, with minor ArgyllCMS tweaks,
and the ArgyllCMS V1.3.3 Jambase as the default rule set.

Note that you'll find the original Jam README in the file README.ORG
"""

Thoughts?
Jack

Re: Jam: which licence is this?

[Jack Hill]

I have asked the FSF licensing lab about this in RT #1718940

Best,
Jack

Re: Jam: which licence is this?

[Jack Hill]

On Sun, 25 Apr 2021, Jack Hill wrote:

> I have asked the FSF licensing lab about this in RT #1718940

I've also asked OSI: 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2021-April/005139.html

Best,
Jack

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Jack,

Jack Hill <jackhill@jackhill.us> writes:

> On Sun, 25 Apr 2021, Jack Hill wrote:
>
>> I have asked the FSF licensing lab about this in RT #1718940

Thanks very much for doing this, Jack.

> I've also asked OSI: 
> https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2021-April/005139.html

Since the Guix project has committed to follow the GNU FSDG, the
relevant question here is whether the license is a "free software"
license, and that's a question for the FSF, not the OSI.

The OSI is only qualified to answer a different question: whether a
license is an "open source" license.  That question is not relevant for
our purposes.

Anyway, thanks again for your diligence here.

     Regards,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

Re: Jam: which licence is this?

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On 2021-04-25, Jack Hill wrote:
> On Sun, 25 Apr 2021, Vagrant Cascadian wrote:
>> On 2021-04-25, Jack Hill wrote:
>>> I'm working on packaging the Argyll Color Management System for Guix. To
>>> build, it uses the Jam tool, which has the following license:
>>>
>>> ```
>>> This is Release 2.5 of Jam, a make-like program.
>>>
>>> License is hereby granted to use this software and distribute it
>>> freely, as long as this copyright notice is retained and modifications
>>> are clearly marked.
>>>
>>> ALL WARRANTIES ARE HEREBY DISCLAIMED.
>>> ```
>>
>> Permission to use, check.
>> Permission to study, probably(?)
>> Permission to share, check.
>> Permission to modify, .... ?
>>
>> Is it even free software? There is no mention of modification which
>> doesn't appear to be free by my layman's reading...
>
> I do see a mention of modification "…modifications are clearly marked." 

Yes, somehow I glazed over this at first... it implies that
modifications which are clearly marked are allowed. :)

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]