3:48 p.m.
On Fri, Feb 17, 2023 at 3:07 PM Mark Wielaard <mark(a)klomp.org> wrote:
Hi,
On Fri, Feb 17, 2023 at 12:54:58PM -0500, Richard Fontana wrote:
> On Fri, Feb 17, 2023 at 12:49 PM Richard Fontana <rfontana(a)redhat.com>
> wrote:
> We have unambiguously rejected the
> concept of the effective license, except possibly in some extreme
> scenarios. For this reason alone, it is possible that most Fedora package
> license tags are inaccurate even if you assume that the relevant
> identifiers are truly synonymous, which they aren't.
>
> I am not sure how we will act upon the hope for further auditing, but maybe
> better documentation could help result in more accurate (or
> guidelines-conformant) license tags over a long period of time.
Sorry for not really having followed this discussion earlier. But I
think not having an "effective license" is a bit of a problem for
packagers of (larger) GPL packages. At least in my experience with
such projects, e.g. valgrind for which I am both the packager and part
of upstream.
As far as I can tell most such projects follow guidelines like
https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
So they might incorporate works covered by GPL compatible
lax-permissive licenses, but (effectively) distribute the whole under
the GPL. Although the original licenses and snippets of code are there
in the code it is not really possible to extract and redistribute/use
those snippets under their original licenses. Unless they are
explicitly put into separate unmodified files. Because they are mixed
with and treated as normal GPL code in the project.
If there is a reference to the original code and version that was
incorporated then you could maybe look at that and reuse that under
the original declared license. But I think it is somewhat pointless to
list all such code snippets separately under their original license
terms. For all intends and purposes those snippets of code are really
(re)distributed under the GPL now by the project incorporating them.
What is the goal of dropping the effective license and make packagers
list all the licences of some code snippets originally incorporated
under lax-permissive licenses? Is that not just make work for the
packager if upsteam just uses one effective license?
One rationale is given in Fedora legal documentation:
"There is no agreed-upon set of criteria or rules under which one can
make conclusions about “effective” licenses or reduce composite
license expressions to something simpler."
Basically, everyone has been making up their own interpretive system
for deciding what an "effective license" is, with no consistencies
across upstream packages and Fedora package maintainers. Given that
situation, we are aiming for a more objective and administratively
easier standard for downstream package license metadata: a simple
enumeration of the licenses covering any code or content in the
installed RPM. Administratively easier because the package maintainer
doesn't have to construct some theory of effective licensing and
figure out how it applies to their package (possibly agreeing or
disagreeing with whatever theory of effective licensing the upstream
project has implicitly or explicitly developed, in subtle ways), or
apply some implicitly-formulated upstream theory which might not
actually make any sense; they just list the licenses they find in
relevant source files.
Also, I don't think "snippets" are the typical case. Often the non-GPL
license will appear to cover a whole file or perhaps a set of multiple
files. I have found it somewhat common for a Fedora package to include
multiple "merely aggregated" works which may be under the GPL and
other licenses. That's mere aggregation based on the license steward's
traditional guidance on interpretation of the GPL. In those scenarios
attempts to apply an effective license theory that ignores the non-GPL
license seem to embody a misunderstanding of the orthodox
interpretation of the GPL.
When you say "upstream just uses one effective license", unfortunately
it is rarely so clear even if you set aside the basic lack of clarity
on what an effective license even is.
The goal of the policy is not to promote reusability of isolated
source code elements under particular associated licenses. Rather, as
I see it, license metadata is fundamentally unnecessary, but if we are
going to have license metadata at all, and for better or worse I think
there is an expectation that we must, it might as well strive for
accuracy and consistency with metadata across all packages.
Richard