Date   

Re: Use <year> <copyright holder> in 0BSD license text.

J Lovejoy
 

Hi Jakukyo,

Thanks for the input (and sorry for a slow response).

While I agree that others may and do use this license other than Rob Landley and ToyBox, the SPDX License List matching guidelines (#10) states that copyright notices can be ignored for purposes of matching. In other words, the same license with a different name in the copyright notice will still be considered the same licenses. https://spdx.org/spdx-license-list/matching-guidelines

We are in the process of improving the markup associated with the matching guidelines, so these kinds of things will only become more obvious in the future.

Hope that makes sense.

Jilayne

SPDX Legal Team co-lead
opensource@...

On Oct 13, 2016, at 9:17 AM, Jakukyo Friel <weakish@...> wrote:

Currently 0BSD text[0] uses the hard-coded year and copyright holder
value from the toybox project.

I think it is better to use `<year>` and `<copyright holder>` since
projects other than ToyBox may use 0BSD license.

[0]: https://spdx.org/licenses/0BSD.html
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal


Re: Unicode-TOU revision

Steven R. Loomis <srl295@...>
 

Hello, 
 My apologies for delay in responding.
What you wrote sounds reasonable process wise.

I ask because ICU (icu-project.org) is now released under what you identified as "Unicode-DFS-2016" and so it would be important to note the SPDX identifier.  I actually missed that "Unicode-TOU" did not cover the "DFS" part as well. 

 I will ask about making sure the copyright page is versioned and whether there are other revisions.

Thanks,
Steven

 

On Thu, Sep 29, 2016 at 11:51 AM, J Lovejoy <opensource@...> wrote:
Hi Steven,

We discussed this request on our call today and are a bit confused as to what you are requesting.  We observed the following changes, along with how we propose to deal with them.  Please let us know if this is right, and if you have any other information to add as to changes in the licenses, etc.

http://www.unicode.org/copyright.html has two licenses included: 
Unicode Terms of Use
Unicode, Inc. License Agreement - Data Files and Software

The Unicode Terms of Use (Unicode-TOU) are already included on the SPDX License List: https://spdx.org/licenses/Unicode-TOU.html
We noticed that there are recent (2016?) minor changes, namely the word “and” was added to A.3. and “Exhibit 1” was replaced with “License” and links to the license below.
We don’t deem these changes a requiring a new license, but would accommodate them with template markup.
- Does that sound okay to you?

We also noticed that we did not have Unicode, Inc. License Agreement - Data Files and Software on the SPDX License List. And that this license has changed (as of 2016) by dropping clause c.  
This change is significant and thus, we think we should add both the previous version (with clause c) and the current version (with clause c removed). To add these two versions, we need to come up with short identifiers to distinguish them, we have proposed the following:

Do you know if these are the only variations/versions? It would be helpful if Unicode versioned the licenses, but it does not appear to have done so and instead the website is merely updated, which is a bit hard to track.  This is why we simply used the year in the short identifier.  
Also, if you have a better suggestion for the short identifiers, that is welcome.

Thanks,
Jilayne


SPDX Legal Team co-lead
opensource@...


On Jul 27, 2016, at 3:07 PM, Steven R. Loomis <srl295@...> wrote:

Hello, - this license has a revision.

Short name: Unicode-TOU



Please note that the Unicode-TOU has been revved, see http://www.unicode.org/copyright.html – the ICU project is now under Unicode, and so ICU is now under Unicode-TOU and not under ICU 

Example use:
ICU website: http://site.icu-project.org link “open source license”

_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal



Re: Joint Call: Tuesday, Oct 25th w/Tech Team

Mark D. Baushke <mdb@...>
 

Hi Alexios,

Zavras, Alexios <alexios.zavras@...> writes:

I think there has been a misunderstanding.
Yes, that is very likely. I regret that I seem to be having trouble
understanding the topic. I will endeavor to make my point with more
clarity.

The "encoding" item on the agenda simply means that there is a
proposal to standardize on UTF-8 for the file format in which the XML
version of the licenses (in the SPDX master license repo) are stored.
Yes. My question seems to have been unclear. I regret this.

The difficulty is in the word standardize. UTF-8 allows for many
possible expressions of the same token. In particular, the text
expected in a standard license in XML will contain a number of
different characters which have multiple representations.

One meaning of the term standardize would be to come up with a single
cannincal representation for the template.

Will this meeting take up which of those many representations should be
used as the cannonical representation in the SPDX XML master license
repository?

Items we see in a copyright and license file may include multiple
representations of:

Double Quote, Single quote, Copyright Sign, Registered Sign, Trade
Mark Sign, etc.

Will there be an SPDX specification of what to put into the template
even if it may also be needful to look for the laternatives when doing
an extraction? Or, will there be an SPDX XML token that specifies the
class of representations that may be present?

fwiw: I would also hope that a full set of DTDs are to be generated for
the SPDX dialect of XML.

As to what you should be looking for, in order to extract copyright
notices, the list is longer than what you include. For example, when
reading an HTML file, the copyright symbol might be encoded as the
characters "&#169;" or "&#xa9;" (besides the "&copy;" that you have).
And strings in C or Python code might use ""\u00A9"" or "u"\u00A9"",
although these are probably not a copyright notice for the file
itself.
True. However, looking at the XML prototype license, what cannonical
form should be used to represent all of the other possible forms?

My original question was not clear.

I am asking if we are going to see something like <copyright-sign/> as
the SPDX XML template to represent any of the various encodings that
could exist?

For example, in MIT.xml should I see

<p>Copyright (c) &lt;year&gt; &lt;copyright holder&gt;</p>

or

<p>Copyright <copyright-sign/> <year-range/> <copyright-holder/></p>

so that each element could be used as a processing token for pattern
matching?

Also, in that file we have the text

(the "Software")

which uses U+0022 for the double quote. I have seen some documents that
are using the multibyte 'LEFT DOUBLE QUOTATION MARK' (U+201C) Software
'RIGHT DOUBLE QUOTATION MARK' (U+201D). What cannonical representation
will be used in the XML templates? My personal preference is U+201D.

I hope this helps with the understanding of my question as it relates to
UTF-8 selection for XML templates.

Please pardon the length of this message, I only endeavor to make my
question more clear.
--
Mark D. Baushke
mdb@...


Re: Joint Call: Tuesday, Oct 25th w/Tech Team

Alexios Zavras
 

I think there has been a misunderstanding.

 

The “encoding” item on the agenda simply means that there is a proposal to standardize on UTF-8 for the file format in which the XML version of the licenses (in the SPDX master license repo) are stored.

 

As to what you should be looking for, in order to extract copyright notices, the list is longer than what you include. For example, when reading an HTML file, the copyright symbol might be encoded as the characters “&#169;” or “&#xa9;” (besides the “&copy;” that you have). And strings in C or Python code might use “"\u00A9"” or “u"\u00A9"”, although these are probably not a copyright notice for the file itself.

 

 

-- zvr –

 

-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Mark D. Baushke
Sent: Friday, 21 October, 2016 18:16
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: Joint Call: Tuesday, Oct 25th w/Tech Team

 

Hi Jilayne & Paul,

 

- Encoding (propose UTF-8)

 

I have no problem with this. I do think that some folks may not completely understand the implications.

 

I would like to see a table of all of the representations of various copyright signs that we need to consider when we extract from a file.

 

To date I have observed the following:

 

  (c)         - 0x28 0x63 0x29

           (U+0028 U+0063 U+0029)

  (C)        - 0x28 0x43 0x29

           (U+0028 U+0043 U+0029)

         - 0xc2 0xa9 (U+00A9) - 'COPYRIGHT SIGN'

         - U+24B8 'circled latin capital letter c'

  &copy; - 0x26 0x63 0x6f 0x70 0x79 0x3b

           (U+0026 U+0063 U+006f U+0070 U+0079 U+003b)

 

Although I have only seen the graphic for the 'SOUND RECORDING COPYRIGHT' on labels, I thought it may also be worth mentioning:

 

  (P)    - 0x28 0x50 0x29 (U+0028 U+0050 U+0029)

               - 0xe2 0x84 0x97 (U+2117) 'SOUND RECORDING COPYRIGHT'

               - 0xe2 0x93 0x85 (U+24C5) 'circled latin captial letter p'

 

Note that I have also seen a bare 0xa9 in a file without the proceeding

0xc2 byte. Tehnically that is not a valid UTF-8 file representation. So, we may need to also consider how to handle those kinds of situations.

 

There are other interesting multiple representations in licenses such as:

 

  - ''as is'' (uses U+0027) and

  - "as is"   (uses quotation mark U+0022) and

  - &ldquo;as is&rdquo; and

  - <U+201C>as is<U+201D>

  - <U+201F>as is<U+201F>

 

there may be a few others as well.

 

I guess the point I am trying to make is that it may be desirable to transcode some UTF-8 into a cannonical and recommended encoding form when doing things like license extraction.

 

--

Mark D. Baushke

mdb@...

_______________________________________________

Spdx-legal mailing list

Spdx-legal@...

https://lists.spdx.org/mailman/listinfo/spdx-legal

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Joint Call: Tuesday, Oct 25th w/Tech Team

Mark D. Baushke <mdb@...>
 

Hi Jilayne & Paul,

- Encoding (propose UTF-8)

I have no problem with this. I do think that some folks may not
completely understand the implications.

I would like to see a table of all of the representations of various
copyright signs that we need to consider when we extract from a file.

To date I have observed the following:

(c) - 0x28 0x63 0x29
(U+0028 U+0063 U+0029)
(C) - 0x28 0x43 0x29
(U+0028 U+0043 U+0029)
- 0xc2 0xa9 (U+00A9) - 'COPYRIGHT SIGN'
- U+24B8 'circled latin capital letter c'
&copy; - 0x26 0x63 0x6f 0x70 0x79 0x3b
(U+0026 U+0063 U+006f U+0070 U+0079 U+003b)

Although I have only seen the graphic for the 'SOUND RECORDING
COPYRIGHT' on labels, I thought it may also be worth mentioning:

(P) - 0x28 0x50 0x29 (U+0028 U+0050 U+0029)
- 0xe2 0x84 0x97 (U+2117) 'SOUND RECORDING COPYRIGHT'
- 0xe2 0x93 0x85 (U+24C5) 'circled latin captial letter p'

Note that I have also seen a bare 0xa9 in a file without the proceeding
0xc2 byte. Tehnically that is not a valid UTF-8 file representation. So,
we may need to also consider how to handle those kinds of situations.

There are other interesting multiple representations in licenses such as:

- ''as is'' (uses U+0027) and
- "as is" (uses quotation mark U+0022) and
- &ldquo;as is&rdquo; and
- <U+201C>as is<U+201D>
- <U+201F>as is<U+201F>

there may be a few others as well.

I guess the point I am trying to make is that it may be desirable to
transcode some UTF-8 into a cannonical and recommended encoding form
when doing things like license extraction.

--
Mark D. Baushke
mdb@...


Re: Joint Call: Tuesday, Oct 25th w/Tech Team

Brad Edmondson
 

Works for me; thanks Jilayne and Gary.

Best,
Brad

--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

On Fri, Oct 21, 2016 at 12:29 AM, J Lovejoy <opensource@...> wrote:
We will have a joint call with tech team, joining their regular call time on Tuesday, Oct 25th @ 18:00 GMT (10:00AM PT, 11:00 MT, 12:00PM CT, 1:00PM ET).  Please mark your calendars.

Dial-in (same as we use): http://uberconference.com/SPDXTeam or  Call: +1-857-216-2871
PIN # 38633

Agenda:

Close on the terms and discuss any next steps related to the following items:
 
-          Encoding (propose UTF-8)
-          The high level element name
-          Paragraph tag or p or some other term
-          Use of the <br> tags
 
All of the proposals except encoding are on the Google docs page:


Thanks,
Jilayne & Paul
SPDX Legal Team co-leads



_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal



Joint Call: Tuesday, Oct 25th w/Tech Team

J Lovejoy
 

We will have a joint call with tech team, joining their regular call time on Tuesday, Oct 25th @ 18:00 GMT (10:00AM PT, 11:00 MT, 12:00PM CT, 1:00PM ET).  Please mark your calendars.

Dial-in (same as we use): http://uberconference.com/SPDXTeam or  Call: +1-857-216-2871
PIN # 38633

Agenda:

Close on the terms and discuss any next steps related to the following items:
 
-          Encoding (propose UTF-8)
-          The high level element name
-          Paragraph tag or p or some other term
-          Use of the <br> tags
 
All of the proposals except encoding are on the Google docs page:


Thanks,
Jilayne & Paul
SPDX Legal Team co-leads



Re: HPND & NTP

Alexios Zavras
 

Phil,

As it was explained in the bake-off: the disclaimer (second paragraph in the license text shown in https://spdx.org/licenses/HPND.html) is all enclosed in square brackets ("[...]"), and therefore was considered optional. The same happens with some individual words ("and", "that", etc.) of the first paragraph.

Therefore some text matching only the first paragraph can definitely match the complete license. That was the case found.

Yes, once this is correctly rendered in a template, this would be much more obvious.


-- zvr –

-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Philippe Ombredanne
Sent: Friday, 7 October, 2016 17:17
To: J Lovejoy <opensource@...>
Cc: spdx-tech@...; SPDX-legal <spdx-legal@...>
Subject: Re: HPND & NTP

On Fri, Oct 7, 2016 at 10:20 AM, J Lovejoy <opensource@...> wrote:
Hi All,

During the SPDX bake-off it came up that NTP
https://spdx.org/licenses/NTP.html can match to HPND
https://spdx.org/licenses/HPND.html due to the template nature of
HPND. The folks in the bakeoff wanted to know if we ought to
deprecate one of these licenses in favor of using the other or how a
tool should reconcile which license to “pick” where both could be a
valid answer. Talking about this here in Berlin and looking at the
licenses, can we please discuss the following items on the next legal call:

1) Both of these licenses are OSI-approved, which is why they are both
on the SPDX License List. Given that we endeavor to have all
OSI-approved licenses on the SPDX License List (even if they are old
or have been voluntarily deprecated by the author, as has HPND), so I
don’t view deprecation as an option. All agree?

2) As to HPND, we did not have markup for this license, but it needs
it - Sam has added markup to the XML template and Brad has reviewed.
It is flagged for review by the legal team:
https://github.com/spdx/license-list-XML/pull/89/files - can we get
another set of eyes on this, both from the legal perspective and to
check the markup?

3) OSI has comments as to how to “match” this license at the bottom of
their page - https://opensource.org/licenses/HPNDl - should we add
this to the Notes field, as is suggested in the XML file (do we really
need it, especially if we have the markup and since the line about
white space and capitalization merely repeats a couple of our matching
guidelines?)

4) I would recommend adding a comment in the Notes field for each
license along the lines of the following:
- for NTP: "This license is the same as HPND, when taking into
consideration the templatizing options given in that license. This is
included as a separate license on the SPDX License List because it is
separately approved by the OSI.”

- HPND: “Due to the templatization options of this license, it can be
the same text as NTP license. This is included as a separate license
on the SPDX License List because it is separately approved by the OSI.”

Please edit as needed. Perhaps we can then ask the OSI to add similar
language on their pages as well, so it is all consistent.
This all make sense. The only point is that the licenses are not the same, but are similar: the HPND has an additional warranty disclaimer.
So I am not sure why this would ever be an issue matching-wise and this may not warrant a note in the license.
--
Cordially
Philippe Ombredanne
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Use <year> <copyright holder> in 0BSD license text.

Jakukyo Friel <weakish@...>
 

Currently 0BSD text[0] uses the hard-coded year and copyright holder
value from the toybox project.

I think it is better to use `<year>` and `<copyright holder>` since
projects other than ToyBox may use 0BSD license.

[0]: https://spdx.org/licenses/0BSD.html


Canceled: SPDX Legal call

Paul Madick
 



The SPDX legal call today is canceled.  Jilayne is out of pocket and unfortunately I have a work emergency that conflicts with the time for our meeting.  We will reconvene in two weeks.
 
Best,
 
Paul
 


This email and all contents are subject to the following disclaimer:
"http://www.dimensiondata.com/emaildisclaimer"


Re: First pass of License XML terms completed by Tech Team

Gary O'Neall
 

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 “spdx.org/licenses”.  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.

 

Thanks,

Gary

 

From: Brad Edmondson [mailto:brad.edmondson@...]
Sent: Wednesday, October 12, 2016 11:13 AM
To: Gary O'Neall
Cc: spdx-tech@...; 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 comments:

 

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.

 

Best,

Brad


--

Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

 

On Tue, Oct 11, 2016 at 2:27 PM, <gary@...> 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: https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit

 

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 terms

 

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 attributes.

 

Thanks,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

 


_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal

 


Re: First pass of License XML terms completed by Tech Team

Brad Edmondson
 

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 comments:

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.

Best,
Brad

--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

On Tue, Oct 11, 2016 at 2:27 PM, <gary@...> 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: https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit

 

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 terms

 

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 attributes.

 

Thanks,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

 


_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal



First pass of License XML terms completed by Tech Team

Gary O'Neall
 

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: https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit

 

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 terms

 

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 attributes.

 

Thanks,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

 


Re: [PATCH] Fix typo where the name SUN was split across two lines.

Gary O'Neall
 

Hi Mark, Brad, and SPDX legal team,

I don't think we every discussed the encoding standards for the XML files -
we have standardized on UTF-8 for the license text in the current
git.spdx.org licenses repo and the SPDX documents themselves. I would
propose we standardize on UTF-8 for the XML as well to be consistent.

In terms of fixing the typo's, I'll coordinate with Jilayne on fixing (both
Jilayne and I have commit access to the git.spdx.org licenses repo).

Gary

-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-
bounces@...] On Behalf Of Mark D. Baushke
Sent: Friday, October 7, 2016 9:33 AM
To: Brad Edmondson
Cc: SPDX Legal
Subject: Re: [PATCH] Fix typo where the name SUN was split across two
lines.

Hi Brad,

As no documentation (other than searching the mailing list archive) on
the spdx.org site seems to point to github right now, I think it would
be best if someone could fix git.spdx.org sooner than later.

I would very much like to see both typos you mention fixed.

Regarding https://github.com/spdx/license-list-XML

Are we to assume that all of these are using an encodeing="ISO8859-1"

I am uncertain if there is any instanes of Unicode 'COPYRIGHT SIGN'
(U+00A9) being encoded as either hex (0xc2, 0xa9) or just hex (0xa9) as
I have found in some source files. (I already expect to see it as (c),
(C), and &copy; in various files...)

Thanks,
-- Mark
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal


Re: [PATCH] Fix typo where the name SUN was split across two lines.

Brad Edmondson
 

Thanks Mark, I think you have the right idea with that perspective.

Also, please note that the GH files are NOT STABLE in structure or in substantive content at this point, so you're right to continue to look to spdx.org for authoritative files.

Best,
Brad

--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

On Fri, Oct 7, 2016 at 12:33 PM, Mark D. Baushke <mdb@...> wrote:
Hi Brad,

As no documentation (other than searching the mailing list archive) on
the spdx.org site seems to point to github right now, I think it would
be best if someone could fix git.spdx.org sooner than later.

I would very much like to see both typos you mention fixed.

Regarding https://github.com/spdx/license-list-XML

Are we to assume that all of these are using an encodeing="ISO8859-1"

I am uncertain if there is any instanes of Unicode 'COPYRIGHT SIGN'
(U+00A9) being encoded as either hex (0xc2, 0xa9) or just hex (0xa9) as
I have found in some source files. (I already expect to see it as (c),
(C), and &copy; in various files...)

        Thanks,
        -- Mark


Re: [PATCH] Fix typo where the name SUN was split across two lines.

Mark D. Baushke <mdb@...>
 

Hi Brad,

As no documentation (other than searching the mailing list archive) on
the spdx.org site seems to point to github right now, I think it would
be best if someone could fix git.spdx.org sooner than later.

I would very much like to see both typos you mention fixed.

Regarding https://github.com/spdx/license-list-XML

Are we to assume that all of these are using an encodeing="ISO8859-1"

I am uncertain if there is any instanes of Unicode 'COPYRIGHT SIGN'
(U+00A9) being encoded as either hex (0xc2, 0xa9) or just hex (0xa9) as
I have found in some source files. (I already expect to see it as (c),
(C), and &copy; in various files...)

Thanks,
-- Mark


Re: HPND & NTP

Philippe Ombredanne
 

On Fri, Oct 7, 2016 at 10:20 AM, J Lovejoy <opensource@...> wrote:
Hi All,

During the SPDX bake-off it came up that NTP
https://spdx.org/licenses/NTP.html can match to HPND
https://spdx.org/licenses/HPND.html due to the template nature of HPND. The
folks in the bakeoff wanted to know if we ought to deprecate one of these
licenses in favor of using the other or how a tool should reconcile which
license to “pick” where both could be a valid answer. Talking about this
here in Berlin and looking at the licenses, can we please discuss the
following items on the next legal call:

1) Both of these licenses are OSI-approved, which is why they are both on
the SPDX License List. Given that we endeavor to have all OSI-approved
licenses on the SPDX License List (even if they are old or have been
voluntarily deprecated by the author, as has HPND), so I don’t view
deprecation as an option. All agree?

2) As to HPND, we did not have markup for this license, but it needs it -
Sam has added markup to the XML template and Brad has reviewed. It is
flagged for review by the legal team:
https://github.com/spdx/license-list-XML/pull/89/files - can we get another
set of eyes on this, both from the legal perspective and to check the
markup?

3) OSI has comments as to how to “match” this license at the bottom of their
page - https://opensource.org/licenses/HPNDl - should we add this to the
Notes field, as is suggested in the XML file (do we really need it,
especially if we have the markup and since the line about white space and
capitalization merely repeats a couple of our matching guidelines?)

4) I would recommend adding a comment in the Notes field for each license
along the lines of the following:
- for NTP: "This license is the same as HPND, when taking into consideration
the templatizing options given in that license. This is included as a
separate license on the SPDX License List because it is separately approved
by the OSI.”

- HPND: “Due to the templatization options of this license, it can be the
same text as NTP license. This is included as a separate license on the SPDX
License List because it is separately approved by the OSI.”

Please edit as needed. Perhaps we can then ask the OSI to add similar
language on their pages as well, so it is all consistent.
This all make sense. The only point is that the licenses are not the
same, but are similar: the HPND has an additional warranty disclaimer.
So I am not sure why this would ever be an issue matching-wise and
this may not warrant a note in the license.
--
Cordially
Philippe Ombredanne


Re: HPND & NTP

David A. Wheeler
 

Jilayne’s recommendation makes sense to me…!

 

--- David A. Wheeler

 

 

From: spdx-tech-bounces@... [mailto:spdx-tech-bounces@...] On Behalf Of J Lovejoy
Sent: Friday, October 07, 2016 4:21 AM
To: SPDX-legal
Cc: spdx-tech@...
Subject: HPND & NTP

 

Hi All,

 

During the SPDX bake-off it came up that NTP https://spdx.org/licenses/NTP.html can match to HPND https://spdx.org/licenses/HPND.html due to the template nature of HPND.  The folks in the bakeoff wanted to know if we ought to deprecate one of these licenses in favor of using the other or how a tool should reconcile which license to “pick” where both could be a valid answer.  Talking about this here in Berlin and looking at the licenses, can we please discuss the following items on the next legal call:

 

1) Both of these licenses are OSI-approved, which is why they are both on the SPDX License List. Given that we endeavor to have all OSI-approved licenses on the SPDX License List (even if they are old or have been voluntarily deprecated by the author, as has HPND), so I don’t view deprecation as an option.  All agree?

 

2) As to HPND, we did not have markup for this license, but it needs it - Sam has added markup to the XML template and Brad has reviewed. It is flagged for review by the legal team: https://github.com/spdx/license-list-XML/pull/89/files  - can we get another set of eyes on this, both from the legal perspective and to check the markup? 

 

3) OSI has comments as to how to “match” this license at the bottom of their page - https://opensource.org/licenses/HPNDl - should we add this to the Notes field, as is suggested in the XML file (do we really need it, especially if we have the markup and since the line about white space and capitalization merely repeats a couple of our matching guidelines?)

 

4) I would recommend adding a comment in the Notes field for each license along the lines of the following:

- for NTP: "This license is the same as HPND, when taking into consideration the templatizing options given in that license.  This is included as a separate license on the SPDX License List because it is separately approved by the OSI.”

 

- HPND: “Due to the templatization options of this license, it can be the same text as NTP license. This is included as a separate license on the SPDX License List because it is separately approved by the OSI.”

 

Please edit as needed.  Perhaps we can then ask the OSI to add similar language on their pages as well, so it is all consistent.

 

 

Thanks,

Jilayne

 

 

SPDX Legal Team co-lead
opensource@...

 


HPND & NTP

J Lovejoy
 

Hi All,

During the SPDX bake-off it came up that NTP https://spdx.org/licenses/NTP.html can match to HPND https://spdx.org/licenses/HPND.html due to the template nature of HPND.  The folks in the bakeoff wanted to know if we ought to deprecate one of these licenses in favor of using the other or how a tool should reconcile which license to “pick” where both could be a valid answer.  Talking about this here in Berlin and looking at the licenses, can we please discuss the following items on the next legal call:

1) Both of these licenses are OSI-approved, which is why they are both on the SPDX License List. Given that we endeavor to have all OSI-approved licenses on the SPDX License List (even if they are old or have been voluntarily deprecated by the author, as has HPND), so I don’t view deprecation as an option.  All agree?

2) As to HPND, we did not have markup for this license, but it needs it - Sam has added markup to the XML template and Brad has reviewed. It is flagged for review by the legal team: https://github.com/spdx/license-list-XML/pull/89/files  - can we get another set of eyes on this, both from the legal perspective and to check the markup? 

3) OSI has comments as to how to “match” this license at the bottom of their page - https://opensource.org/licenses/HPNDl - should we add this to the Notes field, as is suggested in the XML file (do we really need it, especially if we have the markup and since the line about white space and capitalization merely repeats a couple of our matching guidelines?)

4) I would recommend adding a comment in the Notes field for each license along the lines of the following:
- for NTP: "This license is the same as HPND, when taking into consideration the templatizing options given in that license.  This is included as a separate license on the SPDX License List because it is separately approved by the OSI.”

- HPND: “Due to the templatization options of this license, it can be the same text as NTP license. This is included as a separate license on the SPDX License List because it is separately approved by the OSI.”

Please edit as needed.  Perhaps we can then ask the OSI to add similar language on their pages as well, so it is all consistent.


Thanks,
Jilayne


SPDX Legal Team co-lead
opensource@...



Re: [PATCH] Fix typo where the name SUN was split across two lines.

Brad Edmondson
 

Issues here:

typo in BSD-3-Clause-No-Nuclear-License.txt

typo in BSD-3-Clause-No-Nuclear-License-2014.txt

Best,
Brad

--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

On Thu, Oct 6, 2016 at 12:37 PM, Brad Edmondson <brad.edmondson@...> wrote:
Thanks very much Mark for pointing out these issues and supplying a patch.

We are in the middle of a transition from the git repo on SPDX.org to github, so there will soon be an easy way to create a pull request for things like this. However, the BSD-3-Clause-No-Nuclear-License was added to the license list after the initial migration of existing licenses into the github repo. 

Can Gary or Kris or someone else with more developer experience weigh in on whether we should (a) do a true-up at the end of the SPDX legal license review project or (b) import newly accepted licenses into the GH repo one by one? As it stands I can pull things into GH but I do not have edit rights on the existing SPDX.org git repository, so I could correct this in a PR on GH but not in the existing text on git.spdx.org.

I also noticed a typo on line 2 of BSD-3-Clause-No-Nuclear-License-2014.txt which should be subject to a similar fix: either fix now in git.spdx.org and true-up GH later, or pull into GH and correct now. What do we all think about those options?

Best,
Brad

PS - I'll open GH issues for these so we don't forget them. That should be helpful regardless of which update path we choose.

--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

On Wed, Oct 5, 2016 at 11:12 AM, Mark Baushke <mdb@...> wrote:
Please pardon if this is the incorrect mailing list for patches to existing
license files.

For your consideration, the following is a suggested patch to the
http://git.spdx.org/license-list.git BSD-3-Clause-No-Nuclear-License.txt
file to make the name SUN appear on one line instead of being split
across two lines.

Note: I would suggest that the files in the git repository use a
canonical line ending for all of the files. Some files have \r\n
and some have \n only. Please be consistent where text may
be intended to be machine readable.

        Enjoy!
        -- Mark


_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal



1701 - 1720 of 3281