Re: License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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_licensing_situations.3F, 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@xxxxxxxxxxxxxxxxxxxxxxx
>>> To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
>>> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>>>
>>
> 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux