Hi Jilayne:

On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy <opensource@...> wrote:

I’m sending this to both the legal and general mailing lists to ensure
greatest visibility. The legal team has come up with a final draft of the
license inclusion guidelines based on various conversations and feedback
over the past 8 months of intermittent discussion.
The pull request representing this draft is located here:
https://github.com/spdx/license-list-XML/pull/990

On January 31st a compliance tooling meeting and hackathon took place
in Brussels before FOSDEM [1]. One of the session topics was SPDX.
Everyone there agreed that SPDX license inclusion criteria should be
relaxed.

Adding more restrictions and filters is IMHO counterproductive in several ways:
- it requires more work to apply these restrictions and filters
- more work means fewer licenses are added
- as a shared "vocabulary" the utility function of the license list is
directly related to the number of "words" we can use.

Restricting the number of words in the license vocabulary only means
that these words cannot be used in shared conversation about licenses.

But these licenses still exist, so the restrictions impact mostly the
usefulness and expressiveness of SPDX, especially in the more common
cases where license expressions are used without an SPDX document.

This could increasingly make the SPDX License list irrelevant if it is
missing important license vocabulary. The existing and proposed license
inclusion criteria seem counterproductive and likely to subtract value from
SPDX.

The community does not need SPDX to police or enforce OSS license
"purity" via the license list. Instead there should be fewer barriers
to adding new licenses to the list in order to optimize the utility of
the SPDX license list and the number of common licenses SPDX
expressions can deal with.

Since SPDX does not interpret license conditions, the inclusion
guidelines should be loosened to include commonly-used and public
licenses without an OSS litmus test (e.g. free proprietary licenses).
This will become more important for SPDX as more organizations become
more focused on compliance and are looking for a way to account for
all licenses detected from scans or other analysis.

[1] https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#
--
Cordially
Philippe Ombredanne

On Mar 12, 2020, at 3:30 PM, William Bartholomew <iamwillbar@...> wrote:

Philippe,

I agree with you but I think it is orthogonal, the SPDX license inclusion guidelines would govern what goes in the official SPDX license namespace, it does not restrict what could go into other license namespaces (which would be implemented by the other proposal currently being discussed).

William

On 3/12/20 2:23 PM, Philippe Ombredanne wrote:

Hi Jilayne:

On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy <opensource@...> wrote:

I’m sending this to both the legal and general mailing lists to ensure

greatest visibility.  The legal team has come up with a final draft of the

license inclusion guidelines based on various conversations and feedback

over the past 8 months of intermittent discussion.

The pull request representing this draft is located here:

https://github.com/spdx/license-list-XML/pull/990

On January 31st a compliance tooling meeting and hackathon took place

in Brussels before FOSDEM [1]. One of the session topics was SPDX.

Everyone there agreed that SPDX license inclusion criteria should be

relaxed.

Adding more restrictions and filters is IMHO counterproductive in several ways:

- it requires more work to apply these restrictions and filters

- more work means fewer licenses are added

- as a shared "vocabulary" the utility function of the license list is

directly related to the number of "words" we can use.

Restricting the number of words in the license vocabulary only means

that these words cannot be used in shared conversation about licenses.

But these licenses still exist, so the restrictions impact mostly the

usefulness and expressiveness of SPDX, especially in the more common

cases where license expressions are used without an SPDX document.

This could increasingly make the SPDX License list irrelevant if it is

missing important license vocabulary. The existing and proposed license

inclusion criteria seem counterproductive and likely to subtract value from

SPDX.

The community does not need SPDX to police or enforce OSS license

"purity" via the license list. Instead there should be fewer barriers

to adding new licenses to the list in order to optimize the utility of

the SPDX license list and the number of common licenses SPDX

expressions can deal with.

Since SPDX does not interpret license conditions, the inclusion

guidelines should be loosened to include commonly-used and public

licenses without an OSS litmus test (e.g. free proprietary licenses).

This will become more important for SPDX as more organizations become

more focused on compliance and are looking for a way to account for

all licenses detected from scans or other analysis.

[1] https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#

--

Cordially

Philippe Ombredanne