Skip to content

Latest commit

 

History

History
91 lines (69 loc) · 6.25 KB

2020-10-06.md

File metadata and controls

91 lines (69 loc) · 6.25 KB
Raw

SPDX Tech Team Minutes, October 6, 2020

Attending

  • William Bartholomew
  • Rishabh Bhatnagar
  • Nisha Kumar
  • Gary O'Neall
  • Peter Shin
  • Kate Stewart
  • Steve Winslow

Agenda

  • License Model Discussion

Minutes

CommunityBridge updates

  • Both students still doing some fixes on their code, probably running about a week behind but both doing well, good contributions
  • Python library ready for review, anyone one interested in using, should be review and identify high priority fixes. (Alexios is a mentor who can be looped in to help if something spotted.) The repository under development can be found here: https://github.com/Yash-Varshney/tools-python

License Model

2.2 model summary

  • AnyLicenseInfo - any license will be of this type; just a superclass, has no properties itself
  • SimpleLicensingInfo: represents either an extracted license or a listed license; text, name
  • Other types for representing license expressions:
    • OrLaterOperator ('+' in license expression) - only thing that can be Or-Later'd is an actual license, not a license expression
      • Note that this means that, at least according to the model, a LicenseRef- can have a + operator
    • ConjunctiveLicenseSet ('AND' in license expression) - one-to-many members, each of which is an AnyLicenseInfo
    • DisjunctiveLicenseSet ('OR') - same
    • WithExceptionOperator ('WITH') - two members, license to which the operator applies, and the exception
      • according to the model, should be able to apply an exception to a LicenseRef
  • SimpleLicensingInfo is also an abstract class: either ExtractedLicenseInfo or License
  • ExtractedLicenseInfo: Only one property, extractedText
  • License: separates out class of "License" from "ListedLicense", in order to allow more representations of licenses than what's in the SPDX License List itself
    • means that all fields are in the License field
    • fields should be current, but aren't documented in the spec anywhere
    • documenting it would be mostly about updating the text of the spec
  • ListedLicense: subclass of License, for licenses on the SPDX License List; currently don't find Licenses anywhere other than ListedLicenses

discussion of potential changes

  • Gary: would be clearer if licenseText were on SimpleLicensingInfo, rather than separate fields in children

  • Discussed licenseInfoFromFiles field (becoming Declared License), likely want to change this from SimpleLicenseInfo to AnyLicenseInfo, so that it can include exceptions as well as license expressions

  • Discussed: want to be able to enable folks to create custom exceptions. May want to have it so that different field names rather than LicenseName, etc. should be used for exceptions. Essentially, under LicenseException there would be two subclasses, extractedExceptionText and ListedException

    • Steve: If this is the direction we go with exceptions, the naming of "Extracted text","Extracted Licensing Info" - not sure if would translate into "Custom License" which is how we're using. Maybe something like "Custom" vs "Listed" as the distinction.
    • Gary: In serialization, in XML you seen the class names, and some of the other serializations, may make some sense and this is the time to do it.
    • Steve: Changing --> Extracted --> Custom, and moving ?? up to simple licening field.
    • Gary: Should we put License as the superclass? If all the fields are optional in license ids. Are any not applicable to extracted licensing info?

  • Steve: How about renaming AnyLicenseInfo to LicenseExpression?

    • Kate: LicenseExpression is more logical representation of concept
    • Gary: Has reservations. (Later discussion, potentially more okay with this change)
    • Steve: We want some way of representing a tree of license components? Its workable as is, but may be good to make it easier to folks.

  • Nisha: For tools not in the business of interpretting the license - there are a lot of no-assertions. If organizations have guidance that they don't want developers interpreting, just provide license text as is. Gets cluttererd, etc.

    • Kate: Not select the Licensing Profile?
    • Steve: All except for license text maybe should be optional? Then could do licensing profile, but it can be ommited as optional field.
    • Nisha: Seeing these use cases, wanting licenses interpretted by tool, others not so.

  • Steve: Filenotice could be used to represent the text of every file info was found. Then its there in document right there to the file.

  • Gary: Profile of lawyers change, tab on spreadsheet has all of license text. Its good to capture, as they will ask. Presenting in format that makes it easy to read the raw text.

  • Gary: NOASSERTION / NONE should be added as subclasses - NoneLicense / NoassertionLicense

  • Gary: AnyLicenseInfo => now like calling it LicenseExpression. Makes it more readable; also more users of the document will more likely use a string for the expression

  • Peter: ExtractedLicenseInfo - how to know author of license info?

    • Steve: Do you mean the author of the SPDX document, the author of the code, the author of the license itself?
    • Peter: How do I specify which version of the tool found something? which person found something? Meta information attach?
    • Kate: currently doing it at the document level, for tools or people etc.
    • Peter: How to capture which are required and optional from model?
    • Kate: 0..1, 0..n, 1..n, etc. in the model.

  • Rishabh: Currently, the SPDX model doesn't allow OrLaterOperator to have a WithExceptionOperator License and vice versa. It is not possible to have both of them at the same time.

    • Gary & Steve: agree, this needs to be clairified, and translate into the model as it exists now.

Next time: Review new version of model.