On 6/9/22 4:27 PM, Neal Gompa wrote:
On Thu, Jun 9, 2022 at 6:01 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> wrote:
On 6/8/22 12:23 PM, Neal Gompa wrote:
On Wed, Jun 8, 2022 at 2:09 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> wrote:
` If the license is not on the SPDX License List, then submit the license to the to the SPDX-legal team at https://tools.spdx.org/app/submit_new_license/. In addition to the required information, include a note that it is under review for Fedora and a link to the related Fedora License Data Gitlab issue.
Shouldn't this step depend on the license actually being approved by
Fedora first? I guess that's more of an SPDX question than a Fedora
question. Do you want people to be submitting licenses to SPDX even if
the end result might be that Fedora classifies it as "not allowed"? Of
course the license might still meet SPDX's inclusion guidelines.
It should be approved by Fedora with a provisional identifier, and
that identifier should be forwarded to SPDX. We don't want to have
Fedora wait on SPDX.
I already responded to Richard's comment above as to why not wait on
this step, but to add to that and in light of Neal's comment about the
identifier - while "waiting on SPDX" is not ideal, we also don't want to
jump to fast to using a provisional identifier, as it's on the SPDX
legal team to ensure that identifier is not already used by another
license - pretty important aspect for all involved.
If we're already using SPDX identifiers for the basis of our license
identifier list, this problem isn't going to happen.
well, no, this could happen if Fedora reviewed a new license, not on
SPDX License List and waited to submit it to SPDX License List, started
using a proposed identifier in the package spec file, and then SPDX
determined, 'oh, can't use that identifier, as it's already used' - this
may be unlikely, but still something I think we want to prevent.
It already
doesn't happen today even with our distinctly different identifier
systems. So I consider this optimization worth implementing, because
SPDX legal is inherently not bound to Fedora and I don't want to add
more drag to our already very slow FE-Legal process.
I'm not sure what you meant by SPDX legal is inherently not bound to
Fedora but let me add some key things for people to understand here who
may not be familiar with SPDX License List inclusion principles:
- if Fedora or even Debian have already concluded that a license meets
their free/open guidelines and that license is used for software
included in a major Linux distribution - this is pretty much a shoe-in
for inclusion on the SPDX License List. In other words, this make the
decision-making part easy for the SPDX legal team.
(for those on this list who are not already aware - I have been a
maintainer of the SPDX License List since its inception)
For insight as to how the process works over at SPDX - here is an
example of a (Fedora) license I submitted the other day:
https://github.com/spdx/license-list-XML/issues/1522
I'm aware of the process (now) after observing it for openSUSE to get
FDK-AAC added, but I've also observed that the process is pretty slow
with other licenses submitted over the past few months.
obviously, I am acutely aware of the potential for slowness and the
myriad of reasons for that, not all of which are within the control of
the SPDX legal team. Nor can I single-handedly guarantee that all
submissions by Fedora will move lightning fast. However, I can report
that the SPDX legal team is aware of the work going on over here at
Fedora and supportive of it. SPDX legal is also aware that 1) moving
quickly on these types of requests, especially when there is a new
package review tied to the license review, is key and that 2) as a
result of license review of old packages and the "category" license ids
that Fedora has used may result in a bunch of new license submissions.
The general view there is that if that means improving processes, then
great - we'll do that. Just like any open source community when faced
with a new challenge.
Anyway, there's more I could explain there, but this isn't really the
right place and if anyone is really interested, I'd encourage people to
join the SPDX legal team mailing list. In the meantime, I'm trying to
effectively participate in both communities while also standing in the
middle with my arms outstretched to make sure things get pulled together
when need be. :D
One reason I actually prefer our existing system is that we are able
to be responsive once *we've* decided we're good with it. Our
transition to SPDX-style identifiers should not cause us to lose this
advantage. Notably, even Debian has so far refused to transition to
SPDX identifiers and only merely made their existing DEP-5 identifiers
"SPDX-like"[1]. They maintain their own identifier base, it just
happens to be SPDX-ish.
Debian is another story as their quasi-adoption was back when the SPDX
License List was a mere babe.
From my perspective, this is the approach I want Fedora to have. Our
agency is important because *we're* considered a Linux world licensing
authority, just like Debian is. If Fedora and Debian disagree (which
happens sometimes), then both opinions are used by third parties to
make informed decisions.
One of the worst things openSUSE did was blindly drop their agency
around license policy. It was chaos and I refuse to allow that to
happen again.
I can't speak to the details of that situation, but I'm sorry for the
scars it has left you with!
J.
[1]: https://wiki.debian.org/Proposals/CopyrightFormat
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
