1. Spdx-Legal
  2. Messages

Re: for discussion: license inclusion guidelines

Steve Winslow
 

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...

I could see a Change Proposal being appropriate here. Modifying the License Inclusion Principles is a pretty substantive policy change and not something we want to undertake lightly or frequently.

Karsten -- you're welcome to put together and share a formal Change Proposal for your concept if you would like. Speaking personally, I would not be in favor of making that change to a sort of two-tiered license list. If you do want to discuss it further on the mailing list, I'd ask if you could please discuss it in a separate thread, so that we're not diverting from Jilayne's original question here regarding Debian / Fedora. Thanks!

Steve

On Tue, Sep 6, 2022 at 1:49 AM Karsten Klein <karsten.klein@...> wrote:
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
Join Spdx-legal@lists.spdx.org to automatically receive all group messages.