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.
New subject: [Fedora-legal-list] license of the binary policy
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.
New subject: [Fedora-legal-list] license of the binary policy
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.
New subject: [Fedora-legal-list] license of the binary policy
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.
New subject: [Fedora-legal-list] Re: license of the binary policy
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.
New subject: [Fedora-legal-list] Re: license of the binary policy
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.
New subject: [Fedora-legal-list] Re: license of the binary policy
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.
New subject: [Fedora-legal-list] Re: license of the binary policy
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.
New subject: [Fedora-legal-list] Re: license of the binary policy
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.
New subject: [Fedora-legal-list] Re: license of the binary policy
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.
New subject: [Fedora-legal-list] Re: license of the binary policy
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
5:23 p.m.
New subject: [Fedora-legal-list] Re: license of the binary policy
On Mon, May 23, 2022 at 10:07 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, May 23, 2022 at 3:53 PM Jilayne Lovejoy <jlovejoy(a)redhat.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...
Side note: We actually worked around the problem you're discussing
with Rust packaging.
- source package name: rust-%{crate}
- built packages (containing source code): rust-%{crate}-devel etc.
- built packages (containing binaries): %{crate} (usually)
- there is no built package with the name rust-%{crate}
So while the main "License" tag from the rust-%{crate} source package
(which can be generated from upstream's SPDX metadata) is
automatically inherited by all subpackages, the subpackage that
actually contains the binaries can have a different "License" tag
(i.e. one that takes all statically linked content into account),
because its name is different than the name of the source package.
Fabio
1:45 a.m.
New subject: [Fedora-legal-list] license of the binary policy
On 5/23/22 19:44, 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. This is particularly kludgy
when you have vendored or bundled code.
I seem to have a dim recollection of ability to define source license
separately being requested at some point years ago, but it never went
anywhere, for whatever reason.
...
After rummaging through some dusty archives, turns that discussion took
place between Spot and myself in August 2007. No wonder the recollection
was dim. I guess there was never any ticket/bug filed on it and the
email simply got slowly buried in the sediment.
Feel free to open a ticket at
https://github.com/rpm-software-management/rpm/ if this is something we
should look into. Doesn't seem like rocket science to add an optional
SourceLicense that would be used for the src.rpm license if present, or
something like that.
- Panu -
1:11 a.m.
Jilayne Lovejoy kirjoitti 23.5.2022 klo 19.31:
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
As a maintainer of modest amount of packages and occassional new package
reviewer,
the issues I have with the current licensing policy as linked above are:
1. The "effective license" thing that is already discussed in another
thread does not appear in the policy at all, and it does not appear in
Fedora Licensing page, either. The only places that mention it that I
have discovered are Licensing:FAQ [1] and random discussions at mailing
lists and so on. This makes it quite difficult to understand if
"effective licensing" is actually part of the policy or not. It would be
easier to understand its status if it was covered in the policy itself.
The policy itself should be unambiguous and possible to interpret
without reference to any FAQ. A FAQ should not introduce new
requirements and exceptions.
2. In general, it is confusing that the policy is split between
Packaging Guidelines, Fedora Licensing main page and, apparently, also
the FAQ. How can I determine if any given docs or wiki page is
authorative? Would it be possible to consolidate everything that is
authorative to a single page and declare it such?
3. Specifically related to the effective licensing question, MIT and BSD
basically *only* ask to include the license text when shipping binaries.
The effective licensing thing then erases those licenses, if there is
GPL somewhere in the mix. The cognitive dissonance between wanting to
honor upstream licenses and not shipping them due to effective licensing
is serious. Since MIT and BSD are very common licenses, and code under
them is also very commonly found embedded in otherwise GPL projects, I
would like the licensing policy explicitly cover this situation and
explain why it is allowed to not ship the MIT/BSD license in this case.
(Perhaps, it would be good to revisit the part of the policy that
discussed shipping license texts and consider, why is that required: It
is in order to honor upstream licenses, or for some other reason, like
end user convenience?)
[1]: https://fedoraproject.org/wiki/Licensing:FAQ
4:13 p.m.
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi> wrote:
As a maintainer of modest amount of packages and occassional new package
reviewer,
the issues I have with the current licensing policy as linked above are:
1. The "effective license" thing that is already discussed in another
thread does not appear in the policy at all, and it does not appear in
Fedora Licensing page, either. The only places that mention it that I
have discovered are Licensing:FAQ [1] and random discussions at mailing
lists and so on. This makes it quite difficult to understand if
"effective licensing" is actually part of the policy or not. It would be
easier to understand its status if it was covered in the policy itself.
The policy itself should be unambiguous and possible to interpret
without reference to any FAQ. A FAQ should not introduce new
requirements and exceptions.
That part of the FAQ will have to be revisited, if the approach I
suggested today is adopted (a good example of why it isn't exactly
maintaining the existing policy). Basically, the "simple enumeration"
approach would mean that there is no such thing as "effective
licensing".
If people think that "effective licensing" is something that is so
valuable that it is worth the resulting unavoidable complexity of
analysis and inconsistency across packages, that view should be
voiced. I *can* imagine providing some more detailed rules about what
"effective licensing" means (and at an earlier stage I was actually
thinking of working on something like this). I basically gave up
because it's clear no one agrees on what effective licensing means,
which means it's not effective. :)
2. In general, it is confusing that the policy is split between
Packaging Guidelines, Fedora Licensing main page and, apparently, also
the FAQ. How can I determine if any given docs or wiki page is
authorative? Would it be possible to consolidate everything that is
authorative to a single page and declare it such?
Good idea.
3. Specifically related to the effective licensing question, MIT and
BSD
basically *only* ask to include the license text when shipping binaries.
The effective licensing thing then erases those licenses, if there is
GPL somewhere in the mix. The cognitive dissonance between wanting to
honor upstream licenses and not shipping them due to effective licensing
is serious. Since MIT and BSD are very common licenses, and code under
them is also very commonly found embedded in otherwise GPL projects, I
would like the licensing policy explicitly cover this situation and
explain why it is allowed to not ship the MIT/BSD license in this case.
(Perhaps, it would be good to revisit the part of the policy that
discussed shipping license texts and consider, why is that required: It
is in order to honor upstream licenses, or for some other reason, like
end user convenience?)
All the licenses are shipped in that they are found in the SRPM.
Implicitly, Fedora's position is that this is compliant with those
permissive licenses. I think the issue you're raising is Fedora's
policy on what license texts to install in /usr/share/licenses. I
don't think that issue is directly tied to how the License: field is
populated. I couldn't immediately find any documentation on the
/usr/share/licenses policy, but my intuition from looking at lots of
Fedora and RHEL packages is that this contains any license text that
seems to be "global" in some way, and in cases where there is no
obvious such license, some appropriate license is selected from the
source files for this purpose. We might want to separately revisit the
/usr/share/licenses policy at some point if there is interest.
Richard
[1]: https://fedoraproject.org/wiki/Licensing:FAQ
_______________________________________________
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
--
4:18 p.m.
On Mon, Jun 6, 2022 at 5:13 PM Richard Fontana <rfontana(a)redhat.com> wrote:
We might want to separately revisit the
/usr/share/licenses policy at some point if there is interest.
Oh, while we are on that topic, I will repeat what I think I've said
before, that Fedora should consider adopting the Debian approach of
having a /usr/share/common-licenses directory. (Debian also has a
per-package "copyright file" approach that is related to this topic
but that would probably be more controversial.)
Richard
2:46 a.m.
New subject: [Fedora-legal-list] Re: Re: license of the binary policy
>>>> Richard Fontana <rfontana(a)redhat.com> writes:
Oh, while we are on that topic, I will repeat what I think I've
said
before, that Fedora should consider adopting the Debian approach of
having a /usr/share/common-licenses directory.
How would this differ from what we do currently, besides the obvious
name change from the current /usr/share/licenses directory? Is it a
question of the directory layout, or something more basic like ignoring
the license text from upstream completely and just linking to it?
- J<
4:49 p.m.
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana <rfontana(a)redhat.com> wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi> wrote:
>
> As a maintainer of modest amount of packages and occassional new package
> reviewer,
> the issues I have with the current licensing policy as linked above are:
>
> 1. The "effective license" thing that is already discussed in another
> thread does not appear in the policy at all, and it does not appear in
> Fedora Licensing page, either. The only places that mention it that I
> have discovered are Licensing:FAQ [1] and random discussions at mailing
> lists and so on. This makes it quite difficult to understand if
> "effective licensing" is actually part of the policy or not. It would be
> easier to understand its status if it was covered in the policy itself.
> The policy itself should be unambiguous and possible to interpret
> without reference to any FAQ. A FAQ should not introduce new
> requirements and exceptions.
That part of the FAQ will have to be revisited, if the approach I
suggested today is adopted (a good example of why it isn't exactly
maintaining the existing policy). Basically, the "simple enumeration"
approach would mean that there is no such thing as "effective
licensing".
I wonder what you think about simple cases of "effective" licenses?
For example, most Rust projects are dual-licensed as "Apache-2.0 OR
MIT", but some odd ones are released under "MIT"-only or
"Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR
MIT" and "MIT"-only projects, we usually "collapsed" that into
just
"MIT".
Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
MIT" - would be kind of silly, in my opinion.
Adding the full "Apache-2.0 OR MIT" choice from the first project
seems to be pointless, since it actually cannot result in a choice of
license - because that choice is already forced by the "MIT"-only
second project. Please correct me if this analysis is wrong.
Fabio
9:31 a.m.
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana <rfontana(a)redhat.com> wrote:
>
> On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi> wrote:
> >
> > As a maintainer of modest amount of packages and occassional new package
> > reviewer,
> > the issues I have with the current licensing policy as linked above are:
> >
> > 1. The "effective license" thing that is already discussed in
another
> > thread does not appear in the policy at all, and it does not appear in
> > Fedora Licensing page, either. The only places that mention it that I
> > have discovered are Licensing:FAQ [1] and random discussions at mailing
> > lists and so on. This makes it quite difficult to understand if
> > "effective licensing" is actually part of the policy or not. It would
be
> > easier to understand its status if it was covered in the policy itself.
> > The policy itself should be unambiguous and possible to interpret
> > without reference to any FAQ. A FAQ should not introduce new
> > requirements and exceptions.
>
> That part of the FAQ will have to be revisited, if the approach I
> suggested today is adopted (a good example of why it isn't exactly
> maintaining the existing policy). Basically, the "simple enumeration"
> approach would mean that there is no such thing as "effective
> licensing".
I wonder what you think about simple cases of "effective" licenses?
For example, most Rust projects are dual-licensed as "Apache-2.0 OR
MIT", but some odd ones are released under "MIT"-only or
"Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR
MIT" and "MIT"-only projects, we usually "collapsed" that into
just
"MIT".
Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we
are stubbornly clinging to the practice of recording a FOSS dual
license in the license tag, when not doing so could provide some
simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was
what Fedora traditionally did; (2) it matches general upstream culture
(the idea of passing down a FOSS license choice through a chain of
distributees; (3) there's a contrary corporate culture seen in some
quarters of making sure that "bad" (from their perspective) FOSS
licenses in a dual license scheme are eliminated, which I think is
based mostly on ignorance and copyleftphobia and so forth, which we
don't want to encourage or be associated with; (4) there isn't going
to be a good, consistently-applicable basis for selecting one or the
other license -- this is related to (3). (4) is also related to the
"effective license" problem: there isn't really any coherent effective
license doctrine that can be consistently applied. I guess also (5)
which is a community counterpart to (3): you would end up with
licenses being selected out of a dual license based on the individual
preferences of a Fedora packager. In one case, a Fedora packager might
personally prefer the Apache License 2.0 over MIT, in another case the
opposite. This contradicts the tradition of passing down the choice to
the user.
Adding the full "Apache-2.0 OR MIT" choice from the first
project
seems to be pointless, since it actually cannot result in a choice of
license - because that choice is already forced by the "MIT"-only
second project. Please correct me if this analysis is wrong.
I understand this point but the idea that the choice is forced seems
to be a form of "effective license" analysis. I am not dismissive of
the idea since I think there is something fundamentally unclear about
what composite licensing means. However, the general problems with
effective license analysis apply to this case too.
Richard
3:37 p.m.
On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini
<decathorpe(a)gmail.com> wrote:
> On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana <rfontana(a)redhat.com> wrote:
>> On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi> wrote:
>>
> I wonder what you think about simple cases of "effective" licenses?
> For example, most Rust projects are dual-licensed as "Apache-2.0 OR
> MIT", but some odd ones are released under "MIT"-only or
> "Apache-2.0"-only licenses.
>
> So, for a binary package that contains code from both "Apache-2.0 OR
> MIT" and "MIT"-only projects, we usually "collapsed" that
into just
> "MIT".
> Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
> MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we
are stubbornly clinging to the practice of recording a FOSS dual
license in the license tag, when not doing so could provide some
simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was
what Fedora traditionally did; (2) it matches general upstream culture
(the idea of passing down a FOSS license choice through a chain of
distributees; (3) there's a contrary corporate culture seen in some
quarters of making sure that "bad" (from their perspective) FOSS
licenses in a dual license scheme are eliminated, which I think is
based mostly on ignorance and copyleftphobia and so forth, which we
don't want to encourage or be associated with; (4) there isn't going
to be a good, consistently-applicable basis for selecting one or the
other license -- this is related to (3). (4) is also related to the
"effective license" problem: there isn't really any coherent effective
license doctrine that can be consistently applied. I guess also (5)
which is a community counterpart to (3): you would end up with
licenses being selected out of a dual license based on the individual
preferences of a Fedora packager. In one case, a Fedora packager might
personally prefer the Apache License 2.0 over MIT, in another case the
opposite. This contradicts the tradition of passing down the choice to
the user.
Ha, you start out with "stubbornly clinging" and that maybe not
recording the dual license in the license tag helping simply things, but
then after reading your points (1) through (5), I felt even more
convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by
example) can be really annoying for downstream recipients or downstream
of downstream. I have memories of doing source code audits and running
into this and relying on some form of "tribal knowledge" that there was
a choice upstream that had gotten removed and then going upstream to
find it, so the choice could be made "again". Fedora, as a free and open
source software distro, need not make an explicit choice between two
free and open source licenses (in the way a commercial software
distribution might), so the policy of passing along the original choice
makes sense to me as a matter of convenience (for downstream recipients)
and in keeping with the principles of Fedora being free and open more
generally.
> Adding the full "Apache-2.0 OR MIT" choice from the first project
> seems to be pointless, since it actually cannot result in a choice of
> license - because that choice is already forced by the "MIT"-only
> second project. Please correct me if this analysis is wrong.
sort of, but given
the above points, I don't think it hurts to capture
"(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to
what is going on.
I understand this point but the idea that the choice is forced seems
to be a form of "effective license" analysis. I am not dismissive of
the idea since I think there is something fundamentally unclear about
what composite licensing means. However, the general problems with
effective license analysis apply to this case too.
Richard
_______________________________________________
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
4:09 p.m.
On Wed, Jul 13, 2022 at 10:38 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
On 7/12/22 8:31 AM, Richard Fontana wrote:
> On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
>> On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana <rfontana(a)redhat.com>
wrote:
>>> On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi>
wrote:
>>>
>> I wonder what you think about simple cases of "effective" licenses?
>> For example, most Rust projects are dual-licensed as "Apache-2.0 OR
>> MIT", but some odd ones are released under "MIT"-only or
>> "Apache-2.0"-only licenses.
>>
>> So, for a binary package that contains code from both "Apache-2.0 OR
>> MIT" and "MIT"-only projects, we usually "collapsed"
that into just
>> "MIT".
>> Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
>> MIT" - would be kind of silly, in my opinion.
> I wanted to follow up on this point since it does feel to me like we
> are stubbornly clinging to the practice of recording a FOSS dual
> license in the license tag, when not doing so could provide some
> simplification of license tag expressions.
>
> In my mind, there were a few reasons for this practice: (1) it was
> what Fedora traditionally did; (2) it matches general upstream culture
> (the idea of passing down a FOSS license choice through a chain of
> distributees; (3) there's a contrary corporate culture seen in some
> quarters of making sure that "bad" (from their perspective) FOSS
> licenses in a dual license scheme are eliminated, which I think is
> based mostly on ignorance and copyleftphobia and so forth, which we
> don't want to encourage or be associated with; (4) there isn't going
> to be a good, consistently-applicable basis for selecting one or the
> other license -- this is related to (3). (4) is also related to the
> "effective license" problem: there isn't really any coherent
effective
> license doctrine that can be consistently applied. I guess also (5)
> which is a community counterpart to (3): you would end up with
> licenses being selected out of a dual license based on the individual
> preferences of a Fedora packager. In one case, a Fedora packager might
> personally prefer the Apache License 2.0 over MIT, in another case the
> opposite. This contradicts the tradition of passing down the choice to
> the user.
Ha, you start out with "stubbornly clinging" and that maybe not
recording the dual license in the license tag helping simply things, but
then after reading your points (1) through (5), I felt even more
convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by
example) can be really annoying for downstream recipients or downstream
of downstream. I have memories of doing source code audits and running
into this and relying on some form of "tribal knowledge" that there was
a choice upstream that had gotten removed and then going upstream to
find it, so the choice could be made "again". Fedora, as a free and open
source software distro, need not make an explicit choice between two
free and open source licenses (in the way a commercial software
distribution might), so the policy of passing along the original choice
makes sense to me as a matter of convenience (for downstream recipients)
and in keeping with the principles of Fedora being free and open more
generally.
Sorry, I'm somewhat confused by these last two responses to my question.
On the other hand, you seem to be making arguments that *favor*
simplification of dual licenses.
But the conclusion seems to be that "just specify everything" is still better?
For a few packages, the license string would get very long (hundreds
of characters), and basically meaningless for any user of the package.
And what I don't understand: In the case of a project that contains -
or includes - both "(ASL 2.0 OR MIT)" and "MIT" licensed code,
hasn't
the upstream project basically already made the decision about the
resulting license (i.e. "MIT")?
Assume that I as the packager would actually make a "choice" here, and
"choose" ASL 2.0", that would result in a package with license "ASL
2.0 and MIT".
However, if I make the more "obvious" choice of "MIT", the license
will be just "MIT".
So the first "choice" results in a package with *strictly more*
licensing restrictions than the second "choice".
I as the packager don't want to (or should?) produce a package that
has stronger licensing restrictions than necessary (or intended).
>> Adding the full "Apache-2.0 OR MIT" choice from
the first project
>> seems to be pointless, since it actually cannot result in a choice of
>> license - because that choice is already forced by the "MIT"-only
>> second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture
"(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to
what is going on.
It might be accurate. But this is also a very simplified example to
illustrate my point.
Here's a more realistic one (taken from one of my packages, where I
also happen to be the upstream developer).
This is the list of licenses of the project itself and its
dependencies, which are all statically linked together into a final
binary:
# (ASL 2.0 or MIT) and BSD
# ASL 2.0
# ASL 2.0 or Boost
# ASL 2.0 or MIT
# BSD
# MIT
# MIT or ASL 2.0
# MIT or ASL 2.0 or zlib
# Unlicense or MIT
# zlib or ASL 2.0 or MIT
Just recording everything would result in a license string of:
License: (ASL 2.0 or MIT) and BSD and ASL 2.0 and (ASL 2.0 or Boost)
and (ASL 2.0 or MIT) and BSD and MIT and (MIT or ASL 2.0) and (MIT or
ASL 2.0 or zlib) and (Unlicense or MIT) and (zlib or ASL 2.0 or MIT)
This is already kind of silly, because it's stupidly long, and there
are duplicates, or clauses that are identical except for the order of
their contents.
I would not say that this is "somewhat obvious as to what is going
on", because nobody will even read this string in its entirety.
Now, is reordering the contents of the clauses and removing any
duplicates already considered as doing an "effective license
analysis"? :)
Anyhow, for this package, I have "simplified" the license string to:
License: ASL 2.0 and BSD and MIT
This satisfies every clause, and I'd argue it is *much more obvious*
to users what it means than the silly long string above.
It doesn't give users any "choices", but any "choice" they would
have
made (differently than what I did when packaging this project) would
have resulted in a package with *strictly more* restrictions, but
never *fewer*.
I'd argue that 1) minimizing restrictions and 2) making the resulting
license actually understandable for users is much more important than
to preserve any "choice" that, if exercised differently, would only
result in either more restrictions, more complicated licensing terms,
or both.
Fabio
4:19 p.m.
HI Fabio
On 7/13/22 3:09 PM, Fabio Valentini wrote:
On Wed, Jul 13, 2022 at 10:38 PM Jilayne
Lovejoy<jlovejoy(a)redhat.com> wrote:
> On 7/12/22 8:31 AM, Richard Fontana wrote:
>> On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini<decathorpe(a)gmail.com>
wrote:
>>> On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana<rfontana(a)redhat.com>
wrote:
>>>> On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen<oturpe(a)iki.fi>
wrote:
>>>>
>>> I wonder what you think about simple cases of "effective"
licenses?
>>> For example, most Rust projects are dual-licensed as "Apache-2.0 OR
>>> MIT", but some odd ones are released under "MIT"-only or
>>> "Apache-2.0"-only licenses.
>>>
>>> So, for a binary package that contains code from both "Apache-2.0 OR
>>> MIT" and "MIT"-only projects, we usually "collapsed"
that into just
>>> "MIT".
>>> Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
>>> MIT" - would be kind of silly, in my opinion.
>> I wanted to follow up on this point since it does feel to me like we
>> are stubbornly clinging to the practice of recording a FOSS dual
>> license in the license tag, when not doing so could provide some
>> simplification of license tag expressions.
>>
>> In my mind, there were a few reasons for this practice: (1) it was
>> what Fedora traditionally did; (2) it matches general upstream culture
>> (the idea of passing down a FOSS license choice through a chain of
>> distributees; (3) there's a contrary corporate culture seen in some
>> quarters of making sure that "bad" (from their perspective) FOSS
>> licenses in a dual license scheme are eliminated, which I think is
>> based mostly on ignorance and copyleftphobia and so forth, which we
>> don't want to encourage or be associated with; (4) there isn't going
>> to be a good, consistently-applicable basis for selecting one or the
>> other license -- this is related to (3). (4) is also related to the
>> "effective license" problem: there isn't really any coherent
effective
>> license doctrine that can be consistently applied. I guess also (5)
>> which is a community counterpart to (3): you would end up with
>> licenses being selected out of a dual license based on the individual
>> preferences of a Fedora packager. In one case, a Fedora packager might
>> personally prefer the Apache License 2.0 over MIT, in another case the
>> opposite. This contradicts the tradition of passing down the choice to
>> the user.
> Ha, you start out with "stubbornly clinging" and that maybe not
> recording the dual license in the license tag helping simply things, but
> then after reading your points (1) through (5), I felt even more
> convinced of the value in recording/retaining such info!
>
> I must say - the scenario where someone makes the choices (point (3) by
> example) can be really annoying for downstream recipients or downstream
> of downstream. I have memories of doing source code audits and running
> into this and relying on some form of "tribal knowledge" that there was
> a choice upstream that had gotten removed and then going upstream to
> find it, so the choice could be made "again". Fedora, as a free and open
> source software distro, need not make an explicit choice between two
> free and open source licenses (in the way a commercial software
> distribution might), so the policy of passing along the original choice
> makes sense to me as a matter of convenience (for downstream recipients)
> and in keeping with the principles of Fedora being free and open more
> generally.
Sorry, I'm somewhat confused by these last two responses to my question.
On the other hand, you seem to be making arguments that *favor*
simplification of dual licenses.
But the conclusion seems to be that "just specify everything" is still better?
yeah... I think Richard and I are both sort of working through this as
you all come up with additional and perhaps more complex examples :)
(and trying to add to/draft guidance that will be (relative) easy to
follow and captures enough actual examples as well)
>>> Adding the full "Apache-2.0 OR MIT" choice from the first project
>>> seems to be pointless, since it actually cannot result in a choice of
>>> license - because that choice is already forced by the "MIT"-only
>>> second project. Please correct me if this analysis is wrong.
> sort of, but given the above points, I don't think it hurts to capture
> "(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as
to
> what is going on.
It might be accurate. But this is also a very simplified example to
illustrate my point.
ok, fair enough - that was a simple example. And I have a
feeling that
the guidance on dual-licensed packages probably contemplated more simple
scenarios, but...
Here's a more realistic one (taken from one of my packages, where I
also happen to be the upstream developer).
great!
This is the list of licenses of the project itself and its
dependencies, which are all statically linked together into a final
binary:
# (ASL 2.0 or MIT) and BSD
# ASL 2.0
# ASL 2.0 or Boost
# ASL 2.0 or MIT
# BSD
# MIT
# MIT or ASL 2.0
# MIT or ASL 2.0 or zlib
# Unlicense or MIT
# zlib or ASL 2.0 or MIT
Just recording everything would result in a license string of:
License: (ASL 2.0 or MIT) and BSD and ASL 2.0 and (ASL 2.0 or Boost)
and (ASL 2.0 or MIT) and BSD and MIT and (MIT or ASL 2.0) and (MIT or
ASL 2.0 or zlib) and (Unlicense or MIT) and (zlib or ASL 2.0 or MIT)
This is already kind of silly, because it's stupidly long, and there
are duplicates, or clauses that are identical except for the order of
their contents.
I would not say that this is "somewhat obvious as to what is going
on", because nobody will even read this string in its entirety.
yeah, this is
a more interesting example for sure and agreed, it does
get a bit ridiculous looking even if still "accurate"
Now, is reordering the contents of the clauses and removing any
duplicates already considered as doing an "effective license
analysis"? :)
Anyhow, for this package, I have "simplified" the license string to:
License: ASL 2.0 and BSD and MIT
This satisfies every clause, and I'd argue it is *much more obvious*
to users what it means than the silly long string above.
It doesn't give users any "choices", but any "choice" they would
have
made (differently than what I did when packaging this project) would
have resulted in a package with *strictly more* restrictions, but
never *fewer*.
I'd argue that 1) minimizing restrictions and 2) making the resulting
license actually understandable for users is much more important than
to preserve any "choice" that, if exercised differently, would only
result in either more restrictions, more complicated licensing terms,
or both.
Thanks for this, really helpful. Richard and I will discuss a bit more...
Going back to some of the original comments in this thread (or another
similar one?) - is the above actual example a common scenario for Rust
and Go packages? And can it get even more complex or lengthy than this
example? Just trying to get a sense of the typical range of examples
you all come up against, so we can be sure to try to cover those.
Thanks!
Jilayne
Fabio
_______________________________________________
packaging mailing list --packaging(a)lists.fedoraproject.org
To unsubscribe send an email topackaging-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.fe...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
4:41 p.m.
So, in Fabio's example, you could simplify it somewhat, because under
our in-progress guidelines we say or intend to say that order of
license identifiers in a license expression doesn't matter: i.e., (MIT
OR Apache-2.0) is the same as (Apache-2.0 OR MIT) (Jilayne, does the
SPDX spec itself say this?). So you wouldn't repeat those, any more
than you'd repeat multiple occurrences of "MIT" (say, a package with
multiple executable binaries each determined to be under the MIT
license). This is an aspect of the "simple enumeration" policy. The
resulting license expression will still be pretty lengthy, I admit.
For me personally, I think experience has shown that simplification of
license description is fraught with problems and it is better to
attempt greater accuracy around license description. This is a major
reason why I (a longtime skeptic of SPDX) got on board with the idea
of Fedora using SPDX identifiers, because if used properly they
provide more information than counterpart Callaway expressions. On the
other hand, if the license tags don't really matter to users, why have
them at all? I just don't see the point of a middle ground between no
license tags and license tags that attempt accurate description, where
the middle ground is going to involve value judgements and legal
analysis that will differ from packager to packager.
If we were to start entertaining some rules around license expression
simplification, though, I think the dual licenses would be a logical
place to start.
Richard
On Wed, Jul 13, 2022 at 5:19 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
HI Fabio
On 7/13/22 3:09 PM, Fabio Valentini wrote:
On Wed, Jul 13, 2022 at 10:38 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana <rfontana(a)redhat.com> wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi> wrote:
I wonder what you think about simple cases of "effective" licenses?
For example, most Rust projects are dual-licensed as "Apache-2.0 OR
MIT", but some odd ones are released under "MIT"-only or
"Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR
MIT" and "MIT"-only projects, we usually "collapsed" that into
just
"MIT".
Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we
are stubbornly clinging to the practice of recording a FOSS dual
license in the license tag, when not doing so could provide some
simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was
what Fedora traditionally did; (2) it matches general upstream culture
(the idea of passing down a FOSS license choice through a chain of
distributees; (3) there's a contrary corporate culture seen in some
quarters of making sure that "bad" (from their perspective) FOSS
licenses in a dual license scheme are eliminated, which I think is
based mostly on ignorance and copyleftphobia and so forth, which we
don't want to encourage or be associated with; (4) there isn't going
to be a good, consistently-applicable basis for selecting one or the
other license -- this is related to (3). (4) is also related to the
"effective license" problem: there isn't really any coherent effective
license doctrine that can be consistently applied. I guess also (5)
which is a community counterpart to (3): you would end up with
licenses being selected out of a dual license based on the individual
preferences of a Fedora packager. In one case, a Fedora packager might
personally prefer the Apache License 2.0 over MIT, in another case the
opposite. This contradicts the tradition of passing down the choice to
the user.
Ha, you start out with "stubbornly clinging" and that maybe not
recording the dual license in the license tag helping simply things, but
then after reading your points (1) through (5), I felt even more
convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by
example) can be really annoying for downstream recipients or downstream
of downstream. I have memories of doing source code audits and running
into this and relying on some form of "tribal knowledge" that there was
a choice upstream that had gotten removed and then going upstream to
find it, so the choice could be made "again". Fedora, as a free and open
source software distro, need not make an explicit choice between two
free and open source licenses (in the way a commercial software
distribution might), so the policy of passing along the original choice
makes sense to me as a matter of convenience (for downstream recipients)
and in keeping with the principles of Fedora being free and open more
generally.
Sorry, I'm somewhat confused by these last two responses to my question.
On the other hand, you seem to be making arguments that *favor*
simplification of dual licenses.
But the conclusion seems to be that "just specify everything" is still better?
yeah... I think Richard and I are both sort of working through this as you all come up
with additional and perhaps more complex examples :)
(and trying to add to/draft guidance that will be (relative) easy to follow and captures
enough actual examples as well)
Adding the full "Apache-2.0 OR MIT" choice from the first project
seems to be pointless, since it actually cannot result in a choice of
license - because that choice is already forced by the "MIT"-only
second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture
"(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to
what is going on.
It might be accurate. But this is also a very simplified example to
illustrate my point.
ok, fair enough - that was a simple example. And I have a feeling that the guidance on
dual-licensed packages probably contemplated more simple scenarios, but...
Here's a more realistic one (taken from one of my packages, where I
also happen to be the upstream developer).
great!
This is the list of licenses of the project itself and its
dependencies, which are all statically linked together into a final
binary:
# (ASL 2.0 or MIT) and BSD
# ASL 2.0
# ASL 2.0 or Boost
# ASL 2.0 or MIT
# BSD
# MIT
# MIT or ASL 2.0
# MIT or ASL 2.0 or zlib
# Unlicense or MIT
# zlib or ASL 2.0 or MIT
Just recording everything would result in a license string of:
License: (ASL 2.0 or MIT) and BSD and ASL 2.0 and (ASL 2.0 or Boost)
and (ASL 2.0 or MIT) and BSD and MIT and (MIT or ASL 2.0) and (MIT or
ASL 2.0 or zlib) and (Unlicense or MIT) and (zlib or ASL 2.0 or MIT)
This is already kind of silly, because it's stupidly long, and there
are duplicates, or clauses that are identical except for the order of
their contents.
I would not say that this is "somewhat obvious as to what is going
on", because nobody will even read this string in its entirety.
yeah, this is a more interesting example for sure and agreed, it does get a bit
ridiculous looking even if still "accurate"
Now, is reordering the contents of the clauses and removing any
duplicates already considered as doing an "effective license
analysis"? :)
Anyhow, for this package, I have "simplified" the license string to:
License: ASL 2.0 and BSD and MIT
This satisfies every clause, and I'd argue it is *much more obvious*
to users what it means than the silly long string above.
It doesn't give users any "choices", but any "choice" they would
have
made (differently than what I did when packaging this project) would
have resulted in a package with *strictly more* restrictions, but
never *fewer*.
I'd argue that 1) minimizing restrictions and 2) making the resulting
license actually understandable for users is much more important than
to preserve any "choice" that, if exercised differently, would only
result in either more restrictions, more complicated licensing terms,
or both.
Thanks for this, really helpful. Richard and I will discuss a bit more...
Going back to some of the original comments in this thread (or another similar one?) - is
the above actual example a common scenario for Rust and Go packages? And can it get even
more complex or lengthy than this example? Just trying to get a sense of the typical
range of examples you all come up against, so we can be sure to try to cover those.
Thanks!
Jilayne
Fabio
_______________________________________________
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
_______________________________________________
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
4:14 p.m.
I would add, though I guess it's covered by what I said, that there
are situations where it's not clear, as a matter of what's basically
legal analysis, which side of a FOSS dual license is actually
'better'. A good example might be the Sun GPLv2 with Classpath
Exception | CDDL case -- in the cases where that dual license applies,
you can come up with arguments why one or the other license is
preferable based on various factors.
- Richard
On Wed, Jul 13, 2022 at 4:37 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
On 7/12/22 8:31 AM, Richard Fontana wrote:
> On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
>> On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana <rfontana(a)redhat.com>
wrote:
>>> On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi>
wrote:
>>>
>> I wonder what you think about simple cases of "effective" licenses?
>> For example, most Rust projects are dual-licensed as "Apache-2.0 OR
>> MIT", but some odd ones are released under "MIT"-only or
>> "Apache-2.0"-only licenses.
>>
>> So, for a binary package that contains code from both "Apache-2.0 OR
>> MIT" and "MIT"-only projects, we usually "collapsed"
that into just
>> "MIT".
>> Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
>> MIT" - would be kind of silly, in my opinion.
> I wanted to follow up on this point since it does feel to me like we
> are stubbornly clinging to the practice of recording a FOSS dual
> license in the license tag, when not doing so could provide some
> simplification of license tag expressions.
>
> In my mind, there were a few reasons for this practice: (1) it was
> what Fedora traditionally did; (2) it matches general upstream culture
> (the idea of passing down a FOSS license choice through a chain of
> distributees; (3) there's a contrary corporate culture seen in some
> quarters of making sure that "bad" (from their perspective) FOSS
> licenses in a dual license scheme are eliminated, which I think is
> based mostly on ignorance and copyleftphobia and so forth, which we
> don't want to encourage or be associated with; (4) there isn't going
> to be a good, consistently-applicable basis for selecting one or the
> other license -- this is related to (3). (4) is also related to the
> "effective license" problem: there isn't really any coherent
effective
> license doctrine that can be consistently applied. I guess also (5)
> which is a community counterpart to (3): you would end up with
> licenses being selected out of a dual license based on the individual
> preferences of a Fedora packager. In one case, a Fedora packager might
> personally prefer the Apache License 2.0 over MIT, in another case the
> opposite. This contradicts the tradition of passing down the choice to
> the user.
Ha, you start out with "stubbornly clinging" and that maybe not
recording the dual license in the license tag helping simply things, but
then after reading your points (1) through (5), I felt even more
convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by
example) can be really annoying for downstream recipients or downstream
of downstream. I have memories of doing source code audits and running
into this and relying on some form of "tribal knowledge" that there was
a choice upstream that had gotten removed and then going upstream to
find it, so the choice could be made "again". Fedora, as a free and open
source software distro, need not make an explicit choice between two
free and open source licenses (in the way a commercial software
distribution might), so the policy of passing along the original choice
makes sense to me as a matter of convenience (for downstream recipients)
and in keeping with the principles of Fedora being free and open more
generally.
>
>> Adding the full "Apache-2.0 OR MIT" choice from the first project
>> seems to be pointless, since it actually cannot result in a choice of
>> license - because that choice is already forced by the "MIT"-only
>> second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture
"(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to
what is going on.
> I understand this point but the idea that the choice is forced seems
> to be a form of "effective license" analysis. I am not dismissive of
> the idea since I think there is something fundamentally unclear about
> what composite licensing means. However, the general problems with
> effective license analysis apply to this case too.
>
> Richard
> _______________________________________________
> 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
4:21 p.m.
how did you know that is the exact past example I was thinking of that
plagued me in the past!! (and hoping it's a bit less common these
days... or at least not found as part of the complex scenario that Fabio
just mentioned)
:)
On 7/13/22 3:14 PM, Richard Fontana wrote:
I would add, though I guess it's covered by what I said, that
there
are situations where it's not clear, as a matter of what's basically
legal analysis, which side of a FOSS dual license is actually
'better'. A good example might be the Sun GPLv2 with Classpath
Exception | CDDL case -- in the cases where that dual license applies,
you can come up with arguments why one or the other license is
preferable based on various factors.
- Richard
On Wed, Jul 13, 2022 at 4:37 PM Jilayne Lovejoy<jlovejoy(a)redhat.com> wrote:
>
>
> On 7/12/22 8:31 AM, Richard Fontana wrote:
>> On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini<decathorpe(a)gmail.com>
wrote:
>>> On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana<rfontana(a)redhat.com>
wrote:
>>>> On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen<oturpe(a)iki.fi>
wrote:
>>>>
>>> I wonder what you think about simple cases of "effective"
licenses?
>>> For example, most Rust projects are dual-licensed as "Apache-2.0 OR
>>> MIT", but some odd ones are released under "MIT"-only or
>>> "Apache-2.0"-only licenses.
>>>
>>> So, for a binary package that contains code from both "Apache-2.0 OR
>>> MIT" and "MIT"-only projects, we usually "collapsed"
that into just
>>> "MIT".
>>> Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND
>>> MIT" - would be kind of silly, in my opinion.
>> I wanted to follow up on this point since it does feel to me like we
>> are stubbornly clinging to the practice of recording a FOSS dual
>> license in the license tag, when not doing so could provide some
>> simplification of license tag expressions.
>>
>> In my mind, there were a few reasons for this practice: (1) it was
>> what Fedora traditionally did; (2) it matches general upstream culture
>> (the idea of passing down a FOSS license choice through a chain of
>> distributees; (3) there's a contrary corporate culture seen in some
>> quarters of making sure that "bad" (from their perspective) FOSS
>> licenses in a dual license scheme are eliminated, which I think is
>> based mostly on ignorance and copyleftphobia and so forth, which we
>> don't want to encourage or be associated with; (4) there isn't going
>> to be a good, consistently-applicable basis for selecting one or the
>> other license -- this is related to (3). (4) is also related to the
>> "effective license" problem: there isn't really any coherent
effective
>> license doctrine that can be consistently applied. I guess also (5)
>> which is a community counterpart to (3): you would end up with
>> licenses being selected out of a dual license based on the individual
>> preferences of a Fedora packager. In one case, a Fedora packager might
>> personally prefer the Apache License 2.0 over MIT, in another case the
>> opposite. This contradicts the tradition of passing down the choice to
>> the user.
> Ha, you start out with "stubbornly clinging" and that maybe not
> recording the dual license in the license tag helping simply things, but
> then after reading your points (1) through (5), I felt even more
> convinced of the value in recording/retaining such info!
>
> I must say - the scenario where someone makes the choices (point (3) by
> example) can be really annoying for downstream recipients or downstream
> of downstream. I have memories of doing source code audits and running
> into this and relying on some form of "tribal knowledge" that there was
> a choice upstream that had gotten removed and then going upstream to
> find it, so the choice could be made "again". Fedora, as a free and open
> source software distro, need not make an explicit choice between two
> free and open source licenses (in the way a commercial software
> distribution might), so the policy of passing along the original choice
> makes sense to me as a matter of convenience (for downstream recipients)
> and in keeping with the principles of Fedora being free and open more
> generally.
>>> Adding the full "Apache-2.0 OR MIT" choice from the first project
>>> seems to be pointless, since it actually cannot result in a choice of
>>> license - because that choice is already forced by the "MIT"-only
>>> second project. Please correct me if this analysis is wrong.
> sort of, but given the above points, I don't think it hurts to capture
> "(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as
to
> what is going on.
>> I understand this point but the idea that the choice is forced seems
>> to be a form of "effective license" analysis. I am not dismissive of
>> the idea since I think there is something fundamentally unclear about
>> what composite licensing means. However, the general problems with
>> effective license analysis apply to this case too.
>>
>> Richard
>> _______________________________________________
>> packaging mailing list --packaging(a)lists.fedoraproject.org
>> To unsubscribe send an email topackaging-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.fe...
>> Do not reply to spam on the list, report
it:https://pagure.io/fedora-infrastructure
11:33 a.m.
On 6/6/22 3:13 PM, Richard Fontana wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi>
wrote:
> As a maintainer of modest amount of packages and occassional new package
> reviewer,
> the issues I have with the current licensing policy as linked above are:
>
> 1. The "effective license" thing that is already discussed in another
> thread does not appear in the policy at all, and it does not appear in
> Fedora Licensing page, either. The only places that mention it that I
> have discovered are Licensing:FAQ [1] and random discussions at mailing
> lists and so on. This makes it quite difficult to understand if
> "effective licensing" is actually part of the policy or not. It would be
> easier to understand its status if it was covered in the policy itself.
> The policy itself should be unambiguous and possible to interpret
> without reference to any FAQ. A FAQ should not introduce new
> requirements and exceptions.
That part of the FAQ will have to be revisited, if the approach I
suggested today is adopted (a good example of why it isn't exactly
maintaining the existing policy). Basically, the "simple enumeration"
approach would mean that there is no such thing as "effective
licensing".
If people think that "effective licensing" is something that is so
valuable that it is worth the resulting unavoidable complexity of
analysis and inconsistency across packages, that view should be
voiced. I *can* imagine providing some more detailed rules about what
"effective licensing" means (and at an earlier stage I was actually
thinking of working on something like this). I basically gave up
because it's clear no one agrees on what effective licensing means,
which means it's not effective. :)
> 2. In general, it is confusing that the policy is split between
> Packaging Guidelines, Fedora Licensing main page and, apparently, also
> the FAQ. How can I determine if any given docs or wiki page is
> authorative? Would it be possible to consolidate everything that is
> authorative to a single page and declare it such?
Good idea.
Absolutely. We are thinking that the end result here would be the
packaging guidelines[1] where the policy is stated in one sentence
followed by, "When in doubt, ask." would instead say something like,
"For more information, see LINK" - where the link would go to ONE (new)
page in the Fedora-legal docs further explaining the policy and
providing examples. This would include anything helpful or revised from
the original wiki FAQ page as applicable. The idea being that we don't
want to clutter up the packaging guidelines page with policy details,
examples etc.
And yes, the existing examples on the packaging guidelines page will
also be reviewed in light of this and updated as needed.
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
> 3. Specifically related to the effective licensing question, MIT and BSD
> basically *only* ask to include the license text when shipping binaries.
> The effective licensing thing then erases those licenses, if there is
> GPL somewhere in the mix. The cognitive dissonance between wanting to
> honor upstream licenses and not shipping them due to effective licensing
> is serious. Since MIT and BSD are very common licenses, and code under
> them is also very commonly found embedded in otherwise GPL projects, I
> would like the licensing policy explicitly cover this situation and
> explain why it is allowed to not ship the MIT/BSD license in this case.
> (Perhaps, it would be good to revisit the part of the policy that
> discussed shipping license texts and consider, why is that required: It
> is in order to honor upstream licenses, or for some other reason, like
> end user convenience?)
All the licenses are shipped in that they are found in the SRPM.
Implicitly, Fedora's position is that this is compliant with those
permissive licenses. I think the issue you're raising is Fedora's
policy on what license texts to install in /usr/share/licenses. I
don't think that issue is directly tied to how the License: field is
populated. I couldn't immediately find any documentation on the
/usr/share/licenses policy, but my intuition from looking at lots of
Fedora and RHEL packages is that this contains any license text that
seems to be "global" in some way, and in cases where there is no
obvious such license, some appropriate license is selected from the
source files for this purpose. We might want to separately revisit the
/usr/share/licenses policy at some point if there is interest.
Richard
> [1]: https://fedoraproject.org/wiki/Licensing:FAQ
> _______________________________________________
> 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
--
12:30 a.m.
Richard Fontana kirjoitti 7.6.2022 klo 0.13:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi>
wrote:
> 3. Specifically related to the effective licensing question, MIT and BSD
> basically *only* ask to include the license text when shipping binaries.
> The effective licensing thing then erases those licenses, if there is
> GPL somewhere in the mix. The cognitive dissonance between wanting to
> honor upstream licenses and not shipping them due to effective licensing
> is serious. Since MIT and BSD are very common licenses, and code under
> them is also very commonly found embedded in otherwise GPL projects, I
> would like the licensing policy explicitly cover this situation and
> explain why it is allowed to not ship the MIT/BSD license in this case.
> (Perhaps, it would be good to revisit the part of the policy that
> discussed shipping license texts and consider, why is that required: It
> is in order to honor upstream licenses, or for some other reason, like
> end user convenience?)
All the licenses are shipped in that they are found in the SRPM.
Implicitly, Fedora's position is that this is compliant with those
permissive licenses. I think the issue you're raising is Fedora's
policy on what license texts to install in /usr/share/licenses. I
don't think that issue is directly tied to how the License: field is
populated. I couldn't immediately find any documentation on the
/usr/share/licenses policy, but my intuition from looking at lots of
Fedora and RHEL packages is that this contains any license text that
seems to be "global" in some way, and in cases where there is no
obvious such license, some appropriate license is selected from the
source files for this purpose. We might want to separately revisit the
/usr/share/licenses policy at some point if there is interest.
Yes, I was talking about installed license texts.
I brought it up because it is part of the Licensing Guidelines,
in section License Text [1].
If the purpose of the current effort is just to upgrade the License
identifiers,
then it is out of scope as you say.
Anyhow, the License Text section seems to imply that the only allowed
method of shipping the license
is to install it as part of the binary package:
"
However, in situations where upstream is unresponsive, unable, or
unwilling to provide proper full license text as part of the source
code, and the indicated license requires that the full license text be
included, Fedora Packagers must either:
* Include a copy of what they believe the license text is intended to
be, as part of the Fedora package in %license, in order to remain in
compliance.
* Choose not to package that software for Fedora.
"
Adding the missing license as a new Source: would push it to srpm,
but would violate the above rule, which is written as a MUST.
[1]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
2:33 p.m.
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
3:19 p.m.
I personally favor the suggestion to move to a more mechanical construction of license
expressions. While I appreciate the convenience of simple license expressions, I think
that, with so many possible combinations of source licenses, usefully and reliably
combining licenses under the “effective license” theory has required too much undocumented
knowledge and/or amateur legal analysis.
I am curious whether or not this would be accompanied by any changes to the requirements
for documenting the license breakdown in multiple licensing scenarios[1].
– Ben Beasley
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
On Mon, Jun 6, 2022, at 3:33 PM, Richard Fontana wrote:
> 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
> _______________________________________________
> 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:47 a.m.
On 6/06/2022 21:33, Richard Fontana wrote:
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.
As a relatively new packager, the
License: field has always been a bit
confusing to me (it doesn't help that many projects don't include the
license files of libraries...). I liked the effective license approach
(although it's confusing and not easy to compute) because otherwise the
license field would look like a confusing mess for some packages. For
example moolticute [0], with the new approach (please correct me if I'm
wrong) the license field would be: "License: GPLv3+ and GPLv3 and MIT
and BSD and CC-BY". This isn't representative of the license of the
Moolticute project (which is GPLv3+).
I think the policy depends on what the goal of the license field is. I
didn't exactly know what the goal was to be honest, but Neal described
it earlier as:
The point of the License tag in Fedora is to provide good guidance
on
leveraging the software.
I'm not sure that listing all licenses that end up in
the binary rpm
accomplished this goal. But I agree that the current situation isn't
ideal, and I'm not sure what the best solution is.
[0]:
https://src.fedoraproject.org/rpms/moolticute/blob/rawhide/f/moolticute.s...
--
Arthur Bols
fas/irc: principis
2:19 a.m.
V Thu, Jun 09, 2022 at 06:47:58PM +0200, Arthur Bols napsal(a):
As a relatively new packager, the License: field has always been a
bit
confusing to me (it doesn't help that many projects don't include the
license files of libraries...). I liked the effective license approach
(although it's confusing and not easy to compute) because otherwise the
license field would look like a confusing mess for some packages. For
example moolticute [0],
From the spec file:
# The entire source code is GPLv3+ except:
# src/AnsiEscapeCodeHandler.[cpp|h] which is GPLv3,
# src/QtAwesome/QtAwesome/ src/http-parser/ and src/qtcsv which are MIT,
# src/QtAwesome/QtAwesome/fonts/ which is CC-BY,
# src/CyoEncode/ src/SimpleCrypt/ and src/zxcvbn-c/ which are BSD.
with the new approach (please correct me if I'm
wrong) the license field would be: "License: GPLv3+ and GPLv3 and MIT and
BSD and CC-BY". This isn't representative of the license of the Moolticute
project (which is GPLv3+).
Maybe it's not what Moolticute project claims, but it's correct. If
Moolticute
project bundles the font which is not GPLv3+, but CC-BY, and does not say so,
then the project's claim is incorrect.
CC-BY has distinct requirements from GPLv3+. E.g. it requires you to carry
a copy of the CC-BY license text, or
<https://creativecommons.org/licenses/by/4.0/legalcode> URI. If you don't do
so, you violate CC-BY.
Now to the License tag of the binary RPM package: /usr/bin/moolticute contains
a copy of src/QtAwesome/QtAwesome/fonts/fontawesome-4.6.1.ttf (grep for
"DDhg-iW" string). Hence you need to list a license of that font file in the
License tag. RPM License tag is not about servility to upstream projects. It's
about providing accurate license data. You should not copy mistakes of the
upstream.
Now to the actual license of fontawesome-4.6.1.ttf. I briefely looked at it
and the only information about a license I found is this text with fontforge
tool on that file:
Fullname: FontAwesome Regular
License URL: http://fontawesome.io/license/
A text on that License URL web page is about "Font Awesome Pro" and the
license is not CC-BY. The same page also menitions a different product with
a different license called "Font Awesome Free"
<https://fontawesome.com/license/free> which claims SIL Open Font License 1.1
(OFL). But a git repository for that Free font
<https://github.com/FortAwesome/Font-Awesome> notes that version 4 is obsolete
and replaced with version 6. History of the git repository does not contain
version 4.
How did you come to a conclusion that the font is CC-BY? In my opinion it
could be OFL, if it were Font Awesome Free.
-- Petr
4:27 a.m.
On 10/06/2022 09:19, Petr Pisar wrote:
Maybe it's not what Moolticute project claims, but it's
correct. If Moolticute
project bundles the font which is not GPLv3+, but CC-BY, and does not say so,
then the project's claim is incorrect.
The license for QtAwesome is contained
in the repo, so it is mentioned.
Now to the License tag of the binary RPM package: /usr/bin/moolticute
contains
a copy of src/QtAwesome/QtAwesome/fonts/fontawesome-4.6.1.ttf (grep for
"DDhg-iW" string). Hence you need to list a license of that font file in the
License tag. RPM License tag is not about servility to upstream projects. It's
about providing accurate license data. You should not copy mistakes of the
upstream.
I don't think upstream is making a mistake (except when license files
for included libraries are missing). When someone creates a FOSS
project, they choose a license. They should check that all libraries are
compatible with that license, but I don't agree that it is a mistake
that there isn't a license breakdown in the repo. The license is
normally (and should be) mentioned at the top of the library files
themselves, or somewhere in the library directory.
How did you come to a conclusion that the font is CC-BY? In my
opinion it
could be OFL, if it were Font Awesome Free.
I guess due to licensecheck, but I
don't recall. The license should be
OFL as mentioned in the LICENSE file [0]. I'll correct the mistake next
release.
But I don't think this specific package and project is the topic of this
thread. It was given as an example to explain my point of view.
[0]:
https://github.com/mooltipass/moolticute/blob/master/src/QtAwesome/LICENS...
--
Arthur Bols
fas/irc: principis
6:20 a.m.
V Fri, Jun 10, 2022 at 11:27:27AM +0200, Arthur Bols napsal(a):
On 10/06/2022 09:19, Petr Pisar wrote:
> Maybe it's not what Moolticute project claims, but it's correct. If
Moolticute
> project bundles the font which is not GPLv3+, but CC-BY, and does not say so,
> then the project's claim is incorrect.
The license for QtAwesome is contained in the repo, so it is mentioned.
It's not in the tar ball which upstream distributes to Fedora.
> Now to the License tag of the binary RPM package:
/usr/bin/moolticute contains
> a copy of src/QtAwesome/QtAwesome/fonts/fontawesome-4.6.1.ttf (grep for
> "DDhg-iW" string). Hence you need to list a license of that font file in
the
> License tag. RPM License tag is not about servility to upstream projects. It's
> about providing accurate license data. You should not copy mistakes of the
> upstream.
I don't think upstream is making a mistake (except when license files for
included libraries are missing). When someone creates a FOSS project, they
choose a license. They should check that all libraries are compatible with
that license, but I don't agree that it is a mistake that there isn't a
license breakdown in the repo. The license is normally (and should be)
mentioned at the top of the library files themselves, or somewhere in the
library directory.
That's everything fine. (Although there are licenses which explicitly require
mentioning a license disclaimer in every piece of documentation.) But this not
case of v0.55.0.tar.gz. It does not contain a word about a license of the font.
A recipient of the tar ball gets a wrong impression that GPLv3 agreement is
the only set of requirement he needs to fulfill. And that's not true. He also
needs to fullfill requirements of the the license of the font.
> How did you come to a conclusion that the font is CC-BY? In my
opinion it
> could be OFL, if it were Font Awesome Free.
I guess due to licensecheck, but I don't recall. The license should be OFL
as mentioned in the LICENSE file [0]. I'll correct the mistake next release.
But I don't think this specific package and project is the topic of this
thread. It was given as an example to explain my point of view.
[0]:
https://github.com/mooltipass/moolticute/blob/master/src/QtAwesome/LICENS...
Why isn't this LICENSE.md file in the tar ball, or Fedora dist-git? You
should
add it there as well as a copy of OFL. OFL has very similar requirment as
CC-BY:
2) Original or Modified Versions of the Font Software may be bundled,
redistributed and/or sold with any software, provided that each copy
contains the above copyright notice and this license. These can be
included either as stand-alone text files, human-readable headers or
in the appropriate machine-readable metadata fields within text or
binary files as long as those fields can be easily viewed by the user.
This specific package is very relevant to this thread: It demonstrates the
very same problem. Upstream thinks that not putting a license text into the
tar ball is fine. And you think that not declaring the missing license in
License tag is fine. And you argue with effective licensing.
But that's not how licensing works. If you have a file whose license requires
forwarding the license text (like OFL), then simply each participant in the
chain of distribution must do it. And a fact that the license is "compatible"
with GPLv3 has no effect on it. Technically it isn't compatible. GPLv3 does
not mandate carrying OFL text. Hence once you combine GPLv3 and OFL code, you
need to forward OFL text forever. An idea that a license overlays another one
is not generally true. It always depends on the specific license.
And that's the community effective licensing cult Mr. Fontana discourages and
instead recommends listing all the licenses in the RPM tag. Because people
does not understand it make does the effective simplification incorrectly.
-- Petr
7:51 a.m.
On 10/06/2022 13:20, Petr Pisar wrote:
That's everything fine. (Although there are licenses which
explicitly require
mentioning a license disclaimer in every piece of documentation.) But this not
case of v0.55.0.tar.gz. It does not contain a word about a license of the font.
The
src/QtAwesome/LICENSE.md is contained in the v0.55.0.tar.gz which
explicitly states:
The Font Awesome font is licensed under the SIL Open Font License
The OFL license itself is missing though, I will ask upstream to include
it.
Why isn't this LICENSE.md file in the tar ball, or Fedora
dist-git? You should
add it there as well as a copy of OFL. OFL has very similar requirment as
CC-BY:
2) Original or Modified Versions of the Font Software may be bundled,
redistributed and/or sold with any software, provided that each copy
contains the above copyright notice and this license. These can be
included either as stand-alone text files, human-readable headers or
in the appropriate machine-readable metadata fields within text or
binary files as long as those fields can be easily viewed by the user.
Since
we're expanding on this specific package (the license
documentation should be substantially improved in this regard), how
would you deal with the "the above copyright notice" issue? In the
Moolticute project, there are multiple libraries with different licenses
and different copyright notices. Most licenses state that the copyright
notice must be included. For example, src/CyoEncode and src/SimpleCrypt
are both BSD (to be completely accurate: the former is 2-clause, the
latter 3-clause), but they have different copyright notices. The license
is included in the source itself, so upstream is correct. How should
packagers deal with this? Do they have to extract the license from every
file and call them for example "LICENSE.CyoEncode" and
"LICENSE.SimpleCrypt" and include those in dist-git?
This specific package is very relevant to this thread: It
demonstrates the
very same problem. Upstream thinks that not putting a license text into the
tar ball is fine. And you think that not declaring the missing license in
License tag is fine. And you argue with effective licensing.
Let me be clear, I
agree that licenses are important and they should be
included in the rpm. I viewed the license field as something different,
which is why I preferred the "effective" license. New packagers have a
very steep learning curve. It doesn't help that licensing is a
complicated and sensitive matter. The current documentation just isn't
clear enough (at least for me) on how to deal with it. That the licenses
aren't included is a mistake on my part as this was my first package. I
am not arguing what is better or worse, since I feel like I don't have
enough experience, I'm trying get a better understanding of what and why.
And that's the community effective licensing cult Mr. Fontana
discourages and
instead recommends listing all the licenses in the RPM tag. Because people
does not understand it make does the effective simplification incorrectly.
I
understand where you're coming from, but calling it a cult is not
necessary.
--
Arthur Bols
fas/irc: principis
9:08 a.m.
V Fri, Jun 10, 2022 at 02:51:03PM +0200, Arthur Bols napsal(a):
On 10/06/2022 13:20, Petr Pisar wrote:
> That's everything fine. (Although there are licenses which explicitly require
> mentioning a license disclaimer in every piece of documentation.) But this not
> case of v0.55.0.tar.gz. It does not contain a word about a license of the font.
The src/QtAwesome/LICENSE.md is contained in the v0.55.0.tar.gz which
explicitly states:
The Font Awesome font is licensed under the SIL Open Font License
I see. I overlooked this file. I saw only the top-level ./LICENSE. I'm
sorry.
The OFL license itself is missing though, I will ask upstream to
include it.
> Why isn't this LICENSE.md file in the tar ball, or Fedora dist-git? You should
> add it there as well as a copy of OFL. OFL has very similar requirment as
> CC-BY:
>
> 2) Original or Modified Versions of the Font Software may be bundled,
> redistributed and/or sold with any software, provided that each copy
> contains the above copyright notice and this license. These can be
> included either as stand-alone text files, human-readable headers or
> in the appropriate machine-readable metadata fields within text or
> binary files as long as those fields can be easily viewed by the user.
Since we're expanding on this specific package (the license documentation
should be substantially improved in this regard), how would you deal with
the "the above copyright notice" issue? In the Moolticute project, there are
multiple libraries with different licenses and different copyright notices.
Most licenses state that the copyright notice must be included. For example,
src/CyoEncode and src/SimpleCrypt are both BSD (to be completely accurate:
the former is 2-clause, the latter 3-clause), but they have different
copyright notices. The license is included in the source itself, so upstream
is correct. How should packagers deal with this? Do they have to extract the
license from every file and call them for example "LICENSE.CyoEncode" and
"LICENSE.SimpleCrypt" and include those in dist-git?
Basically yes. You are on the right track. If a license requires for binary
distributions to deliver the texts, then the packager needs to extract them
(they are often called license declarations or license headers or copyright
disclaimers) and store them into the binary RPM package using %license macro.
You can do it manually and save them into dist-git, or you can use some kind
of sed script in the spec file to collect all lines from " * Copyright (c)" to
" * OF THIS SOFTWARE" lines. You can deduplicate identical pieces if you want.
Of course the scripted method is prone to aging and it should be verified from
time to time that it still works. Here very helps if upstream keeps the
license declarations identical. Then the packager only needs to copy one,
usually the top-level LICENSE file. If you have an Android phone, go to
settings and somewhere deep there is a very long web page with all these
license declarations.
Of course there are people who claim that it's tedious and too demanding and
a user can download and unpack source RPM if he wants to see the license. But
I believe the license intention is to have the texts available next to the
binaries.
Therefore GPL recommends programmers to have a feature in their code to show
the license declaration. This alleviates packager's life.
For the very same reason I'm not fond of writing license declarations into
each source file. I prefer keeping only a single instance in LICENSE or
README file.
> This specific package is very relevant to this thread: It
demonstrates the
> very same problem. Upstream thinks that not putting a license text into the
> tar ball is fine. And you think that not declaring the missing license in
> License tag is fine. And you argue with effective licensing.
Let me be clear, I agree that licenses are important and they should be
included in the rpm. I viewed the license field as something different,
which is why I preferred the "effective" license. New packagers have a very
steep learning curve. It doesn't help that licensing is a complicated and
sensitive matter. The current documentation just isn't clear enough (at
least for me) on how to deal with it. That the licenses aren't included is a
mistake on my part as this was my first package. I am not arguing what is
better or worse, since I feel like I don't have enough experience, I'm
trying get a better understanding of what and why.
No problem. I agree that the Fedora guidelines are not exact enough regarding
to packaging the licenses. At the beginning of my packaging experience I also
preferred the effective approach. But after years of contact with various
licenses, I changed my mind. Keeping a spirit of a license is off doubts.
But why a part of a license specifying what I can do with the code should be
more important than another part of the license specifying what I have to do
with the license text? If they are equal, then the effective simplification
should not overlook the other aspect. And thus should be equally good reason
why to keep the license listed in the License tag.
On the other hand, I understand that the overlong, complicated License tag
is not much appeling to the users and that it is laborious for packages.
That's probably the reason why the guidelines keep a silent status quo.
At the end the License tag is nothing the licenses require us to maintain.
It's just an additional value Fedora provides its users.
-- Petr
12:08 p.m.
On Fri, Jun 10, 2022 at 04:08:08PM +0200, Petr Pisar wrote:
At the end the License tag is nothing the licenses require us to
maintain.
It's just an additional value Fedora provides its users.
This is an excellent way to look at the question. We should do what provides
the most value -- while being reasonable for packagers as well.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
438
days inactive
489
days old
packaging@lists.fedoraproject.org
35 comments
11 participants
participants (11)
-
Arthur Bols -
Ben Beasley -
Fabio Valentini -
Jason Tibbitts -
Jilayne Lovejoy -
Matthew Miller -
Neal Gompa -
Otto Urpelainen -
Panu Matilainen -
Petr Pisar -
Richard Fontana