Hi Jilayne,


once in a while I come back with my yet informal proposal to treat new licenses in two stages:

Stage 1 - Registration
Register a license text providing a unique name and short id. (New) Registration guidelines only make sure no other SPDX license is duplicated / affected.
This stage is basically about identification of a license and provides fast acceptance without sacrificing inclusion principles.

Stage 2 - Inclusion
The remainder of the current process to include licenses and do the matching part.
This stage is basically about qualification of a license (in the SPDX License List style)

A license may remain in stage 1 in case the inclusion principles are not met.
A license may be leveled-up from stage 1 to stage 2 in case the inclusion principles are met and once the license is approved and further metadata was collected.
A license in either stage 1 or stage 2 may go through a dedicated change process (deprecation) in case past decisions or provisions need to be reiterated.

This reply also covers your email "for discussion: when can people start using short ids?", since people can start using the name and short id once registered.

I volunteer to write a formal change proposal in case there is sufficient interest in the outline of such an approach.

Regards,
Karsten



On 05.09.22, 22:12, "J Lovejoy" <Spdx-legal@... on behalf of opensource@...> wrote:

    Hi all,

    I just made a new issue to capture this, but wanted to raise it here for broader discussion. 

    If we say that all OSI-approved are included on the SPDX License List, would we want to extend this to licenses that have been deemed to meet the Debian Free Software Guidelines, Fedora guidelines, or Linux kernel guidance?

    Even if not a definitive factor, would we want to allow for a lighter-weight review of such licenses to make it faster/easier to get to acceptance?

    Thinking being that if large distros really want to be able to use SPDX ids across the board, then we need to be able to move quickly in the license review phase. While we have tended toward this in practice, we do not have it recorded in policy. 

    (not sure if this would be worthy of use of the new Change Proposal format - feels borderline for that, but happy to raise in that way, if people think that would help!)

    Jilayne

On Sep 15, 2022, at 10:08 PM, Richard Fontana <rfontana@...> wrote:

On Wed, Sep 7, 2022 at 2:17 PM Steve Winslow <swinslow@...> wrote:

Jilayne -- yes, I'd be open to a lighter-weight or streamlined approach to approving licenses submitted from use in distros such as Debian and Fedora.

In these cases we have greater confidence that those communities have done the work to vet certain of the license inclusion principles. In particular the first and most important "Other Factor" re: "substantially complies with open source definitions"; and its inclusion in the distro likely demonstrates the "substantial use" factor for SPDX purposes.

I expect we'd want to be a bit specific about what we mean by "is included in the distro". For instance, for Debian I'd think `main` would be covered, `non-free` would not, and I don't know for `contrib`. I don't know how Fedora divides things up...

In contrast to Debian, Fedora does not have separate
official/project-administered package repositories with different
license inclusion criteria.

Fedora has an explanation here that may be helpful:
https://docs.fedoraproject.org/en-US/legal/license-approval/

To summarize, there are different categories of material to which
different license standards are applied:

- The general "allowed" category -- licenses here are determined by
Fedora to be FOSS through a sort of common law-like approach (Fedora
has no DFSG/FSD/OSD counterpart of its own)
- "Allowed-documentation" -- licenses approved only for documentation.
The intent here is that the licenses are libre, i.e., equivalent in
permissiveness/restrictiveness to software-oriented FOSS licenses,
except that a few licenses (already recognized by SPDX) are treated as
allowed-documentation for historical reasons even though they can't
seriously be considered to meet all the standards of the licenses in
the allowed category
- "Allowed-content" -- licenses approved only for "content" which
basically means something that can't be considered software,
documentation, or fonts. These have to be FOSS except they can
prohibit modification and have a "no patent licenses" provision.
- "Allowed-firmware" -- licenses approved only for binary firmware
files that meet certain technical operating system-related criteria;
these licenses need not be FOSS but only certain kinds of non-FOSS
terms are permitted.
- "Allowed-fonts" -- licenses approved only for fonts. These licenses
must meet the standards for FOSS except that they can have a "Sun RPC"
clause (i.e. a prohibition on resale/distribution in isolation, which
is for some reason commonly found in pseudo-FOSS font licenses). The
main community authorities on FOSS definitional norms (FSF, OSI,
Debian) have all implicitly taken the position that these kinds of
clauses do not preclude a classification of a font license as FOSS,
but to varying degrees and with a large dose of historical
inconsistency have taken the view that they are generally not
acceptable in a FOSS software license. Fedora is simply being more
transparent that there are relaxed community standards for font
licenses in this one respect.

So I think Fedora has made an effort to ensure that the licenses in
the "allowed", "allowed-documentation" and "allowed-fonts" categories
substantially comply with widely-held community open source
definitions. That can't be said of all licenses in the
allowed-content (probably) and allowed-firmware (definitely)
categories. However, I wonder if the fact that these generally
non-FOSS licenses are determined to meet the license criteria of a
distro that is basically conceptualized as a free software community
distro ought to justify the lighter-weight review Jilayne speaks of.

Richard