Thanks Kris!

Regarding Gary’s comment about input format and the additional tags for fields 
in the spreadsheet - I got a bit cheeky and just added a suggestion for the 
missing ones (url, notes, psi-approved) to your MASTER example and the 
explanations below but not to the MATCHING FORMAT (to make it easier to see the 
difference).  

I also added them to the definition of tags list as well (with my initial next 
to them, again to call out what I have messed up, er, added to your work). 
Although much of the definitions of these fields is already written (here, see 
bottom of page: http://spdx.org/spdx-license-list/license-list-overview 
<http://spdx.org/spdx-license-list/license-list-overview>) so we can probably 
easily collapse/combine that info with the tag explanation as one.

As for the matching guidelines, I’m thinking those can probably be revised a 
bit more or be more explicit… it looks like you updated the statements as to 
whether markup is included in the template or not, as appropriate.  But I 
wonder if the explanation of the tags could be incorporated into the matching 
guidelines (I may have just contradicted my previous paragraph - thinking 
whilst typing…)

IN any case, hope to have some time on the legal call tomorrow to discuss! 
(agenda coming soon)

Jilayne

SPDX Legal Team co-lead
[email protected]


> On Mar 1, 2016, at 1:33 PM, Kris.re <[email protected]> wrote:
> 
> As long as there is a build process we can name them whatever we want; I was 
> referring more to the structure of them (for example, in my initial proposal 
> the ‘bullet’ tag was just an empty element, not retaining the initial value… 
> but now I’m suggesting we instead retain the initial text. Same for the 
> ‘synonym’ tag). Do you have specific items on your hit list? Any proposal 
> about what to do with tags that may not exist in the spec?
>  
> Re: extra columns, sure. I can go through and extend the current data as 
> appropriate, will try and work in some time to do that.
>  
> Kris
>  
> From: Gary O'Neall [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: Tuesday, March 01, 2016 12:47
> To: Kris.re <[email protected] <mailto:[email protected]>>; 
> [email protected] <mailto:[email protected]>; 'SPDX-legal' 
> <[email protected] <mailto:[email protected]>>
> Subject: RE: Updated templates
>  
> Thanks Kris!
>  
> Good progress on the formats and licenses (as well as some interesting 
> findings on the existing license texts).
>  
> Just a couple comments related to format.
>  
> Input format:
> In order to do away with the spreadsheet, we'll need a few more tags to 
> represent all of the columns (e.g. OSI approved, other web pages for the 
> license, notes).
>  
> Output format:
> I would propose the property names in the output format to be consistent with 
> the spec for consistency.  If we want the output XML format to be consistent 
> with the input format, we may want to change the names of the properties on 
> the input format to make the entire set of formats use consistent terms. 
>  
> Gary
>  
> From: [email protected] 
> <mailto:[email protected]> 
> [mailto:[email protected] 
> <mailto:[email protected]>] On Behalf Of Kris.re
> Sent: Monday, February 29, 2016 4:43 PM
> To: [email protected] <mailto:[email protected]>; 'SPDX-legal'
> Subject: Updated templates
>  
> Hello folks. The results of my second pass at converting the license list can 
> be found here:
> 
> https://github.com/myndzi/license-list/tree/xml-test/src 
> <https://github.com/myndzi/license-list/tree/xml-test/src>
> 
> Notably, I was a lot more aggressive with what qualifies as optional text. 
> The substantive body text of the licenses is no longer wrapped in any markup; 
> instead, the entire license body is wrapped in the <body> tag, and the 
> optional sections are nested inside. Optional sections should be taken to 
> mean optional *for the purpose of matching*; they may contain text that is 
> not optional for the purpose of actually utilizing the license. This was hard 
> to decide on in a few cases with preamble sections, for example, and is 
> probably not consistent in its treatment through every license.
>  
> I ran into a few strange cases and marked many of them with the ‘review’ 
> comment tag at the top of the file as before. I also noticed a few license 
> templates that actually include multiple licenses concatenated together; I am 
> uncertain how these should be dealt with, particularly with regards to 
> copyright notices in the “second” license and so forth. In one case (open 
> ssl, including the ssleay license text in whole) this may have been a 
> requirement of the license for the library the software was based on, but at 
> least one other case (I’m sorry: I don’t remember specifically which one) it 
> seemed more like things were just thrown together.
>  
> I noticed that the PHP license includes a reference to the Zend framework, 
> though there is a separate Zend license.
>  
> There are a few times where the license text proper has been interrupted by 
> an optional tag; that is to say, the meaningful text is not all one piece in 
> every license. For the purposes of matching, this may be difficult to resolve 
> – if you say that optional tags may be matched in an “all or nothing” manner, 
> you will fail to match in cases where the interleaved “optional” text is in 
> the form of a copyright notice which has been changed; marking these out as 
> alt text may be the correct solution.
> 
> I also updated the wiki:
>  
> http://wiki.spdx.org/view/Legal_Team/Templatizing/tags-matching 
> <http://wiki.spdx.org/view/Legal_Team/Templatizing/tags-matching>
>  
> I’ve outlined the general structure of the XML files here, as well as revised 
> my original proposal to make the master and matching formats almost identical.
>  
> I edited the matching guidelines to identify the ones that would change, 
> though I imagine the text I included could do to be revised. Applicable 
> sections are 7 through 12.
>  
> Please have a look if you’re interested and share feedback.
>  
> Kris
> _______________________________________________
> Spdx-legal mailing list
> [email protected] <mailto:[email protected]>
> https://lists.spdx.org/mailman/listinfo/spdx-legal 
> <https://lists.spdx.org/mailman/listinfo/spdx-legal>
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech

Reply via email to