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

Technical Team/Minutes/2012-02-21

From SPDX Wiki
< Technical Team‎ | Minutes
Revision as of 20:33, 21 February 2012 by Goneall (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Minutes 2/21/2012

Attendees:

  •        Gary O’Neall
  •        Bill Schineller
  •        Kate Stewart
  •        Peter Williams
  •        Ed Warnicke
  •        Rana Rahal
  •        Brandon Robinson
  •        Rana Raha

Agenda:

  •        Review minutes from last week
  •        Discuss proposal for hierarchical supply chain (bug 818)

Need to figure out planning of breakout session for Linux Collab in April.

 

SPDX Licensable vs. SPDX Package - no clear decision from last week of how SPDX package relates to SPDX licensable.

 

Three proposals:

   - Ed: original

<a href="http://spdx.org/wiki/rough-proposal-signing-and-supply-chain-friendliness-spdx.2.0">http://spdx.org/wiki/rough-proposal-signing-and-supply-chain-friendliness-spdx.2.0</a>

   - Gary: Updated for property mappings and a proposal for referencing SPDX licensable (note that the referencing proposal is not considered very complete)

   <a href="http://spdx.org/wiki/2012-feb-1-merged-model-proposal">http://spdx.org/wiki/2012-feb-1-merged-model-proposal</a>

   - Peter(Licensable incorporated into Package) from mail list.

 

Discussion on annotations - when can it be used?

  - Example: a license header that is incorrect creeps into source, email permission from author to correct header prior to release of the package.

  - Example: producer after SPDX is created - sign combined entity only?

 

Annotation - include information you need. 

 

Failure mode example - inbound some source code,  upstream too lazy to do it, don't want to be bound by all rights reserved.. but want to put on SPDX data.

 

Discussion on concluded license vs. declared license - Ed asserting is it really is not needed if we have annotations.   Conflicting assertions - arbitrary subsequent opinions may be problematic, using current model.

 

Example for discussion: 

  Individual has created SPDX file, 2 files in high level directory,

The asserted license in the SPDX document is incorrect (inconsistent with text in the distribution).  How is this handled with annotations and make it clear it is an issue with the asserted license and not a new conclusion on the license?

 

  Basically there exists some complex scenarios as to when you need fine semantic differences to be explicit.  GPLv3 is going to be lots of opportunity for confusion adding in to mess.

 

  To what extent is the review field able to compensate for annotations?

Under discussion. 

 

  Very complicated networks that emerge, and want to know providence.

Want to preserve this...  duplicate vs. backward chains.  (copy or annotate on backward chain).

 

How to get closure & conclusions?  Mixing a couple of things here:

1) how SPDX licenseable elements refer to one another

   - problem that needs to be solved.

2) what is the model for an SPDX document (licensable, but what else is really needed, and what is modeled)

3) heirarchy mechanisms - URI/hashed/etc. (annotations vs. concluded licenses vs. reviewers.)

 

Concern: supply chain day, can use this as a way of picking brains once these proposals are fleshed out and structured for more working conversation.  Collaborative to work through problems rather than marketing to people.  Ed wants to have input from technical team into agenda.

 

Assertion that all the proposals are wrong size - either too big or too small.  Too much vague around the edges.   Reach conclusion and agree on.

 

Can we disconnect the mechanism we use for linking Licensable elements from the model?  Proposed as a way to move the discussion forward.

 

Some of the proposals for the linkage mechanism work well for RDF but not for tag/value. 

 

Gary proposed there may be a way to represent the RDF in a text file in a readable format using triplets.

Gary to send ideas.