Hi all,

Quick question: What type of expertise is needed to participate in the license review process?

Kind regards,

Rob Guinness

FOSSID

On Thu, Jun 6, 2019, at 3:07 PM, Steve Winslow wrote:

Hi all, echoing Phil's comments -- several people have indicated interest in increasing the velocity of adding new licenses to the license list. I'd encourage anyone who shares this goal to participate in reviewing and commenting on requests and issues, and creating/reviewing the license XML files, in the license list 's GitHub repo [1].

I wanted to share a few other thoughts (speaking just for myself and from my own perspective!) Apologies for the lengthy response below.

For those who aren't familiar with the process of adding a license to the list, details are at [2]. High-level, there are two major steps:

1) Legal Team evaluation and consensus around whether a new request should be added. The SPDX legal team community reviews the request and evaluates whether it is appropriate for inclusion on the license list -- e.g., is it already on the license list (taking the SPDX matching guidelines into account); does it meet the list inclusion principles [3]; etc.

2) Creating an XML file representing the license text and a test text file. Separately from the evaluation in #1, adding the license requires creating a representation of the license text in XML format that conforms to the list's schema definition, together with a test text file that is used for validating the XML file.

Currently, for both of these steps, the process typically involves discussion of each license during an SPDX legal team call. This has often meant, for each submission, getting verbal consensus on both whether the license is appropriate to include on the list, and whether the submitted XML file is correctly formatted and templated.

Since the legal team call is biweekly, I think that the only way the process will accelerate to add licenses more quickly will be if more decision-making occurs in the GitHub issue discussions, outside the calls. E.g., if participants are actively reviewing and weighing in on submissions directly in the issue threads, and making recommendations + determining consensus or lack thereof.

Where there isn't consensus among the regular reviewers about a thumbs-up or thumbs-down, that probably signals that it deserves discussion on one of the biweekly calls. But where there's general agreement, perhaps we should more readily accept and iterate based on the issue discussions.

Jilayne has done a fantastic job of encouraging this participation for a long time, and of nudging the rest of us to review and comment between calls (thank you Jilayne for all your efforts in moving us all forward!)

I guess I'm asking the rest of us who want to see licenses added faster to the list, myself included, to each figure out how we can better participate in reviews of license submissions and creation of XML files, and reach consensus (or identify where it's lacking), out-of-band from the team calls. Just like with any other volunteer-powered community, the license list will only be able to grow in line with the effort and availability of those who care to contribute and participate in it on an ongoing basis.

If you've made it this far, thanks for your attention to my ramblings...

Steve

[1] https://github.com/spdx/license-list-XML/issues

[2] https://github.com/spdx/license-list-XML/blob/master/DOCS/new-license-workflow.md

[3] https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md

On Tue, Jun 4, 2019 at 9:41 AM Phil Odence <phil.odence@...> wrote:

One consideration in this discussion is the practical limits of the legal team’s capacity.

 

Adding a new license on the list requires a chunk of work and every license on the list adds incrementally to the maintenance burden over time. There’s been some great work done to putting infrastructure in place automate and track, but processing licenses still involves humans. IMO, there would be more appetite for broadening the criteria if more folks were getting involved, rolling up their sleeves and helping to process license requests.

 

We’re pinched for resources across the board in SPDX, but this is a particular choke point. The SPDX Legal Group is very welcoming and the leaders are some of the nicest folks I know.

 

Phil

 

On 6/3/19, 5:12 PM, "Spdx-legal@... on behalf of Kyle Mitchell" <Spdx-legal@... on behalf of kyle@...> wrote:

 

    On 2019-06-03 20:06, David A. Wheeler wrote:

    > Phil Odence:

    > > And, also, bear in mind that SPDX can handle any

    > > license. Worst case, you identify a local license

    > > identifier and include the license. The goal of the

    > > license list is to minimize the need to do that, but at

    > > the same time, this keeps the list from being a

    > > constraint.

    >

    > For those people who are using the entire SPDX file

    > format, that’s absolutely true.

    >

    > For those who are *only* using SPDX License Expressions

    > within a larger context (e.g., within a package

    > specification), that doesn’t work.  MANY people use ONLY

    > the SPDX license expressions.

   

    It's true that many folks only use SPDX for the license

    list, to code their own license information in package

    manifests.  But npm defines its own magic values for

    unidentified licenses.  Those values function as surrogates

    for the "missing pieces" from the broader SPDX XML standard.

   

    https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.npmjs.com_files_package.json-23license&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=Lagm9_rSjPYjWrFYo1zL4JF-bPtuo7YaHfWyPgsI_Rw&m=0lzIdrRzTIONdga6XuMk0iQ_a1Pk-sI7rqXfdqM6jNg&s=RM4cPzVRO3GPFbuXIqNSzLxez8yclWXpHHTNuDq6xi8&e= :

   

    > If you are using a license that hasn’t been assigned an

    > SPDX identifier, or if you are using a custom license, use

    > a string value like this one:

    >

    >     { "license" : "SEE LICENSE IN <filename>" }

    >

    > Then include a file named <filename> at the top level of

    > the package.

    >

    > ...

    >

    > Finally, if you do not wish to grant others the right to

    > use a private or unpublished package under any terms:

    >

    >     { "license": "UNLICENSED" }

    >

    > Consider also setting "private": true to prevent

    > accidental publication.

   

    I'd strongly recommend that other manifest standards define

    magic values, too.

   

    --

    Kyle Mitchell, attorney // Oakland // (510) 712 - 0933

   

    

   

    

--

Steve Winslow

Director of Strategic Programs

The Linux Foundation

swinslow@...