7:15 a.m.
Dne 18. 01. 24 v 14:09 Vít Ondruch napsal(a):
Dne 18. 01. 24 v 0:01 Richard Fontana napsal(a):
> On Wed, Jan 17, 2024 at 5:47 PM Mark Wielaard <mark(a)klomp.org> wrote:
>> Hi Richard,
>>
>> Going to chop this discssion into smaller parts.
>>
>> On Fri, Nov 24, 2023 at 08:07:02PM +0100, Mark Wielaard wrote:
>>> On Mon, 2023-09-18 at 20:47 -0400, Richard Fontana wrote:
>>>> I think anyone should be free to propose a new umbrella identifier
>>>> (in
>>>> SPDX expression format) that would cover multiple licenses, as
we've
>>>> done with `LicenseRef-Fedora-Public-Domain` and
>>>> `LicenseRef-Fedora-UltraPermissive`. The important thing is that
>>>> it be
>>>> well defined in some way.
>> One idea would be to just collect all licenses, copyrights and notices
>> as found in the actual sources and put them into one file put in the
>> srpm. Kind of like debian/copyright. The advantage is that you then
>> don't have to find some exact (or inexact) match with specific
>> identifiers and that it can be shared with upstream and/or other
>> distros. For the packager they can just put
>> LicenseRef-Fedora-SourceLicenses in the License field instead of
>> trying to come up with some expression that mimics the actual license
>> texts. For the users it is also easier to have the actual license
>> notices text all together in a known place/file.
> I would support this idea if we were starting from scratch. The
> problem is that Fedora (and Red Hat) have had this tradition of *not*
> doing that, and this tradition of (instead?) using the License: tag
> for RPMs, so a move to Debian copyright sort of system would be a
> much more radical change than, say, the switch from Callaway notation
> to SPDX license expressions. I expect it would meet massive resistance
> from Fedora package maintainers. I could be wrong though. :)
>
> A possible idea is to have this be an optional approach the package
> maintainer could take, more or less as you describe. I have thought of
> something like that. When I suggested something similar to this idea
> to my fellow Fedora Legal/SPDX Migration team members, I think their
> general sentiment was skeptical to negative.
It seems to me that SPDX on itself supports:
~~~
DocumentRef-"(idstring)"
~~~
https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
Therefore if we support SPDX and SPDX supports this, then we support
it, don't we?
Vít
BTW this is interesting discussion about license field not being
expressive enough:
https://github.com/puma/puma/issues/3311#issuecomment-1886065710
TLDR: "What I do not want is for someone to think BSD, MIT in the
license field applies to the entire Puma project, as that is not how
this project is licensed. We're talking about 50 lines of code in a
5000+ line library, giving the two equal billing in the licenses field
doesn't describe what's happening here."
And that is the context where I hit the DocumentRef
Vít
>
> Anyway, I don't think this idea should be dismissed, but it would be
> challenging to adopt. We should possibly admit to ourselves that the
> License: tag approach was always highly flawed and we've basically
> been putting bandaids on it.
>
> It should be noted that if we switched to this sort of approach it
> wouldn't mean abandoning the use of SPDX identifiers since we'd still
> use them for purposes of license approval and license classification,
> and conceivably also in the equivalent of the "copyright" file itself.
>
> If I remember correctly, someone on this list (Neal?) said they
> weren't overly fond of the dep5 format.
>
> Richard
> --
> _______________________________________________
> legal mailing list -- legal(a)lists.fedoraproject.org
> To unsubscribe send an email to legal-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/legal@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue