THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Legal Team/Minutes/2013-05-23

From SPDX Wiki
Jump to: navigation, search

Attendees:

  • Jilayne Lovejoy, OpenLogic
  • Gary O'Neall, Source Auditor
  • Tom Incorvia, Micro Focus
  • Jason Buttura, Cisco
  • Karen Copenhaver, LF
  • Daniel German, U. of Victoria
  • Zac White, Entente
  • Jack Manbeck, TI
  • Phil Odence, Black Duck
  • Paul Madick, HP
  • Tom Vidal

Matching Guidelines joint discussion w/Legal and Tech teams

Review Current Proposal

  • Review of the proposal on Github from Daniel German – overview, explanation of proposal which uses double-curly brackets (a field) that include multiple attributes, e.g. a name for the item, type (e.g. options or required text), and an example; some (but only a few) regular expression language terms are used for this proposal
    • issue that this proposal it requires two files: one with the markup and one that is "plain" text for the license

Comments, Feedback

  • Gary's proposal to add another field which is the text to be used in the standard text output
    • or could re-purpose "example" text in Daniel's proposal
    • could this attribute first in field, for readability; order of attributes does not matter
    • make new attribute called "original" which contains text that was there, it would be required, but can be empty and have that listed first in field
    • more work for anyone doing this to create a new example, so using examples already there - seems more efficient
  • we will need to document the fields and attributes and explain what it is, intention, and so forth - should that become part of the spec or an exhibit to the spec? - TBD, Kate not on call
  • regular expression is common enough that it will not limit tool-makers/innovation for scanning development
    • SPDX tools will be updated to generate the standard text from the template and also generate a highlighted webpage for the license - thus allowing the license list to be maintained with 1 file per license (instead of two)
    • do people need to have a "plain" text files? can the templated text file be enough (i.e. idea of just having ONE file maintained and everything created from that? yes
    • can we take templates to GitHub (yes, we need to do this anyway)
  • what needs to have markup?
    • no question that we need markup for text that is within the license or additional exhibits that do not need to be included for the license to be a match
    • what about titles - is the guideline enough or do we need markup? discussed, decided to not markup titles as a rule and decide further as we go along
    • what about copyright notices (and issue that some copyright notices are for the license itself and some are for the code)? should be marked up

Process for Implementation

  • getting into process - what is the variability that we need to implement in current licenses? how to communicate that?
  • regular expression language probably too complicated to have legal team take-on. Daniel offered to do this part, but will need guidance from legal team as to what is variable
  • use text files and put {{ }} around
  • start with most common or problematic licenses first; track what has been reviewed by legal team
  • Gary and Daniel to sort out details for repository for getting files to Daniel, storing, access. etc - on GitHub or some such repository that we can all easily access
Retrieved from "https://wiki.spdx.org/index.php?title=Legal_Team/Minutes/2013-05-23&oldid=2555"