Re: for discussion: license inclusion guidelines
Karsten Klein
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
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