Hi all,
As you all know, we have a larger project of moving Fedora license data to a data format and repository, updating and improving Fedora-legal documentation related to licensing, and adoption of SPDX ids. In light of that, it is also relevant to look at the process for review of a new license for potential inclusion in Fedora.
I'd describe the past/current process as: - send email to this list, some discussion may ensue on list (with community members and Red Hat legal), decision made and then license is added to the applicable wiki table (good or bad) at https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing - Of course, up until somewhat recently, this entire workflow was shepherded by Tom Callaway
Now that we have the license data in a repository, it seems like we can use Issues and Merge Requests for the process flow, instead of relying on email. As such, I'd like to propose something along the following lines:
* **How to request review of a new license* If you find a license for a package you want to include in Fedora and that license is not listed in the Fedora License Data, you can submit it for review as follows:
Note: you must be a Fedora contributer and become part of the Fedora Gitlab group. See LINK for more on how to become a Fedora contributor.
1) Create a new issue in the Fedora License Data repo with the following information: license name, link to text of license, package name and link, why you want to include it in Fedora, whether it is on the SPDX License List, and the SPDX expression as applicable (see below for hints on determining if a license text matches a license on the SPDX License List)
2) All discussion related to the license review based on the license criteria will be on the Issue thread and a decision will be noted there. ` 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. The ultimate decision for licenses allowed or not-allowed for Fedora based upon the license criteria rests with Red Hat legal.
3) Once a decision has been made, the person who submitted the license for review creates a Merge Request for the license using the TOML file format.
4) Merge Requests will be reviewed and merged by the Fedora License Data repo maintainers.
Happy to hear your thoughts, feedback, and suggestions!
Thanks, Jilayne
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
How to request review of a new license If you find a license for a package you want to include in Fedora and that license is not listed in the Fedora License Data, you can submit it for review as follows:
Note: you must be a Fedora contributer and become part of the Fedora Gitlab group. See LINK for more on how to become a Fedora contributor.
I can sort of see why you'd want the submitter to be a Fedora contributor (I assume that means a Fedora account holder) but is it necessary to become part of the Fedora Gitlab group just to submit an issue?
- Create a new issue in the Fedora License Data repo with the following information: license name, link to text of license, package name and link, why you want to include it in Fedora, whether it is on the SPDX License List, and the SPDX expression as applicable (see below for hints on determining if a license text matches a license on the SPDX License List)
Is "why you want to include it in Fedora" necessary? If they are linking to a package, presumably that's either an existing Fedora package (i.e., the license *should* have been approved but never was, or was approved based on outdated criteria and methodology) or a proposed Fedora package. So the rationale for inclusion should always be obvious and not require any further justification.
` 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.
Richard
On Wed, Jun 8, 2022 at 2:09 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
How to request review of a new license If you find a license for a package you want to include in Fedora and that license is not listed in the Fedora License Data, you can submit it for review as follows:
Note: you must be a Fedora contributer and become part of the Fedora Gitlab group. See LINK for more on how to become a Fedora contributor.
I can sort of see why you'd want the submitter to be a Fedora contributor (I assume that means a Fedora account holder) but is it necessary to become part of the Fedora Gitlab group just to submit an issue?
You're forced to sign in with FAS when you interact with the gitlab.com/fedora group.
- Create a new issue in the Fedora License Data repo with the following information: license name, link to text of license, package name and link, why you want to include it in Fedora, whether it is on the SPDX License List, and the SPDX expression as applicable (see below for hints on determining if a license text matches a license on the SPDX License List)
Is "why you want to include it in Fedora" necessary? If they are linking to a package, presumably that's either an existing Fedora package (i.e., the license *should* have been approved but never was, or was approved based on outdated criteria and methodology) or a proposed Fedora package. So the rationale for inclusion should always be obvious and not require any further justification.
I agree, this is not necessary. Nobody would be making a request if it wasn't needed already.
` 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.
On 6/8/22 12:23 PM, Neal Gompa wrote:
On Wed, Jun 8, 2022 at 2:09 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com 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.
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
Jilayne
On Thu, Jun 9, 2022 at 6:01 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 6/8/22 12:23 PM, Neal Gompa wrote:
On Wed, Jun 8, 2022 at 2:09 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com 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. 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.
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.
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.
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.
[1]: https://wiki.debian.org/Proposals/CopyrightFormat
On 6/9/22 4:27 PM, Neal Gompa wrote:
On Thu, Jun 9, 2022 at 6:01 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 6/8/22 12:23 PM, Neal Gompa wrote:
On Wed, Jun 8, 2022 at 2:09 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com 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.
On Thu, Jun 9, 2022 at 7:06 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 6/9/22 4:27 PM, Neal Gompa wrote:
On Thu, Jun 9, 2022 at 6:01 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 6/8/22 12:23 PM, Neal Gompa wrote:
On Wed, Jun 8, 2022 at 2:09 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com 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.
The likelihood would be very low. We can already search if an existing identifier is present. If not, we can make our own and submit at the same time. We will use the new identifier as if it's approved, since SPDX will eventually approve it based on our usage anyway.
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)
If this is the case, then my proposal on process should be fine. SPDX's purpose is to document the world, Fedora's purpose is to create that world. My problem with us blocking on SPDX is that it punishes packagers for trying to ship new software by forcing them to wait on a group that doesn't really need to align to us if they don't want to.
Moreover, we wouldn't submit a request anyway if the license isn't good for Fedora anyway. So it doesn't make sense to submit to SPDX first, but instead for us to do the process ourselves, give an identifier, and then submit to SPDX to let them incorporate it eventually.
"Blocking on the SPDX-legal team" is the one aspect of this process that I am somewhat worried about, and I think it might be something unprecedented for Fedora, so it's important that people can get behind that as an experiment. Also I went back and looked at Jilayne's original email in this thread and I'm not sure that this was an obvious feature of the proposal. So it's important to understand: under this proposal, Fedora package submitters will have to wait for an external project to make a decision, for some unspecified amount of time, and I'm not even sure if we can say what that time period might be based on past experience because this relationship is going to be new for SPDX as well as for Fedora.
Probably worth keeping in mind, though, that new licenses in new packages are *probably* going to be a relatively uncommon event, assuming that we don't primarily use the new package process as the means of transitioning existing approved Callaway license symbols to SPDX-conformant identifiers.
I don't know how much delay Fedora packagers can tolerate or how fast SPDX-legal can be. I would assume this is something new for SPDX too -- the first time an external consumer of SPDX identifiers is dependent on SPDX-legal acting somewhat fast. I believe we talked (maybe this was on the spdx-legal list) about defining an SPDX-legal decision as being the merging of a pull request at github.com/spdx/license-list-XML, not on a formal release of a new license list by SPDX (which I think we can agree would be unacceptable for Fedora).
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
Richard
On Thu, Jun 9, 2022 at 7:34 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jun 9, 2022 at 7:06 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 6/9/22 4:27 PM, Neal Gompa wrote:
On Thu, Jun 9, 2022 at 6:01 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 6/8/22 12:23 PM, Neal Gompa wrote:
On Wed, Jun 8, 2022 at 2:09 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com 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.
The likelihood would be very low. We can already search if an existing identifier is present. If not, we can make our own and submit at the same time. We will use the new identifier as if it's approved, since SPDX will eventually approve it based on our usage anyway.
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)
If this is the case, then my proposal on process should be fine. SPDX's purpose is to document the world, Fedora's purpose is to create that world. My problem with us blocking on SPDX is that it punishes packagers for trying to ship new software by forcing them to wait on a group that doesn't really need to align to us if they don't want to.
Moreover, we wouldn't submit a request anyway if the license isn't good for Fedora anyway. So it doesn't make sense to submit to SPDX first, but instead for us to do the process ourselves, give an identifier, and then submit to SPDX to let them incorporate it eventually.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@redhat.com wrote:
"Blocking on the SPDX-legal team" is the one aspect of this process that I am somewhat worried about, and I think it might be something unprecedented for Fedora, so it's important that people can get behind that as an experiment. Also I went back and looked at Jilayne's original email in this thread and I'm not sure that this was an obvious feature of the proposal. So it's important to understand: under this proposal, Fedora package submitters will have to wait for an external project to make a decision, for some unspecified amount of time, and I'm not even sure if we can say what that time period might be based on past experience because this relationship is going to be new for SPDX as well as for Fedora.
Probably worth keeping in mind, though, that new licenses in new packages are *probably* going to be a relatively uncommon event, assuming that we don't primarily use the new package process as the means of transitioning existing approved Callaway license symbols to SPDX-conformant identifiers.
So, this is where I will disagree here, sadly. Transitioning from the Fedora/Callaway system (which allows license families to be given the same designator) to the SPDX system (which does not) means that we will have the sad duty of having to generate identifiers for licenses that don't deserve them.
Tom's system had one very important property that SPDX lacks: human coherence. SPDX is inherently verbose and forces specificity where none is necessary in practice, which means that even minute variations in licenses (and we all know that BSD and MIT variants are a dime a dozen) now need new identifiers.
I don't know how much delay Fedora packagers can tolerate or how fast SPDX-legal can be. I would assume this is something new for SPDX too -- the first time an external consumer of SPDX identifiers is dependent on SPDX-legal acting somewhat fast. I believe we talked (maybe this was on the spdx-legal list) about defining an SPDX-legal decision as being the merging of a pull request at github.com/spdx/license-list-XML, not on a formal release of a new license list by SPDX (which I think we can agree would be unacceptable for Fedora).
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
This problem is the principal reason why I don't think Debian will ever fully adopt SPDX identifiers in the same way openSUSE did, and why I don't think it'd be a good idea for us to do so either. We may be adopting SPDX-style identifiers, but we aren't going to rely on their data set for our systems. That's why David Cantrell is making a new one for us.
Clearly the wind is blowing for us to make life easier for lawyers and harder for packagers, but that doesn't mean I want to give up *too* much ground on that front.
And I've made it clear in the past and I'll reiterate again: LicenseRef-* identifiers should *not* be used except in the absolute worst circumstances.
Those tags indicate three things:
1. A lack of agency 2. A lack of coherence 3. A lack of agreement
Fedora, when identifying acceptable licenses, should not have those problems.
Hi all,
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@redhat.com wrote:
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
The Fedora Community has a good reputation for collaboration across communities. Given the close connection to the SPDX Legal team via Jilayne's role as a maintainer, I think it is worth giving it a go with a clear flag to the community as trialing a new process.
A contingency plan for when things don't go ideally is a way to build efficacy into the process. It is a reason why a contingency plan is included in the Fedora Change Proposal template. There should also be a scheduled window to retrospect on the process and identify what is working well and what is not. If this is submitted as a Fedora 37 Change, then perhaps targeting a retrospective in Fedora 39 or 40.
On Friday, June 10th, 2022 at 09:44, Vít Ondruch vondruch@redhat.com wrote:
Maybe I wonder (similarly to you) what would be purpose of this ML, if all discussion happens in some issue tracker.
Maybe for people like me who are plugged into too many issue trackers as it is. :-) Although a tag for #legal on discussion.fp.o could be nice… ;-)
On Friday, June 10th, 2022 at 10:33, Neal Gompa ngompa13@gmail.com wrote:
Tom's system had one very important property that SPDX lacks: human coherence. SPDX is inherently verbose and forces specificity where none is necessary in practice, which means that even minute variations in licenses (and we all know that BSD and MIT variants are a dime a dozen) now need new identifiers.
I understand this. It adds low-value labor to the packaging workflow for every package to require a perfectly accurate identifier. There is also significant labor in transitioning not only existing identifiers, but also habits of existing packagers to support this change.
But instead of identifiers, shouldn't this be solved at the level of process and software? I see a strong case for maintaining simplicity for packagers, but I also do not see a strong case against supporting SPDX identifiers in some capacity. These were two ideas I had, but I don't have a deep RPM development background to back them:
1. A subset of identifiers as "super identifiers" that support license families under commonly-understood terms. Packagers are encouraged to use more verbose identifiers, but super identifiers are also permitted. Super identifiers are understood to be intentionally unspecific as license families.
2. Creating a Fedora-specific license identifier that indicates a new license is acknowledged by Fedora Legal, but it does not have an assigned SPDX identifier or it is under review. For the purpose of identifiers, this could be a prefix like "FE-" combined with a super identifier (above) that represents a known license family. I think this supports packagers in getting quick answers for identifiers to use in packages, while enabling a Fedora Legal/SPDX Legal discussion to pan out. If/when a SPDX identifier is created for a new license, the Fedora-specific license identifier can be aliased to the new SPDX identifier.
I'm not sure how viable these ideas are in the RPM end of things, but I am pulling from my experience as a packager and also O.S. legal enthusiast in other places. I believe this approach better balances the scale of manual packager labor to using a common set of identifiers to aid in legal support for Fedora.
On Fri, Jun 10, 2022 at 3:52 PM Justin W. Flory (he/him) foss@jwf.io wrote:
Hi all,
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@redhat.com wrote:
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
The Fedora Community has a good reputation for collaboration across communities. Given the close connection to the SPDX Legal team via Jilayne's role as a maintainer, I think it is worth giving it a go with a clear flag to the community as trialing a new process.
A contingency plan for when things don't go ideally is a way to build efficacy into the process. It is a reason why a contingency plan is included in the Fedora Change Proposal template. There should also be a scheduled window to retrospect on the process and identify what is working well and what is not. If this is submitted as a Fedora 37 Change, then perhaps targeting a retrospective in Fedora 39 or 40.
On Friday, June 10th, 2022 at 09:44, Vít Ondruch vondruch@redhat.com wrote:
Maybe I wonder (similarly to you) what would be purpose of this ML, if all discussion happens in some issue tracker.
Maybe for people like me who are plugged into too many issue trackers as it is. :-) Although a tag for #legal on discussion.fp.o could be nice… ;-)
On Friday, June 10th, 2022 at 10:33, Neal Gompa ngompa13@gmail.com wrote:
Tom's system had one very important property that SPDX lacks: human coherence. SPDX is inherently verbose and forces specificity where none is necessary in practice, which means that even minute variations in licenses (and we all know that BSD and MIT variants are a dime a dozen) now need new identifiers.
I understand this. It adds low-value labor to the packaging workflow for every package to require a perfectly accurate identifier. There is also significant labor in transitioning not only existing identifiers, but also habits of existing packagers to support this change.
But instead of identifiers, shouldn't this be solved at the level of process and software? I see a strong case for maintaining simplicity for packagers, but I also do not see a strong case against supporting SPDX identifiers in some capacity. These were two ideas I had, but I don't have a deep RPM development background to back them:
A subset of identifiers as "super identifiers" that support license families under commonly-understood terms. Packagers are encouraged to use more verbose identifiers, but super identifiers are also permitted. Super identifiers are understood to be intentionally unspecific as license families.
Creating a Fedora-specific license identifier that indicates a new license is acknowledged by Fedora Legal, but it does not have an assigned SPDX identifier or it is under review. For the purpose of identifiers, this could be a prefix like "FE-" combined with a super identifier (above) that represents a known license family. I think this supports packagers in getting quick answers for identifiers to use in packages, while enabling a Fedora Legal/SPDX Legal discussion to pan out. If/when a SPDX identifier is created for a new license, the Fedora-specific license identifier can be aliased to the new SPDX identifier.
I'm not sure how viable these ideas are in the RPM end of things, but I am pulling from my experience as a packager and also O.S. legal enthusiast in other places. I believe this approach better balances the scale of manual packager labor to using a common set of identifiers to aid in legal support for Fedora.
In my ideal world, we would not explicitly "switch to SPDX", but instead replace 1:1 identifiers with SPDX ones. We'd keep our license math and conventions, but identifiers would be remapped where it made sense. The more specific SPDX identifiers for various MIT and BSD variants would be acceptable, but not required.
SPDX would essentially be an advisor for us, rather than a dependency. That's what Debian did, more or less.
As for "FE-", I'd rather not make that prefix exist more than it already has to. We also don't need it, since we would have our own license list, with identifiers and the will-it-blend(tm) chart. Again, the only reason to do weird prefixes is if we needed to maintain coherence across multiple indexes. We don't, so that's not an issue.
On Fri, Jun 10, 2022 at 04:32:10PM -0400, Neal Gompa wrote:
On Fri, Jun 10, 2022 at 3:52 PM Justin W. Flory (he/him) foss@jwf.io wrote:
Hi all,
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@redhat.com wrote:
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
The Fedora Community has a good reputation for collaboration across communities. Given the close connection to the SPDX Legal team via Jilayne's role as a maintainer, I think it is worth giving it a go with a clear flag to the community as trialing a new process.
A contingency plan for when things don't go ideally is a way to build efficacy into the process. It is a reason why a contingency plan is included in the Fedora Change Proposal template. There should also be a scheduled window to retrospect on the process and identify what is working well and what is not. If this is submitted as a Fedora 37 Change, then perhaps targeting a retrospective in Fedora 39 or 40.
On Friday, June 10th, 2022 at 09:44, Vít Ondruch vondruch@redhat.com wrote:
Maybe I wonder (similarly to you) what would be purpose of this ML, if all discussion happens in some issue tracker.
Maybe for people like me who are plugged into too many issue trackers as it is. :-) Although a tag for #legal on discussion.fp.o could be nice… ;-)
On Friday, June 10th, 2022 at 10:33, Neal Gompa ngompa13@gmail.com wrote:
Tom's system had one very important property that SPDX lacks: human coherence. SPDX is inherently verbose and forces specificity where none is necessary in practice, which means that even minute variations in licenses (and we all know that BSD and MIT variants are a dime a dozen) now need new identifiers.
I understand this. It adds low-value labor to the packaging workflow for every package to require a perfectly accurate identifier. There is also significant labor in transitioning not only existing identifiers, but also habits of existing packagers to support this change.
But instead of identifiers, shouldn't this be solved at the level of process and software? I see a strong case for maintaining simplicity for packagers, but I also do not see a strong case against supporting SPDX identifiers in some capacity. These were two ideas I had, but I don't have a deep RPM development background to back them:
A subset of identifiers as "super identifiers" that support license families under commonly-understood terms. Packagers are encouraged to use more verbose identifiers, but super identifiers are also permitted. Super identifiers are understood to be intentionally unspecific as license families.
Creating a Fedora-specific license identifier that indicates a new license is acknowledged by Fedora Legal, but it does not have an assigned SPDX identifier or it is under review. For the purpose of identifiers, this could be a prefix like "FE-" combined with a super identifier (above) that represents a known license family. I think this supports packagers in getting quick answers for identifiers to use in packages, while enabling a Fedora Legal/SPDX Legal discussion to pan out. If/when a SPDX identifier is created for a new license, the Fedora-specific license identifier can be aliased to the new SPDX identifier.
I'm not sure how viable these ideas are in the RPM end of things, but I am pulling from my experience as a packager and also O.S. legal enthusiast in other places. I believe this approach better balances the scale of manual packager labor to using a common set of identifiers to aid in legal support for Fedora.
In my ideal world, we would not explicitly "switch to SPDX", but instead replace 1:1 identifiers with SPDX ones. We'd keep our license math and conventions, but identifiers would be remapped where it made sense. The more specific SPDX identifiers for various MIT and BSD variants would be acceptable, but not required.
SPDX would essentially be an advisor for us, rather than a dependency. That's what Debian did, more or less.
As for "FE-", I'd rather not make that prefix exist more than it already has to. We also don't need it, since we would have our own license list, with identifiers and the will-it-blend(tm) chart. Again, the only reason to do weird prefixes is if we needed to maintain coherence across multiple indexes. We don't, so that's not an issue.
I read this as you are opposed to the SPDX change proposal as written, in which case I ask that you remove your name from the change owners list.
On Tue, Jun 14, 2022 at 11:00 AM David Cantrell dcantrell@redhat.com wrote:
On Fri, Jun 10, 2022 at 04:32:10PM -0400, Neal Gompa wrote:
On Fri, Jun 10, 2022 at 3:52 PM Justin W. Flory (he/him) foss@jwf.io wrote:
Hi all,
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@redhat.com wrote:
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
The Fedora Community has a good reputation for collaboration across communities. Given the close connection to the SPDX Legal team via Jilayne's role as a maintainer, I think it is worth giving it a go with a clear flag to the community as trialing a new process.
A contingency plan for when things don't go ideally is a way to build efficacy into the process. It is a reason why a contingency plan is included in the Fedora Change Proposal template. There should also be a scheduled window to retrospect on the process and identify what is working well and what is not. If this is submitted as a Fedora 37 Change, then perhaps targeting a retrospective in Fedora 39 or 40.
On Friday, June 10th, 2022 at 09:44, Vít Ondruch vondruch@redhat.com wrote:
Maybe I wonder (similarly to you) what would be purpose of this ML, if all discussion happens in some issue tracker.
Maybe for people like me who are plugged into too many issue trackers as it is. :-) Although a tag for #legal on discussion.fp.o could be nice… ;-)
On Friday, June 10th, 2022 at 10:33, Neal Gompa ngompa13@gmail.com wrote:
Tom's system had one very important property that SPDX lacks: human coherence. SPDX is inherently verbose and forces specificity where none is necessary in practice, which means that even minute variations in licenses (and we all know that BSD and MIT variants are a dime a dozen) now need new identifiers.
I understand this. It adds low-value labor to the packaging workflow for every package to require a perfectly accurate identifier. There is also significant labor in transitioning not only existing identifiers, but also habits of existing packagers to support this change.
But instead of identifiers, shouldn't this be solved at the level of process and software? I see a strong case for maintaining simplicity for packagers, but I also do not see a strong case against supporting SPDX identifiers in some capacity. These were two ideas I had, but I don't have a deep RPM development background to back them:
A subset of identifiers as "super identifiers" that support license families under commonly-understood terms. Packagers are encouraged to use more verbose identifiers, but super identifiers are also permitted. Super identifiers are understood to be intentionally unspecific as license families.
Creating a Fedora-specific license identifier that indicates a new license is acknowledged by Fedora Legal, but it does not have an assigned SPDX identifier or it is under review. For the purpose of identifiers, this could be a prefix like "FE-" combined with a super identifier (above) that represents a known license family. I think this supports packagers in getting quick answers for identifiers to use in packages, while enabling a Fedora Legal/SPDX Legal discussion to pan out. If/when a SPDX identifier is created for a new license, the Fedora-specific license identifier can be aliased to the new SPDX identifier.
I'm not sure how viable these ideas are in the RPM end of things, but I am pulling from my experience as a packager and also O.S. legal enthusiast in other places. I believe this approach better balances the scale of manual packager labor to using a common set of identifiers to aid in legal support for Fedora.
In my ideal world, we would not explicitly "switch to SPDX", but instead replace 1:1 identifiers with SPDX ones. We'd keep our license math and conventions, but identifiers would be remapped where it made sense. The more specific SPDX identifiers for various MIT and BSD variants would be acceptable, but not required.
SPDX would essentially be an advisor for us, rather than a dependency. That's what Debian did, more or less.
As for "FE-", I'd rather not make that prefix exist more than it already has to. We also don't need it, since we would have our own license list, with identifiers and the will-it-blend(tm) chart. Again, the only reason to do weird prefixes is if we needed to maintain coherence across multiple indexes. We don't, so that's not an issue.
I read this as you are opposed to the SPDX change proposal as written, in which case I ask that you remove your name from the change owners list.
I am not opposed to changing to SPDX identifiers, but there's a world of difference between that and basically saying that we are not in control of our license process. Switching to SPDX identifiers and the SPDX identifier scheme has a ton of consequences, and we need to actually be cognizant and account for them. I'm bringing this up all the time because I've seen it go wrong before and I don't want it to go wrong here now.
On Tue, Jun 14, 2022 at 11:12 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 14, 2022 at 11:00 AM David Cantrell dcantrell@redhat.com wrote:
On Fri, Jun 10, 2022 at 04:32:10PM -0400, Neal Gompa wrote:
On Fri, Jun 10, 2022 at 3:52 PM Justin W. Flory (he/him) foss@jwf.io wrote:
Hi all,
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@redhat.com wrote:
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
The Fedora Community has a good reputation for collaboration across communities. Given the close connection to the SPDX Legal team via Jilayne's role as a maintainer, I think it is worth giving it a go with a clear flag to the community as trialing a new process.
A contingency plan for when things don't go ideally is a way to build efficacy into the process. It is a reason why a contingency plan is included in the Fedora Change Proposal template. There should also be a scheduled window to retrospect on the process and identify what is working well and what is not. If this is submitted as a Fedora 37 Change, then perhaps targeting a retrospective in Fedora 39 or 40.
On Friday, June 10th, 2022 at 09:44, Vít Ondruch vondruch@redhat.com wrote:
Maybe I wonder (similarly to you) what would be purpose of this ML, if all discussion happens in some issue tracker.
Maybe for people like me who are plugged into too many issue trackers as it is. :-) Although a tag for #legal on discussion.fp.o could be nice… ;-)
On Friday, June 10th, 2022 at 10:33, Neal Gompa ngompa13@gmail.com wrote:
Tom's system had one very important property that SPDX lacks: human coherence. SPDX is inherently verbose and forces specificity where none is necessary in practice, which means that even minute variations in licenses (and we all know that BSD and MIT variants are a dime a dozen) now need new identifiers.
I understand this. It adds low-value labor to the packaging workflow for every package to require a perfectly accurate identifier. There is also significant labor in transitioning not only existing identifiers, but also habits of existing packagers to support this change.
But instead of identifiers, shouldn't this be solved at the level of process and software? I see a strong case for maintaining simplicity for packagers, but I also do not see a strong case against supporting SPDX identifiers in some capacity. These were two ideas I had, but I don't have a deep RPM development background to back them:
A subset of identifiers as "super identifiers" that support license families under commonly-understood terms. Packagers are encouraged to use more verbose identifiers, but super identifiers are also permitted. Super identifiers are understood to be intentionally unspecific as license families.
Creating a Fedora-specific license identifier that indicates a new license is acknowledged by Fedora Legal, but it does not have an assigned SPDX identifier or it is under review. For the purpose of identifiers, this could be a prefix like "FE-" combined with a super identifier (above) that represents a known license family. I think this supports packagers in getting quick answers for identifiers to use in packages, while enabling a Fedora Legal/SPDX Legal discussion to pan out. If/when a SPDX identifier is created for a new license, the Fedora-specific license identifier can be aliased to the new SPDX identifier.
I'm not sure how viable these ideas are in the RPM end of things, but I am pulling from my experience as a packager and also O.S. legal enthusiast in other places. I believe this approach better balances the scale of manual packager labor to using a common set of identifiers to aid in legal support for Fedora.
In my ideal world, we would not explicitly "switch to SPDX", but instead replace 1:1 identifiers with SPDX ones. We'd keep our license math and conventions, but identifiers would be remapped where it made sense. The more specific SPDX identifiers for various MIT and BSD variants would be acceptable, but not required.
SPDX would essentially be an advisor for us, rather than a dependency. That's what Debian did, more or less.
As for "FE-", I'd rather not make that prefix exist more than it already has to. We also don't need it, since we would have our own license list, with identifiers and the will-it-blend(tm) chart. Again, the only reason to do weird prefixes is if we needed to maintain coherence across multiple indexes. We don't, so that's not an issue.
I read this as you are opposed to the SPDX change proposal as written, in which case I ask that you remove your name from the change owners list.
I am not opposed to changing to SPDX identifiers, but there's a world of difference between that and basically saying that we are not in control of our license process. Switching to SPDX identifiers and the SPDX identifier scheme has a ton of consequences, and we need to actually be cognizant and account for them. I'm bringing this up all the time because I've seen it go wrong before and I don't want it to go wrong here now.
To elaborate, using SPDX-style identifiers and even working with SPDX itself is something I consider reasonable. However, I *do not* consider it reasonable to make *our* legal process block on someone else's.
The only quibble with the Change document I have is this: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1#With_Fedora_abb...
SPDX license expression parsers are required to handle all-lowercase "and"/"or"/"with", and I think we should keep doing that for Fedora license math because SPDX identifiers are title case words and that makes it easy for humans to identify discrete clauses. Using all caps makes it annoying to read.
The license field is designed to make it easy for people and machines to figure out what the license of a package is, we should not forget humans matter here too.
Personally, I don't think we should require full conversion when partial SPDX conversions net us significant benefits too (https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1#Can_we_combine_...), but I don't feel too strongly about it.
Beyond the Change document, there's a whole extra undefined process for how we deal with new licenses and license identifiers. I don't want us waiting on SPDX, and I don't want us using LicenseRef-* if we don't absolutely need to. Aside from the reasons I stated earlier, LicenseRef-* tags can basically never go away because we are not in control of the universe of packages that ship using our packaging guidelines. Since we know what identifiers exist when making a new one, we can designate the identifier ourselves, use it in Fedora, and submit it upstream to SPDX to reconcile it.
Fundamentally, I want us to be prepared for the event that SPDX either doesn't exist anymore or is no longer in common use. I signed onto this project principally because I want us to have a proper coherent database of our license policy that our tools can consume that is central to our ecosystem. Whether the identifiers came from SPDX or somewhere else isn't a huge deal to me, but unifying our license identification databases is. That will enable future efforts for mechanizing and automating audits across the entire distribution.
SPDX isn't responsible for Fedora, Red Hat and Fedora are. So I want to make sure we are designing this with that value in mind.
On 6/14/22 9:30 AM, Neal Gompa wrote:
On Tue, Jun 14, 2022 at 11:12 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 14, 2022 at 11:00 AM David Cantrell dcantrell@redhat.com wrote:
On Fri, Jun 10, 2022 at 04:32:10PM -0400, Neal Gompa wrote:
In my ideal world, we would not explicitly "switch to SPDX", but instead replace 1:1 identifiers with SPDX ones. We'd keep our license math and conventions, but identifiers would be remapped where it made sense. The more specific SPDX identifiers for various MIT and BSD variants would be acceptable, but not required.
SPDX would essentially be an advisor for us, rather than a dependency. That's what Debian did, more or less.
As for "FE-", I'd rather not make that prefix exist more than it already has to. We also don't need it, since we would have our own license list, with identifiers and the will-it-blend(tm) chart. Again, the only reason to do weird prefixes is if we needed to maintain coherence across multiple indexes. We don't, so that's not an issue.
I read this as you are opposed to the SPDX change proposal as written, in which case I ask that you remove your name from the change owners list.
I have to agree with David here, Neal. I don't know exactly what the criteria is for identifying changes owners, but it'd seem like at a minimum it would be someone who is 1) fully supportive on the Change Proposal and 2) actively contributing to moving it forward.
As David has already noted and others have before - this is not a new idea. Many of the issues you continue to raise have been discussed multiple times over the years.
I am not opposed to changing to SPDX identifiers, but there's a world of difference between that and basically saying that we are not in control of our license process. Switching to SPDX identifiers and the SPDX identifier scheme has a ton of consequences, and we need to actually be cognizant and account for them. I'm bringing this up all the time because I've seen it go wrong before and I don't want it to go wrong here now.
I'm sorry that you are still scarred from this previous experience outside of Fedora, which I think involved some kind of adoption of SPDX identifiers without collaborating with the SPDX community. But that was then/that experience - and this is now. Let's focus on moving forward :)
Jilayne
On Tue, Jun 14, 2022 at 12:19 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 6/14/22 9:30 AM, Neal Gompa wrote:
On Tue, Jun 14, 2022 at 11:12 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 14, 2022 at 11:00 AM David Cantrell dcantrell@redhat.com wrote:
On Fri, Jun 10, 2022 at 04:32:10PM -0400, Neal Gompa wrote:
In my ideal world, we would not explicitly "switch to SPDX", but instead replace 1:1 identifiers with SPDX ones. We'd keep our license math and conventions, but identifiers would be remapped where it made sense. The more specific SPDX identifiers for various MIT and BSD variants would be acceptable, but not required.
SPDX would essentially be an advisor for us, rather than a dependency. That's what Debian did, more or less.
As for "FE-", I'd rather not make that prefix exist more than it already has to. We also don't need it, since we would have our own license list, with identifiers and the will-it-blend(tm) chart. Again, the only reason to do weird prefixes is if we needed to maintain coherence across multiple indexes. We don't, so that's not an issue.
I read this as you are opposed to the SPDX change proposal as written, in which case I ask that you remove your name from the change owners list.
I have to agree with David here, Neal. I don't know exactly what the criteria is for identifying changes owners, but it'd seem like at a minimum it would be someone who is 1) fully supportive on the Change Proposal and 2) actively contributing to moving it forward.
As David has already noted and others have before - this is not a new idea. Many of the issues you continue to raise have been discussed multiple times over the years.
But they haven't been discussed here. And finding references to older discussions elsewhere is not easy, so I'm reduced to bringing it up again and making sure that's all captured.
And any discussions that happened within Red Hat *did not happen* from a Fedora point of view, and I certainly don't know about them. Contrary to popular belief, I don't work at Red Hat and have no idea what's actually going on there a good chunk of the time. :)
I am not opposed to changing to SPDX identifiers, but there's a world of difference between that and basically saying that we are not in control of our license process. Switching to SPDX identifiers and the SPDX identifier scheme has a ton of consequences, and we need to actually be cognizant and account for them. I'm bringing this up all the time because I've seen it go wrong before and I don't want it to go wrong here now.
I'm sorry that you are still scarred from this previous experience outside of Fedora, which I think involved some kind of adoption of SPDX identifiers without collaborating with the SPDX community. But that was then/that experience - and this is now. Let's focus on moving forward :)
Indeed. Perhaps we'll do better this time around.
-- 真実はいつも一つ!/ Always, there's only one truth!
On 6/14/22 10:26 AM, Neal Gompa wrote:
On Tue, Jun 14, 2022 at 12:19 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 6/14/22 9:30 AM, Neal Gompa wrote:
On Tue, Jun 14, 2022 at 11:12 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 14, 2022 at 11:00 AM David Cantrell dcantrell@redhat.com wrote:
On Fri, Jun 10, 2022 at 04:32:10PM -0400, Neal Gompa wrote:
In my ideal world, we would not explicitly "switch to SPDX", but instead replace 1:1 identifiers with SPDX ones. We'd keep our license math and conventions, but identifiers would be remapped where it made sense. The more specific SPDX identifiers for various MIT and BSD variants would be acceptable, but not required.
SPDX would essentially be an advisor for us, rather than a dependency. That's what Debian did, more or less.
As for "FE-", I'd rather not make that prefix exist more than it already has to. We also don't need it, since we would have our own license list, with identifiers and the will-it-blend(tm) chart. Again, the only reason to do weird prefixes is if we needed to maintain coherence across multiple indexes. We don't, so that's not an issue.
I read this as you are opposed to the SPDX change proposal as written, in which case I ask that you remove your name from the change owners list.
I have to agree with David here, Neal. I don't know exactly what the criteria is for identifying changes owners, but it'd seem like at a minimum it would be someone who is 1) fully supportive on the Change Proposal and 2) actively contributing to moving it forward.
As David has already noted and others have before - this is not a new idea. Many of the issues you continue to raise have been discussed multiple times over the years.
But they haven't been discussed here. And finding references to older discussions elsewhere is not easy, so I'm reduced to bringing it up again and making sure that's all captured.
And any discussions that happened within Red Hat *did not happen* from a Fedora point of view, and I certainly don't know about them. Contrary to popular belief, I don't work at Red Hat and have no idea what's actually going on there a good chunk of the time. :)
I'm 99.9% sure you raised it here https://pagure.io/packaging-committee/pull-request/971# :)
Keep in mind that with any change, not everything will go perfectly smoothly and we will experience bumps along the way. It is impossible to anticipate every possible challenge or risk. The best for any change and planning is to consider the range of possibility, prepare as best one can, and adapt as needed! I truly believe we are in a good place in that regard.
I am not opposed to changing to SPDX identifiers, but there's a world of difference between that and basically saying that we are not in control of our license process. Switching to SPDX identifiers and the SPDX identifier scheme has a ton of consequences, and we need to actually be cognizant and account for them. I'm bringing this up all the time because I've seen it go wrong before and I don't want it to go wrong here now.
I'm sorry that you are still scarred from this previous experience outside of Fedora, which I think involved some kind of adoption of SPDX identifiers without collaborating with the SPDX community. But that was then/that experience - and this is now. Let's focus on moving forward :)
Indeed. Perhaps we'll do better this time around.
we will. have a little faith, ok? :)
-- 真実はいつも一つ!/ Always, there's only one truth!
Hi all,
I meant to respond to this thread on Friday, but time got away from me and more messages came in, so I'm just going to respond here and try to address a few over-arching things and then to Justin's helpful comments below as well.
First of all - the original intent of this email was to suggest and gain acceptance for a process change for when a package maintainer comes across a new license and needs review - to essentially use Gitlab instead of email. It seems like most people are fine with this, but the discussion has gotten stuck on my draft process description putting - submit to SPDX at the point in time when Fedora is assessing whether the license is allowed rather than after that determination is made. This is a detail that is not even critical at this point and really, something that is probably better discussed cross-community with the SPDX-legal team ultimately. But given my experience there, I put that "step" (if needed at all) earlier in the process because I have prior experience from in a similar scenario in terms of OSI approving a license and needing an SPDX id (OSI adopted SPDX ids back in 2011). So, this scenario with the interplay on processes, timing, and dependency is not new with Fedora. And learning from the past experience, Fedora and SPDX can come up with a better plan.
This thread has seen a tangent about SPDX-legal team processes. I'm happy to answer any questions as needed, but I also can't get into every possible thing SPDX-legal is doing and that kind of knowledge is better gained by joining that community as is always the case. That being said, strong opinions stated as fact that are based on minimal involvement or impressions of SPDX are not helpful, nor productive.
To Richard's point about - what if Jilayne gets hit by a bus (okay, I know that is not what Richard actually said) - this is a good question. Part of the improvements here related to all aspects of Fedora license data, documentation, processes is to create a more sustainable and scalable model that does not depend on one person. (because, I think we can all agree - there won't be another spot!). To that end, I have made SPDX-legal aware of the work going on here with Fedora for some time now and there is excellent support. SPDX-legal is also very much aware of the need-for-speed in that Fedora package maintainers might be waiting on SPDX-legal in some cases. In any case, I feel pretty confident that if I got hit by a bus tomorrow, all would not be lost. Someone else would have to take up the more direct communications with SPDX and I could see David or Miroslov being excellent candidates for that and they would find a welcoming community at SPDX. So, there is my succession planning ;)
As for when Fedora would need to submit a license to SPDX, let's be clear that there are two distinct scenarios here: 1) when new packages have new licenses. As Richard already pointed out, this is not a high volume situation, which makes it easier to move fast for all parties involved. 2) for when we enter "phase 2" and start going through old packages. I think this will need a different process in any case. For example, for the Fedora category licenses like "MIT" - it would probably make sense to go through those, collect the various license texts and then collaborate with SPDX-legal for some sort of "bulk review". I have more thoughts on this, but given we are not in phase 2 yet, I'll wait to share more details on that later (so let's please not go down that rabbit hole now :)
A few more comments below
Thanks, Jilayne
On 6/10/22 1:52 PM, Justin W. Flory (he/him) wrote:
Hi all,
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontanarfontana@redhat.com wrote:
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
The Fedora Community has a good reputation for collaboration across communities. Given the close connection to the SPDX Legal team via Jilayne's role as a maintainer, I think it is worth giving it a go with a clear flag to the community as trialing a new process.
Thanks for saying this! The same can be said of the SPDX community. I can also say that having observed various adoptions of SPDX license ids or use of the SPDX License List over the years, the most successful results have come with collaboration between the relevant communities. Where a community has gone off and done their own thing using various aspects of SPDX (as they have every right to do) - usually misses the benefit of more informed implementation. So, that is why I feel so strongly around cross-collaboration. :)
A contingency plan for when things don't go ideally is a way to build efficacy into the process. It is a reason why a contingency plan is included in the Fedora Change Proposal template. There should also be a scheduled window to retrospect on the process and identify what is working well and what is not. If this is submitted as a Fedora 37 Change, then perhaps targeting a retrospective in Fedora 39 or 40.
On Friday, June 10th, 2022 at 09:44, Vít Ondruchvondruch@redhat.com wrote:
Maybe I wonder (similarly to you) what would be purpose of this ML, if all discussion happens in some issue tracker.
Maybe for people like me who are plugged into too many issue trackers as it is. :-) Although a tag for #legal on discussion.fp.o could be nice… ;-)
FWIW - SPDX-legal used to use email, very similar to Fedora-legal, for our license review process. Once a license was approved, one person had to update the "data" (at that time held in a .txt file and spreadsheet... the horror!). We eventually moved to Github and started using issues. Considering the SPDX-legal community is not necessarily day-to-day Github (or other repo) users, this was a big lift! For awhile, people still used email and we just made an issue for them. Anyway, point being, I'd think the Fedora community is probably way more Gitlab savvy and this transition would be an easier shift. But if someone still sent an email to fedora-legal, it's also easy enough for anyone to make an issue and then reply on email to follow there. I'd guess there will be a transition period where this may happen as people become aware of the new process.
On Friday, June 10th, 2022 at 10:33, Neal Gompangompa13@gmail.com wrote:
Tom's system had one very important property that SPDX lacks: human coherence. SPDX is inherently verbose and forces specificity where none is necessary in practice, which means that even minute variations in licenses (and we all know that BSD and MIT variants are a dime a dozen) now need new identifiers.
I understand this. It adds low-value labor to the packaging workflow for every package to require a perfectly accurate identifier. There is also significant labor in transitioning not only existing identifiers, but also habits of existing packagers to support this change.
But instead of identifiers, shouldn't this be solved at the level of process and software? I see a strong case for maintaining simplicity for packagers, but I also do not see a strong case against supporting SPDX identifiers in some capacity. These were two ideas I had, but I don't have a deep RPM development background to back them:
A subset of identifiers as "super identifiers" that support license families under commonly-understood terms. Packagers are encouraged to use more verbose identifiers, but super identifiers are also permitted. Super identifiers are understood to be intentionally unspecific as license families.
Creating a Fedora-specific license identifier that indicates a new license is acknowledged by Fedora Legal, but it does not have an assigned SPDX identifier or it is under review. For the purpose of identifiers, this could be a prefix like "FE-" combined with a super identifier (above) that represents a known license family. I think this supports packagers in getting quick answers for identifiers to use in packages, while enabling a Fedora Legal/SPDX Legal discussion to pan out. If/when a SPDX identifier is created for a new license, the Fedora-specific license identifier can be aliased to the new SPDX identifier.
I'm not sure how viable these ideas are in the RPM end of things, but I am pulling from my experience as a packager and also O.S. legal enthusiast in other places. I believe this approach better balances the scale of manual packager labor to using a common set of identifiers to aid in legal support for Fedora.
legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-leave@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 on the list, report it:https://pagure.io/fedora-infrastructure
On Fri, Jun 10, 2022 at 10:33:38AM -0400, Neal Gompa wrote:
On Fri, Jun 10, 2022 at 9:35 AM Richard Fontana rfontana@redhat.com wrote:
"Blocking on the SPDX-legal team" is the one aspect of this process that I am somewhat worried about, and I think it might be something unprecedented for Fedora, so it's important that people can get behind that as an experiment. Also I went back and looked at Jilayne's original email in this thread and I'm not sure that this was an obvious feature of the proposal. So it's important to understand: under this proposal, Fedora package submitters will have to wait for an external project to make a decision, for some unspecified amount of time, and I'm not even sure if we can say what that time period might be based on past experience because this relationship is going to be new for SPDX as well as for Fedora.
Probably worth keeping in mind, though, that new licenses in new packages are *probably* going to be a relatively uncommon event, assuming that we don't primarily use the new package process as the means of transitioning existing approved Callaway license symbols to SPDX-conformant identifiers.
So, this is where I will disagree here, sadly. Transitioning from the Fedora/Callaway system (which allows license families to be given the same designator) to the SPDX system (which does not) means that we will have the sad duty of having to generate identifiers for licenses that don't deserve them.
Tom's system had one very important property that SPDX lacks: human coherence. SPDX is inherently verbose and forces specificity where none is necessary in practice, which means that even minute variations in licenses (and we all know that BSD and MIT variants are a dime a dozen) now need new identifiers.
If you are fundamentally opposed to this change proposal, please remove your name from the owners list.
I don't know how much delay Fedora packagers can tolerate or how fast SPDX-legal can be. I would assume this is something new for SPDX too -- the first time an external consumer of SPDX identifiers is dependent on SPDX-legal acting somewhat fast. I believe we talked (maybe this was on the spdx-legal list) about defining an SPDX-legal decision as being the merging of a pull request at github.com/spdx/license-list-XML, not on a formal release of a new license list by SPDX (which I think we can agree would be unacceptable for Fedora).
Jilayne, I think we can be confident that SPDX-legal will be efficient enough as long as you are involved in leading it and also are involved on the Fedora side, but it would be reasonable for Fedora community members to wonder what will happen if one or both of those involvements were to ever change. Maybe we should think about a backup plan (like, if some version of the SPDX namespace proposal is adopted, making use of that if SPDX-legal is not responsive by a certain time, or using LicenseRef- to create SPDX-conformant identifiers that can be altered later on to SPDX-adopted identifiers as needed).
This problem is the principal reason why I don't think Debian will ever fully adopt SPDX identifiers in the same way openSUSE did, and why I don't think it'd be a good idea for us to do so either. We may be adopting SPDX-style identifiers, but we aren't going to rely on their data set for our systems. That's why David Cantrell is making a new one for us.
Clearly the wind is blowing for us to make life easier for lawyers and harder for packagers, but that doesn't mean I want to give up *too* much ground on that front.
This is quite a jump. Please assume good intent.
This project has been underway for YEARS now. I noticed internally at Red Hat that across our products and then across Fedora had many overlapping license tracking efforts. Why? Should we not try to combine efforts? The Fedora list had not real process or owner other than spot and I think the project (and downstream consumers of Fedora) will benefit from a documented process and data set owners. spot did a lot of great work to get us here, but we need a better process now and a central set of data.
And I've made it clear in the past and I'll reiterate again: LicenseRef-* identifiers should *not* be used except in the absolute worst circumstances.
I do not understand this position. From my point of view, LicenseRef-* syntax is a great part of the SPDX spec to let us accept a license, use it, and then in parallel submit it to SPDX. If SPDX accepts the license, we can make the change in our package(s) and if they don't we can just keep using the LicenseRef-* identifier we created because that's still SPDX spec-compatible.
Those tags indicate three things:
- A lack of agency
- A lack of coherence
- A lack of agreement
Fedora, when identifying acceptable licenses, should not have those problems.
I do not see it that way. I see it as a way for us to define SPDX spec-compatible license identifiers that are only in our data set and not [yet] accepted in to the upstream SPDX list.
Thanks,
On 6/8/22 12:08 PM, Richard Fontana wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
How to request review of a new license If you find a license for a package you want to include in Fedora and that license is not listed in the Fedora License Data, you can submit it for review as follows:
Note: you must be a Fedora contributer and become part of the Fedora Gitlab group. See LINK for more on how to become a Fedora contributor.
I can sort of see why you'd want the submitter to be a Fedora contributor (I assume that means a Fedora account holder) but is it necessary to become part of the Fedora Gitlab group just to submit an issue?
Not up to us, as far as I understand it, so was adding that as an expectation. Looks like Neal may have answered this in next email as well.
- Create a new issue in the Fedora License Data repo with the following information: license name, link to text of license, package name and link, why you want to include it in Fedora, whether it is on the SPDX License List, and the SPDX expression as applicable (see below for hints on determining if a license text matches a license on the SPDX License List)
Is "why you want to include it in Fedora" necessary? If they are linking to a package, presumably that's either an existing Fedora package (i.e., the license *should* have been approved but never was, or was approved based on outdated criteria and methodology) or a proposed Fedora package. So the rationale for inclusion should always be obvious and not require any further justification.
okay, fair enough. I wasn't sure if that was something that was included in the past. I'll remove that part!
` 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.
That is how I had it at first, but I am thinking that giving SPDX a heads up sooner than later would be advantageous. That way the SPDX id can be sort of prepped and then if the license ends up being not-allowed, well, closing an issue on the SPDX side as "not accepted" (to the SPDX License List) is relatively easy. :)
J.
Richard
On Wed, Jun 08, 2022 at 01:08:38PM -0600, Jilayne Lovejoy wrote:
On 6/8/22 12:08 PM, Richard Fontana wrote:
On Wed, Jun 8, 2022 at 1:58 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
How to request review of a new license If you find a license for a package you want to include in Fedora and that license is not listed in the Fedora License Data, you can submit it for review as follows:
Note: you must be a Fedora contributer and become part of the Fedora Gitlab group. See LINK for more on how to become a Fedora contributor.
I can sort of see why you'd want the submitter to be a Fedora contributor (I assume that means a Fedora account holder) but is it necessary to become part of the Fedora Gitlab group just to submit an issue?
Not up to us, as far as I understand it, so was adding that as an expectation. Looks like Neal may have answered this in next email as well.
- Create a new issue in the Fedora License Data repo with the following information: license name, link to text of license, package name and link, why you want to include it in Fedora, whether it is on the SPDX License List, and the SPDX expression as applicable (see below for hints on determining if a license text matches a license on the SPDX License List)
Is "why you want to include it in Fedora" necessary? If they are linking to a package, presumably that's either an existing Fedora package (i.e., the license *should* have been approved but never was, or was approved based on outdated criteria and methodology) or a proposed Fedora package. So the rationale for inclusion should always be obvious and not require any further justification.
okay, fair enough. I wasn't sure if that was something that was included in the past. I'll remove that part!
I think it's useful to specify a link to the package review or such. (Why? For example the following scenario: a package review request is created, then it becomes blocked on the license review, and for whatever reason it takes a long time. Once the license ticket is closed, people would like to jump back to the package review…) In general, more links is better, it's hard to coordinate things between the different trackers that Fedora uses.
So maybe make the "why you want to include it in Fedora" part optional: "Reason for the license review? (Optional. E.g. link to package review ticket.)"
` 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.
That is how I had it at first, but I am thinking that giving SPDX a heads up sooner than later would be advantageous. That way the SPDX id can be sort of prepped and then if the license ends up being not-allowed, well, closing an issue on the SPDX side as "not accepted" (to the SPDX License List) is relatively easy. :)
Zbyszek
Dne 08. 06. 22 v 19:58 Jilayne Lovejoy napsal(a):
Hi all,
As you all know, we have a larger project of moving Fedora license data to a data format and repository, updating and improving Fedora-legal documentation related to licensing, and adoption of SPDX ids. In light of that, it is also relevant to look at the process for review of a new license for potential inclusion in Fedora.
I'd describe the past/current process as:
- send email to this list, some discussion may ensue on list (with
community members and Red Hat legal), decision made and then license is added to the applicable wiki table (good or bad) at https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing
- Of course, up until somewhat recently, this entire workflow was
shepherded by Tom Callaway
Now that we have the license data in a repository, it seems like we can use Issues and Merge Requests for the process flow, instead of relying on email. As such, I'd like to propose something along the following lines:
**How to request review of a new license* If you find a license for a package you want to include in Fedora and that license is not listed in the Fedora License Data, you can submit it for review as follows:
Note: you must be a Fedora contributer and become part of the Fedora Gitlab group. See LINK for more on how to become a Fedora contributor.
- Create a new issue in the Fedora License Data repo with the
following information: license name, link to text of license, package name and link, why you want to include it in Fedora, whether it is on the SPDX License List, and the SPDX expression as applicable (see below for hints on determining if a license text matches a license on the SPDX License List)
Is is possible to follow the repository somehow? Not sure. If that is not the case, it would be useful if note about the issue was sent to this ML. Or the discussion was forwarded here.
Vít
- All discussion related to the license review based on the license
criteria will be on the Issue thread and a decision will be noted there. ` 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. The ultimate decision for licenses allowed or not-allowed for Fedora based upon the license criteria rests with Red Hat legal.
- Once a decision has been made, the person who submitted the license
for review creates a Merge Request for the license using the TOML file format.
- Merge Requests will be reviewed and merged by the Fedora License
Data repo maintainers.
Happy to hear your thoughts, feedback, and suggestions!
Thanks, Jilayne
legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-leave@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 on the list, report it:https://pagure.io/fedora-infrastructure
On Thu, Jun 09, 2022 at 01:03:27PM +0200, Vít Ondruch wrote:
Dne 08. 06. 22 v 19:58 Jilayne Lovejoy napsal(a): Is is possible to follow the repository somehow? Not sure. If that is not the case, it would be useful if note about the issue was sent to this ML. Or the discussion was forwarded here.
This draft doesn't specify a specific git forge, but it seems all of them allow subscribing to issues and/or pull requests.
Zbyszek
On 6/9/22 10:01 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jun 09, 2022 at 01:03:27PM +0200, Vít Ondruch wrote:
Dne 08. 06. 22 v 19:58 Jilayne Lovejoy napsal(a): Is is possible to follow the repository somehow? Not sure. If that is not the case, it would be useful if note about the issue was sent to this ML. Or the discussion was forwarded here.
This draft doesn't specify a specific git forge, but it seems all of them allow subscribing to issues and/or pull requests.
in my draft that will go on the documentation page, there is a hot link, but that gets stripped out in text email :) but yes, all links where appropriate!
as for following the repo - I know this is easy to do as an individual, but I can't see how that would translate to having a mailing list follow a repo. I don't think that would work and would create a lot of noise on the mailing list.
part of the point of the process change is to leverage using the repo now that the license data is in a repo! instead of email which is harder to follow on a specific issue (yes, a non-developer, lawyer-type just said that!!).
What would you want to see specifically on the mailing list? Maybe an "announcement" of sorts when a new license review is completed? but then the license would show up on the list of licenses once the MR is merged... so maybe there is a way to "watch" those pages?
ok, I just raised more questions... this might be something we look at *after* the documentation is published as it's kind of hard to "picture" at this point.
The main thing is - does anyone have issue with changing the process to use issues and MRs for license review (rather than solely the mailing list)?
J.
legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
Dne 09. 06. 22 v 19:27 Jilayne Lovejoy napsal(a):
On 6/9/22 10:01 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jun 09, 2022 at 01:03:27PM +0200, Vít Ondruch wrote:
Dne 08. 06. 22 v 19:58 Jilayne Lovejoy napsal(a): Is is possible to follow the repository somehow? Not sure. If that is not the case, it would be useful if note about the issue was sent to this ML. Or the discussion was forwarded here.
This draft doesn't specify a specific git forge, but it seems all of them allow subscribing to issues and/or pull requests.
in my draft that will go on the documentation page, there is a hot link, but that gets stripped out in text email :) but yes, all links where appropriate!
as for following the repo - I know this is easy to do as an individual, but I can't see how that would translate to having a mailing list follow a repo. I don't think that would work and would create a lot of noise on the mailing list.
part of the point of the process change is to leverage using the repo now that the license data is in a repo! instead of email which is harder to follow on a specific issue (yes, a non-developer, lawyer-type just said that!!).
What would you want to see specifically on the mailing list? Maybe an "announcement" of sorts when a new license review is completed? but then the license would show up on the list of licenses once the MR is merged... so maybe there is a way to "watch" those pages?
ok, I just raised more questions... this might be something we look at *after* the documentation is published as it's kind of hard to "picture" at this point.
The main thing is - does anyone have issue with changing the process to use issues and MRs for license review (rather than solely the mailing list)?
I'll provide just generic answer here, sorry ;) I am member of at least two MLs (ruby-core and rpm-maint), where maybe 99% of content is notification from bug tracking systems and the rest is the original ML content. And this works well IMO.
Maybe I wonder (similarly to you) what would be purpose of this ML, if all discussion happens in some issue tracker.
But this is not super important issue :)
Vít
Dne 09. 06. 22 v 18:01 Zbigniew Jędrzejewski-Szmek napsal(a):
On Thu, Jun 09, 2022 at 01:03:27PM +0200, Vít Ondruch wrote:
Dne 08. 06. 22 v 19:58 Jilayne Lovejoy napsal(a): Is is possible to follow the repository somehow? Not sure. If that is not the case, it would be useful if note about the issue was sent to this ML. Or the discussion was forwarded here.
This draft doesn't specify a specific git forge, but it seems all of them allow subscribing to issues and/or pull requests.
It is possible. The address is
https://gitlab.com/fedora/legal/fedora-license-data
and once you log in, you can subscribe to the notification of the repo (the bell at header space) and it can be widely customized.
Miroslav