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 [email protected] 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 Ondruch<[email protected]> 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 Gompa<[email protected]> 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.
_______________________________________________
legal mailing list [email protected]
To unsubscribe send an email [email protected]
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/[email protected]
Do not reply to spam on the list, report
it:https://pagure.io/fedora-infrastructure
_______________________________________________
legal mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
