On Fri, Feb 17, 2023 at 3:07 PM Mark Wielaard <mark@xxxxxxxxx> 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@xxxxxxxxxx> > > 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 _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
