Re: License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler
Hi,
On 7/9/21 6:56 PM, Ben Beasley wrote:
Hans,
Thanks for noticing, and for your very reasonable question.
In all of these cases, the CC0 component was due to the AppData XML file for a desktop
application. (In libinstpatch, the Public Domain component was due to md5-plumb “copylib”
source files that are linked into the library.)
I’ve retained the pre-existing detailed comments in the spec files, so there is still
some record of per-file licensing for the curious.
-----
Your interpretation of preserving separate license terms in the License field when they
apply to separate installed files seems to be supported by
https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple...,
at least in the case of separate compiled binaries. However, there was a big discussion
about effective licensing on the fedora-devel list a month or two ago (and, a little
earlier, a question on fedora-legal) specifically concerning CC0-licensed AppData XML
files.
I recall that all parties who spoke up felt it was correct to form an effective license
that did not mention CC0 in this case. As far as I know, everyone understood that the
AppData is installed as a separate XML file asset and not linked into the code. Some
seemed to feel that leaving CC0 in the License field rather than forming a simpler
effective license is actually *wrong* and should not be allowed, an opinion I don’t share
but don’t care to debate.>
-----
I am hoping not to initiate a broader discussion of when it is and isn’t reasonable to
expect packagers to derive effective licenses. Suffice it to say that, in these specific
simple cases, I think the changes are clearly consistent with the community consensus,
such as it is, and with guidance from fedora-legal.
Not listing the CC0 in case when it is only used for the appdata xml file seems reasonable
to me. In this case the intent of the author of the file clearly was to give as broad a
license as possible (1), so I think that not listing it separately is fine for appdata xml
files (still not a lawyer, etc.).
1) arguably CC0 always indicates the author is trying to not claim any rights in so far
possible, but that is a separate discussion.
Regards,
Hans
On 7/9/21 10:07 AM, Hans de Goede wrote:
> Hi Benjamin,
>
> On 7/9/21 3:47 PM, Benjamin Beasley wrote:
>> I’ve updated several of my packages to use only the “effective license” in their
License fields, in cases where it was very clear that a single effective license was
correct. The following packages are affected:
>>
>> - agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
>> - appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
>> - gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
>> - harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
>> - libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
>> - notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
>> - sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
>
> In general this is the right thing to do, thank you for simplifying
> the License field for these packages.
>
> One remark about this tough, I wonder what files the CC0 licenses
> were for ?
>
> Sometimes acceptable CC licenses (typically other ones then CC0)
> are used for assets, like icons / artwork / docs.
>
> In that case, since those assets are not linked into a resulting
> binary the assets stay under the CC license (AFAIK, IANAL, etc.).
>
> So if that is the case for any of the above packages then the new
> License field should still include the "and CC0", with the binaries
> being under the GPL variant and the assets being under CC0.
>
> This is typically documented with a comment in the .spec above the
> License field explaining things.
>
> Regards,
>
> Hans
>
>
>
>
>
>
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
>>
>