11:31 a.m.
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file
(as described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
) states, "The License: field refers to the licenses of the contents of
the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing,
it would be helpful to hear people's thoughts on the following:
1) how do you (package maintainers) interpret this policy in practice?
2) what further information/documentation about this policy would be
helpful?
3) should this policy be different, and if so, how?
4) any other related thoughts or observations
Thanks!
Jilayne
11:44 a.m.
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... ) states,
"The License: field refers to the licenses of the contents of the binary rpm. When in
doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be
helpful to hear people's thoughts on the following:
1) how do you (package maintainers) interpret this policy in practice?
2) what further information/documentation about this policy would be helpful?
3) should this policy be different, and if so, how?
4) any other related thoughts or observations
I generally interpret it to mean the effective license that covers the
resulting artifacts shipped in the binary RPM. I think this is fine,
but we definitely have a gap in RPM packaging in that we can't declare
the license of the Source RPM anywhere. This is particularly kludgy
when you have vendored or bundled code.
To be honest, I don't particularly relish redoing the licensing of
some things with SPDX identifiers because it's going to triple the
length of the license string there. Too much specificity can hurt...
I don't have specific solutions here, but I would like to avoid having
the list licenses for literally everything in a source tree when it
doesn't matter for binary RPMs.
--
真実はいつも一つ！/ Always, there's only one truth!
12:03 p.m.
On 5/23/22 10:44 AM, Neal Gompa wrote:
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy
<jlovejoy(a)redhat.com> wrote:
> Hi Fedora legal and packaging,
>
> I'm cross-posting this, as I think it's relevant to both groups.
>
> The current policy for filling out the license field of the spec file (as described
at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... )
states, "The License: field refers to the licenses of the contents of the binary rpm.
When in doubt, ask."
>
> As we consider how to improve documentation related to Fedora licensing, it would be
helpful to hear people's thoughts on the following:
>
> 1) how do you (package maintainers) interpret this policy in practice?
>
> 2) what further information/documentation about this policy would be helpful?
>
> 3) should this policy be different, and if so, how?
>
> 4) any other related thoughts or observations
>
I generally interpret it to mean the effective license that covers the
resulting artifacts shipped in the binary RPM. I think this is fine,
but we definitely have a gap in RPM packaging in that we can't declare
the license of the Source RPM anywhere.
Are you saying we should have a way to
declare both 1) the license that
covers the resulting artifacts shipped in the binary RPM
and 2) the license of the source (that creates said binary)?
This is particularly kludgy
when you have vendored or bundled code.
I don't have specific solutions here, but I would like to avoid having
the list licenses for literally everything in a source tree when it
doesn't matter for binary RPMs.
isn't having to list license for everything
in the source the same as 2??
Jilayne
--
真実はいつも一つ！/ Always, there's only one truth!
12:56 p.m.
On Mon, May 23, 2022 at 1:03 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
On 5/23/22 10:44 AM, Neal Gompa wrote:
> On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
>> Hi Fedora legal and packaging,
>>
>> I'm cross-posting this, as I think it's relevant to both groups.
>>
>> The current policy for filling out the license field of the spec file (as
described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... ) states,
"The License: field refers to the licenses of the contents of the binary rpm. When in
doubt, ask."
>>
>> As we consider how to improve documentation related to Fedora licensing, it
would be helpful to hear people's thoughts on the following:
>>
>> 1) how do you (package maintainers) interpret this policy in practice?
>>
>> 2) what further information/documentation about this policy would be helpful?
>>
>> 3) should this policy be different, and if so, how?
>>
>> 4) any other related thoughts or observations
>>
> I generally interpret it to mean the effective license that covers the
> resulting artifacts shipped in the binary RPM. I think this is fine,
> but we definitely have a gap in RPM packaging in that we can't declare
> the license of the Source RPM anywhere.
Are you saying we should have a way to declare both 1) the license that
covers the resulting artifacts shipped in the binary RPM
and 2) the license of the source (that creates said binary)?
> This is particularly kludgy
> when you have vendored or bundled code.
>
>
> I don't have specific solutions here, but I would like to avoid having
> the list licenses for literally everything in a source tree when it
> doesn't matter for binary RPMs.
isn't having to list license for everything in the source the same as 2??
We are required to document source licensing for bundled stuff, which
contravenes the "effective binary licensing" policy we have in
general. If we didn't have that, we could avoid this whole problem.
--
真実はいつも一つ！/ Always, there's only one truth!
2:30 p.m.
On Mon, May 23, 2022 at 2:03 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, May 23, 2022 at 1:03 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
>
>
>
> On 5/23/22 10:44 AM, Neal Gompa wrote:
> > On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy <jlovejoy(a)redhat.com>
wrote:
> >> Hi Fedora legal and packaging,
> >>
> >> I'm cross-posting this, as I think it's relevant to both groups.
> >>
> >> The current policy for filling out the license field of the spec file (as
described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... ) states,
"The License: field refers to the licenses of the contents of the binary rpm. When in
doubt, ask."
> >>
> >> As we consider how to improve documentation related to Fedora licensing, it
would be helpful to hear people's thoughts on the following:
> >>
> >> 1) how do you (package maintainers) interpret this policy in practice?
> >>
> >> 2) what further information/documentation about this policy would be
helpful?
> >>
> >> 3) should this policy be different, and if so, how?
> >>
> >> 4) any other related thoughts or observations
> >>
> > I generally interpret it to mean the effective license that covers the
> > resulting artifacts shipped in the binary RPM. I think this is fine,
> > but we definitely have a gap in RPM packaging in that we can't declare
> > the license of the Source RPM anywhere.
> Are you saying we should have a way to declare both 1) the license that
> covers the resulting artifacts shipped in the binary RPM
> and 2) the license of the source (that creates said binary)?
> > This is particularly kludgy
> > when you have vendored or bundled code.
> >
> >
> > I don't have specific solutions here, but I would like to avoid having
> > the list licenses for literally everything in a source tree when it
> > doesn't matter for binary RPMs.
> isn't having to list license for everything in the source the same as 2??
>
We are required to document source licensing for bundled stuff, which
contravenes the "effective binary licensing" policy we have in
general. If we didn't have that, we could avoid this whole problem.
Do you mean bundled stuff that is distributed with the binary RPM
(whether in the same form or somehow transformed), or bundled stuff
that happens to be in the source tarball or whatever but is ignored in
building the binary RPM?
If it's the latter then that does seem to contradict the "license of
the binary" policy.
Richard
2:53 p.m.
On 5/23/22 1:30 PM, Richard Fontana wrote:
On Mon, May 23, 2022 at 2:03 PM Neal Gompa <ngompa13(a)gmail.com>
wrote:
> On Mon, May 23, 2022 at 1:03 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
>>
>>
>> On 5/23/22 10:44 AM, Neal Gompa wrote:
>>> On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy <jlovejoy(a)redhat.com>
wrote:
>>>> Hi Fedora legal and packaging,
>>>>
>>>> I'm cross-posting this, as I think it's relevant to both groups.
>>>>
>>>> The current policy for filling out the license field of the spec file (as
described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... ) states,
"The License: field refers to the licenses of the contents of the binary rpm. When in
doubt, ask."
>>>>
>>>> As we consider how to improve documentation related to Fedora licensing,
it would be helpful to hear people's thoughts on the following:
>>>>
>>>> 1) how do you (package maintainers) interpret this policy in practice?
>>>>
>>>> 2) what further information/documentation about this policy would be
helpful?
>>>>
>>>> 3) should this policy be different, and if so, how?
>>>>
>>>> 4) any other related thoughts or observations
>>>>
>>> I generally interpret it to mean the effective license that covers the
>>> resulting artifacts shipped in the binary RPM. I think this is fine,
>>> but we definitely have a gap in RPM packaging in that we can't declare
>>> the license of the Source RPM anywhere.
>> Are you saying we should have a way to declare both 1) the license that
>> covers the resulting artifacts shipped in the binary RPM
>> and 2) the license of the source (that creates said binary)?
>>> This is particularly kludgy
>>> when you have vendored or bundled code.
>>>
>>>
>>> I don't have specific solutions here, but I would like to avoid having
>>> the list licenses for literally everything in a source tree when it
>>> doesn't matter for binary RPMs.
>> isn't having to list license for everything in the source the same as 2??
>>
> We are required to document source licensing for bundled stuff, which
> contravenes the "effective binary licensing" policy we have in
> general. If we didn't have that, we could avoid this whole problem.
Do you mean bundled stuff that is distributed with the binary RPM
(whether in the same form or somehow transformed), or bundled stuff
that happens to be in the source tarball or whatever but is ignored in
building the binary RPM?
If it's the latter then that does seem to contradict the "license of
the binary" policy.
Richard
I'm also wondering where the "required to document source licensing for
bundled stuff" is documented? Can you point to that?
J.
2:57 p.m.
On Mon, May 23, 2022 at 3:53 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
On 5/23/22 1:30 PM, Richard Fontana wrote:
> On Mon, May 23, 2022 at 2:03 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>> On Mon, May 23, 2022 at 1:03 PM Jilayne Lovejoy <jlovejoy(a)redhat.com>
wrote:
>>>
>>>
>>> On 5/23/22 10:44 AM, Neal Gompa wrote:
>>>> On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy
<jlovejoy(a)redhat.com> wrote:
>>>>> Hi Fedora legal and packaging,
>>>>>
>>>>> I'm cross-posting this, as I think it's relevant to both
groups.
>>>>>
>>>>> The current policy for filling out the license field of the spec
file (as described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... ) states,
"The License: field refers to the licenses of the contents of the binary rpm. When in
doubt, ask."
>>>>>
>>>>> As we consider how to improve documentation related to Fedora
licensing, it would be helpful to hear people's thoughts on the following:
>>>>>
>>>>> 1) how do you (package maintainers) interpret this policy in
practice?
>>>>>
>>>>> 2) what further information/documentation about this policy would be
helpful?
>>>>>
>>>>> 3) should this policy be different, and if so, how?
>>>>>
>>>>> 4) any other related thoughts or observations
>>>>>
>>>> I generally interpret it to mean the effective license that covers the
>>>> resulting artifacts shipped in the binary RPM. I think this is fine,
>>>> but we definitely have a gap in RPM packaging in that we can't
declare
>>>> the license of the Source RPM anywhere.
>>> Are you saying we should have a way to declare both 1) the license that
>>> covers the resulting artifacts shipped in the binary RPM
>>> and 2) the license of the source (that creates said binary)?
>>>> This is particularly kludgy
>>>> when you have vendored or bundled code.
>>>>
>>>>
>>>> I don't have specific solutions here, but I would like to avoid
having
>>>> the list licenses for literally everything in a source tree when it
>>>> doesn't matter for binary RPMs.
>>> isn't having to list license for everything in the source the same as
2??
>>>
>> We are required to document source licensing for bundled stuff, which
>> contravenes the "effective binary licensing" policy we have in
>> general. If we didn't have that, we could avoid this whole problem.
> Do you mean bundled stuff that is distributed with the binary RPM
> (whether in the same form or somehow transformed), or bundled stuff
> that happens to be in the source tarball or whatever but is ignored in
> building the binary RPM?
>
> If it's the latter then that does seem to contradict the "license of
> the binary" policy.
>
> Richard
>
I'm also wondering where the "required to document source licensing for
bundled stuff" is documented? Can you point to that?
It was something we were told to do years ago for Rust/Go stuff. I'm
not sure I can find a specific reference for it. I have mentioned it
before though[1].
[1]:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
--
真実はいつも一つ！/ Always, there's only one truth!
3:29 p.m.
On Mon, May 23, 2022 at 3:58 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> I'm also wondering where the "required to document source licensing for
> bundled stuff" is documented? Can you point to that?
>
It was something we were told to do years ago for Rust/Go stuff. I'm
not sure I can find a specific reference for it. I have mentioned it
before though[1].
[1]:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
Leaving aside the specifics of the bundling/Rust cases, one of the
questions here is whether we want to have License: fields that state
something relatively complex like
License: ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and ISC
and MIT and ((MIT or ASL 2.0) and BSD) and (Unlicense or MIT)
or its equivalent in SPDX which if anything might seem slightly more
complex depending on the details.
The assumption I've been making is that we basically can't avoid
having complex license expressions in the general case, and that is
(for me) a major justification for switching from Callaway to SPDX,
since SPDX is a somewhat richer and more coherent expression language
for complex licensing details.
But if people think we should find ways of making license expressions
simpler, that doesn't mean not using SPDX or something that seems
syntactically/symbolically identical to SPDX for the representation of
the resulting simplified expressions.
I think this also goes to how "licenses of the contents of the binary
RPM" is ambiguous. It might mean, for example:
* Every identifiable license in a source file that is included (in
compiled form or otherwise) in the binary RPM -- I think we see some
packages that attempt this
* A simplified representation of those licenses based on application
of common / seemingly noncontroversial FOSS (often
GPL-community-specific) folkloric legal conventions. Two examples:
1) an executable program built from GPLv2+ and MIT licensed source
files gets represented simply as "GPLv2+" (GPL-2.0-or-later in SPDX)
2) an executable program built from GPLv2+ source files but which
dynamically links against a GPLv3+ separately-packaged library (also
distributed in Fedora) gets represented as "GPLv3+"
I think there are many examples of 1) and I know of one example of 2),
but I think neither of those kinds of cases are handled consistently
across Fedora packages today (not saying that we need absolute
consistency)
Are simpler or more complex license expressions preferable, even if
simpler expressions mean some loss of useful information or accuracy?
That's one issue that is connected to Jilayne's question.
Richard
* something else?
4:16 p.m.
On Mon, May 23, 2022 at 4:29 PM Richard Fontana <rfontana(a)redhat.com> wrote:
On Mon, May 23, 2022 at 3:58 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
>
> > I'm also wondering where the "required to document source licensing
for
> > bundled stuff" is documented? Can you point to that?
> >
>
> It was something we were told to do years ago for Rust/Go stuff. I'm
> not sure I can find a specific reference for it. I have mentioned it
> before though[1].
>
> [1]:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
Leaving aside the specifics of the bundling/Rust cases, one of the
questions here is whether we want to have License: fields that state
something relatively complex like
License: ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and ISC
and MIT and ((MIT or ASL 2.0) and BSD) and (Unlicense or MIT)
or its equivalent in SPDX which if anything might seem slightly more
complex depending on the details.
The assumption I've been making is that we basically can't avoid
having complex license expressions in the general case, and that is
(for me) a major justification for switching from Callaway to SPDX,
since SPDX is a somewhat richer and more coherent expression language
for complex licensing details.
That might be the case in the container circus, but in the RPM world,
we mostly get to avoid complex licensing details.
The weirdest license expression is the one for perl-Exporter-Tidy[1],
which requires us to evaluate the entire list of acceptable licenses
and export them to the License tag since the license terms state as
such[2]. Outside of that, only crazy packages like Chromium wind up
having complex licensing. The rest are reasonably simple.
[1]: https://src.fedoraproject.org/rpms/perl-Exporter-Tidy
[2]: https://metacpan.org/pod/Exporter::Tidy#LICENSE
But if people think we should find ways of making license
expressions
simpler, that doesn't mean not using SPDX or something that seems
syntactically/symbolically identical to SPDX for the representation of
the resulting simplified expressions.
I think this also goes to how "licenses of the contents of the binary
RPM" is ambiguous. It might mean, for example:
* Every identifiable license in a source file that is included (in
compiled form or otherwise) in the binary RPM -- I think we see some
packages that attempt this
* A simplified representation of those licenses based on application
of common / seemingly noncontroversial FOSS (often
GPL-community-specific) folkloric legal conventions. Two examples:
1) an executable program built from GPLv2+ and MIT licensed source
files gets represented simply as "GPLv2+" (GPL-2.0-or-later in SPDX)
2) an executable program built from GPLv2+ source files but which
dynamically links against a GPLv3+ separately-packaged library (also
distributed in Fedora) gets represented as "GPLv3+"
I think there are many examples of 1) and I know of one example of 2),
but I think neither of those kinds of cases are handled consistently
across Fedora packages today (not saying that we need absolute
consistency)
Are simpler or more complex license expressions preferable, even if
simpler expressions mean some loss of useful information or accuracy?
That's one issue that is connected to Jilayne's question.
The point of the License tag in Fedora is to provide good guidance on
leveraging the software. If you want total accuracy, then you need
per-file license metadata. That's even *more* prone to errors, and
isn't even useful in most cases. I would prefer simpler,
understandable expressions than crazy accurate ones. For example, if
we changed to per-file accuracy, we'd need to start documenting all
the autotools bundled licensing, which we've never done.
--
真実はいつも一つ！/ Always, there's only one truth!
9:46 a.m.
On Mon, May 23, 2022 at 5:17 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
The weirdest license expression is the one for
perl-Exporter-Tidy[1],
which requires us to evaluate the entire list of acceptable licenses
and export them to the License tag since the license terms state as
such[2]. Outside of that, only crazy packages like Chromium wind up
having complex licensing. The rest are reasonably simple.
[1]: https://src.fedoraproject.org/rpms/perl-Exporter-Tidy
[2]: https://metacpan.org/pod/Exporter::Tidy#LICENSE
I think for that one it would be better to treat the contents of that
LICENSE file as a unique license (that happens to incorporate some set
of OSI-approved licenses that may vary at any given point in time).
The point of the License tag in Fedora is to provide good guidance
on
leveraging the software. If you want total accuracy, then you need
per-file license metadata. That's even *more* prone to errors, and
isn't even useful in most cases. I would prefer simpler,
understandable expressions than crazy accurate ones. For example, if
we changed to per-file accuracy, we'd need to start documenting all
the autotools bundled licensing, which we've never done.
Well, I assume that "license of the binary" is designed in part to
easily exclude autotools.
You could have per-source-file accuracy but only for files that are
"in" the binary, if you will. But then you have the overhead of
figuring out what is "in" the binary.
If you give up on per-source-file accuracy, this seems to imply the
overhead of making a legal or quasi-legal (e.g. what I call
'folkloric') conclusion.
Maybe instead of that we can come up with simple rules with the
understanding that the (generally very simple) result is sometimes
going to be fairly inaccurate.
I don't know which of these options is better. There are probably
various other ones.
Richard
10:11 a.m.
great discussion, Neal and Richard!
Just a ping that it'd be great to hear from others in the Fedora
community on this topic (see questions in original posts)
Thanks!!
On 5/24/22 8:46 AM, Richard Fontana wrote:
On Mon, May 23, 2022 at 5:17 PM Neal Gompa<ngompa13(a)gmail.com>
wrote:
> The weirdest license expression is the one for perl-Exporter-Tidy[1],
> which requires us to evaluate the entire list of acceptable licenses
> and export them to the License tag since the license terms state as
> such[2]. Outside of that, only crazy packages like Chromium wind up
> having complex licensing. The rest are reasonably simple.
>
> [1]:https://src.fedoraproject.org/rpms/perl-Exporter-Tidy
> [2]:https://metacpan.org/pod/Exporter::Tidy#LICENSE
I think for that one it would be better to treat the contents of that
LICENSE file as a unique license (that happens to incorporate some set
of OSI-approved licenses that may vary at any given point in time).
> The point of the License tag in Fedora is to provide good guidance on
> leveraging the software. If you want total accuracy, then you need
> per-file license metadata. That's even *more* prone to errors, and
> isn't even useful in most cases. I would prefer simpler,
> understandable expressions than crazy accurate ones. For example, if
> we changed to per-file accuracy, we'd need to start documenting all
> the autotools bundled licensing, which we've never done.
Well, I assume that "license of the binary" is designed in part to
easily exclude autotools.
You could have per-source-file accuracy but only for files that are
"in" the binary, if you will. But then you have the overhead of
figuring out what is "in" the binary.
If you give up on per-source-file accuracy, this seems to imply the
overhead of making a legal or quasi-legal (e.g. what I call
'folkloric') conclusion.
Maybe instead of that we can come up with simple rules with the
understanding that the (generally very simple) result is sometimes
going to be fairly inaccurate.
I don't know which of these options is better. There are probably
various other ones.
Richard
2:33 p.m.
New subject: [Fedora-packaging] license of the binary policy
Following up on this thread: A few of us in Red Hat discussed this
issue and settled on the idea that we should preserve the "licenses of
the contents of the binary rpm" policy, rather than the most obvious
alternative which would be "list the licenses found in the source
tarball". A major justification for that is that there isn't much
point in having the License: field merely replicate what you could get
by using a source code license scanner with some minimal analysis.
However, it seems clear that "licenses of the contents of the binary
rpm" is ambiguous and this partly explains why today Fedora packagers
seem to be applying non-uniform standards to figuring out what to
include in the License: field. There also may continue to be cases
where different licensing of binary subpackages makes a difference to
some package consumers.
We considered a few different options and we concluded that the best
approach is for the License: field to consist of a simple enumeration
of the licenses (including, possibly, disjunctive license expressions)
covering anything that ends up in a given binary RPM (whether compiled
to binary code or otherwise). The Fedora package maintainer is in the
best position to figure out what this subset of material in the source
code is, and how it appears to be licensed.
Importantly, this "simply enumerate" approach means not attempting to
do any sort of further analysis such as GPL derivative works analysis,
algebraic simplifications or resolutions of long strings of
conjunctive license expressions based on longstanding community
conventions around FOSS licensing, etc.
As before, any comments on this are most welcome!
Richard
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... ) states,
"The License: field refers to the licenses of the contents of the binary rpm. When in
doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be
helpful to hear people's thoughts on the following:
1) how do you (package maintainers) interpret this policy in practice?
2) what further information/documentation about this policy would be helpful?
3) should this policy be different, and if so, how?
4) any other related thoughts or observations
Thanks!
Jilayne
_______________________________________________
packaging mailing list -- packaging(a)lists.fedoraproject.org
To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
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/packaging@lists.fedoraproje...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
11:21 a.m.
New subject: [Fedora-packaging] license of the binary policy
Dne 06. 06. 22 v 21:33 Richard Fontana napsal(a):
Following up on this thread: A few of us in Red Hat discussed this
issue and settled on the idea that we should preserve the "licenses of
the contents of the binary rpm" policy, rather than the most obvious
alternative which would be "list the licenses found in the source
tarball". A major justification for that is that there isn't much
point in having the License: field merely replicate what you could get
by using a source code license scanner with some minimal analysis.
Please note that source licenses does not map to binary RPMs 1:1. It is
well possible the source tarball contains multiple licenses while some
subpackage content is licensed by only subset of the licenses. E.g. you
might have source tarball containing MIT code and CC0 data. Then you
have -data subpackage which contains just the data, therefore the
license for that subpackage should be just CC0.
Of course the guidelines could suggest against using specific License
field for subpackages. Dunno if that would help anything.
Vít
However, it seems clear that "licenses of the contents of the binary
rpm" is ambiguous and this partly explains why today Fedora packagers
seem to be applying non-uniform standards to figuring out what to
include in the License: field. There also may continue to be cases
where different licensing of binary subpackages makes a difference to
some package consumers.
We considered a few different options and we concluded that the best
approach is for the License: field to consist of a simple enumeration
of the licenses (including, possibly, disjunctive license expressions)
covering anything that ends up in a given binary RPM (whether compiled
to binary code or otherwise). The Fedora package maintainer is in the
best position to figure out what this subset of material in the source
code is, and how it appears to be licensed.
Importantly, this "simply enumerate" approach means not attempting to
do any sort of further analysis such as GPL derivative works analysis,
algebraic simplifications or resolutions of long strings of
conjunctive license expressions based on longstanding community
conventions around FOSS licensing, etc.
As before, any comments on this are most welcome!
Richard
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
> Hi Fedora legal and packaging,
>
> I'm cross-posting this, as I think it's relevant to both groups.
>
> The current policy for filling out the license field of the spec file (as described
at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel... )
states, "The License: field refers to the licenses of the contents of the binary rpm.
When in doubt, ask."
>
> As we consider how to improve documentation related to Fedora licensing, it would be
helpful to hear people's thoughts on the following:
>
> 1) how do you (package maintainers) interpret this policy in practice?
>
> 2) what further information/documentation about this policy would be helpful?
>
> 3) should this policy be different, and if so, how?
>
> 4) any other related thoughts or observations
>
>
> Thanks!
> Jilayne
> _______________________________________________
> packaging mailing list -- packaging(a)lists.fedoraproject.org
> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
> 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/packaging@lists.fedoraproje...
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
legal mailing list -- legal(a)lists.fedoraproject.org
To unsubscribe send an email to legal-leave(a)lists.fedoraproject.org
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/legal@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
688
days inactive
703
days old
12 comments
4 participants
participants (4)
-
Jilayne Lovejoy -
Neal Gompa -
Richard Fontana -
Vít Ondruch