toggle quoted messageShow quoted text
Thanks for pulling this all together, and summarizing. :) Sorry I couldn't be on the last call. In reading through the summary couple of thoughts occurred.
Can I suggest LicenseSeen rather than LicenseInformation, as the name for that field? Information could get us back into those ambiguous name discussions for someone seeing this for the first time - using Seen might make it a bit more explicit that this is what was seen in the file for those not doing a detailed reading of the spec. ;)
In the case when there is a fragement or some non-standardized license, the references in the non-standard-license should be made with the same syntax, specifically "LICENSE"-N, Introducing new varients of keywords in the Non Standard License section, will cause complications I think, and lead to redundancy - ie. do I use "FullLicense-1" and "FullLicenseInformation-1" to refer to same license or not, are there multiple entries, etc.
--- On Mon, 2/7/11, Esteban Rockett <mgia3940@...> wrote:
From: Esteban Rockett <mgia3940@...>
Subject: Re: Purpose of licensing info
Date: Monday, February 7, 2011, 11:31 AM
SPDX Legal Workstream Members:
Below please find the revised Section 5.3 text discussed
during our last meeting, for your comment.
I will post the same to Bugzilla later today.
Proposal: Section 5.3 (License(s)) of the SPDX
Specification will become 3 fields:
5.3a Concluded License(s)
5.3a.1 Purpose: This field contains the license the
reviewer has concluded as governing the file, if it can be
determined. The options to populate this field are
limited to: (a) the SPDX standardized license short form
identifier; this should be used when the concluded license
is on the SPDX standardized license short list; (b) a
verbatim copy of the concluded license when the concluded
license is not on the SPDX standardized license short list
(“non-standard license”); (c) “UNDETERMINED”; this
should be used (i) if the reviewer has attempted to but
cannot reach a reasonable objective determination of the
concluded license, or (ii) if the reviewer is uncomfortable
concluding a license, despite some license information being
available; or (d) left blank; this should be used if the
reviewer has made no attempt to arrive at a concluded
license. With respect to “a” and “b” above, if
there is more than one concluded license, all should be
recited. If the recipient has a choice of multiple
licenses, then each of the choices should be recited as a
"disjunctive" license. With respect to “c”, a
written explanation must be provided in the License Comments
field below. Lastly, if the Conclude License(s)
conflicts with the License Information in File, a written
explanation must be provided in the License Comments field
5.3a.2 Intent: Here, the intent is to have the
reviewer analyze the License Information in File and other
objective information, e.g., “COPYING FILE”, etc.,
together with the results from any scanning tools, to arrive
at a reasonably objective conclusion as to what license is
governing the file.
5.3a.3 Cardinality: Mandatory, one or many.
5.3a.4 Tag: "LicenseConcluded:"
5.3a.5 RDF: TBD (include Disjunctive form here)
5.3a.6 Data Format: <short form identifier in Appendix
I> | "FullLicense"-N | UNDETERMINED | (left blank)
5.3b License Information in File
5.3b.1 Purpose: This field contains the license information
actually recited in the file, if any. Any license
information not actually in the file, e.g., “COPYING
FILE”, etc., should not be reflected in this field.
This information is most commonly found in the header of the
file, although it may be in other areas of the actual
file. The options to populate this field are limited
to: (a) the SPDX standardized license short form identifier;
this should be used when the license is on the SPDX
standardized license short list and has no ambiguous or
superfluous text; (b) a verbatim copy of the license
information the file when the license information in the
file is not on the SPDX standardized license short list
(“non-standard license”); (c) “NONE”; this should be
used if the actual file contains no license information; or
(d) left blank; this should be used if the reviewer has not
examined the contents of the actual files. With
respect to “a” and “b” above, if license information
for more than one license is recited in the file, all should
be reflected in this field. If the license information
offers the recipient a choice of licenses, then each of the
choices should be recited as a "disjunctive" licenses.
5.ba.2 Intent: Here, the intent is to provide the
reader with the license information actually in the file, as
compared to the Concluded License field.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseInformation:"
5.3b.5 RDF: TBD (not including disjunctive form, if
multiple many should be specified )
5.3b.6 Data Format: <short form identifier in Appendix
I> | "FullLicenseInformation"-N | NONE | (left blank)
5.3c License Comments
5.3c.1 Purpose: This field is a detailed description of the
analysis and any relevent background references that went in
to arriving at the Concluded License(s) for a file. If
the Concluded License(s) does not match the License
Information in File, such rationale must be recited by the
reviewer in this field. This field is also where an
explanation must be recited if the reviewer placed
“UNDETERMINED” as the Conclude License(s).
5.3c.2 Intent: Here, the intent is to provide the
reader with a detailed explanation of how the Concluded
License(s) was determined if it does not match the License
Information in File, is marked “UNDETERMINED”, or other
helpful information for the reader relevant to determining
the license of the file.
5.3c.3 Cardinality: Optional, single instance
5.3c.4 Tag: "LicenseComments:"
5.3c.5 RDF: TBD
5.3c.6 Data Format: free form text than can span multiple
lines, preceded with <text> and ending with
5.3c.7 Example: LicenseComments: <text> The Concluded
License(s) was taken from the package level that the file
was included in. This information was found in the
COPYING.txt file in the xyz directory. </text>
Spdx mailing list