Clarify the license field of the package

Clarify the license field of the package

[宋文武]

Hello list, I have some questions about the 'license' of a package,
currently defined as:

    The license of the package; a value from ‘(guix licenses)’, or a
    list of such values.

1. It's the license of source files (guix build -S) or built binary
   files?

2. When its value is a list of multiple licenses, it's files under
   different licenses (eg: lib/*.so under LGPL, while bin/* under GPL),
   or files under one license select from choices?

My guess is that the license field is for source files since we can
disable binary substitutes, and list is used for files under different
licenses.

Does my guess is correct?  Thank you!

Re: Clarify the license field of the package

[John Kehayias]

Hello 宋文武,

On Mon, Aug 22, 2022 at 05:02 PM, 宋文武 wrote:

> Hello list, I have some questions about the 'license' of a package,
> currently defined as:
>
>     The license of the package; a value from ‘(guix licenses)’, or a
>     list of such values.
>
> 1. It's the license of source files (guix build -S) or built binary
>    files?
>

Not a lawyer by any means, so I'm not sure how it works. For sure it applies to the source, but after building the binary output will contain a LICENSE or COPYING file (always? I would assume). Other than that, I don't know :)

> 2. When its value is a list of multiple licenses, it's files under
>    different licenses (eg: lib/*.so under LGPL, while bin/* under GPL),
>    or files under one license select from choices?
>

In packaging, I have seen this when a package contains multiple sources for whatever reason, though we do try to unbundle as much as possible. I've also seen a few that just have multiple licenses as the source had specified multiple licenses, whether for different files or for user choice. Often, this is commented in the package definition for which license applies to which files, or why multiple are listed.

For example, in the recent haxe package (which I wrote and I believe you pushed), the compiler and standard library are packaged together with different licenses. This is noted in the comments of the license field. While it may be possible to package these separately, I'm not sure if it really makes sense given how they are used and what upstream intends.

> My guess is that the license field is for source files since we can
> disable binary substitutes, and list is used for files under different
> licenses.
>
> Does my guess is correct?  Thank you!

Those are my guesses/experiences above, hope that is helpful.

John

Re: Clarify the license field of the package

[宋文武]

John Kehayias <john.kehayias@protonmail.com> writes:

> Hello 宋文武,
>
> On Mon, Aug 22, 2022 at 05:02 PM, 宋文武 wrote:
>
>> Hello list, I have some questions about the 'license' of a package,
>> currently defined as:
>>
>>     The license of the package; a value from ‘(guix licenses)’, or a
>>     list of such values.
>>
>> 1. It's the license of source files (guix build -S) or built binary
>>    files?
>>
>
> Not a lawyer by any means, so I'm not sure how it works. For sure it
> applies to the source, but after building the binary output will
> contain a LICENSE or COPYING file (always? I would assume). Other than
> that, I don't know :)

Yes, guix distribute both sources and binaries (via substitute).  As a
packager, I'm afraid to get that 'license' field wrong...

> [...]
> Those are my guesses/experiences above, hope that is helpful.

Thank you for join discussion!

Re: Clarify the license field of the package

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 2556 bytes --]

On 22-08-2022 11:02, 宋文武 wrote:

> Hello list, I have some questions about the 'license' of a package,
> currently defined as:
>
>      The license of the package; a value from ‘(guix licenses)’, or a
>      list of such values.
>
> 1. It's the license of source files (guix build -S) or built binary
>     files?

(If 'built binary files', I would include generated or copied 
documentation in the list. And icons, .desktop files, ..., I'm not 
restricting myself to _executable_ binaries here and also not to 
binaries that aren't sources as well.)

Rarely, there is some weirdness where the source code is free 
(VSCodium?) but the official build has a non-free license (VSCode?). At 
least for that example, it doesn't apply to Guix though (because 
VSCodium is not packaged, and because with some rare exceptions we build 
from source).

However, in my experience, in free software they almost always have the 
same license, so the distinction appears meaningless to me with the 
possible exception of build scripts and test files (including, but not 
limited to, test code).

I think it should include the source files, as the license of the source 
is important for people doing 'guix build --source'.

> 2. When its value is a list of multiple licenses, it's files under
>     different licenses (eg: lib/*.so under LGPL, while bin/* under GPL),
>     or files under one license select from choices?
>
> My guess is that the license field is for source files since we can
> disable binary substitutes, and list is used for files under different
> licenses.
>
> Does my guess is correct?  Thank you!

As answered in a reply to a patch, myself I go for 'files under 
different licenses' -- to me it seems hard to go wrong with 'just 
include all participating licenses' instead of trying to make a selection.

However, keep in mind that sometimes a file is part licensed as, say, 
BSD(*), part as Expat, with modifications under the GPL -- to me it 
appears that for practical purposes you could consider such a thing to 
be 'effectively GPL', but that's not 100% accurate, as it appears 
required to preserve the BSD and Expat license text. (Such things can 
happen when incorporating code from other, differently-licensed, projects).

(*) let's say without the advertising clause or whatever it was (IIRC 
and IIUC the original BSD was incompatible with the GPL?).

If there's some consensus, I think it would be nice to clarify this 
matter in the manual.

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Clarify the license field of the package

[宋文武]

Maxime Devos <maximedevos@telenet.be> writes:

> On 22-08-2022 11:02, 宋文武 wrote:
>
>> Hello list, I have some questions about the 'license' of a package,
>> currently defined as:
>>
>>      The license of the package; a value from ‘(guix licenses)’, or a
>>      list of such values.
>>
>> 1. It's the license of source files (guix build -S) or built binary
>>     files?
>
> (If 'built binary files', I would include generated or copied
> documentation in the list. And icons, .desktop files, ..., I'm not
> restricting myself to _executable_ binaries here and also not to
> binaries that aren't sources as well.)

Sure, it should be clear what license any file has.  Below, I'd refer
them as sources and outputs.
>
> Rarely, there is some weirdness where the source code is free
> (VSCodium?) but the official build has a non-free license
> (VSCode?). At least for that example, it doesn't apply to Guix though
> (because VSCodium is not packaged, and because with some rare
> exceptions we build from source).
>
> However, in my experience, in free software they almost always have
> the same license, so the distinction appears meaningless to me with
> the possible exception of build scripts and test files (including, but
> not limited to, test code).

There are 2 main cases which the licenses of sources and outputs of a
package can be different:

  1. statically linked binaries (eg: golang, rust), leading outputs has
  more licenses than the package's sources (should be all sources), see:
  https://artemis.sh/2022/08/21/this-program-is-illegally-packaged-in-14-distributions.html

  2. not used sources or when licenses not propagated to outputs during
  build (eg: tests, build tools, sources generator), leading outputs has
  less licenses than sources.

I think this distinction will be important when we audit the license
compatibility issues for outputs, since we also distribute outputs via
substitutes.
>
> I think it should include the source files, as the license of the
> source is important for people doing 'guix build --source'.

I agree too.
>
>> 2. When its value is a list of multiple licenses, it's files under
>>     different licenses (eg: lib/*.so under LGPL, while bin/* under GPL),
>>     or files under one license select from choices?
>>
>> My guess is that the license field is for source files since we can
>> disable binary substitutes, and list is used for files under different
>> licenses.
>>
>> Does my guess is correct?  Thank you!
>
> As answered in a reply to a patch, myself I go for 'files under
> different licenses' -- to me it seems hard to go wrong with 'just
> include all participating licenses' instead of trying to make a
> selection.
>
> However, keep in mind that sometimes a file is part licensed as, say,
> BSD(*), part as Expat, with modifications under the GPL -- to me it
> appears that for practical purposes you could consider such a thing to
> be 'effectively GPL', but that's not 100% accurate, as it appears
> required to preserve the BSD and Expat license text. (Such things can
> happen when incorporating code from other, differently-licensed,
> projects).
>
> (*) let's say without the advertising clause or whatever it was (IIRC
> and IIUC the original BSD was incompatible with the GPL?).
>
> If there's some consensus, I think it would be nice to clarify this
> matter in the manual.

Yes, after read
<https://www.gnu.org/licenses/license-compatibility.html> (Combining code),
I think we should list all licenses of sources files in the package's
license field.  

And for license choices, write in comments, since we lacking "OR", our
list of multiple license is same as "AND" in SPDX license expressions.

https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
https://wiki.spdx.org/view/FileNoticeExamples

Later, I think we can introduce a "OR" form for license field or use SPDX license
expressions directly.


In summary, I think our next steps are:

1. Clarify the license field is for sources and the list is for files
under multiple license (required to simultaneously comply with two or
more licenses) in our manual.

2. Consider extend the license field with "OR" form or use SPDX license
expressions.

3. Introduce some ways to show and check licenses for package's outputs.


What do you think?  Thanks for help!

Re: Clarify the license field of the package

[Maxim Cournoyer]

Hi,

Maxime Devos <maximedevos@telenet.be> writes:

[...]

> However, keep in mind that sometimes a file is part licensed as, say,
> BSD(*), part as Expat, with modifications under the GPL -- to me it
> appears that for practical purposes you could consider such a thing to
> be 'effectively GPL', but that's not 100% accurate, as it appears
> required to preserve the BSD and Expat license text. (Such things can
> happen when incorporating code from other, differently-licensed,
> projects).

My personal take on this is that I find little value in listing 50
lesser licenses in the license fields if the effective license of the
whole built project would require to be GPL, say.  In that case I would
find it sufficient to say the program is gpl3+, say, with a comment
mentioning there are other non-copyleft licenses involved but that the
GPL license wins.

In my view that is more useful and tidy.

Thanks,

Maxim