Should I mention Build-scripts' licensing terms in a spec's License field?

[Peter Lemenkov]

Hello!
I stumbled upon the following situation. I am packaging a library
under MIT license. However the upstream-provided build-script in a
tarball explicitly licensed under ISC license (has a header with ISC
license). If it matters I do not use this script for building at all.
So I have two questions.

1. If a tarball has a differently licensed file which is not going to
a final RPM should I still list its license in a spec's %license
field?
2. Does it change anything if this file wasn't used at all during RPM
build process?

[Miroslav Suchý]

Dne 01. 08. 24 v 12:28 odp. Peter Lemenkov napsal(a):
> Hello!
> I stumbled upon the following situation. I am packaging a library
> under MIT license. However the upstream-provided build-script in a
> tarball explicitly licensed under ISC license (has a header with ISC
> license). If it matters I do not use this script for building at all.
> So I have two questions.
> If a tarball has a differently licensed file which is not going to
>
> a final RPM should I still list its license in a spec's %license
> field?
> 2. Does it change anything if this file wasn't used at all during RPM
> build process?

See

https://gitlab.com/fedora/legal/fedora-legal-docs/-/issues/61
> Does not affect the License tag. But the license of the file must be from the allowed list.

[Peter Lemenkov]

Thanks for the answer! I've got it now.

On Thu, Aug 1, 2024 at 12:33 PM Miroslav Suchý  wrote:
> Dne 01. 08. 24 v 12:28 odp. Peter Lemenkov napsal(a):
> > Hello!
> > I stumbled upon the following situation. I am packaging a library
> > under MIT license. However the upstream-provided build-script in a
> > tarball explicitly licensed under ISC license (has a header with ISC
> > license). If it matters I do not use this script for building at all.
> > So I have two questions.
> > If a tarball has a differently licensed file which is not going to
> >
> > a final RPM should I still list its license in a spec's %license
> > field?
> > 2. Does it change anything if this file wasn't used at all during RPM
> > build process?
>
> See
>
> https://gitlab.com/fedora/legal/fedora-legal-docs/-/issues/61
> > Does not affect the License tag. But the license of the file must be from the allowed list.
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
>
> --
> _______________________________________________
> legal mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Neal Gompa]

On Thu, Aug 1, 2024 at 6:33 AM Miroslav Suchý  wrote:
> Dne 01. 08. 24 v 12:28 odp. Peter Lemenkov napsal(a):
> > Hello!
> > I stumbled upon the following situation. I am packaging a library
> > under MIT license. However the upstream-provided build-script in a
> > tarball explicitly licensed under ISC license (has a header with ISC
> > license). If it matters I do not use this script for building at all.
> > So I have two questions.
> > If a tarball has a differently licensed file which is not going to
> >
> > a final RPM should I still list its license in a spec's %license
> > field?
> > 2. Does it change anything if this file wasn't used at all during RPM
> > build process?
>
> See
>
> https://gitlab.com/fedora/legal/fedora-legal-docs/-/issues/61
> > Does not affect the License tag. But the license of the file must be from the allowed list.

That's not the full answer. We do have a way to represent this
information by using the SourceLicense tag. This tag should be used to
define a superset of the License tag information in this case, since
it's used to override License for the SRPM.

However, this tag does not exist before RHEL 9.4 for EPEL purposes.

Note that for packages of static-link ecosystems like Rust and Go,
this is flipped: the License tag is a superset of the SourceLicense
tag, as the License tag represents the mixture of licenses for all the
statically linked packages, whereas SourceLicense just indicates the
license of the sources shipped in the SRPM.

--
真実はいつも一つ！/ Always, there's only one truth!

[Vít Ondruch]

Dne 01. 08. 24 v 12:54 Neal Gompa napsal(a):
> On Thu, Aug 1, 2024 at 6:33 AM Miroslav Suchý  wrote:
> > Dne 01. 08. 24 v 12:28 odp. Peter Lemenkov napsal(a):
> > > Hello!
> > > I stumbled upon the following situation. I am packaging a library
> > > under MIT license. However the upstream-provided build-script in a
> > > tarball explicitly licensed under ISC license (has a header with ISC
> > > license). If it matters I do not use this script for building at all.
> > > So I have two questions.
> > > If a tarball has a differently licensed file which is not going to
> > >
> > > a final RPM should I still list its license in a spec's %license
> > > field?
> > > 2. Does it change anything if this file wasn't used at all during RPM
> > > build process?
> >
> > See
> > https://gitlab.com/fedora/legal/fedora-legal-docs/-/issues/61
> >
> > > Does not affect the License tag. But the license of the file must be from the allowed list.
>
> That's not the full answer. We do have a way to represent this
> information by using the SourceLicense tag.

I don't think this tag is reflected in our guidelines or is it?

Vít
> This tag should be used to
> define a superset of the License tag information in this case, since
> it's used to override License for the SRPM.
>
> However, this tag does not exist before RHEL 9.4 for EPEL purposes.
>
> Note that for packages of static-link ecosystems like Rust and Go,
> this is flipped: the License tag is a superset of the SourceLicense
> tag, as the License tag represents the mixture of licenses for all the
> statically linked packages, whereas SourceLicense just indicates the
> license of the sources shipped in the SRPM.
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!

[Richard Fontana]

On Thu, Aug 1, 2024 at 7:10 AM Vít Ondruch  wrote:
> Dne 01. 08. 24 v 12:54 Neal Gompa napsal(a):
> > On Thu, Aug 1, 2024 at 6:33 AM Miroslav Suchý  wrote:
> > > Dne 01. 08. 24 v 12:28 odp. Peter Lemenkov napsal(a):
> > > > Hello!
> > > > I stumbled upon the following situation. I am packaging a library
> > > > under MIT license. However the upstream-provided build-script in a
> > > > tarball explicitly licensed under ISC license (has a header with ISC
> > > > license). If it matters I do not use this script for building at all.
> > > > So I have two questions.
> > > > If a tarball has a differently licensed file which is not going to
> > > >
> > > > a final RPM should I still list its license in a spec's %license
> > > > field?
> > > > 2. Does it change anything if this file wasn't used at all during RPM
> > > > build process?
> > >
> > > See
> > > https://gitlab.com/fedora/legal/fedora-legal-docs/-/issues/61
> > >
> > > > Does not affect the License tag. But the license of the file must be from the allowed list.
> >
> > That's not the full answer. We do have a way to represent this
> > information by using the SourceLicense tag.
>
> I don't think this tag is reflected in our guidelines or is it?

No, because hardly anyone seems to be using it.

Richard

[Neal Gompa]

On Thu, Aug 1, 2024 at 9:43 AM Richard Fontana  wrote:
> On Thu, Aug 1, 2024 at 7:10 AM Vít Ondruch  wrote:
> > Dne 01. 08. 24 v 12:54 Neal Gompa napsal(a):
> > > On Thu, Aug 1, 2024 at 6:33 AM Miroslav Suchý  wrote:
> > > > Dne 01. 08. 24 v 12:28 odp. Peter Lemenkov napsal(a):
> > > > > Hello!
> > > > > I stumbled upon the following situation. I am packaging a library
> > > > > under MIT license. However the upstream-provided build-script in a
> > > > > tarball explicitly licensed under ISC license (has a header with ISC
> > > > > license). If it matters I do not use this script for building at all.
> > > > > So I have two questions.
> > > > > If a tarball has a differently licensed file which is not going to
> > > > >
> > > > > a final RPM should I still list its license in a spec's %license
> > > > > field?
> > > > > 2. Does it change anything if this file wasn't used at all during RPM
> > > > > build process?
> > > >
> > > > See
> > > > https://gitlab.com/fedora/legal/fedora-legal-docs/-/issues/61
> > > >
> > > > > Does not affect the License tag. But the license of the file must be from the allowed list.
> > >
> > > That's not the full answer. We do have a way to represent this
> > > information by using the SourceLicense tag.
> >
> > I don't think this tag is reflected in our guidelines or is it?
>
> No, because hardly anyone seems to be using it.

Yes, because it's relatively new and it's not that important most of
the time. It was added in RPM 4.18.

[Vít Ondruch]

Dne 01. 08. 24 v 15:47 Neal Gompa napsal(a):
> On Thu, Aug 1, 2024 at 9:43 AM Richard Fontana  wrote:
> > On Thu, Aug 1, 2024 at 7:10 AM Vít Ondruch  wrote:
> > > Dne 01. 08. 24 v 12:54 Neal Gompa napsal(a):
> > > > On Thu, Aug 1, 2024 at 6:33 AM Miroslav Suchý  wrote:
> > > > > Dne 01. 08. 24 v 12:28 odp. Peter Lemenkov napsal(a):
> > > > > > Hello!
> > > > > > I stumbled upon the following situation. I am packaging a library
> > > > > > under MIT license. However the upstream-provided build-script in a
> > > > > > tarball explicitly licensed under ISC license (has a header with ISC
> > > > > > license). If it matters I do not use this script for building at all.
> > > > > > So I have two questions.
> > > > > > If a tarball has a differently licensed file which is not going to
> > > > > >
> > > > > > a final RPM should I still list its license in a spec's %license
> > > > > > field?
> > > > > > 2. Does it change anything if this file wasn't used at all during RPM
> > > > > > build process?
> > > > >
> > > > > See
> > > > >  https://gitlab.com/fedora/legal/fedora-legal-docs/-/issues/61
> > > > >
> > > > > > Does not affect the License tag. But the license of the file must be from the allowed list.
> > > >
> > > > That's not the full answer. We do have a way to represent this
> > > > information by using the SourceLicense tag.
> > >
> > > I don't think this tag is reflected in our guidelines or is it?
> >
> > No, because hardly anyone seems to be using it.
>
> Yes, because it's relatively new and it's not that important most of
> the time. It was added in RPM 4.18.

Well, unless it is in guidelines, I don't think it will be used.

Vít

[Fabio Valentini]

On Fri, Aug 2, 2024 at 2:01 PM Vít Ondruch  wrote:
> Dne 01. 08. 24 v 15:47 Neal Gompa napsal(a):
> > Yes, because it's relatively new and it's not that important most of
> > the time. It was added in RPM 4.18.
>
> Well, unless it is in guidelines, I don't think it will be used.

Rust packages generated with rust2rpm use it when it makes sense to
differentiate License of the built packages vs. license of the project
sources.
This is the case for packages where <source package name> == <built
package name>, so usually for large Rust projects packaged from $FORGE
tarballs instead of from sources hosted on crates.io.
For projects packaged from crates.io, the source package name
(rust-<crate>) and built package name (usually <crate>) are already
always different, so using SourceLicense is not necessary to
differentiate license of the package sources and license of the
contents of the built package.

And support for SourceLicense is even getting backported to RHEL 9 -
one less reason *not* to use this :)
https://issues.redhat.com/browse/RHEL-28798

Fabio

[Miroslav Suchý]

Dne 02. 08. 24 v 6:59 odp. Fabio Valentini napsal(a):
> Rust packages generated with rust2rpm use it when it makes sense to
> differentiate License of the built packages vs. license of the project
> sources.

Is it?

SourceLicense tag is used only in 35 packages in whole Fedora. And only in 2 rust packages: rust2rpm-helper and rustup.

I will love to see more usage of this tag, but I believe the documentatin has to be updated first. PR for packaging 
guidelines and legal doc is welcome.

[Fabio Valentini]

On Fri, Aug 2, 2024 at 9:07 PM Miroslav Suchý  wrote:
> Dne 02. 08. 24 v 6:59 odp. Fabio Valentini napsal(a):
>
> Rust packages generated with rust2rpm use it when it makes sense to
> differentiate License of the built packages vs. license of the project
> sources.
>
> Is it?
>
> SourceLicense tag is used only in 35 packages in whole Fedora. And only in 2 rust packages: rust2rpm-helper and rustup.
>
> I will love to see more usage of this tag, but I believe the documentatin has to be updated first. PR for packaging guidelines and legal doc is welcome.

It looks like your query was too limited (rust* ?), there's more:

- bpftop
- corrosion
- clevis-pin-tpm2
- cosmic-comp
- fapolicy-analyzer
- firecracker
- helvum
- keyring-ima-signer
- librsvg2
- maturin
- ntpd-rs
- parsec
- ruff
- rustup
- rust2rpm-helper
- sad
- snapshot
- stgit
- sudo-rs
- trunk
- udev-hid-bpf

So at this point I'd say ~50% of usage of SourceLicense is in Rust packages.

Fabio

[Miroslav Suchý]

Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> I will love to see more usage of this tag, but I believe the documentatin has to be updated first. PR for packaging 
> guidelines and legal doc is welcome.

Here it comes https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306

[Peter Lemenkov]

Awesome, thank you!

пт, 2 авг. 2024 г., 21:38 Miroslav Suchý :
> Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> > I will love to see more usage of this tag, but I believe the
>
> documentatin has to be updated first. PR for packaging
> > guidelines and legal doc is welcome.
>
> Here it comes
> https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
>
> --
> _______________________________________________
> legal mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Vít Ondruch]

Dne 02. 08. 24 v 21:37 Miroslav Suchý napsal(a):
> Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> > I will love to see more usage of this tag, but I believe the 
> > documentatin has to be updated first. PR for packaging guidelines and 
> > legal doc is welcome.
>
> Here it comes 
> https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306

Thank you for the PR, because this is hard one. I think that in ideal 
world, the PR should be worded in a way that:

1) The `SourceLicense` tag is always used and it fully describes the 
content of the SRPM, i.e. it should contain all licenses which would be 
identified by some (ideal) scanner

2) The `License` tag would be used in cases when the resulting (sub) 
package has different license from the `SourceLicense` (e.g. build 
scripts are not part of the resulting binary obviously).

The question is if we can get from the current state to the state I 
proposed above.

Vít

[Daniel P. Berrangé]

On Mon, Aug 05, 2024 at 11:23:08AM +0200, Vít Ondruch wrote:
> Dne 02. 08. 24 v 21:37 Miroslav Suchý napsal(a):
> > Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> > > I will love to see more usage of this tag, but I believe the
> > > documentatin has to be updated first. PR for packaging guidelines
> > > and legal doc is welcome.
> >
> > Here it comes
> > https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306
>
> Thank you for the PR, because this is hard one. I think that in ideal world,
> the PR should be worded in a way that:
> The `SourceLicense` tag is always used and it fully describes the content
>
> of the SRPM, i.e. it should contain all licenses which would be identified
> by some (ideal) scanner
> The `License` tag would be used in cases when the resulting (sub) package
>
> has different license from the `SourceLicense` (e.g. build scripts are not
> part of the resulting binary obviously).
>
> The question is if we can get from the current state to the state I proposed
> above.

Implementing this requires a (re-)review of everything in the source tarball,
which is an exercise we just went through for SDPX in many cases. The idea of
doing this again in order to add SourceLicense is not going to fly in terms
of the time investment asked of maintainers.

With regards,
Daniel

[Richard Fontana]

On Mon, Aug 5, 2024 at 5:40 AM Daniel P. Berrangé  wrote:
> On Mon, Aug 05, 2024 at 11:23:08AM +0200, Vít Ondruch wrote:
> > Dne 02. 08. 24 v 21:37 Miroslav Suchý napsal(a):
> > > Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> > > > I will love to see more usage of this tag, but I believe the
> > > > documentatin has to be updated first. PR for packaging guidelines
> > > > and legal doc is welcome.
> > >
> > > Here it comes
> > > https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306
> >
> > Thank you for the PR, because this is hard one. I think that in ideal world,
> > the PR should be worded in a way that:
> > The `SourceLicense` tag is always used and it fully describes the content
> >
> > of the SRPM, i.e. it should contain all licenses which would be identified
> > by some (ideal) scanner
> > The `License` tag would be used in cases when the resulting (sub) package
> >
> > has different license from the `SourceLicense` (e.g. build scripts are not
> > part of the resulting binary obviously).
> >
> > The question is if we can get from the current state to the state I proposed
> > above.
>
> Implementing this requires a (re-)review of everything in the source tarball,
> which is an exercise we just went through for SDPX in many cases. The idea of
> doing this again in order to add SourceLicense is not going to fly in terms
> of the time investment asked of maintainers.

I don't really see the justification. Apart from maybe the
complications of Rust and Go packages that were mentioned (which I
think raise some deeper issues that haven't really been addressed
satisfactorily yet), I see no point in having *both* `License:` and
`SourceLicense:`. If a full license breakdown of what's in the SRPM is
desired then that should be the standard of what goes in `License:`,
instead of the traditional Fedora approach of having `License:` be a
subset (or, as it was formerly described, "the license of the binary
RPM").

If the idea is to record what some particular scanner produced, that
may be something like SPDX's ill-defined "Declared License" concept.
But even the best scanners produce a lot of junk information and you
still have to undertake analysis to exclude things that are spurious
licenses, misidentified licenses, things that purport to be licenses
for which licenses aren't needed, etc.

I feel like the strongest argument for saying something about
`SourceLicense:` is that the RPM project adopted this tag so it
shouldn't be ignored. Which doesn't feel like a strong argument.

Richard

[Vít Ondruch]

Dne 05. 08. 24 v 15:24 Richard Fontana napsal(a):
> On Mon, Aug 5, 2024 at 5:40 AM Daniel P. Berrangé  wrote:
> > On Mon, Aug 05, 2024 at 11:23:08AM +0200, Vít Ondruch wrote:
> > > Dne 02. 08. 24 v 21:37 Miroslav Suchý napsal(a):
> > > > Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> > > > > I will love to see more usage of this tag, but I believe the
> > > > > documentatin has to be updated first. PR for packaging guidelines
> > > > > and legal doc is welcome.
> > > >
> > > > Here it comes
> > > > https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306
> > >
> > > Thank you for the PR, because this is hard one. I think that in ideal world,
> > > the PR should be worded in a way that:
> > > The `SourceLicense` tag is always used and it fully describes the content
> > >
> > > of the SRPM, i.e. it should contain all licenses which would be identified
> > > by some (ideal) scanner
> > > The `License` tag would be used in cases when the resulting (sub) package
> > >
> > > has different license from the `SourceLicense` (e.g. build scripts are not
> > > part of the resulting binary obviously).
> > >
> > > The question is if we can get from the current state to the state I proposed
> > > above.
> >
> > Implementing this requires a (re-)review of everything in the source tarball,
> > which is an exercise we just went through for SDPX in many cases. The idea of
> > doing this again in order to add SourceLicense is not going to fly in terms
> > of the time investment asked of maintainers.
>
> I don't really see the justification. Apart from maybe the
> complications of Rust and Go packages that were mentioned (which I
> think raise some deeper issues that haven't really been addressed
> satisfactorily yet), I see no point in having *both* `License:` and
> `SourceLicense:`. If a full license breakdown of what's in the SRPM is
> desired then that should be the standard of what goes in `License:`,
> instead of the traditional Fedora approach of having `License:` be a
> subset (or, as it was formerly described, "the license of the binary
> RPM").
>
> If the idea is to record what some particular scanner produced, that
> may be something like SPDX's ill-defined "Declared License" concept.
> But even the best scanners produce a lot of junk information and you
> still have to undertake analysis to exclude things that are spurious
> licenses, misidentified licenses, things that purport to be licenses
> for which licenses aren't needed, etc.
>
> I feel like the strongest argument for saying something about
> `SourceLicense:` is that the RPM project adopted this tag so it
> shouldn't be ignored. Which doesn't feel like a strong argument.

My main point is that SRPM is the thing we redistribute. Therefore we 
should care about License of it. It seems strange that we would care 
that much about binary RPMs and not care about SRPM at all.

Vít

[Vít Ondruch]

Dne 05. 08. 24 v 16:38 Vít Ondruch napsal(a):
> Dne 05. 08. 24 v 15:24 Richard Fontana napsal(a):
> > On Mon, Aug 5, 2024 at 5:40 AM Daniel P. Berrangé 
> >  wrote:
> > > On Mon, Aug 05, 2024 at 11:23:08AM +0200, Vít Ondruch wrote:
> > > > Dne 02. 08. 24 v 21:37 Miroslav Suchý napsal(a):
> > > > > Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> > > > > > I will love to see more usage of this tag, but I believe the
> > > > > > documentatin has to be updated first. PR for packaging guidelines
> > > > > > and legal doc is welcome.
> > > > >
> > > > > Here it comes
> > > > > https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306
> > > >
> > > > Thank you for the PR, because this is hard one. I think that in 
> > > > ideal world,
> > > > the PR should be worded in a way that:
> > > > The `SourceLicense` tag is always used and it fully describes
> > > >
> > > > the content
> > > > of the SRPM, i.e. it should contain all licenses which would be 
> > > > identified
> > > > by some (ideal) scanner
> > > > The `License` tag would be used in cases when the resulting
> > > >
> > > > (sub) package
> > > > has different license from the `SourceLicense` (e.g. build scripts 
> > > > are not
> > > > part of the resulting binary obviously).
> > > >
> > > > The question is if we can get from the current state to the state I 
> > > > proposed
> > > > above.
> > >
> > > Implementing this requires a (re-)review of everything in the source 
> > > tarball,
> > > which is an exercise we just went through for SDPX in many cases. 
> > > The idea of
> > > doing this again in order to add SourceLicense is not going to fly 
> > > in terms
> > > of the time investment asked of maintainers.
> >
> > I don't really see the justification. Apart from maybe the
> > complications of Rust and Go packages that were mentioned (which I
> > think raise some deeper issues that haven't really been addressed
> > satisfactorily yet), I see no point in having *both* `License:` and
> > `SourceLicense:`. If a full license breakdown of what's in the SRPM is
> > desired then that should be the standard of what goes in `License:`,
> > instead of the traditional Fedora approach of having `License:` be a
> > subset (or, as it was formerly described, "the license of the binary
> > RPM").
> >
> > If the idea is to record what some particular scanner produced, that
> > may be something like SPDX's ill-defined "Declared License" concept.
> > But even the best scanners produce a lot of junk information and you
> > still have to undertake analysis to exclude things that are spurious
> > licenses, misidentified licenses, things that purport to be licenses
> > for which licenses aren't needed, etc.
> >
> > I feel like the strongest argument for saying something about
> > `SourceLicense:` is that the RPM project adopted this tag so it
> > shouldn't be ignored. Which doesn't feel like a strong argument.
>
> My main point is that SRPM is the thing we redistribute. Therefore we 
> should care about License of it. It seems strange that we would care 
> that much about binary RPMs and not care about SRPM at all.

And the second point is that we won't ever be able to 100% cover RPMs by 
license scanners, but we could achieve that for SRPMs.

Vít
> Vít

[Richard Fontana]

On Mon, Aug 5, 2024 at 10:53 AM Vít Ondruch  wrote:
> And the second point is that we won't ever be able to 100% cover RPMs by
> license scanners, but we could achieve that for SRPMs.

I don't agree. I think the "less than 100%" would similarly apply to
SRPMs. They're really the same inquiry with the same challenges
(misidentified licenses, false positives, phony licenses ...). The
only difference is that some of the enumerated licenses in a
hypothetical `SourceLicense:` would be removed from `License:`. So
`SourceLicense:` is maybe recording a step in the computation of
`License:` that might otherwise not be recorded.

Richard

[Vít Ondruch]

Dne 05. 08. 24 v 17:19 Richard Fontana napsal(a):
> On Mon, Aug 5, 2024 at 10:53 AM Vít Ondruch  wrote:
> > And the second point is that we won't ever be able to 100% cover RPMs by
> > license scanners, but we could achieve that for SRPMs.
>
> I don't agree. I think the "less than 100%" would similarly apply to
> SRPMs. They're really the same inquiry with the same challenges
> (misidentified licenses, false positives, phony licenses ...).

I have deliberately ignored all the possible challenges. Ideally, we 
should be able to automatically detect 100% licenses in source code.
> The
> only difference is that some of the enumerated licenses in a
> hypothetical `SourceLicense:` would be removed from `License:`. So
> `SourceLicense:` is maybe recording a step in the computation of
> `License:` that might otherwise not be recorded.

I don't disagree, but if you see challenges in detecting source 
licenses, then determining binary license is even harder.

Vít

[Richard Fontana]

On Mon, Aug 5, 2024 at 10:39 AM Vít Ondruch  wrote:
> Dne 05. 08. 24 v 15:24 Richard Fontana napsal(a):
> > On Mon, Aug 5, 2024 at 5:40 AM Daniel P. Berrangé  wrote:
> > > On Mon, Aug 05, 2024 at 11:23:08AM +0200, Vít Ondruch wrote:
> > > > Dne 02. 08. 24 v 21:37 Miroslav Suchý napsal(a):
> > > > > Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> > > > > > I will love to see more usage of this tag, but I believe the
> > > > > > documentatin has to be updated first. PR for packaging guidelines
> > > > > > and legal doc is welcome.
> > > > >
> > > > > Here it comes
> > > > > https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306
> > > >
> > > > Thank you for the PR, because this is hard one. I think that in ideal world,
> > > > the PR should be worded in a way that:
> > > > The `SourceLicense` tag is always used and it fully describes the content
> > > >
> > > > of the SRPM, i.e. it should contain all licenses which would be identified
> > > > by some (ideal) scanner
> > > > The `License` tag would be used in cases when the resulting (sub) package
> > > >
> > > > has different license from the `SourceLicense` (e.g. build scripts are not
> > > > part of the resulting binary obviously).
> > > >
> > > > The question is if we can get from the current state to the state I proposed
> > > > above.
> > >
> > > Implementing this requires a (re-)review of everything in the source tarball,
> > > which is an exercise we just went through for SDPX in many cases. The idea of
> > > doing this again in order to add SourceLicense is not going to fly in terms
> > > of the time investment asked of maintainers.
> >
> > I don't really see the justification. Apart from maybe the
> > complications of Rust and Go packages that were mentioned (which I
> > think raise some deeper issues that haven't really been addressed
> > satisfactorily yet), I see no point in having *both* `License:` and
> > `SourceLicense:`. If a full license breakdown of what's in the SRPM is
> > desired then that should be the standard of what goes in `License:`,
> > instead of the traditional Fedora approach of having `License:` be a
> > subset (or, as it was formerly described, "the license of the binary
> > RPM").
> >
> > If the idea is to record what some particular scanner produced, that
> > may be something like SPDX's ill-defined "Declared License" concept.
> > But even the best scanners produce a lot of junk information and you
> > still have to undertake analysis to exclude things that are spurious
> > licenses, misidentified licenses, things that purport to be licenses
> > for which licenses aren't needed, etc.
> >
> > I feel like the strongest argument for saying something about
> > `SourceLicense:` is that the RPM project adopted this tag so it
> > shouldn't be ignored. Which doesn't feel like a strong argument.
>
> My main point is that SRPM is the thing we redistribute. Therefore we
> should care about License of it. It seems strange that we would care
> that much about binary RPMs and not care about SRPM at all.

We do care about the licensing of SRPMs - Fedora legal docs say:

"Fedora’s license approval standards apply to everything that is made
available by the Fedora Project, not just installable binary packages
in Fedora Linux. For example, everything available at Fedora Pagure,
Fedora Source Packages, Fedora Koji, Fedora documentation and Copr
repositories is subject to the same licensing rules as Fedora Linux
packages."

"If a license that covers something in Fedora, or in a package that
has been or is intended to be proposed for inclusion in Fedora Linux,
is not listed on the allowed and not-allowed lists, then it must be
reviewed."

"The Fedora convention is that License: tags describe a relevant
subset of the licenses that apply to the source code of the package.
Any license that applies to anything in the source code must be
Fedora-acceptable (assuming you actually need a license for that
material), even if it is ultimately not included in the License: tag."

The issue is just what gets reflected in license metadata. We could
dispense with `License:` altogether and it wouldn't mean we don't care
about licenses. (For example, I believe Debian and its derivatives
don't have any real concept of package license metadata.)

Now yes it *is* strange that `License:` does not consist of what you
want `SourceLicense:` to be used for. But that is explained by Fedora
tradition going back nearly two decades at this point. So again I
think the issue here is that if people think that we need package
license metadata to reflect the full contents of SRPMs then we should
change the standard for `License:` rather than normalize the
additional use of `SourceLicense:`.

I do worry about the current approach because I have seen from
various cases it seems to lead some to believe that "source licenses
don't matter" or "source licenses don't matter to Fedora". I have
tried to make it very clear in the Fedora legal docs that they do
matter. I guess you could argue that mandating `SourceLicense:` would
make this even clearer, but I think at that point `License:` and
`SourceLicense:` should be the same.

As an aside I think it is odd that the RPM project adopted
`SourceLicense:` given that non-Fedora(based) RPM-package-based
distributions might very well decide that `License:` should contain a
complete enumeration of source code licenses. For example I have no
idea what the standard for license tags is in the openSUSE world other
than that it must be quite different from Fedora's traditions.

Richard

[Björn Persson]

Richard Fontana wrote:
> I don't really see the justification. Apart from maybe the
> complications of Rust and Go packages that were mentioned (which I
> think raise some deeper issues that haven't really been addressed
> satisfactorily yet), I see no point in having *both* `License:` and
> `SourceLicense:`. If a full license breakdown of what's in the SRPM is
> desired then that should be the standard of what goes in `License:`,
> instead of the traditional Fedora approach of having `License:` be a
> subset (or, as it was formerly described, "the license of the binary
> RPM").

I'll note this just so it's not forgotten in this debate: There isn't
just one License tag. Subpackages can have their own License tags.
Different SourceLicense tags on different subpackages would not make
sense. If License would be redefined to contain the license of the
source package, then License tags on subpackages would have to be
banned at the same time.

Björn Persson