Legal Team/Minutes/2019-05-02

Attendees

• Jilayne Lovejoy
• Steve Winslow
• Brad Edmondson
• John Horan
• Alexios Zavras
• Paul Madick
• Mark Atwood
• Alan Tse

Agenda

1) meetings posted for April 4th; most of work from April 18th are mostly in Github issues that were discussed

2) discussed suggestion of asking license submitters to help with generating XML files and have legal team folks review - will try this with a couple of the new submissions and see how it goes.

• also need to get team members to review licenses and comment in issues (not just doing it on call) - would it help to send email during off-meeting week with links to licenses to check out?

3) Topic from email in advance of meeting re: inclusion principles: SPDX has always endeavored to have ALL OSI-approved licenses on the SPDX License List. The SPDX License List also has NOT included licenses that are clearly not open source (with a couple notable exceptions, like CC-NC-* and CC-ND-*). What if the OSI rejects a license - then it’s not open source, does not meet the OSD - should then, SPDX not include it on the SPDX License List? Another scenario to consider: What if the OSI just mulls something over for a long time, looks like it’s not going to approve it, then the author pulls the request, so there is never a technical rejection? (this has happened a couple times recently) We have one historical example of this in the CC-0 public domain dedication. Below is the thoughts and discussion from brainstorming on these topics during the call:

• use in wild can be a delineating factor but not the only one (b/c people are now submitting to SPDX in advance of use so they can use SPDX identifier)
• recent namespace option for organizational licenses helps with license not yet or not on list
• CC-0 example - while OSI didn’t approve officially, FSF did list it as free - another data point in any case
• our inclusion principles state doesn’t have to be strict compliance with OSD, so that gives us room to add something that may not meet all but is used in wild and benefits to add to list
• but some expressed discomfort with putting license on list could encourage more use of non-open source licenses; at same time, SPDX tags are incredibly helpful for communication of licenses (regardless of type of license).
• Some people may not think just b/c on SPDX license list, it is open source - for messaging, maybe flag to people more clearly to pay attention to OSI-approved and FSF libre - as a source of info on being free/open (not necc inclusion on SPDX License List) - might help and point people to what other orgs have said, so SPDX is not seen as making a call (note can sort by those fields on list)
• we now have lawyers drafting licenses and submitting them to SPDX early on, to get identifier so that can be used at the start - this is a good "problem" but then means the "use in wild" factor it not ripe yet (are we are so useful, people don’t want to use licenses until they can use short identifier… :)
• wildly used, but maybe the guiding principle is more of can-be-used by anyone as opposed to one-off, company or project-specific licenses (even though we have some of these). New licenses should be written this way. but we may have old licenses that have this for historical purpose or b/c of wide use or use in major distro, but that should be less-seen nowadays
• maybe also need to draw line on source and content available - you can have a tag, if you can put a text string someplace useful for consumers (e.g., in source files, have to have source files); “source-available” as guiding principle
• if consider worst-case scenario extreme of having an identifier for every possible bilaterally negotiated license, the SPDX License List would become useless, so don’t want to go to that extent
• challenge of decisions made in past that don’t line up with guidelines for present/future - would we consider deprecating licenses that are old, if we really want to signal evolution of principles? This may be something that we do in future as more known licensing, this would be a departure from reasons for deprecating thus far (new identifier, duplicate license) - usually they have been replaced with another identifier, so not sure if that’s a good idea
• the extent of use of a license is a more useful criteria than OSI-approved in some cases; could end up with OSI-rejected license but still add it
• we use a multiple factor approach and factor prevalence is not equal. We may want to also explain historical anomalies explicitly that get asked about often (e.g., CC-ND, CC-NC)- can also mention historical use. for deprecation
• also should state that guiding principles are just that and not necessarily weighted evenly
• also might add that input form license steward is also a factor (this is mentioned in terms of process for naming purposes, but could be a factor for adding in terms of license steward would not submit something but someone else does)

End result: lots of good thoughts and all acknowledged need to update the inclusion principles, which we are in the process of moving from a web page to a doc in the Github repo. JL to merge PR for adding that page, then take first attempt to revise according to discussion and have others review in Github