SPDX Wiki - User contributions [en]

Legal Team

2022-08-11T18:23:46Z

Jlovejoy:

This is the old working area for the Legal Team and is no longer used, but retained for historical work that was captured here.

Please see https://spdx.dev/participate/legal/ for current information.

The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

* [https://github.com/spdx/meetings/tree/master/legal Meeting Minutes of the Legal Team - June 2020 onward]
* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team - prior to March 2020]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]




[[Category:Legal]]

Legal Team

2022-08-11T18:23:01Z

Jlovejoy:

This is the old working area for the Legal Team and is no longer used. Please see https://spdx.dev/participate/legal/ for current information.

The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

* [https://github.com/spdx/meetings/tree/master/legal Meeting Minutes of the Legal Team - June 2020 onward]
* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team - prior to March 2020]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]




[[Category:Legal]]

General Meeting/Old

2020-10-14T03:45:28Z

Jlovejoy:

* [[General_Meeting/License_Field_Discussion|License Field Discussion]]
* [[General_Meeting/Master_Schedule|Master Schedule]]
* [[General_Meeting/Priorities|Current Priorities]]
* [[General_Meeting/Planning_for_Face_to_Face_meeting_in_September-October_2012|Planning for Face to Face meeting in September-October 2012]]
* [[General_Meeting/SPDX_Web_Site_Cleanup|SPDX Website Cleanup]]

[[Category:General]]

General Meeting

2020-10-14T03:45:08Z

Jlovejoy:

This is the working area for the General Team. This team has primary responsibility for summarizing the activities of the three working teams and discussing cross-functional issues. The minutes of this monthly meeting provide a good summary of what's going on across the SPDX group, so signing up for the General Meeting mailing list is a good way to stay in touch.

The General Team meets on the first Thursday of every month at 16:00 GMT (8:00AM PT, 9:00AM MT, 10:00AM CT, 11:00ET).
Join the call: https://www.uberconference.com/SPDXTeam
Optional dial in number: +1-415-881-1586
No PIN needed

* [[General_Meeting/Minutes|Meeting Minutes]]
* [[General_Meeting/Presentation_Materials|Presentation Materials]]
* [[General_Meeting/Old|Older Items]]

[[Category:General]]

Technical Team/Minutes/2020-08-11

2020-08-12T14:22:11Z

Jlovejoy:

August 11, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* Steve Winslow
* Jilayne Lovejoy
* Steve Winslow
* Gary O’Neall
* Rose Judge
* Peter Shin
* Brad Goldring
* John Horan
* Rose Judge
* Vicky Brasseur
* William Bartolomew
* Mark Atwood

Topics:
* Licensing profile - consolidation of license fields

==Legal Profile==
* Initial draft by Steve and Jilayne in Google Docs https://docs.google.com/document/d/1k_2tSlFXvW_SbW-I1DcSEoCNBMQJd4FEFIQr6KCJuyU/edit#
* Note: didn't really update section numbers
* Note: Has not been reviewed by the entire legal team – will review in upcoming legal team meeting
* Normalized naming (e.g. references to Spdx Document rather than Spdx File) - this needs to be done across spec
* Focus on artifact fields - consolidation of license related fields for Package, Files, and Snippets. Not much to change for Document-License List Version field or filed in Other Licensing Info section.
* Discussion on Declared License for Package – metadata
** Thomas raised question on if the Artifact includes the metadata or if it is different
** Discussion on the previous discussions
*** Maven POM files was discussed previously and general agreement that the POM license info would be declared but not concluded
*** POM file license information was not always accurate
** Different scenarios discussed, general agreement that a binary distribution would be a different artifact from the bundle of source
* Discussion on license information that is not completely in the file (e.g. jQuery which includes a link but not the license notice)
** Some tools will fill in the actual license referred to
* Should we document the examples for Declared and Concluded licenses?
** Valuable information
** More specific would be better, but would make it larger
*** Would be nice to have some additional documentation somewhere
** Generally agree to move from the specific fields to the intro for the section
* Discussion on None field for license
** Should the field be renamed NONE_FOUND?
*** Concern it would break tools
** General agreement that NONE means someone looked really hard for a license and couldn’t find one at all
** In the case of “No Rights Reserved”, one would create a LicenseRef-
* Discussion cookbook
** Could create hover over in the spec
*** Concern about accessibility
* Replacing references to Disjunctive license with “OR”
* Continue discussion on the Legal team this Thursday
* What is the name of the profile for licensing?
** “Licensing”
* Discussion on associating copyright owner with license
** Thomas has a requirement to associate the license with the copyright owners
** Current SPDX does not have a mechanism to retain the associations
** Could use snippets to retain the association between copyright owners and licenses for specific code

[[Category:Technical|Minutes]]

Legal Team

2020-07-06T02:45:23Z

Jlovejoy:

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

Work and discussion is primarily done via:

* [https://lists.spdx.org/g/spdx-legal Mailing list]: our traditional form of communication. Meeting reminders, minutes, updates are posted there, as well as discussion.
* [https://github.com/spdx/license-list-XML SPDX License List Github repo]: comments and issues and PRs related to specific changes to the files that comprise the SPDX License List, e.g., update a URL, recommend additional markup for matching purposes. In particular, new license requests are tracked here.
* Bi-weekly calls: used to discuss topics and issues that may be difficult to only discuss via email or via Github.

The Legal Team meets '''every other Thursday at 17:00 GMT (9:00AM PT, 10:00 MT, 11:00 CT, 12:00PM ET)'''.
* [https://github.com/spdx/meetings/tree/master/legal Meeting Minutes of the Legal Team - June 2020 onward]
* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team - prior to March 2020]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]




[[Category:Legal]]

Legal Team/Minutes

2020-06-04T16:23:03Z

Jlovejoy:

SPDX Legal team meetings are now being housed at: https://github.com/spdx/meetings/tree/master/legal
{{#subpages:|limit=500|format=ul|kidsonly=no|pathstyle=none|sort=desc}}

[[Category:Legal|Minutes]]
[[Category:Minutes]]

Legal Team/Minutes/2019-07-11

2019-07-18T03:50:18Z

Jlovejoy:

== Attendees ==
* Alexios Zavras
* Brad Edmondson
* Gary O’Neall
* Jilayne Lovejoy
* John Horan
* Kate Stewart
* Mark Atwood
* Mike Dolan
* Paul Madick
* Steve Winslow

== Agenda ==
1) Joint tech/legal team calls:
* Given the increase in cross-functional tech team/legal team topics coming up, it was suggested on the general call was right before legal call to have a standing joint tech & legal team call at a regular interval. This would avoid having to schedule something separate
* Since the tech team already meets every week, it was decided to do this for the third Tuesday tech team call every month. Dial info and time here: https://wiki.spdx.org/view/Technical_Team
* Recurring invite will be sent to the legal team
* If issues in tech call that legal team might not be aware of, tag in spec as “legal team review” and discuss in joint call

2) “SPDX-Copyright:” tag – suggestion from REUSE folks and discussion in Github issue here:
https://github.com/spdx/spdx-spec/issues/122
* REUSE requested it in SPDX because SPDX is a specification (whereas they are producing guidance documentation). If this was added to the SPDX specification, it would be in the form of an appendix, which would explain the use-case and parameters, similar to how the SPDX-LicenseIdentifier has its own appendix (see: https://github.com/spdx/spdx-spec/blob/master/chapters/appendix-V-using-SPDX-short-identifiers-in-source-files.md )
highlights of discussion on call:
* must make sure it’s not perceived as SPDX giving legal advice in the sense of recommending use of a copyright notice when most Berne jurisdictions don’t require it - the challenges of tooling being able to do this accurately has long been a known difficulty.
* goal of having this is if people are going to use a copyright, it provides a tag that makes finding the copyright notice easier/helps tooling (and extract, if needed for license compliance)
* consider two sides of colon in the tag - the name of the tag to the left of the colon and what goes on the left side of the colon. SPDX should not recommend or prescribe any format for the right side of the colon
* Discussed possible name of tag for left side: discussed various options and pros and cons, but key point that came to some consensus was that if this is tied to spec, it should be consistent with what is used in the spec. In this case, section 4.8 of the spec defines the field for copyright text and uses “FileCopyrightText:” for the SPDX tag value, so would make sense to be consistent, see: https://github.com/spdx/spdx-spec/blob/master/chapters/4-file-information.md#48-copyright-text-
** People have asked about using other fields from SPDX spec in source files, so if we defined a way to do so, then would answer that question and give people a path if they found other SPDX specification fields useful to be used in this way or elsewhere, perhaps in one appendix
** noted that SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag, nature of the use and how it evolved, so it will be its own appendix
** pros and cons of “SPDX” being part of the tag - could be confusing (it's not the copyright for SPDX...) but also queues as to where it is defined; will need to be clear on description in appendix
** Looking at e.g. “SPDX-FileCopyrightText:” - maps on SPDX field, uses "SPDX" to queue relationship and definition in spec

3) SPDX-License-Identifier: should it be confined to only one line? (not delineated either way currently)
* can possible have more than one line/tag if files are combined, so probably not good to constrain this
* this led to comment about when more than one license, but don't know if it's "and" or "or" - issue raised already for using semicolon as operator to indicate unknown relationship (another topic to discuss on joint call with tech/legal team)

4) Collaboration with OSI: Jilayne and Pam Chestek had a good chat and identified some items that need to be fixed/updated to align SPDX and OSI licenses, issues logged in SPDX where applicable and Jilayne sent email to OSI board with summary and suggestions. Aim to work on areas of potential collaboration going forward.

Legal Team/Minutes/2019-07-11

2019-07-18T03:49:58Z

Jlovejoy:

== Attendees ==
* Alexios Zavras
* Brad Edmondson
* Gary O’Neall
* Jilayne Lovejoy
* John Horan
* Kate Stewart
* Mark Atwood
* Mike Dolan
* Paul Madick
* Steve Winslow

== Agenda ==
1) Joint tech/legal team calls:
* Given the increase in cross-functional tech team/legal team topics coming up, it was suggested on the general call was right before legal call to have a standing joint tech & legal team call at a regular interval. This would avoid having to schedule something separate
* Since the tech team already meets every week, it was decided to do this for the third Tuesday tech team call every month. Dial info and time here: https://wiki.spdx.org/view/Technical_Team
* Recurring invite will be sent to the legal team
* If issues in tech call that legal team might not be aware of, tag in spec as “legal team review” and discuss in joint call

2) “SPDX-Copyright:” tag – suggestion from REUSE folks and discussion in Github issue here:
https://github.com/spdx/spdx-spec/issues/122
* REUSE requested it in SPDX because SPDX is a specification (whereas they are producing guidance documentation). If this was added to the SPDX specification, it would be in the form of an appendix, which would explain the use-case and parameters, similar to how the SPDX-LicenseIdentifier has its own appendix (see: https://github.com/spdx/spdx-spec/blob/master/chapters/appendix-V-using-SPDX-short-identifiers-in-source-files.md )
highlights of discussion on call:
* must make sure it’s not perceived as SPDX giving legal advice in the sense of recommending use of a copyright notice when most Berne jurisdictions don’t require it - the challenges of tooling being able to do this accurately has long been a known difficulty.
* goal of having this is if people are going to use a copyright, it provides a tag that makes finding the copyright notice easier/helps tooling (and extract, if needed for license compliance)
* consider two sides of colon in the tag - the name of the tag to the left of the colon and what goes on the left side of the colon. SPDX should not recommend or prescribe any format for the right side of the colon
• Discussed possible name of tag for left side: discussed various options and pros and cons, but key point that came to some consensus was that if this is tied to spec, it should be consistent with what is used in the spec. In this case, section 4.8 of the spec defines the field for copyright text and uses “FileCopyrightText:” for the SPDX tag value, so would make sense to be consistent, see: https://github.com/spdx/spdx-spec/blob/master/chapters/4-file-information.md#48-copyright-text-
** People have asked about using other fields from SPDX spec in source files, so if we defined a way to do so, then would answer that question and give people a path if they found other SPDX specification fields useful to be used in this way or elsewhere, perhaps in one appendix
** noted that SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag, nature of the use and how it evolved, so it will be its own appendix
** pros and cons of “SPDX” being part of the tag - could be confusing (it's not the copyright for SPDX...) but also queues as to where it is defined; will need to be clear on description in appendix
** Looking at e.g. “SPDX-FileCopyrightText:” - maps on SPDX field, uses "SPDX" to queue relationship and definition in spec

3) SPDX-License-Identifier: should it be confined to only one line? (not delineated either way currently)
* can possible have more than one line/tag if files are combined, so probably not good to constrain this
* this led to comment about when more than one license, but don't know if it's "and" or "or" - issue raised already for using semicolon as operator to indicate unknown relationship (another topic to discuss on joint call with tech/legal team)

4) Collaboration with OSI: Jilayne and Pam Chestek had a good chat and identified some items that need to be fixed/updated to align SPDX and OSI licenses, issues logged in SPDX where applicable and Jilayne sent email to OSI board with summary and suggestions. Aim to work on areas of potential collaboration going forward.

Legal Team/Minutes/2019-07-11

2019-07-18T03:34:11Z

Jlovejoy: Created page with "== Attendees == * Alexios Zavras * Brad Edmondson * Gary O’Neall * Jilayne Lovejoy * John Horan * Kate Stewart * Mark Atwood * Mike Dolan * Paul Madick * Steve Winslow ==..."

== Attendees ==
* Alexios Zavras
* Brad Edmondson
* Gary O’Neall
* Jilayne Lovejoy
* John Horan
* Kate Stewart
* Mark Atwood
* Mike Dolan
* Paul Madick
* Steve Winslow

== Agenda ==

1) Joint tech/legal team calls:
* Given the increase in cross-functional tech team/legal team topics coming up, it was suggested on the general call was right before legal call to have a standing joint tech & legal team call at a regular interval. This would avoid having to schedule something separate
* Since the tech team already meets every week, it was decided to do this for the third Tuesday tech team call every month. Dial info and time here: https://wiki.spdx.org/view/Technical_Team
* Recurring invite will be sent to the legal team
* If issues in tech call that legal team might not be aware of, tag in spec as “legal team review” and discuss in joint call

3) “SPDX-Copyright:” tag – suggestion from REUSE folks and discussion in Github issue here:
https://github.com/spdx/spdx-spec/issues/122
* REUSE requested it in SPDX because SPDX is a specification (whereas they are producing guidance documentation). If this was added to the SPDX specificaiton, it would be in the form of an appendix, which would explain the use-case and parameters, similar to how SPDX-LicenseIdentifier has its own appendix (see: https://github.com/spdx/spdx-spec/blob/master/chapters/appendix-V-using-SPDX-short-identifiers-in-source-files.md )
highlights of discussion on call:
* must make sure it’s not perceived as SPDX giving legal advice in the sense of recommending use of a copyright notice when most Berne jurisdictions don’t require it - the challenges of tooling being able to do this accurately has long been a known difficulty.
* goal of having this is if people are going to use a copyright, it provides a tag that makes finding the copyright notice easier/helps tooling (and extract, if needed for license compliance)
* consider two sides of colon in the tag - the name of the tag to the left of the colon and what goes on the left side of the colon. SPDX should not recommend or prescribe any format for the right side of the colon
• Discussed possible name of tag for left side:

Discussed various options and pros and cons, but key point that came to some consensus was that if this is tied to spec, it should be consistent with what is used in the spec. In this case, setion 4.8 of the spec defines the field for copyright text and uses “FileCopyrightText:” for the SPDX tag value, so would make sense to be consistent
– see: https://github.com/spdx/spdx-spec/blob/master/chapters/4-file-information.md#48-copyright-text-
o People have asked about using other fields from SPDX spec in source files, so if we defined a way to do so, then would answer that question and give people a path if they found other SPDX specification fields useful to be used in this way or elsewhere
o pros and cons of “SPDX” being part of the tag
• SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag
o
•

name of field could be confusing

Looking at e.g. “SPDX-FileCopyrightText:” or

left side of colon: looking at SPDX-FileCopyrightText:

forward-looking for adding other tags
SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag
Discussed SPDX spec fields for file copyright text, file notice and/or other attribution notices

5) Ad hoc request – how to tag this type of info from SPDX docs in source files? Should SPDX have recommendations?

6) SPDX-License-Identifier: should there be only one line?
Something that is composing / concatenating multiple source files could end up grabbing multiple versions of these
Issue for this already, along with semicolon operator => discuss on joint call

8) Collaboration with OSI, conversations between Jilayne and Pam Chestek – looking at OSI licenses list and differences with latest SPDX license list, using IDs consistently across lists, etc.

Legal Team/Minutes/2019-05-30

2019-05-30T18:28:51Z

Jlovejoy: Created page with "== Attendees == * John Horan * Jilayne Lovejoy * Mark Atwood * Gary O’Neall * Steve Winslow * Jim Vitrano * Brad Edmondson * Paul Madick * Mike Dolan * Umang Taneja (GSoC s..."

== Attendees ==
* John Horan
* Jilayne Lovejoy
* Mark Atwood
* Gary O’Neall
* Steve Winslow
* Jim Vitrano
* Brad Edmondson
* Paul Madick
* Mike Dolan
* Umang Taneja (GSoC student)

== Agenda ==
1) GSoC update from Umang who is working on a project to enhance the workflow for online license request. See proposal here: https://docs.google.com/document/d/14WRI0cCVArYukVvc0T3thEW2HZ1fGwxn1Nrv65CCMUg/edit
* Umang discussed the ideas for the proposal which will check new license submissions against the current SPDX Licensee List. Will also use an API. (see proposal for full description)
* questions from team: would tool create XML file? what is output from tool if license gets accepted? XML already created in current tool but this will improve that output
* question about how comparison will use the new license-diff tool? that tool does text match, but still needs someone to look at it, as doesn't use full matching guidelines and gives percentage match, which isn't definitive. the matching mechanism Umang is going to work on will implement the full matching guidelines
* if finds a full match, proposal states it would pop-up to user and discard the request. discussed if we want a to track this or not. maybe have in the pop-up ask if the requestor wants a new issue or not (that way they don't have to if they would be embarrassed) and then have a label in Github that adds to the issue to note it's a duplicate.
* if there is a close match, would be good if issue created provides a diff or link to diff so team can see that. maybe also ask requestor if they want to comment on those potential changes
* could we put visual of diff in Archive Requests section and add a link to the issue that points to the diff there (and license text) or something along those lines
* for ideas like above - record as issues in online tools repo https://github.com/spdx/spdx-online-tools
* Mark raised awareness of a tool Amazon has for matching that implements full XML matching rules: https://github.com/amzn/askalono - pulls from SPDX repository. Does matching text and XML but not all matching guidelines. Could be helpful here? (Gary and Umang to review)
* Gary noted that full implementation of matching guidelines is compute intensive and hard to do but key for this use-case (new license requests)

2) Release cycle description: 2 people asked about this recently. Didn't realize we hadn't published this anywhere so Jilayne added to Contributing doc. Discussed details of timing:
* if release is to be published on last day of month for quarter
* 1 week prior: all PRs have been merged that are going to be part of release and no more PRs merged
* 4 weeks prior: any new issues after this point will likely be tagged for next release, unless it's an easy-to-resolve issue
* add above to contributing doc

3) Need more feedback on documentation updates - see email sent earlier this week, comment on PRs in Github
* discussed licenses that aren't squarely open source and variations on how far fall out and how to deal with this potential slippery slope. Some are clearly not open source (use, technology restrictions), then there are licenses intended to be open source, but impose new copyleft-type conditions (SSPL, Parity). We don't want to get into the business of defining what is open source, but we have to make a call on these licenses - how to do this without getting into the middle of the debate?
* licenses that are project and/or entity-specific are likely not to be added, especially if have other factors that cuts against
* need to get licesne inclusion guidelines merged and make further updates

*NOTE: entire next call for discussing any remaining issues for 3.6 release - EVERYONE, PLEASE REVIEW NEW LICENSE REQUESTS AND HELP MOVE THINGS ALONG!!

Legal Team/Minutes/2019-05-16

2019-05-16T17:35:17Z

Jlovejoy: Created page with "== Attendees == * Brad Edmondson * Steve Winslow * John Horan * Paul Madick * Jilayne Lovejoy == Agenda == 1) Update on GSoC - maybe next call have Gary update us on which pr..."

== Attendees ==
* Brad Edmondson
* Steve Winslow
* John Horan
* Paul Madick
* Jilayne Lovejoy

== Agenda ==
1) Update on GSoC - maybe next call have Gary update us on which projects are going forward and what relates to SPDX License List or relevant tools

2) Revising the Overview page and other DOCS
* Moved field descriptions to markdown page in Github DOCS directory. Also removed references to this in CONTRIBUTING as the fields definitions are now in pop-ups in the SPDX license submission online tool.
** agreed to add links to FSF free page and OSI-approved page in Fields description
** reminder to submit issue to also update to tool pop-ups for links (or any changes) so they are same
** add is FSF free? question to license submission tool as well
* license inclusion principles part of overview page also moved to markdown page in Github DOCS
** need to add link to open data definition and FSF 4 freedoms
** may also want to add a note that any license approved by the orgs listed would be appropriate for inclusion on SPDX License List
** re-write background principles and include comment about past decisions and usefulness of SPDX License list (mark’s point from last call) - but move to end. maybe include here some examples of "exceptions"
** consider adding list of negative factors - things we would not put on based on examples of past rejections

* Overview page currently has 3 parts: definition at top (used on other pages as well); license inclusion principles; fields: license inclusion principles and fields now on own md page in Github - what about the ‘what is the SPDX License List’ part? Jilayne made a stab at a re-write, which could also be part of web "redesign" - for now, putting in separate Github page for review, see: https://github.com/spdx/license-list-XML/blob/jlovejoy-inclusion-1/DOCS/what-why-how.md
** all on call thought this was good
** if this was to be used at top of license list main page, need to ask Gary about whether license list tool can pull text from Github repo

* what to do with Overview HTML page and planning?
** get info pulled into Github, and some amount of review, then reduce overview page to bullets of “this has been moved” and links to that info - aim to do this by next call or so
** need to point people on mailing list to these pages/work, as some people are not following Github repo closely
** then consider what to do with links to Overview page (including on License List page)

* readme in DOCS needs to be updated accordingly to above changes

Legal Team/Minutes/2019-05-02

2019-05-02T23:26:28Z

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * Steve Winslow * Brad Edmondson * John Horan * Alexios Zavras * Paul Madick * Mark Atwood * Alan Tse == Agenda == 1) meetings posted for Ap..."

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

Legal Team/Minutes/2019-04-04

2019-05-02T14:46:34Z

Jlovejoy:

== Attendees ==
* Jilayne Lovejoy
* Mark Atwood
* Paul Madick
* John Horan
* Brad Edmondson
* Steve Winslow
* Gary O’Neall
* Nathan Willis
* Mike Dolan
* Steve Winslow

== Agenda ==

1) Steve and Gary gave a great presentation on the general call prior to this call. Slides can be found here:
https://events.linuxfoundation.org/wp-content/uploads/2018/07/SPDX-Bridging-the-Compliance-Tooling-Gap.pdf

2) We have talked about some potential revisions to the Overview page (https://spdx.org/spdx-license-list/license-list-overview) on the calls/mailing list and we also discussed some related website updates at the F2F a few weeks ago. Discussed some ideas related to this:
* moving description of fields for SPDX License List currently on Overview page into Github repo to DOCS directory and call “SPDX-License-List-fields” or something like that
* also move “license inclusion principles” section to its own markdown page in DOCS directory as well
* make list of places that link to Overview page and what needs to change/be updated
* then look back and reconsider use and content for Overview page and possible re-purpose or revise what’s remaining on the overview page and decide if any further changes need to be made or if we can remove that web page altogether

3) Also discussed issue of “drive-by” license submissions and how to better deal with that. Same issue happens on coding projects, but can apply meritocracy approach and be okay with letting issues lie until someone contributes to help make it happen or someone is interested.
* In our case, might help in our CONTRIBUTING documentation to bifurcate review and acceptance/rejection from legal team versus preparing actual files. We also should try to route more of approval process into issue comments.
* Some of text in CONTRIBUTING page is going to be moved to Submit New License tool to have hover-over text with instructions, so that will also help reduce the “wall of text’ on that page. Need to add that info to issue in tools Github issue.
* Maybe we need another DOC in the repo with simple explanation of what the license list, what the legal team does, etc.?
* README probably also needs updates
* What about some guidance on timeline for review and hints towards participating in group helping to speed that up?

Legal Team/Minutes/2019-04-04

2019-05-02T14:44:10Z

Jlovejoy: Created page with "=== Attendees == * Jilayne Lovejoy * Mark Atwood * Paul Madick * John Horan * Brad Edmondson * Steve Winslow * Gary O’Neall * Nathan Willis * Mike Dolan * Steve Winslow ==..."

=== Attendees ==
* Jilayne Lovejoy
* Mark Atwood
* Paul Madick
* John Horan
* Brad Edmondson
* Steve Winslow
* Gary O’Neall
* Nathan Willis
* Mike Dolan
* Steve Winslow

== Agenda ==

1) Steve and Gary gave a great presentation on the general call prior to this call. Slides can be found here:
https://events.linuxfoundation.org/wp-content/uploads/2018/07/SPDX-Bridging-the-Compliance-Tooling-Gap.pdf

2) We have talked about some potential revisions to the Overview page (https://spdx.org/spdx-license-list/license-list-overview) on the calls/mailing list and we also discussed some related website updates at the F2F a few weeks ago. Discussed some ideas related to this:
* moving description of fields for SPDX License List currently on Overview page into Github repo to DOCS directory and call “SPDX-License-List-fields” or something like that
* also move “license inclusion principles” section to its own markdown page in DOCS directory as well
* make list of places that link to Overview page and what needs to change/be updated
* then look back and reconsider use and content for Overview page and possible re-purpose or revise what’s remaining on the overview page and decide if any further changes need to be made or if we can remove that web page altogether

3) Also discussed issue of “drive-by” license submissions and how to better deal with that. Same issue happens on coding projects, but can apply meritocracy approach and be okay with letting issues lie until someone contributes to help make it happen or someone is interested.
* In our case, might help in our CONTRIBUTING documentation to bifurcate review and acceptance/rejection from legal team versus preparing actual files. We also should try to route more of approval process into issue comments.
* Some of text in CONTRIBUTING page is going to be moved to Submit New License tool to have hover-over text with instructions, so that will also help reduce the “wall of text’ on that page. Need to add that info to issue in tools Github issue.
* Maybe we need another DOC in the repo with simple explanation of what the license list, what the legal team does, etc.?
* README probably also needs updates
* What about some guidance on timeline for review and hints towards participating in group helping to speed that up?

Legal Team/Minutes/2019-03-07

2019-04-02T16:42:16Z

Jlovejoy: Created page with "== Attendees == * John Horan * Mark Atwood * Dennis Clark * Brad Edmondson * Steve Winslow * Henri Yandell * Philippe Ombredanne == Agenda == * Discuss open items in Github-..."

== Attendees ==
* John Horan
* Mark Atwood
* Dennis Clark
* Brad Edmondson
* Steve Winslow
* Henri Yandell
* Philippe Ombredanne

== Agenda ==
* Discuss open items in Github- added a number of licenses, deferred action on CC-IGO variant
* Demo of namespace register introduced by Philippe, after much discussion deferred any action.

Legal Team/Minutes/2019-03-21

2019-03-21T18:13:28Z

Jlovejoy: Created page with "== Attendees == * Mark Atwood * Brad Edmondson * Steve Winslow * John Horan * Jilayne Lovejoy * Gary O’Neall * Paul Madick * Kate Stewart == Agenda == 1) go through outsta..."

== Attendees ==
* Mark Atwood
* Brad Edmondson
* Steve Winslow
* John Horan
* Jilayne Lovejoy
* Gary O’Neall
* Paul Madick
* Kate Stewart

== Agenda ==
1) go through outstanding issues for 3.5 release and update:
* two licenses that had some aspect of being non-commercial were submitted, CC license seems to be blessed but there is a warning the comments by Mike L on the many ported CC licenses (e.g. where do we draw line? It would be helpful to have some input from CC on what they consider to be canonical licenses)
* this also touched upon bigger issues of adding more licenses generally and how strict on open source should we be? This, in turn, then touches upon the issue of having only a handful of volunteers who do actual work (most notably, generating the XML files, PRs, comments on issues, etc.) of adding a license. If we decided to be more lenient on what goes on list, the amount of work is not scalable (it's not even really do-able now)
** Currently, it takes probably about half hour to an hour to do one license
** We can improve tooling to some degree, but will always need human review.
** Suggestion to change process such that * SPDX legal team makes decision, but actually building of files to submit has to be done by submitter or other community members interested in having license on list; this way more people have to be involved
* other note on XML markup: where copyright notice and names are in text and replaceable - can have either specific or generic as the text that appears / exemplar text b/c doesn’t matter for matching purposes
* submit issues for online tooling for GSoC students: Gary and team are asking them to work on small issues as part selection process, so helpful to have smaller things to point them to
* various issues for 3.5 assigned and plan for who is going to see which issues/PRs to end. Aim to have all tied up by next Friday, Mar 29 then do actual release on April 1

Legal Team/Minutes/2019-02-21

2019-02-22T04:21:25Z

Jlovejoy: Created page with "== Attendees == * Paul Madick * Dennis Clark * Brad Edmondson * John Horan * Steve Winslow * Mark Baushke * Jilayne Lovejoy * Philippe Ombrdanne == Agenda == 1) Open Source L..."

== Attendees ==
* Paul Madick
* Dennis Clark
* Brad Edmondson
* John Horan
* Steve Winslow
* Mark Baushke
* Jilayne Lovejoy
* Philippe Ombrdanne

== Agenda ==
1) Open Source Leadership Summit agenda
* SPDX f2f time is Monday afternoon 1-5pm
* open agenda with all of SPDX team; rough agenda to cover:
** next release of spec and related topics there
** Mark Atwood’s proposal for non-open source licenses and standardized way to identify
** review from last OSLS discussion on better presentation of SPDX License List as a whole, have we done any of those things, and what still needs to be done
* anything else we should cover?
** should we consider expanding scope of “open source” as a guidance for adding to the list? same problem of doing this still exists - current request relates to a new variant of Creative Commons license - maybe explain the historical context of including all CC licenses and log this somewhere for reference? There is also always the issue of how to find, where to draw line, and the labor involved (no one who asks for this has ever had this answer or has offered)
** we could do better on LicenseRef- option - ReUse guidelines recommends this use - https://reuse.software/practices/2.0/ Mark’s proposal may also help to this end

2) Next release due for end of March - that means we’ll do a freeze as of March 21 meeting. Given current number of issues (some of which need discussion), anything new that isn’t easily resolved will get pushed to next release at this point.

3) Issues for 3.5: Steve discussed a few he has updated:
* Twente license: submitted to OSI and SPDX at same time; MIT variation where they added a few things; concept of derivatives and require list for Data Controllers (seems like they are aiming for GDPR compliance). OSI has been going back and forth and some edits have been made. Submitter has been responsive - Steve asked if text has stabilized and if it’s used - projects waiting to switch to it, but waiting for SPDX identifier.
** we want to wait until OSI finished their process and makes a decision
** we want to have a SPDX short identifier so this if OSI approves, the identifier has already been chosen
* note about NPM: if don’t have an SPDX identifier for your license, NPM throws up warning. Whenever the SPDX License List is updated, NPM doesn’t automatically pick it up, but they usually do, then has to go into next release of NPM client tool and users have to update NPM client tool (long lag time). There is some room for better coordination there ** should we have some kind of advice or write-up that suggests a way to notify when new SPDX License List is release? (kind of like when Gary wrote up paper on programmatically accessing the license list, instead of scraping the website)
* HPND variation - Steve looked at from last call, now submitted a PR
* MIT-CMU / Pillow license - same with templating or new license? discussed and decided to template MIT-CMU

Legal Team/Minutes/2019-02-14

2019-02-22T04:19:28Z

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * Philip Odence * Alexios Zavras * John Horan * Mark Baushke * Steve Winslow * Brad Edmondson * Gary O’Neall * Mike Dolan == Agenda == 1)..."

== Attendees ==
* Jilayne Lovejoy
* Philip Odence
* Alexios Zavras
* John Horan
* Mark Baushke
* Steve Winslow
* Brad Edmondson
* Gary O’Neall
* Mike Dolan

== Agenda ==
1) Open Source Leadership Summit coming up, March 12-14. SPDX face2face on the Monday afternoon. Who will be there?
* maybe Michael Herzog and Philippe O (but not Dennis) from NexB
* Steve W most likely for some of our meeting
* Alexios - maybe
* Gary will be there
* Jilayne will be there

2) Namespace idea for other licenses (not open source or on SPDX License List) - tech team to schedule call on that, will aim for joint call with legal team at tech team time. In the meantime, see email thread to get caught up.

3) Looked at issues marked for 3.5 milestone
* issue 753 re: HPND templating or new license? will add as new license
* issue 752 - discuss “only” and “or later” options on EUPL - how to rectify? currently, implicit that plain means only and + means or later, as it’s always been. Should we add “only” as operator to be explicit? maybe as “=“ or “!” to indicate, so not a word, and distinct from GNU licenses special treatment. Preference for ! symbol
** adding a new operator needs further review with tech team, etc - maybe wait to 3.0 of spec? (next year time frame)

* need people to pick up issues - assign yourself or risk Jilayne assigning you!
* need check list for license review (for SPDX legal team members who are in charge of license) - JL add to repo as new doc, Brad to review

Legal Team/Minutes/2019-01-24

2019-02-22T04:16:45Z

Jlovejoy: Created page with "== Attendees == * Paul Madick * Steve Winslow == Agenda =="

== Attendees ==
* Paul Madick
* Steve Winslow

== Agenda ==

Legal Team/Minutes/2019-01-10

2019-01-11T17:13:32Z

Jlovejoy: Jlovejoy moved page Legal Team/Minutes/2019-0110 to Legal Team/Minutes/2019-01-10: wrong url

== Attendees ==
* Brad Edmondson
* Mark Atwood
* Matija Suklje
* John Horan
* Dennis Clark
* Paul Madick
* Karen Sandler
* Bradley Kuhn
* Gary O’Neall
* Mark Baushke
* Steve Winslow
* Kate Stewart
* Alan Tse

== Agenda ==
1) GSoC - https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas - Process: SPDX application is submitted to GSoC and start looking at projects; if we are picked, then students start really looking at projects (so don’t want to have projects we don’t want to support at that point; but students are already looking!) So, need to add/update by end of next week, Jan 18th
* Port SPDX license expression library to Ruby, Javascript, and Java - more for tool makers; library that enables use of license expressions
* SPDX Specification Views for legal counsels and developers - needs lawyer as mentor, Steve volunteered
* any ideas for further development of online tools?
* Alan’s License Diff tool - now available in SPDX Github repo for anyone who wants to build and install yourself at https://github.com/spdx/spdx-license-diff
** could be GSoC project? Alan has list of enhancements - but not sure if enough to be a project, maybe ask Alan
** Gary had suggestion to move this functionality into online tools (or is it more convenient. Also, current license match is really strict, doesn’t allow you to find close match - add functionality to allow this? some people seem to be confused on this and expect it to be more of a scanner. Would be great to integrate into one option in online tools menu
** for checking if new license request is already on list or match: would be useful to be able to to check license - use compare first, if no match, then use diff tool to check if similar enough that new markup can be added (same license as existing) or is actually different
* also would be great to generate XML markup for match and trigger review by legal team
* also would be helpful to capture variants for regression testing later
* also note that sometimes students will fix existing issues before taking on project, so it’s a good time to submit issues on current tools
* also would be nice if pull in OSI approved info and show that in License Compare or Diff tool
* another idea around being able to identify multiple licenses in one file? or is this
* is there some potential with SPDX license compare and diff to integrate with Github? something to think about for future?
** would be great if in new repo on Github, can use tool to put SPDX identifier in all source files. This is what Reuse project suggests and has some tooling there. Could be a nice cross-collaboration effort b/w Reuse, Github, and SPDX. Also could be integrated with Gitlab and other source repos. Need to contact people at each project to see if we can get this going. Karen S has contact at Gitlab, Matija to sort out right person at Reuse. Jilayne to send email to all and copy Gary
* Alan joined and so Gary recapped ideas for integration with his license diff tool

2) Process for new license requests for 2019:
* make sure any that any new license requests that come via email are moved to issue in Github and submitter is informed of such (Jilayne to do this for now)
* different people on SPDX Legal team to volunteer to shepherd submission through process: make sure all info is gathered, record any discussion/decision in Github issue, update labels accordingly, create XML file if license to be added. We may need to write-up some documentation for this, so people have a guide (CONTRIBUTING page is more focused on perspective of submitter)
** Mark offered to help on this :)

=== Action items from call ===
# Gary and Alan to write up idea for GSoC re: functionality in license compare and license diff tool integration
# Jilayne to send initial email to Github, Gitlab, ReUse contacts re: potential collaboration there (copy Gary); Karen S to provide contact for Gitlab; Matija to provide contact for ReUse
# Jilayne to move any existing license requests into Github issues
# Everyone: to review license submissions in repo, and comment on add-ability of licenses and assign any that are unassigned

Legal Team/Minutes/2019-0110

2019-01-11T17:13:32Z

Jlovejoy: Jlovejoy moved page Legal Team/Minutes/2019-0110 to Legal Team/Minutes/2019-01-10: wrong url

#REDIRECT [[Legal Team/Minutes/2019-01-10]]

Legal Team/Minutes/2019-01-10

2019-01-11T17:12:05Z

Jlovejoy: Created page with "== Attendees == * Brad Edmondson * Mark Atwood * Matija Suklje * John Horan * Dennis Clark * Paul Madick * Karen Sandler * Bradley Kuhn * Gary O’Neall * Mark Baushke * Steve..."

Legal Team/Minutes/2018-12-12

2018-12-13T18:58:17Z

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * John Horan * Alexios Zavras * Gary O’Neall * Matija Suklje * Karen Sandler * Paul Madick * Karen Sandle * Brad Edmondson * Steve Winslow..."

== Attendees ==
* Jilayne Lovejoy
* John Horan
* Alexios Zavras
* Gary O’Neall
* Matija Suklje
* Karen Sandler
* Paul Madick
* Karen Sandle
* Brad Edmondson
* Steve Winslow
* Bradley Kuhn
* Alan Tse
* Dennis Clark

== Agenda ==
1) Contributing updates and license submission tool:
* license submission tool - 3 more issues that need to be addressed; need someone who knows Python in Django framework; Bradley offered to help after Dec 20th-ish; if anyone picks up an issue, just make sure to assign yourself, so people know you are working on it (first come, first serve!)
* 3 issues have to do with updating or adding fields:
** https://github.com/spdx/spdx-online-tools/issues/64 for updating a Comments field (this is most urgent)
** https://github.com/spdx/spdx-online-tools/issues/66 for updates to OSI approved or submitted question
** https://github.com/spdx/spdx-online-tools/issues/65 for adding field regarding license author or steward
* Jilayne to ensure we have a note in CONTRIBUTING as to where to log issues on tool - https://github.com/spdx/spdx-online-tools/issues

2) 3.4 release outstanding issues: comments added and issues and PR closed or merged in repo for 3.4 release, as well as a bit of clean-up of old stuff
* note: for license submissions where submitter has become unresponsive, we added a label for that and informally will give people at least a full release cycle to respond

3) Alan’s new tool for determining if license text is on SPDX License List via diff mechanism!!
* is in his repo in source and Chrome extension where you can take text and diff it against SPDX License List; ranks matches based on amount of differences - https://chrome.google.com/webstore/detail/spdx-diff/kfoadicmilbgnicoldjmccpaicejacdh
* also can be used with Firefox, but not published there yet
* exceptions are not in tool yet
* Steve will talk to Kate about getting extension over to an LF account
* source code is currently here: https://github.com/alandtse/spdx-diff
* need to think about name because we have “diff” tool for diff’ing SPDX documents - put your vote for name in the issues in Github, Alan gets to decide since he wrote

Legal Team/Minutes/2018-11-29

2018-11-29T18:23:16Z

Jlovejoy:

== Attendees ==
* Jilayne Lovejoy
* Bradley Kuhn
* Alexios Zavras
* Karen Copenhaver
* Steve Winslow
* Karen Sandler
* Richard Fontana
* Gary O’Neall
* Paul Madick
* Brad Edmondson

== Agenda ==
1) discussion of “license exceptions” description and particular requests for additions - see https://lists.spdx.org/g/Spdx-legal/message/2445 for some background
* discussed Linux kernel enforcement statement - https://github.com/spdx/license-list-XML/issues/655 and GPL Cooperation Commitment - https://github.com/spdx/license-list-XML/issues/714
** By putting kernel enforcement statement on SPDX list helps to shows that it’s out there and enables use via identifier. Acknowledged that enforcement statement is copyright holder-specific, but it's people might do vetting and figure out what files the enforcement statement applies to across the board (where all copyright holders have signed enforcement statement). At this point, there are big chunks of code that could be under license with kernel enforcement statement, so may not be so hard to determine that. As more kernel copyright holders sign-up, this will get easier, so good to have identifier for that eventuality
** question as to if kernel enforcement statement "changes" the license or just about how certain copyright holders enforce the license?
*** it’s an additional permission, it uses contractual language; then GPL Cooperation Commitment follows with more explicit language
*** problem with "change" is can be interpreted as changing the entire license or changing an aspect (modifying, excepting, augmenting, additional permission) but not changing the over-arching license. Exceptions - as on SPDX License List thus far - are the latter. Description does state that these things are not stand alone licenses.
* Regarding GPL CC: drafted for projects to be used by new projects or existing projects where adoption of commitment can be done for apply as of date
** question as to whether language for corporate and individual versions are similar enough to project version that we can accommodate with matching markup and use one identifier. This needs to be investigated as part of implementation.
*** Richard to help provide diff; Alexios to help with SPDX markup potential, so all can then review/discuss
* implementation of adding kernel enforcement statement question: how to handle list of names (not part of statement?); and preamble/information part at start?
** probably best to do markup as straw man, then discuss on Github issue as to specifics

2) discussion on potential changes to existing explanation for License Exceptions on https://spdx.org/licenses/exceptions-index.html
* Jilayne had proposed changing from "exceptions" to "modifiers", but all on call agreed we didn't actually have to edit this language now; as it stands, the kernel enforcement statement and GPL Cooperation Commitment fit the description
* exceptions or "modifiers" are things that could have legal impact on original/over-arching license
* we might want to add a point that any exception needs to fit the license inclusion principles just as licenses do; so long as any additional term doesn't take a license out of the open source definition, then could still include it
* Google patent grant may stretch this definition a bit and no one from Google on call, so tabled discussion on that issue

Legal Team/Minutes/2018-11-29

2018-11-29T18:14:04Z

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * Bradley Kuhn * Alexios Zavras * Karen Copenhaver * Steve Winslow * Karen Sandler * Richard Fontana * Gary O’Neall * Paul Madick * Brad Ed..."

== Attendees ==
* Jilayne Lovejoy
* Bradley Kuhn
* Alexios Zavras
* Karen Copenhaver
* Steve Winslow
* Karen Sandler
* Richard Fontana
* Gary O’Neall
* Paul Madick
* Brad Edmondson

== Agenda ==
1) discussion of “license exceptions” description and particular requests for additions - see https://lists.spdx.org/g/Spdx-legal/message/2445 for some background
* discussed Linux kernel enforcement statement - https://github.com/spdx/license-list-XML/issues/655 and GPL Cooperation Commitment - https://github.com/spdx/license-list-XML/issues/714
** By putting kernel enforcement statement on SPDX list helps to shows that it’s out there and enables use via identifier. Acknowledged that enforcement statement is copyright holder-specific, but it's people might do vetting and figure out what files the enforcement statement applies to across the board (where all copyright holders have signed enforcement statement). At this point, there are big chunks of code that could be under license with kernel enforcement statement, so may not be so hard to determine that. As more kernel copyright holders sign-up, this will get easier, so good to have identifier for that eventuality
** question as to if kernel enforcement statement "changes" the license or just about how certain copyright holders enforce the license?
*** it’s an additional permission, it uses contractual language; then GPL Cooperation Commitment follows with more explicit language
*** problem with "change" is can be interpreted as changing the entire license or changing an aspect (modifying, excepting, augmenting, additional permission) but not changing the over-arching license. Exceptions - as on SPDX License List thus far - are the latter. Description does state that these things are not stand alone licenses.
* Regarding GPL CC: drafted for projects to be used by new projects or existing projects where adoption of commitment can be done for apply as of date
** question as to whether language for corporate and individual versions are similar enough to project version that we can accommodate with matching markup and use one identifier. This needs to be investigated as part of implementation.
*** Richard to help provide diff; Alexios to help with SPDX markup potential, so all can then review/discuss

discussion of “additional restrictions” - if something didn’t take a license out of open source definition, then could still include it. “modifiers” are things that could have legal impact on licenses

does kernel enforcement statement change the license?

* variants for the Google patent grant - https://github.com/spdx/license-list-XML/issues/646
** is this really an additional exception or a license itself

Legal Team

2018-11-01T22:02:06Z

Jlovejoy:

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

Work and discussion is primarily done via:

* mailing list: our traditional form of communication. Meeting reminders, minutes, updates are posted there, as well as discussion.
* [https://github.com/spdx/license-list-XML SPDX License List Github repo]: comments and issues and PRs related to specific changes to the files that comprise the SPDX License List, e.g., update a URL, recommend additional markup for matching purposes. In particular, new license requests are tracked here.
* bi-weekly calls: used to discuss topics and issues that may be difficult to only discuss via email or via Github.

'''You can join the mailing list and otherwise manage your subscription here''': https://lists.spdx.org/g/spdx-legal

An invite for the bi-weekly calls is sent to the mailing list at the beginning of each year. If you join the mailing list later, you may not have gotten the invite. The details of the calls are below for anyone to join and meeting reminders are usually sent prior to the call on the mailing list.

The Legal Team meets '''every other Thursday at 17:00 GMT (9:00AM PT, 10:00 MT, 11:00 CT, 12:00PM ET)'''.

Web conference: http://uberconference.com/SPDXTeam
Optional dial in number: 415-881-1586
No PIN needed

* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]




[[Category:Legal]]

Legal Team

2018-11-01T22:01:26Z

Jlovejoy:

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ | SPDX License List]; and promotes the SPDX specification to the legal community at-large.

Work and discussion is primarily done via:

* mailing list: our traditional form of communication. Meeting reminders, minutes, updates are posted there, as well as discussion.
* [https://github.com/spdx/license-list-XML|SPDX License List Github repo]: comments and issues and PRs related to specific changes to the files that comprise the SPDX License List, e.g., update a URL, recommend additional markup for matching purposes. In particular, new license requests are tracked here.
* bi-weekly calls: used to discuss topics and issues that may be difficult to only discuss via email or via Github.

'''You can join the mailing list and otherwise manage your subscription here''': https://lists.spdx.org/g/spdx-legal

An invite for the bi-weekly calls is sent to the mailing list at the beginning of each year. If you join the mailing list later, you may not have gotten the invite. The details of the calls are below for anyone to join and meeting reminders are usually sent prior to the call on the mailing list.

The Legal Team meets '''every other Thursday at 17:00 GMT (9:00AM PT, 10:00 MT, 11:00 CT, 12:00PM ET)'''.

Web conference: http://uberconference.com/SPDXTeam
Optional dial in number: 415-881-1586
No PIN needed

* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]




[[Category:Legal]]

Legal Team

2018-11-01T21:49:37Z

Jlovejoy:

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

Work and discussion is primarily done via:

* mailing list: our traditional form of communication. Meeting reminders, minutes, updates are posted there, as well as discussion.
* the SPDX License List Github repo: comments and issues and PRs related to specific changes to the files that comprise the SPDX License List, e.g., update a URL, recommend additional markup for matching purposes. In particular, new license requests are tracked here.
* bi-weekly calls: used to discuss topics and issues that may be difficult to only discuss via email or via Github.

'''You can join the mailing list and otherwise manage your subscription here''': https://lists.spdx.org/g/spdx-legal

An invite for the bi-weekly calls is sent to the mailing list at the beginning of each year. If you join the mailing list later, you may not have gotten the invite. The details of the calls are below for anyone to join and meeting reminders are usually sent prior to the call on the mailing list.

The Legal Team meets '''every other Thursday at 17:00 GMT (9:00AM PT, 10:00 MT, 11:00 CT, 12:00PM ET)'''.

Web conference: http://uberconference.com/SPDXTeam
Optional dial in number: 415-881-1586
No PIN needed

* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]




[[Category:Legal]]

Legal Team/Minutes/2018-11-01

2018-11-01T21:47:38Z

Jlovejoy:

== Attendees ==
* Jilayne Lovejoy
* Steve Winslow
* John Horan
* Dennis Clark
* Philippe Ombredanne
* Andrew Katz
* Brad Edmondson
* Gary O’Neall
* Paul Madick
* Kate Stewart

== Agenda ==
1) 3.3 is out and new RELEASE NOTES have been added to the repo, see: https://github.com/spdx/license-list-XML/blob/master/RELEASE-NOTES.md - feedback?
* include: list of new licenses/exceptions, any other major changes, link to PRs, link to comparison from last version to new version (no need to go into further detail)
* should we also repeat this info on release page, e.g. https://github.com/spdx/license-list-XML/releases
* going forward, Gery to add to workflow for license list release, will need to write release notes in .md file before tagging release

2) new license submission process:
* want to use new license submission tool but need to add a few features: add yes/no question about submitting to OSI; add yes/no as to whether they are license author/steward; change “notes” to “comments”
** —> JL to move issues to https://github.com/spdx/spdx-online-tools/issues - DONE
** also should add field for full name of submitter?
* still have issue where all new issues show as coming from Gary: to fix this, would have to require submitter has Github account or could create a dedicated service account (username like SPDX-license-submission)
* where should discussion happen for license submission - Github or email list? if Github, then have to require Github ID. Everyone agreed that discussion should be on Github issue and move away from email
** concern that we may lose some license submitters who don’t use Github, can still let people use email, then log issue, and then email them to let them know it’s being tracked there, which anyone can view
* need to add note that submitters must respond to questions and if don’t after certain period of time, then submission will be closed. Maybe tie to release cycle. This also means we need to be better at our cadence of submissions.
* do we need to discuss all license submissions on call or can we process otherwise? how do we come to consensus or quorum via Github issue?
** if two lawyers and one non-lawyer sign off that it’s acceptable to add AND no objection from greater community, then we don’t need to discuss on call/ can add. Give people a week to raise any objection after trio sign-off. If objections, then discuss at meeting
* need to get tooling updates first, then can implement this workflow
—> JL to PR Contributing page with recommendations from this call - everyone can review - DONE

2) Next call on Nov 15th is cancelled, actual next call will Nov 29 - scheduled to talk GPL Cooperation and Linux enforcement statement
* look for email with more info on that topic in advance, so we can have a productive call on the 29th

3) License list overview page, which includes license inclusion guidelines: needs to be reviewed and updated generally, as well as consideration for adding hardware and data. This is a webpage only, so now good way to track/review changes
* add HTML for overview page to repo, so can track changes there, same for matching guidelines; add comment at top explaining what the page is/where it lives
* then can make recommendations for changes that can be reviewed
* add link at bottom of page to repo for history of page changes
* --> JL to put two files in own folder, called docs, with README explaining what these are - DONE

—> also noted that a write up history of SPDX License List and inclusion guidelines would be helpful. Turns out, we do have part of this here: https://wiki.spdx.org/view/Legal_Team/Decisions/Inclusion_Guidelines_(Background) - maybe just add to this?

Legal Team/Minutes/2018-11-01

2018-11-01T20:40:15Z

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * Steve Winslow * John Horan * Dennis Clark * Philippe Ombredanne * Andrew Katz * Brad Edmondson * Gary O’Neall * Paul Madick * Kate Stewar..."

== Attendees ==
* Jilayne Lovejoy
* Steve Winslow
* John Horan
* Dennis Clark
* Philippe Ombredanne
* Andrew Katz
* Brad Edmondson
* Gary O’Neall
* Paul Madick
* Kate Stewart

== Agenda ==
1) 3.3 is out and new RELEASE NOTES have been added to the repo, see: https://github.com/spdx/license-list-XML/blob/master/RELEASE-NOTES.md - feedback?
* include: list of new licenses/exceptions, any other major changes, link to PRs, link to comparison from last version to new version (no need to go into further detail)
* should we also repeat this info on release page, e.g. https://github.com/spdx/license-list-XML/releases
* going forward, Gery to add to workflow for license list release, will need to write release notes in .md file before tagging release

2) new license submission process:
* want to use new license submission tool but need to add a few features: add yes/no question about submitting to OSI; add yes/no as to whether they are license author/steward; change “notes” to “comments”
** —> JL to move issues to https://github.com/spdx/spdx-online-tools/issues
** also should add field for full name of submitter?
* still have issue where all new issues show as coming from Gary: to fix this, would have to require submitter has Github account or could create a dedicated service account (username like SPDX-license-submission)
* where should discussion happen for license submission - Github or email list? if Github, then have to require Github ID. Everyone agreed that discussion should be on Github issue and move away from email
** concern that we may lose some license submitters who don’t use Github, can still let people use email, then log issue, and then email them to let them know it’s being tracked there, which anyone can view
* need to add note that submitters must respond to questions and if don’t after certain period of time, then submission will be closed. Maybe tie to release cycle. This also means we need to be better at our cadence of submissions.
* do we need to discuss all license submissions on call or can we process otherwise? how do we come to consensus or quorum via Github issue?
** if two lawyers and one non-lawyer sign off that it’s acceptable to add AND no objection from greater community, then we don’t need to discuss on call/ can add. Give people a week to raise any objection after trio sign-off. If objections, then discuss at meeting
* need to get tooling updates first, then can implement this workflow
—> JL to PR Contributing page with recommendations from this call - everyone can review

2) Next call on Nov 15th is cancelled, actual next call will Nov 29 - scheduled to talk GPL Cooperation and Linux enforcement statement
* look for email with more info on that topic in advance, so we can have a productive call on the 29th

3) License list overview page, which includes license inclusion guidelines: needs to be reviewed and updated generally, as well as consideration for adding hardware and data. This is a webpage only, so now good way to track/review changes
* add HTML for overview page to repo, so can track changes there, same for matching guidelines; add comment at top explaining what the page is/where it lives
* then can make recommendations for changes that can be reviewed
* add link at bottom of page to repo for history of page changes
* --> JL to put two files in own folder, called docs, with README explaining what these are

—> also noted that a write up history of SPDX License List and inclusion guidelines would be helpful. Turns out, we do have part of this here: https://wiki.spdx.org/view/Legal_Team/Decisions/Inclusion_Guidelines_(Background) - maybe just add to this?

Legal Team/Minutes/2018-10-18

2018-10-23T16:41:47Z

Jlovejoy: Created page with "== Attendees == * Bradlee Edmondson * John Horan * Dennis Clark * Steve Winslow * Bradley Kuhn == Agenda == 1) 3.3 final PRs to merge before release: * license for source fil..."

== Attendees ==
* Bradlee Edmondson
* John Horan
* Dennis Clark
* Steve Winslow
* Bradley Kuhn

== Agenda ==
1) 3.3 final PRs to merge before release:
* license for source files associated with SPDX License List - changed to CC0-1.0 - no further comments, done
* CUA-OPL-1.0 is now officially noted as retired in OSI - updated notes section in SPDX to reflect same
* OGL-UK-1.0 - Steve is working on fixing, will submit PR
* FreeRTOS note - add note that exception is old and now released under MIT
** Jilayne had question as to capitalization of XML filename, does this matter or is it just annoying to her?

2) other discussion
* In light of license change for FreeRTOS (and that other projects do change license), Bradley raised idea of recording this in such as way that tooling would find this info that it's been relicensed, something like you might get a notification about the change of license
** all agreed this would be a nice thing to have, but where/how to record? Spec isn't really right place; could we record something in a more machine-readable part of the XML? in license scanning tools?
** Bradley offered to write up description and then we can engage tech team for further discussion/ideas. see: https://github.com/spdx/license-list-XML/issues/716
* need to tackle a couple things related to the "exceptions" list, which we have previously discussed changing the description for or even re-naming. Relatedly, there is the Linux Kernel Enforcement Statement and now the GPL Cooperation Commitment, as well as the Google patent grant (and diff versions). It'd be nice to tackle this on a scheduled call so we can try to have all interested parties (as well as via mailing list, of course). Watch for scheduling of that, likely to be Nov 29th meeting

Legal Team/Minutes/2018-10-04

2018-10-10T20:41:19Z

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * Gary O’Neall * Dennis Clark * John Horan * Steve Winslow * Brad Edmondson * Paul Madick == Agenda == 1) license list tooling update fr..."

== Attendees ==
* Jilayne Lovejoy
* Gary O’Neall
* Dennis Clark
* John Horan
* Steve Winslow
* Brad Edmondson
* Paul Madick

== Agenda ==

1) license list tooling update from Gary - https://spdxtools.sourceauditor.com - need legal team to test for some time, then will move location and document as official workflow
* did some testing and sharing of workflow on call (some "test" issues created as a result, ignore these in repo)
* updated documentation for proposed workflow on call for a few things, see: https://docs.google.com/document/d/1S6nRuSD_KyprDaDGjTRg-kTAy-Cj42xbhT88aRU4Ssw/edit
* log issues at https://github.com/spdx/spdx-online-tools/issues - use label, “required for release” for priority items that we need to have fixed before more general use

2) Went through issues and PRs for 3.3 release (priority) and flagged anything that we didn't get to for 3.4
* Note: need help closing out the rest of 3.3 ASAP
* focus for next call will be to deal with things already flagged for 3.4 and also get on top of older issues, so we can deal with things in some order of submission going forward

Legal Team/Minutes/2018-08-23

2018-09-24T16:05:16Z

Jlovejoy: Created page with "== Attendees == * Paul Madick * Jilayne Lovejoy * Steve Winslow * Gary O’Neall * Brad Edmondson * Dennis Clark * Mark Atwood == Agenda == 1) Update on tooling that came out..."

== Attendees ==
* Paul Madick
* Jilayne Lovejoy
* Steve Winslow
* Gary O’Neall
* Brad Edmondson
* Dennis Clark
* Mark Atwood

== Agenda ==
1) Update on tooling that came out of GSoC:
* couple issues that we discussed on last call, Tushar fixed and code has been committed. GSoC is now over, but sounds like Tushar and Gallo
* Aim to converge tools into one and put on website and any issues that are show stoppers to use resolved by then as well. Once up and ready, would be good to go through another demo on a later legal call and then decide what process changes may be impacted

2) cleaned up status of committers, etc. on Github license-list-XML repo as per Gary’s recommendations

3) went over some of the “discuss on legal call” issues in Github, closed out a few, (Nasa license markup, Open Gov’t License, license for source code) see repo for notes there

Legal Team/Minutes/2018-09-20

2018-09-24T16:02:23Z

Jlovejoy: Created page with "== Attendees == * Paul Madick * Steve Winslow * Matija Suklje * John Horan * Mark Atwood * Jilayne Lovejoy == Agenda == 1) need to sort out emails that are not coming through..."

== Attendees ==
* Paul Madick
* Steve Winslow
* Matija Suklje
* John Horan
* Mark Atwood
* Jilayne Lovejoy

== Agenda ==
1) need to sort out emails that are not coming through unless approved and approve faster and let people know to join list
* discussed whether to remove moderation, but that would result in a lot of junk going to everyone, so not going to do that!

2) Update from LF Legal Summit (meeting under Chatham House Rule): one workshop on compliance tools and general practice. A lot of general dislike of existing tools (scanning and compliance) - areas for improvement and interest in improvement. Support for SPDX as way to communicate.

3) Github issues:
* https://github.com/spdx/license-list-XML/issues/678 - Sendmail license new version to add
* https://github.com/spdx/license-list-XML/issues/670 - request for new license, did we ever get follow-up info?
* https://github.com/spdx/license-list-XML/issues/689 - request for license, not approved b/c not open source
* https://github.com/spdx/license-list-XML/issues/686 - "invariant sections" issue - need to discuss further
* https://github.com/spdx/license-list-XML/issues/683 - license for various files that make up license list, see notes

Legal Team/Minutes/2018-07-26

2018-07-26T17:10:01Z

Jlovejoy: /* Attendees */

== Attendees ==
* Dennis Clark
* John Horan
* Steve Winslow
* Jilayne Lovejoy
* Paul Madick
* Kate Stewart
* Gary O’Neall
* Mark Atwood

== Agenda ==
1) General updates: GSoC is in last stretch, coordinate with Gary to have Tushar come on and demo tool next call?
* XML editor: need to test this and provide bugs /issues here; https://github.com/spdx/spdx-online-tools or email student (and Gary); if raise issue, preface it as “XML online editor”
** Gary has played with it, having a bit of trouble with auto PR function; he did a little demo. If playing with this and using something you want to actually use (not just a test), can download and create PR the usual way to use in meantime
** Note: if you play with it, it WILL create a PR in the actual repository; so if just playing around, make it clear it’s not “real” and then close it or ask one of us to close
* Submit New License project: online tool, fill out form, and auto-creates an Issue in Github repo. Not as far along, so can’t see yet in online tools server. Gary gave us a demo.
** general workflow: user submits new license in form: 2 things then happen: populates a table of all licenses that have been submitted and status and issue is created in repo
** form is for person wanting to request new license
** (for Legal Team) can then click on row of table and click “generate XML file” and it will download XML to your computer, then can use that to create PR in regular way
** OR can go to XML editor tool and upload file, edit it, and use that PR feature
** this tool would replace email option for submitting new license - so, once usable can update those instructions (but may need a bit more work to get to that point)

2) Went through a couple “old issues” in repo that have “legal discussion” or have been hanging around. Notes made there

Legal Team/Minutes/2018-07-26

2018-07-26T17:09:41Z

Jlovejoy: Created page with "== Attendees == * Dennis Clark * John Horan * Steve Winslow * Jilayne Lovejoy * Paul Madick * Kate Stewart * Gary O’Neall == Agenda == 1) General updates: GSoC is in last s..."

== Attendees ==
* Dennis Clark
* John Horan
* Steve Winslow
* Jilayne Lovejoy
* Paul Madick
* Kate Stewart
* Gary O’Neall

== Agenda ==
1) General updates: GSoC is in last stretch, coordinate with Gary to have Tushar come on and demo tool next call?
* XML editor: need to test this and provide bugs /issues here; https://github.com/spdx/spdx-online-tools or email student (and Gary); if raise issue, preface it as “XML online editor”
** Gary has played with it, having a bit of trouble with auto PR function; he did a little demo. If playing with this and using something you want to actually use (not just a test), can download and create PR the usual way to use in meantime
** Note: if you play with it, it WILL create a PR in the actual repository; so if just playing around, make it clear it’s not “real” and then close it or ask one of us to close
* Submit New License project: online tool, fill out form, and auto-creates an Issue in Github repo. Not as far along, so can’t see yet in online tools server. Gary gave us a demo.
** general workflow: user submits new license in form: 2 things then happen: populates a table of all licenses that have been submitted and status and issue is created in repo
** form is for person wanting to request new license
** (for Legal Team) can then click on row of table and click “generate XML file” and it will download XML to your computer, then can use that to create PR in regular way
** OR can go to XML editor tool and upload file, edit it, and use that PR feature
** this tool would replace email option for submitting new license - so, once usable can update those instructions (but may need a bit more work to get to that point)

2) Went through a couple “old issues” in repo that have “legal discussion” or have been hanging around. Notes made there

Legal Team/Minutes/2018-07-12

2018-07-26T17:08:14Z

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * Brad Edmondson * Steve Winslow * Mark Atwood * Dennis Clark * Kate Stewart == Agenda == 1) Monthly SPDX General call was earlier today and..."

== Attendees ==
* Jilayne Lovejoy
* Brad Edmondson
* Steve Winslow
* Mark Atwood
* Dennis Clark
* Kate Stewart

== Agenda ==
1) Monthly SPDX General call was earlier today and GSoC student, Tushar Mittal, presented his work so far on the online XML editor.
* http://13.57.134.254/app/ to try out tool in development and provide feedback. There may be bugs! Function to make Github pull request directly is being added (so keep in mind if testing)
* question as to whether generated PR comes from a person’s account or some generic; what about ability comment?
* follow-on feature to have way to view-as-webpage option
* we need to consider, when this is done, how does this impact/change the instructions for suggesting a new license:
** want to keep email option for people who aren’t comfortable
** or can use editor and generate PR directly? add option later
* maybe update https://spdx.org/spdx-license-list/request-new-license to align with https://github.com/spdx/license-list-XML/blob/master/CONTRIBUTING.md maybe just use the latter
** update webpage to just have a link to CONTRIBUTING.md
** update links to Request page on other pages elsewhere
** once confident we have caught those pages, can get rid of webpage

2) 3.2 is now live
* update for 3.2 major changes to email list
* explore adding “release notes” - is there a way to automate a list based on milestones going forward?

Legal Team/Minutes/2018-06-28

2018-07-05T21:19:47Z

Jlovejoy:

== Attendees ==
* Jilayne Lovejoy
* John Horan
* Dennis Clark
* Bradlee Edmondson
* Steve Winslow
* Gary O’Neall
* Paul Madick

== Agenda ==
1) 3.2 release
* went through outstanding PRs for 3.2 release; updated milestones and assigned a few new licenses that need PR made with XML and .txt files created
* Google patent grant - has 3 variations, Steve has captured in PR, but might be worth discussing for next release and reaching out to Google. Mostly used in Go language with BSD-3-Clause
* Recognized need to do better about how to define stuff that is included on “exception” part of license list - some other language more descriptive than "exception" might be better; all agree the clear feature of all of these things (like Google patent) is that they augment an existing license, live with the code (like a license) and apply across the project (like a license), but are not a license in and of themselves. To discuss more and ideas for changing name of that part of list, further improvements to description there in future (this was also identified as something to improve at the F2F meeting in March)

2) stale URL & case sensitive discussion (updated to SPDX License List collateral/website pages)
* discussed, and reviewed various comments in issues - as per consensus from all that, will add to Overview page the following bullet in the description of the URL field:
** "Note that the source URL may refer to an original URL for the license which is no longer active. We don't remove inactive URLs. New or best available URLs may be added."

Legal Team/Minutes/2018-06-28

2018-07-05T21:19:14Z

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * John Horan * Dennis Clark * Bradlee Edmondson * Steve Winslow * Gary O’Neall * Paul Madick == Agenda == 1) 3.2 release * went through ou..."

== Attendees ==
* Jilayne Lovejoy
* John Horan
* Dennis Clark
* Bradlee Edmondson
* Steve Winslow
* Gary O’Neall
* Paul Madick

== Agenda ==
1) 3.2 release
* went through outstanding PRs for 3.2 release
* Google patent grant - has 3 variations, Steve has captured in PR, but might be worth discussing for next release and reaching out to Google. Mostly used in Go language with BSD-3-Clause
* Recognized need to do better about how to define stuff that is included on “exception” part of license list - some other language more descriptive than "exception" might be better; all agree the clear feature of all of these things (like Google patent) is that they augment an existing license, live with the code (like a license) and apply across the project (like a license), but are not a license in and of themselves. To discuss more and ideas for changing name of that part of list, further improvements to description there in future (this was also identified as something to improve at the F2F meeting in March)

2) stale URL & case sensitive discussion (updated to SPDX License List collateral/website pages)
* discussed, and reviewed various comments in issues - as per consensus from all that, will add to Overview page the following bullet in the description of the URL field:
** "Note that the source URL may refer to an original URL for the license which is no longer active. We don't remove inactive URLs. New or best available URLs may be added."

Legal Team

2018-06-15T03:44:07Z

Jlovejoy:

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

Work for the SPDX Legal Team is done both via the mailing list and bi-weekly calls. In particular, the bi-weekly calls are used to discuss topics and issues that may be difficult to only discuss via email.

'''You can join the mailing list and otherwise manage your subscription here''': https://lists.spdx.org/g/spdx-legal

An invite for the bi-weekly calls is sent to the mailing list at the beginning of each year. If you join the mailing list later, you may not have gotten the invite. The details of the calls are below for anyone to join and meeting reminders are usually sent prior to the call on the mailing list.

The Legal Team meets '''every other Thursday at 17:00 GMT (9:00AM PT, 10:00 MT, 11:00 CT, 12:00PM ET)'''.

Web conference: http://uberconference.com/SPDXTeam
Optional dial in number: 415-881-1586
No PIN needed

* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]




[[Category:Legal]]

Legal Team

2018-06-15T03:43:37Z

Jlovejoy:

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

Work for the SPDX Legal Team is done both via the mailing list and bi-weekly calls. In particular, the bi-weekly calls are used to discuss topics and issues that may be difficult to only discuss via email.

'''You can join the mailing list and otherwise manage your subscription here''': https://lists.spdx.org/g/spdx-legal

An invite for the bi-weekly calls is sent to the mailing list at the beginning of each year. If you join the mailing list later, you may not have gotten the invite. The details of the calls are below for anyone to join and meeting reminders are usually sent prior to the call on the mailing list.

The Legal Team meets '''every other Thursday at 17:00 GMT (9:00AM PT, 10:00 MT, 11:00 CT, 12:00PM ET)'''.

Web conference: http://uberconference.com/SPDXTeam
Optional dial in number: 415-881-1586
No PIN needed

* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]




[[Category:Legal]]

Legal Team/Decisions

2018-06-15T03:43:02Z

Jlovejoy:

Below are links to significant decisions of the Legal Team. More information about these decisions most likely exists in the meeting minutes, but a summary has been posted here to make it easier to find.

* [[Legal_Team/Decisions/Inclusion_Guidelines_(Background)|License Inclusion Guidelines (Background)]]
* [[Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files_(DRAFT)|Dealing with Public Domain within SPDX Files]]
* [[Legal_Team/Decisions/SPDX_Metadata_License:_Preamble_and_CC0_1.0_Universal|SPDX Metadata License: Preamble and CC0 1.0 Universal]]
* [[media:SPDX-TR-2014-1.v1.1.pdf|SPDX Metadata License: Rationale for CC0]]

[[Category:Legal]]

Legal Team/Archive

2018-06-15T03:42:42Z

Jlovejoy:

==Archive==

These links go to working pages for past projects. These pages are archived for historical purposes but should NOT be used as a primary source of information and may not contain current or final decision information.

* [[Legal_Team/License_List/Licenses_Under_Consideration|Licenses & Exceptions Under Consideration]] Licenses or exceptions under consideration to be added to the SPDX License List are now tracked in the Github repository.
* [[Legal_Team/Templatizing|Working page for XML Templatizing project to improve machine detection & recognition]]
* [[Legal_Team/only-operator-proposal|Working page for policy on proposal to add only operator and otherwise better deal with license that have "or later" clauses overall]]
* [[Legal_Team/Archive/license_expression_syntax|License expression syntax proposal]] - original proposal for introduction of license expression syntax from 2014.

Legal Team/Archive/license expression syntax

2018-06-15T03:40:58Z

Jlovejoy: Jlovejoy moved page Legal Team/Decisions/license expression syntax to Legal Team/Archive/license expression syntax: move to new Archive section

== Information & Background on License Expression Syntax Proposal ==

* Background info on the issue is posted on the wiki here: http://wiki.spdx.org/view/Legal_Team/License_Expression_Review_1
* Examples are posted here: http://wiki.spdx.org/view/FileNoticeExamples

'''The following info was posted to the SPDX mailing lists on 9 April 2014:'''

Editor’s note: Big thanks to Mark Gisi for driving this important effort.

In the wake of a highly productive cross-functional meeting at the Linux Collaboration Summit, the SPDX Legal Team proposes certain changes to the SPDX specification and license list.

'''Statement of the problem''':

The current SPDX Specification and License List have a limited language (i.e. and/or) that is not suitable for expressing complex license situations (for examples of such complexity, see http://wiki.spdx.org/view/FileNoticeExamples ). Additionally, the current SPDX License List currently requires the addition of multiple licenses to the list in order to capture combinations of versions, the “or later” license genre (i.e. GPL-2.0 and GPL-2.0+) and the most common exceptions (i.e. GPL-2.0+-with-autoconf-exception and GPL-3.0-with-autoconf-exception). It should be noted that the SPDX Legal Team identified more than 30 discrete exceptions. Finally, license exceptions (i.e. autoconf-exception) are generally not versioned, and therefore, accounting for changes to the license exceptions when they are part of the canonical license creates opportunity for error and confusion. For additional background please see http://wiki.spdx.org/view/Legal_Team/License_Expression_Review_1

'''Aim''':

Improve the ability to describe more license variations utilizing some operator(s) without impact to the current timeline for the next version of the SPDX Specification.

'''Proposed Solution''':

'''1)''' “+” to be added to the SPDX Specification as an operator to denote “or later.” As a result, all current licenses on the SPDX License List with a “Full Name” that includes “or later” will be deprecated. Deprecated means the license entry will technically remain on the list (just moved to the Deprecated section) and list users will be highly discouraged from using them. Deprecated licenses are potentially subject to removal in a future version of the list.
* Example: The license GPL-2.0+ will be deprecated. License entry GPL-2.0 will remain on the SDPX license list and the following is still a valid license expression “GPL-2.0+”. This state’s GPL-2.0 or later because the “+” now plays the role of a unary operator that means ‘the version of this license or a later version’. The following would also be a valid license expression as well: EPL-1.0+ which means EPL-1.0 or a later version. The change of the “+” to an operator will make even more sense once one considers license exceptions (modifiers) in the next section.

'''2)''' “WITH” binary operator (similar to AND/OR) to be added to the SPDX Specification. It denotes that the license identified by the SPDX short name identifier is modified by a well-defined exception on a new “SPDX Modifier List” as described in section (3). As a result, all current licenses that include the term “exception” in the “Full Name” will be deprecated.
* Example: “GPL-2.0-with-bison-exception” will be deprecated but the following expression, which achieves the same result, is now valid: “GPL-2.0 WITH bison-exception”.

'''3)''' The Legal Team will be responsible for creating and maintaining the canonical list of SPDX License List modifiers (i.e. “auto-conf- exception, bison-exception”). It should be noted that licenses that are deprecated will be able to be expressed (more eloquently) with the new changes; hence no license will “fall off” the SPDX License List, nor will this create a compatibility issue. URL references to all deprecated licenses will be maintained for full backward compatibility.
* For example: the following is now a valid expression: “GPL-2.0+ WITH bison-exception” where the “+” and “WITH” operators allow a more flexible expression to be constructed. Prior to this addition this expression was not easy to express.

'''Longer Term Solution''':

Add capability for users to define modifier references local to an SPDX document, analogously the way LicRef is used for licenses not on the License List. This will involve adding “ModRef” to the SPDX Specification so the following would be a valid expression: “GPL-2.0 WITH ModRef23.” Where ModRef23 provides the text of a license modifier that does not appear on the SPDX Modifier List. In the initial proposed solution, the way to express a file with a GPL-2.0 license with an exception, that is not included on the SPDX Modifier canonical List, will be by including the full text of the license and the exception as a single LicRef (which is the current state of affairs as well).

[[Category:Legal]]

'''Rationale:'''

The proposed solution will provide the SPDX community the ability to express more licenses and license combinations in a more elegant and meaningful (human consumable) way then is currently available under the existing SPDX Specification and License List. To the extent that the SPDX community has come to rely on any of the licenses superseded by the new specifications those licenses will still be available on the SPDX License List (although deprecated). Finally, the initial proposed solution is a major improvement to the current situation and is easily extensible to the even more flexible longer term solution without impacting the current timeline for SPDX 2.0.

[[Category:Legal]]

Legal Team/Decisions/license expression syntax

2018-06-15T03:40:58Z

Jlovejoy: Jlovejoy moved page Legal Team/Decisions/license expression syntax to Legal Team/Archive/license expression syntax: move to new Archive section

#REDIRECT [[Legal Team/Archive/license expression syntax]]

Legal Team/Resources

2018-06-15T03:38:32Z

Jlovejoy:

==Resources ==
These links contain helpful information or other resources related to the SPDX License List or that has come out of work by the SPDX Legal team.

* [[Legal_Team/Fedora-comparison|Fedora/SPDX license list inclusion and comparison]]
* [[Legal_Team/later-version-clauses|Licenses with later-version clauses]]

Legal Team

2018-06-15T03:37:25Z

Jlovejoy:

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

Work for the SPDX Legal Team is done both via the mailing list and bi-weekly calls. In particular, the bi-weekly calls are used to discuss topics and issues that may be difficult to only discuss via email.

'''You can join the mailing list and otherwise manage your subscription here''': https://lists.spdx.org/g/spdx-legal

An invite for the bi-weekly calls is sent to the mailing list at the beginning of each year. If you join the mailing list later, you may not have gotten the invite. The details of the calls are below for anyone to join and meeting reminders are usually sent prior to the call on the mailing list.

The Legal Team meets '''every other Thursday at 17:00 GMT (9:00AM PT, 10:00 MT, 11:00 CT, 12:00PM ET)'''.

Web conference: http://uberconference.com/SPDXTeam
Optional dial in number: 415-881-1586
No PIN needed

* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]



'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]



[[Category:Legal]]

Legal Team/Archive

2018-06-15T03:37:02Z

Jlovejoy:

Legal Team

2018-06-15T03:36:19Z

Jlovejoy:

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

Work for the SPDX Legal Team is done both via the mailing list and bi-weekly calls. In particular, the bi-weekly calls are used to discuss topics and issues that may be difficult to only discuss via email.

'''You can join the mailing list and otherwise manage your subscription here''': https://lists.spdx.org/g/spdx-legal

An invite for the bi-weekly calls is sent to the mailing list at the beginning of each year. If you join the mailing list later, you may not have gotten the invite. The details of the calls are below for anyone to join and meeting reminders are usually sent prior to the call on the mailing list.

The Legal Team meets '''every other Thursday at 17:00 GMT (9:00AM PT, 10:00 MT, 11:00 CT, 12:00PM ET)'''.

Web conference: http://uberconference.com/SPDXTeam
Optional dial in number: 415-881-1586
No PIN needed

* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team]]
* [[Legal_Team/Resources|Resources]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]] - summaries of past significant decisions of the SPDX Legal Team
* [[Legal_Team/Archive|Archive]]

* [[Legal_Team/Fedora-comparison|Fedora/SPDX license list inclusion and comparison]]


'''Working pages for project in progress:'''
* [[Legal_Team/non-English-licenses|Working page for policy on how to handle non-English licenses and matching]]



[[Category:Legal]]