Dne 25. 03. 24 v 15:18 Vít Ondruch napsal(a):
Dne 25. 03. 24 v 14:26 Richard Fontana napsal(a):
> On Fri, Mar 22, 2024 at 9:40 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>>
>> Dne 25. 05. 22 v 8:45 Panu Matilainen napsal(a):
>>> On 5/23/22 19:44, Neal Gompa wrote:
>>>> On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy
>>>> <jlovejoy(a)redhat.com> wrote:
>>>>> 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 described at
>>>>>
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
>>>>>
>>>>> ) states, "The License: field refers to the licenses of the
contents
>>>>> of the binary rpm. When in doubt, ask."
>>>>>
>>>>> 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
>>>>> helpful?
>>>>>
>>>>> 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. This is particularly kludgy
>>>> when you have vendored or bundled code.
>>> I seem to have a dim recollection of ability to define source license
>>> separately being requested at some point years ago, but it never went
>>> anywhere, for whatever reason.
>>>
>>> ...
>>>
>>> After rummaging through some dusty archives, turns that discussion
>>> took place between Spot and myself in August 2007. No wonder the
>>> recollection was dim. I guess there was never any ticket/bug filed on
>>> it and the email simply got slowly buried in the sediment.
>>>
>>> Feel free to open a ticket at
>>>
https://github.com/rpm-software-management/rpm/ if this is something
>>> we should look into. Doesn't seem like rocket science to add an
>>> optional SourceLicense that would be used for the src.rpm license if
>>> present, or something like that.
>>>
>> Sorry for resurrecting old thread. But it was never referred here, that
>> after all. this was requested and implemented in RPM:
>>
>>
https://github.com/rpm-software-management/rpm/issues/2079
>>
>>
https://github.com/rpm-software-management/rpm/pull/2117
>>
>> therefore there is now `SourceLicense` tag supported by RPM 4.19+
>> available in F40+.
>>
>> And I wonder, should we update our license guidelines and start to use
>> the `SourceLicense` tag?
> There was an issue several months ago where this was brought up, IIRC.
> My thought was that use of `SourceLicense:` could be optional in
> addition to populating `License` but wouldn't be encouraged. But did
> you mean, should we actually deprecate use of `License` in favor of
> `SourceLicense` (with all that would imply: the `SourceLicense` tag
> would then consist of an enumeration of licenses covering the entirety
> of the source code)? That seems like it would be a pretty radical
> change, which is not to suggest that it's a bad idea.
My thinking is that we redistribute SRPM and therefore the
`SourceLicense:` would be ideal to cover the content of SRPM.
But since you also mentioned deprecating `License` field, it sounds
radical, but after all, it would probably make my life easier. I am
asking because currently, I am looking at:
https://github.com/ruby/ruby/blob/v3_3_0/missing/dtoa.c
Presumably, this code is used just sometimes on some platforms. Now
how am I supposed to know when it happens?
OTOH if we deprecated the `License` tag, then we could keep using it
in the `SourceLicense` meaning, right? We went full circle here :)
BTW this is also one of problems with license scanners. Looking at
scancode toolkit results for Ruby:
There are for example referenced `artistic-1.0 OR gpl-1.0-plus` /
`gpl-1.0-plus OR artistic-perl-1.0` license. At closer look, this is
where the licenses are coming:
and very likely, the win32 files are of no use on Linux. Therefore these
licenses are rightfully omitted from the `License` tag. But then, the
license scanner output won't ever match the license information captured
.spec file. We can never do the basic sanity check that "all licenses
reported by scanner are captured in .spec file".
IOW as long as we are trying to provide license of binaries, the results
of license scanners always require manual review, which makes them not
so convenient.
Vít