Thanks Brad!


Excellent comments.


Your assumption on the crossRefs being an industry standard is correct.  It 
originates in a W3C RDF vocabulary.  Where feasible, we try to use the same 
terms as W3C to make it easy for people and tools to interpret the terms we 
come up with.


I agree with your proposal on the SPDX element proposal of SPDXLicenseDocument. 
 It raises a really good point as to the scope of the XML document.  I makes 
sense to me to allow these document to represent licenses other than listed 
licenses.  There are a few issues we would need to tackle, however.  The 
license ID’s would need to be unique.  We could use some kind of namespace to 
represent the listed  licenses and allow for uniquely identifiable other 
licenses.  We’ve solved this with the SPDX documents, so perhaps we could use a 
similar solution.  We could add an element “LicenseNamespace” which would be a 
URI.  For the listed licenses, it could simply be “”.  What do 
others on the tech team think?  We could add it to the topics for our next 
meeting Tuesday at 10 Pacific if there is time after our discussion of the 
bake-off results.


I don’t have a strong opinion on the other items, but I would be happy to 
facilitate any discussions to close on them in an upcoming tech call or a joint 
tech/legal call.





From: Brad Edmondson [] 
Sent: Wednesday, October 12, 2016 11:13 AM
To: Gary O'Neall
Cc:; SPDX Legal
Subject: Re: First pass of License XML terms completed by Tech Team


Thanks Gary,


I've gone through the linked document and made some comments, though I would 
ask the Tech Team to bear in mind I have some programming experience but none 
in the task of defining specs. With that said, these are my abbreviated 


SPDX element: I agree this should be changed as it's too vague, but I think I 
would prefer "SDPXLicense" for a single license and "SPDXLicenseDocument" (or 
something similar, maybe "SPDXLicenseCollection") representing a collection of 
SDPXLicense elements. I think "ListedLicense" is too tied to the current 
problem, and would be awkward for tools operating on single licenses later on.


CrossRefs: No objection or really any comment per se. It might just help to 
confirm that (as I assume) this comes from some other spec the Tech Team is 
familiar with, or is industry-standard and we/I just don't know it.


Avoiding collision with HTML: Much appreciated; this was super confusing (to 
me, at least) starting out on the XML conversion project.


<b> or <bullet>: This does have a matching purpose and so should probably be 
kept (as the Tech Team concluded)


<paragraph>: I'm sensitive to the goal of avoiding the collision with HTML, but 
this seems a bit cumbersome, and like it could affect the human-readability of 
the XML. If you look at the GH repo there are <p> tags all over the place. Do 
we need to have so many <p> tags, or is there some other way we can keep the 
files somewhat readable?


alt/name/match: I'm relatively new to SPDX, so I can't say I even begin to 
understand the difference among these three elements. But if we need them and 
tech is happy with leaving them as-is, I'm happy even in my ignorance.  :-)


<br> / newline: I have been removing these from the XML licenses I inspect in 
the GH repo, and I would propose removing it from the spec (replacing them with 
<p> or <paragraph> tags where they appear).


Should we add <header> or <sectionTitle> element? I'm wondering if we should 
have something to denote section headers/titles analogous to <h1>, <h2>, etc. 
in HTML. Note that I have been wrapping these in <p> tags as we import licenses 
in XML, e.g. here 



Gary and the rest of the Tech Team, thanks for all your good work, and I look 
forward to keeping up the momentum on this project, both on the spec side and 
on the XML-import side.





Brad Edmondson, Esq.
512-673-8782 |


On Tue, Oct 11, 2016 at 2:27 PM, <> wrote:

Greetings tech and legal teams,


In the technical workgroup, we just completed a first pass review of all of the 
terms and attributes proposed by Kris and the legal team.


The details can be found in the google doc:


The comments column represents the discussion in the tech team and includes any 
proposed changes.  I added a column to include the proposed new name for the 
element or attribute.


A couple of discussions I would like to highlight for the legal team.


We are proposing changing the names for many of the formatting element names.


We decided that some of the formatting tags have semantics – such as ignoring 
bullets.  These should be included in the RDF form of the license.  Some of the 
formatting tags are strictly formatting – such as br.  These will not be 
included in the RDF, but will be used to generate the HTML.


We also felt that we should use terms more human readable and different from 
the HTML tags – e.g. newline instead of br.  There were two reasons:

·         more human readable for those not familiar with HTML 

·         they do represent 2 different problem spaces and should use distinct 


We also spent some time discussing the syn element.  We all agreed that we 
should include a dictionary in XML form that would contain all of the synonyms 
documented in the license matching guidelines.  We has some concerns on 
including a syn element in the license XML files themselves.  In particular, we 
were concerned that new synonyms could be introduced in the license text that 
would be different from the matching guidelines.  We concluded that we may want 
to push this to a release 2 since it requires more discussion.


Please let us know if there is any concerns about the proposed terms and 





Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586



Spdx-legal mailing list


Spdx-legal mailing list

Reply via email to