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>
> >> 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
"The License: field refers to the licenses of the contents of the binary rpm. When in
> >> 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
> >> 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.