|
"LicenseInfoInFile" removes the ambiguity, so going with that seems reasonable.
Kate
|
--- On Tue, 2/8/11, Philip Odence <podence@...> wrote:
From: Philip Odence <podence@...>
Subject: Re: Purpose of licensing info
To: "Peter Williams" <peter.williams@...>
Cc: "Kate Stewart" <kate.stewart@...>, "spdx-legal@..." <spdx-legal@...>, "spdx@..." <spdx@...>, "Esteban Rockett" <mgia3940@...>
Date: Tuesday, February 8, 2011, 5:05 PM
Bear in mind that "LicenseInformation" is the Tag which is a short form of the full name, "License Information in File." This longer name was roundly supported by folks on the last Legal Team call, precisely I think, because it was unambiguous. I frankly am not sure of the limitations on Tag (or how Tag is used) but I would be in favor of "LicenseInformationinFile" or "LicenseInfoinFile".
L. Philip Odence Vice President of Business Development Black Duck Software, inc. 265 Winter Street, Waltham, MA 02451 Phone: 781.810.1819, Mobile: 781.258.9502
On Feb 8, 2011, at 5:44 PM, Peter Williams wrote: On Tue, Feb 8, 2011 at 10:41 AM, < kate.stewart@...> wrote: 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. ;)
I don't
love "LicenseSeen" but i agree that "LicenseInformation" a bit too ambiguous. 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,
We should either stick to one format or not specific the format of these ids at all. I lean toward just saying licenses have an id string and leaving it to the implementations to decide what those ids look like. It is likely that specifying the shape of license ids will make it more difficult to implement rdf/xml (or any other rdf format) file generators. Peter openlogic.com_______________________________________________ Spdx mailing
list Spdx@... https://fossbazaar.org/mailman/listinfo/spdx
-----Inline Attachment Follows-----
|
|
|
Bear in mind that "LicenseInformation" is the Tag which is a short form of the full name, "License Information in File." This longer name was roundly supported by folks on the last Legal Team call, precisely I think, because it was unambiguous. I frankly am not sure of the limitations on Tag (or how Tag is used) but I would be in favor of "LicenseInformationinFile" or "LicenseInfoinFile".
L. Philip Odence Vice President of Business Development Black Duck Software, inc. 265 Winter Street, Waltham, MA 02451 Phone: 781.810.1819, Mobile: 781.258.9502
On Feb 8, 2011, at 5:44 PM, Peter Williams wrote: On Tue, Feb 8, 2011 at 10:41 AM, < kate.stewart@...> wrote: 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. ;)
I don't love "LicenseSeen" but i agree that "LicenseInformation" a bit too ambiguous. 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,
We should either stick to one format or not specific the format of these ids at all. I lean toward just saying licenses have an id string and leaving it to the implementations to decide what those ids look like. It is likely that specifying the shape of license ids will make it more difficult to implement rdf/xml (or any other rdf format) file generators. Peter openlogic.com_______________________________________________ Spdx mailing list Spdx@... https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
Peter Williams <peter.williams@...>
On Tue, Feb 8, 2011 at 10:41 AM, <kate.stewart@...> wrote: 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. ;) I don't love "LicenseSeen" but i agree that "LicenseInformation" a bit too ambiguous. 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, We should either stick to one format or not specific the format of these ids at all. I lean toward just saying licenses have an id string and leaving it to the implementations to decide what those ids look like. It is likely that specifying the shape of license ids will make it more difficult to implement rdf/xml (or any other rdf format) file generators. Peter openlogic.com
|
|
|
Peter Williams <peter.williams@...>
On Mon, Feb 7, 2011 at 10:31 AM, Esteban Rockett <mgia3940@...> wrote: Below please find the revised Section 5.3 text discussed during our
last meeting, for your comment. I think Package should have an optional concluded licensing field also. 5.3a.4 Tag: "LicenseConcluded:" Given that the value of this property is potentially a disjunctive set of licenses (or license sets) would "Licensing" be better than "License" in the name? Also, -- and this one is just a matter of curiosity -- why was that word order chosen? "ConcludedLicense" seems like a more idiomatic formulation. Peter PS: I missed the last call so i apologize if these issues where covered there.
|
|
|
Hi Rockett,
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.
Thanks, Kate
toggle quoted message
Show quoted text
--- On Mon, 2/7/11, Esteban Rockett <mgia3940@...> wrote: From: Esteban Rockett <mgia3940@...>
Subject: Re: Purpose of licensing info
To: spdx@...
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.
Many thanks,
Rockett
***
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
below.
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.3a.7 Example:
LicenseConcluded: GPL-2.0
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.3b.7 Example:
LicenseInformation: GPL-2.0
LicenseInformation: FullLicenseInformation
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
</text>.
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
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
Esteban Rockett <mgia3940@...>
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.
Many thanks,
Rockett
***
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 below.
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.3a.7 Example:
LicenseConcluded: GPL-2.0
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.3b.7 Example:
LicenseInformation: GPL-2.0
LicenseInformation: FullLicenseInformation
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 </text>.
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>
***
|
|
|
Esteban Rockett <mgia3940@...>
** For SPDX Legal WorkStream **
As a means to drive comments/redlines, below please find were we left off in the last SPDX Legal Workstream Call for the following Sections.
Many thanks,
Rockett
***
Proposal: section 5.3 (License(s)) of the spec will become 3 fields:
5.3a Concluded License(s)
5.3a.1 Purpose: This field contains the license concluded as governing the file, if it can be determined. If no license information can be concluded, the license is denoted as "Unknown". The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Concluded License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is concluded in the file, then each should be listed. If any of the concluded licenses offer the recipient a choice of licenses, then each of the choices will be declared as a "disjunctive" license.
5.3a.2 Intent: Here, the intent is to have a uniform method to refer to the license that is concluded to represent the file with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD. If there is a conflict between the Concluded License(s) and Detected License(s) Information, the Concluded License(s) controls, and the rationale for the Concluded License must be recited in the License Comment field.
5.3a.3 Cardinality: Mandatory, one.
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
5.3a.7 Example:
LicenseAsserted: GPL-2.0
5.3b Detected License(s) Information
5.3b.1 Purpose: This field contains the license information recited in the file, if any. It will be explicit from the file header or other information found in the file's source code. If no license information is found it should be denoted as "NotSpecified". If no license information can be determined, the license is denoted as "Unknown". The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License Information does not correspond to one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a "disjunctive" license.
5.ba.2 Intent: Here, the intent is to have a uniform method to refer to each license objectively detected with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseDetected:"
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> | "FullLicense"-N
5.3b.7 Example:
LicenseDetected: GPL-2.0
LicenseDetected: FullLicense-2
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 Detected License(s) Information, such rationale must be recited by the reviewer in this field.
5.3c.2 Intent: Here, the intent is to provide technical readers/reviewers with a detailed technical explanation of how the Concluded License(s) was determined if it does not match the Detected License(s) Information.
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 </text>.
5.3c.7 Example: LicenseComments: <text> The Concluded License(s) was taken from the package level that the file was included in. </text>
***
toggle quoted message
Show quoted text
On 2011-01-20, at 7:20 AM, D M German wrote: Peter> The license of a license file is not necessarily the license defined Peter> in that file. For example, if the file COPYING contains the text of Peter> the GPL-v2 its license should be Peter> Everyone is permitted to copy and distribute verbatim copies of Peter> this license document, but changing it is not allowed. Thanks Peter, this is something I haven't thought about! --dmg -- Daniel M. German http://turingmachine.org/http://silvernegative.com/dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . _______________________________________________ Spdx mailing list Spdx@... https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
Peter> The license of a license file is not necessarily the license defined Peter> in that file. For example, if the file COPYING contains the text of Peter> the GPL-v2 its license should be Peter> Everyone is permitted to copy and distribute verbatim copies of Peter> this license document, but changing it is not allowed. Thanks Peter, this is something I haven't thought about! --dmg -- Daniel M. German http://turingmachine.org/http://silvernegative.com/dmg (at) uvic (dot) ca replace (at) with @ and (dot) with .
|
|
|
Peter Williams <peter.williams@...>
The license of a license file is not necessarily the license defined
in that file. For example, if the file COPYING contains the text of
the GPL-v2 its license should be
Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is not allowed.
because that is license under which the fsf allows copying the text of
the gpl.[1]
We could add a new property for license files to indicate the
license(s) they define/provide, separate from the license under which
they may be copied. Doing so would allow a transitivity approach.
Peter
openlogic.com
toggle quoted message
Show quoted text
On Fri, Jan 14, 2011 at 11:30 PM, dmg <dmg@...> wrote: From the point of view of maintenance of SPDX files, it would be
useful to say, in this case:
On Sat, Jan 15, 2011 at 1:11 AM, Peterson, Scott K (HP Legal)
<scott.k.peterson@...> wrote:
(3)
In the file:
“See COPYING” [where the COPYING file is a copy of the GPL] License: Same as [COPYING]
And COPYING
License: GPL-v2+
The license of the referring file might change without the file
actually being modified.
Basically, allow transitivity in the specification of the license.
Another alternative is to
include inthe referring file the actual license (GPLv2+) and a
standardized note saying:
this license comes from that file COPYING. That way if COPYING changes license
(the actual license changed, or it was incorrectly assessed in the
first place...etc)
this file should change license too.
--dmg
Metadata:
asserted license: GPL-2.0
license information in file: “See COPYING”
Is my understanding of the intent for recording information about what was
actually in the file correct?
-- Scott
--
--dmg
---
Daniel M. German
http://turingmachine.org
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
From the point of view of maintenance of SPDX files, it would be useful to say, in this case: On Sat, Jan 15, 2011 at 1:11 AM, Peterson, Scott K (HP Legal) <scott.k.peterson@...> wrote: (3)
In the file:
“See COPYING” [where the COPYING file is a copy of the GPL] License: Same as [COPYING] And COPYING License: GPL-v2+ The license of the referring file might change without the file actually being modified. Basically, allow transitivity in the specification of the license. Another alternative is to include inthe referring file the actual license (GPLv2+) and a standardized note saying: this license comes from that file COPYING. That way if COPYING changes license (the actual license changed, or it was incorrectly assessed in the first place...etc) this file should change license too. --dmg
Metadata:
asserted license: GPL-2.0
license information in file: “See COPYING”
Is my understanding of the intent for recording information about what was
actually in the file correct?
-- Scott
-- --dmg --- Daniel M. German http://turingmachine.org
|
|
|
Jilayne Lovejoy <Jlovejoy@...>
It seems like there are three possible scenarios for this field:
"I looked and found ____" = field propagated
"I looked and didn't find anything" = NotSpecified
"I didn't even look" = ? field left blank ?
I think the purpose should include the third scenario as well. "None" is confusing, as it is too similar to "NotSpecified" (not sure if that was the suggestion in any case)
5.3b.1 Purpose: This field contains license information explicitly found in the file. If no license information is found it should be denoted as "NotSpecified". If the file was not investigated, then this field should be left blank. This information could be represented using standard short form names. See Appendix I for standardized license short forms. If the detected license information is not one of the standardized license short forms, this field must contain a reference to the full text of the information found in the file included in this SPDX file in section 4. If more than one piece of license information is detected in the file, then each should be listed.
toggle quoted message
Show quoted text
-----Original Message----- From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Peterson, Scott K (HP Legal) Sent: Friday, January 14, 2011 8:41 AM To: Peter Williams Cc: spdx@... Subject: RE: Purpose of licensing info None would imply that one looked and none was found. Absence of the field would not imply whether there was or was not any license information in the file. For example, if someone wanted to use the SPDX format to represent the information for their project, they might manually create the data. They won't necessarily want to take the trouble to indicate whether there was information in each file or not. The asserted license field would be enough for their purpose. Others might prefer that they added information about what was explicitly in the file. Whether the developer wanted to do that extra work ought to be up to them. -- Scott -----Original Message----- From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Peter Williams Sent: Friday, January 14, 2011 10:36 AM To: spdx@... Subject: Re: Purpose of licensing info Given that the field is optional do we need a "none" value? Wouldn't the absence of this field mean "none". On Fri, Jan 14, 2011 at 8:15 AM, Peterson, Scott K (HP Legal) <scott.k.peterson@...> wrote: I have a revision to my proposal below. The file format should permit uses where no assertion about what licensing information is or is not explicitly present in the file. In those cases the field could be omitted. If one want to represent the fact the file was scanned for license information and none was found, the file could have a value of "NoneSpecified".
Thus the change to what I proposed below:
5.3b.3 Cardinality: Optional, zero or many.
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Peterson, Scott K (HP Legal)
Sent: Friday, January 14, 2011 9:46 AM
To: spdx@...
Subject: RE: Purpose of licensing info
With the intent that I heard on the phone this morning, calling the second license field "Detected License" or "Declared License" will confuse people as to the intended meaning of the information in this field. This field is representing information that may be useful in determining the applicable license terms. The field itself is not necessarily representing a license.
Thus I propose modifying 5.3b as follows:
5.3b Detected License Information
5.3b.1 Purpose: This field contains license information explicitly found in the file. If no license information is found it should be denoted as "NotSpecified". This information could be represented using standard short form names. See Appendix I for standardized license short forms. If the detected license information is not one of the standardized license short forms, this field must contain a reference to the full text of the information found in the file included in this SPDX file in section 4. If more than one piece of license information is detected in the file, then each should be listed.
5.ba.2 Intent: Here, the intent is to record the information that is explicitly present in the file that might be relevant to determination of the terms under which the file is licensed.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseInfo:"
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> | "FullLicense"-N
5.3b.7 Examples:
LicenseInfo: GPL-2.0
LicenseInfo: FullLicense-456
LicenseInfo: FullLicense-457
Where FullLicense-456 is "This file is licensed under the same terms as Perl."
where FullLicense-457 is "For license terms, see the file LICENSE."
-- Scott
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of kate.stewart@...
Sent: Thursday, January 13, 2011 2:47 PM
To: spdx@...
Subject: Re: Purpose of licensing info
Based on discussions on the SPDX call today, I think we are closing in on the following proposal for the file level to address the concerns raised by Open Logic.
There will be a special call tomorrow at 9am EST to get resolution on this issue. Please let Esteban Rockett or myself know, off-list, if you are interested in participating and were not in the legal call yesterday or the coordination call today.
Proposal: section 5.3 (License(s)) of the spec will become 3 fields:
5.3a Asserted License
5.3a.1 Purpose: This field contains the license governing the file if it can be determined. If no license information can be determined, the license is denoted as "Unknown". The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a "disjunctive" license.
5.3a.2 Intent: Here, the intent is to have a uniform method to refer to the license that is determined to represent the file with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3a.3 Cardinality: Mandatory, one.
5.3a.4 Tag: "LicenseAsserted:"
5.3a.5 RDF: TBD (include Disjunctive form here)
5.3a.6 Data Format: <short form identifier in Appendix I> | "FullLicense"-N
5.3a.7 Example:
LicenseAsserted: GPL-2.0
5.3b Detected License(s)
5.3b.1 Purpose: This field contains the license governing the file if it is known. It will be explicit from the file header or other information found in the file's source code. If no license information is found it should be denoted as "NotSpecified". If no license information can be determined, the license is denoted as "Unknown". The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a "disjunctive" license.
5.ba.2 Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseDetected:"
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> | "FullLicense"-N
5.3b.7 Example:
LicenseDetected: GPL-2.0
LicenseDetected: FullLicense-2
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 making the asserted license for a file, if the asserted license does not match the detected license that the person creating the SPDX file wants to share with the reviewers.
5.3c.2 Intent: Here, the intent is to provide technical readers/reviewers with a detailed technical explanation of how the asserted license was determined if it does not match the detected license.
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 </text>.
5.3c.7 Example: LicenseComments: <text> The asserted license was taken from the package level that the file was included in. </text>
The above is preliminary at this point, so needs some polishing. I've entered it in bugzilla (http://bugs.linux-foundation.org/show_bug.cgi?id=625), so after the discussion tomorrow, feel free to subscribe, and make improvements there.
Kate
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________ Spdx mailing list Spdx@... https://fossbazaar.org/mailman/listinfo/spdx_______________________________________________ Spdx mailing list Spdx@... https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
Agree.
Tom Incorvia
tom.incorvia@...
Direct: (512) 340-1336
Mobile: (408) 499 6850
toggle quoted message
Show quoted text
-----Original Message----- From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Kim Weins Sent: Friday, January 14, 2011 11:01 AM To: Peter Williams; SPDX Subject: Re: Purpose of licensing info I vote for best effort of the producer On Fri 1/14/11 9:51 AM, "Peter Williams" <peter.williams@...> wrote: On Fri, Jan 14, 2011 at 9:11 AM, Peterson, Scott K (HP Legal)
<scott.k.peterson@...> wrote:
(3)
In the file:
³See COPYING² [where the COPYING file is a copy of the GPL]
Metadata:
asserted license: GPL-2.0
license information in file: ³See COPYING² Are we going to define the mechanism for deciding if a bit of text
that is not a standard header is a licensing statement? Or is it just
the best effort of the producer?
Peter
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx _______________________________________________ Spdx mailing list Spdx@... https://fossbazaar.org/mailman/listinfo/spdxThis message has been scanned for viruses by MailController - www.MailController.altohiway.com
|
|
|
I vote for best effort of the producer On Fri 1/14/11 9:51 AM, "Peter Williams" <peter.williams@...> wrote: On Fri, Jan 14, 2011 at 9:11 AM, Peterson, Scott K (HP Legal)
<scott.k.peterson@...> wrote:
(3)
In the file:
³See COPYING² [where the COPYING file is a copy of the GPL]
Metadata:
asserted license: GPL-2.0
license information in file: ³See COPYING² Are we going to define the mechanism for deciding if a bit of text
that is not a standard header is a licensing statement? Or is it just
the best effort of the producer?
Peter
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
Peter Williams <peter.williams@...>
On Fri, Jan 14, 2011 at 9:11 AM, Peterson, Scott K (HP Legal) <scott.k.peterson@...> wrote: (3)
In the file:
“See COPYING” [where the COPYING file is a copy of the GPL]
Metadata:
asserted license: GPL-2.0
license information in file: “See COPYING” Are we going to define the mechanism for deciding if a bit of text that is not a standard header is a licensing statement? Or is it just the best effort of the producer? Peter
|
|
|
Peterson, Scott K (HP Legal) <scott.k.peterson@...>
Now that I understand the interest in representing material that was explicitly found in the file, let me check my understanding about what specifically is expected to be recorded. (1) In the file: [standard GPLv2+ header] Metadata: asserted license: GPL-2.0+ license information in file: GPL-2.0+ (2) In the file: “Licensed under GPL version 2 or any later version” Metadata: asserted license: GPL-2.0+ license information in file: “Licensed under GPL version 2 or any later version” (3) In the file: “See COPYING” [where the COPYING file is a copy of the GPL] Metadata: asserted license: GPL-2.0 license information in file: “See COPYING” Is my understanding of the intent for recording information about what was actually in the file correct? -- Scott
|
|
|
Peterson, Scott K (HP Legal) <scott.k.peterson@...>
"License Information in File" Yes, that is better. And, that avoids “detected”. From the phone call this morning, I understand people read different things into that word. -- Scott
From: Philip Odence [mailto:podence@...]
Sent: Friday, January 14, 2011 10:29 AM
To: Peterson, Scott K (HP Legal)
Cc: spdx@...
Subject: Re: Purpose of licensing info This all looks very good Scott. I think naming is really important. I suggest being even more explicit with the name of the field to avoid confusion all together and call it: "License Information in File" Vice President of Business Development Black Duck Software, inc. 265 Winter Street, Waltham, MA 02451 Phone: 781.810.1819, Mobile: 781.258.9502 On Jan 14, 2011, at 9:45 AM, Peterson, Scott K (HP Legal) wrote:
With the intent that I heard on the phone this morning, calling the second license field "Detected License" or "Declared License" will confuse people as to the intended meaning of the information in this field. This field is representing information that may be useful in determining the applicable license terms. The field itself is not necessarily representing a license.
Thus I propose modifying 5.3b as follows:
5.3b Detected License Information
5.3b.1 Purpose: This field contains license information explicitly found in the file. If no license information is found it should be denoted as “NotSpecified”. This information could be represented using standard short form names. See Appendix I for standardized license short forms. If the detected license information is not one of the standardized license short forms, this field must contain a reference to the full text of the information found in the file included in this SPDX file in section 4. If more than one piece of license information is detected in the file, then each should be listed.
5.ba.2 Intent: Here, the intent is to record the information that is explicitly present in the file that might be relevant to determination of the terms under which the file is licensed.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseInfo:"
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> | "FullLicense"-N
5.3b.7 Examples:
LicenseInfo: GPL-2.0
LicenseInfo: FullLicense-456
LicenseInfo: FullLicense-457
Where FullLicense-456 is "This file is licensed under the same terms as Perl."
where FullLicense-457 is "For license terms, see the file LICENSE."
-- Scott
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of kate.stewart@...
Sent: Thursday, January 13, 2011 2:47 PM
To: spdx@...
Subject: Re: Purpose of licensing info
Based on discussions on the SPDX call today, I think we are closing in on the following proposal for the file level to address the concerns raised by Open Logic.
There will be a special call tomorrow at 9am EST to get resolution on this issue. Please let Esteban Rockett or myself know, off-list, if you are interested in participating and were not in the legal call yesterday or the coordination call today.
Proposal: section 5.3 (License(s)) of the spec will become 3 fields:
5.3a Asserted License
5.3a.1 Purpose: This field contains the license governing the file if it can be determined. If no license information can be determined, the license is denoted as “Unknown”. The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a “disjunctive” license.
5.3a.2 Intent: Here, the intent is to have a uniform method to refer to the license that is determined to represent the file with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3a.3 Cardinality: Mandatory, one.
5.3a.4 Tag: "LicenseAsserted:"
5.3a.5 RDF: TBD (include Disjunctive form here)
5.3a.6 Data Format: <short form identifier in Appendix I> | "FullLicense"-N
5.3a.7 Example:
LicenseAsserted: GPL-2.0
5.3b Detected License(s)
5.3b.1 Purpose: This field contains the license governing the file if it is known. It will be explicit from the file header or other information found in the file’s source code. If no license information is found it should be denoted as “NotSpecified”. If no license information can be determined, the license is denoted as “Unknown”. The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a “disjunctive” license.
5.ba.2 Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseDetected:"
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> | "FullLicense"-N
5.3b.7 Example:
LicenseDetected: GPL-2.0
LicenseDetected: FullLicense-2
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 making the asserted license for a file, if the asserted license does not match the detected license that the person creating the SPDX file wants to share with the reviewers.
5.3c.2 Intent: Here, the intent is to provide technical readers/reviewers with a detailed technical explanation of how the asserted license was determined if it does not match the detected license.
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 </text>.
5.3c.7 Example: LicenseComments: <text> The asserted license was taken from the package level that the file was included in. </text>
The above is preliminary at this point, so needs some polishing. I've entered it in bugzilla (http://bugs.linux-foundation.org/show_bug.cgi?id=625), so after the discussion tomorrow, feel free to subscribe, and make improvements there.
Kate
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
Peterson, Scott K (HP Legal) <scott.k.peterson@...>
None would imply that one looked and none was found.
Absence of the field would not imply whether there was or was not any license information in the file.
For example, if someone wanted to use the SPDX format to represent the information for their project, they might manually create the data. They won't necessarily want to take the trouble to indicate whether there was information in each file or not. The asserted license field would be enough for their purpose. Others might prefer that they added information about what was explicitly in the file. Whether the developer wanted to do that extra work ought to be up to them.
-- Scott
toggle quoted message
Show quoted text
-----Original Message----- From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Peter Williams Sent: Friday, January 14, 2011 10:36 AM To: spdx@... Subject: Re: Purpose of licensing info Given that the field is optional do we need a "none" value? Wouldn't the absence of this field mean "none". On Fri, Jan 14, 2011 at 8:15 AM, Peterson, Scott K (HP Legal) <scott.k.peterson@...> wrote: I have a revision to my proposal below. The file format should permit uses where no assertion about what licensing information is or is not explicitly present in the file. In those cases the field could be omitted. If one want to represent the fact the file was scanned for license information and none was found, the file could have a value of "NoneSpecified".
Thus the change to what I proposed below:
5.3b.3 Cardinality: Optional, zero or many.
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Peterson, Scott K (HP Legal)
Sent: Friday, January 14, 2011 9:46 AM
To: spdx@...
Subject: RE: Purpose of licensing info
With the intent that I heard on the phone this morning, calling the second license field "Detected License" or "Declared License" will confuse people as to the intended meaning of the information in this field. This field is representing information that may be useful in determining the applicable license terms. The field itself is not necessarily representing a license.
Thus I propose modifying 5.3b as follows:
5.3b Detected License Information
5.3b.1 Purpose: This field contains license information explicitly found in the file. If no license information is found it should be denoted as "NotSpecified". This information could be represented using standard short form names. See Appendix I for standardized license short forms. If the detected license information is not one of the standardized license short forms, this field must contain a reference to the full text of the information found in the file included in this SPDX file in section 4. If more than one piece of license information is detected in the file, then each should be listed.
5.ba.2 Intent: Here, the intent is to record the information that is explicitly present in the file that might be relevant to determination of the terms under which the file is licensed.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseInfo:"
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> | "FullLicense"-N
5.3b.7 Examples:
LicenseInfo: GPL-2.0
LicenseInfo: FullLicense-456
LicenseInfo: FullLicense-457
Where FullLicense-456 is "This file is licensed under the same terms as Perl."
where FullLicense-457 is "For license terms, see the file LICENSE."
-- Scott
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of kate.stewart@...
Sent: Thursday, January 13, 2011 2:47 PM
To: spdx@...
Subject: Re: Purpose of licensing info
Based on discussions on the SPDX call today, I think we are closing in on the following proposal for the file level to address the concerns raised by Open Logic.
There will be a special call tomorrow at 9am EST to get resolution on this issue. Please let Esteban Rockett or myself know, off-list, if you are interested in participating and were not in the legal call yesterday or the coordination call today.
Proposal: section 5.3 (License(s)) of the spec will become 3 fields:
5.3a Asserted License
5.3a.1 Purpose: This field contains the license governing the file if it can be determined. If no license information can be determined, the license is denoted as "Unknown". The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a "disjunctive" license.
5.3a.2 Intent: Here, the intent is to have a uniform method to refer to the license that is determined to represent the file with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3a.3 Cardinality: Mandatory, one.
5.3a.4 Tag: "LicenseAsserted:"
5.3a.5 RDF: TBD (include Disjunctive form here)
5.3a.6 Data Format: <short form identifier in Appendix I> | "FullLicense"-N
5.3a.7 Example:
LicenseAsserted: GPL-2.0
5.3b Detected License(s)
5.3b.1 Purpose: This field contains the license governing the file if it is known. It will be explicit from the file header or other information found in the file's source code. If no license information is found it should be denoted as "NotSpecified". If no license information can be determined, the license is denoted as "Unknown". The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a "disjunctive" license.
5.ba.2 Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseDetected:"
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> | "FullLicense"-N
5.3b.7 Example:
LicenseDetected: GPL-2.0
LicenseDetected: FullLicense-2
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 making the asserted license for a file, if the asserted license does not match the detected license that the person creating the SPDX file wants to share with the reviewers.
5.3c.2 Intent: Here, the intent is to provide technical readers/reviewers with a detailed technical explanation of how the asserted license was determined if it does not match the detected license.
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 </text>.
5.3c.7 Example: LicenseComments: <text> The asserted license was taken from the package level that the file was included in. </text>
The above is preliminary at this point, so needs some polishing. I've entered it in bugzilla (http://bugs.linux-foundation.org/show_bug.cgi?id=625), so after the discussion tomorrow, feel free to subscribe, and make improvements there.
Kate
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________ Spdx mailing list Spdx@... https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
I assumed we'd want to distinguish between "I didn't look" and "I looked and found no license info."
L. Philip Odence Vice President of Business Development Black Duck Software, inc. 265 Winter Street, Waltham, MA 02451 Phone: 781.810.1819, Mobile: 781.258.9502
On Jan 14, 2011, at 10:36 AM, Peter Williams wrote: Given that the field is optional do we need a "none" value? Wouldn't the absence of this field mean "none". On Fri, Jan 14, 2011 at 8:15 AM, Peterson, Scott K (HP Legal) < scott.k.peterson@...> wrote: I have a revision to my proposal below. The file format should permit uses where no assertion about what licensing information is or is not explicitly present in the file. In those cases the field could be omitted. If one want to represent the fact the file was scanned for license information and none was found, the file could have a value of "NoneSpecified".
Thus the change to what I proposed below:
5.3b.3 Cardinality: Optional, zero or many.
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Peterson, Scott K (HP Legal)
Sent: Friday, January 14, 2011 9:46 AM
To: spdx@...
Subject: RE: Purpose of licensing info
With the intent that I heard on the phone this morning, calling the second license field "Detected License" or "Declared License" will confuse people as to the intended meaning of the information in this field. This field is representing information that may be useful in determining the applicable license terms. The field itself is not necessarily representing a license.
Thus I propose modifying 5.3b as follows:
5.3b Detected License Information
5.3b.1 Purpose: This field contains license information explicitly found in the file. If no license information is found it should be denoted as “NotSpecified”. This information could be represented using standard short form names. See Appendix I for standardized license short forms. If the detected license information is not one of the standardized license short forms, this field must contain a reference to the full text of the information found in the file included in this SPDX file in section 4. If more than one piece of license information is detected in the file, then each should be listed.
5.ba.2 Intent: Here, the intent is to record the information that is explicitly present in the file that might be relevant to determination of the terms under which the file is licensed.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseInfo:"
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> | "FullLicense"-N
5.3b.7 Examples:
LicenseInfo: GPL-2.0
LicenseInfo: FullLicense-456
LicenseInfo: FullLicense-457
Where FullLicense-456 is "This file is licensed under the same terms as Perl."
where FullLicense-457 is "For license terms, see the file LICENSE."
-- Scott
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of kate.stewart@...
Sent: Thursday, January 13, 2011 2:47 PM
To: spdx@...
Subject: Re: Purpose of licensing info
Based on discussions on the SPDX call today, I think we are closing in on the following proposal for the file level to address the concerns raised by Open Logic.
There will be a special call tomorrow at 9am EST to get resolution on this issue. Please let Esteban Rockett or myself know, off-list, if you are interested in participating and were not in the legal call yesterday or the coordination call today.
Proposal: section 5.3 (License(s)) of the spec will become 3 fields:
5.3a Asserted License
5.3a.1 Purpose: This field contains the license governing the file if it can be determined. If no license information can be determined, the license is denoted as “Unknown”. The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a “disjunctive” license.
5.3a.2 Intent: Here, the intent is to have a uniform method to refer to the license that is determined to represent the file with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3a.3 Cardinality: Mandatory, one.
5.3a.4 Tag: "LicenseAsserted:"
5.3a.5 RDF: TBD (include Disjunctive form here)
5.3a.6 Data Format: <short form identifier in Appendix I> | "FullLicense"-N
5.3a.7 Example:
LicenseAsserted: GPL-2.0
5.3b Detected License(s)
5.3b.1 Purpose: This field contains the license governing the file if it is known. It will be explicit from the file header or other information found in the file’s source code. If no license information is found it should be denoted as “NotSpecified”. If no license information can be determined, the license is denoted as “Unknown”. The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a “disjunctive” license.
5.ba.2 Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseDetected:"
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> | "FullLicense"-N
5.3b.7 Example:
LicenseDetected: GPL-2.0
LicenseDetected: FullLicense-2
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 making the asserted license for a file, if the asserted license does not match the detected license that the person creating the SPDX file wants to share with the reviewers.
5.3c.2 Intent: Here, the intent is to provide technical readers/reviewers with a detailed technical explanation of how the asserted license was determined if it does not match the detected license.
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 </text>.
5.3c.7 Example: LicenseComments: <text> The asserted license was taken from the package level that the file was included in. </text>
The above is preliminary at this point, so needs some polishing. I've entered it in bugzilla (http://bugs.linux-foundation.org/show_bug.cgi?id=625), so after the discussion tomorrow, feel free to subscribe, and make improvements there.
Kate
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________ Spdx mailing list Spdx@...https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
Peter Williams <peter.williams@...>
Given that the field is optional do we need a "none" value? Wouldn't the absence of this field mean "none". On Fri, Jan 14, 2011 at 8:15 AM, Peterson, Scott K (HP Legal) <scott.k.peterson@...> wrote: I have a revision to my proposal below. The file format should permit uses where no assertion about what licensing information is or is not explicitly present in the file. In those cases the field could be omitted. If one want to represent the fact the file was scanned for license information and none was found, the file could have a value of "NoneSpecified".
Thus the change to what I proposed below:
5.3b.3 Cardinality: Optional, zero or many.
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Peterson, Scott K (HP Legal)
Sent: Friday, January 14, 2011 9:46 AM
To: spdx@...
Subject: RE: Purpose of licensing info
With the intent that I heard on the phone this morning, calling the second license field "Detected License" or "Declared License" will confuse people as to the intended meaning of the information in this field. This field is representing information that may be useful in determining the applicable license terms. The field itself is not necessarily representing a license.
Thus I propose modifying 5.3b as follows:
5.3b Detected License Information
5.3b.1 Purpose: This field contains license information explicitly found in the file. If no license information is found it should be denoted as “NotSpecified”. This information could be represented using standard short form names. See Appendix I for standardized license short forms. If the detected license information is not one of the standardized license short forms, this field must contain a reference to the full text of the information found in the file included in this SPDX file in section 4. If more than one piece of license information is detected in the file, then each should be listed.
5.ba.2 Intent: Here, the intent is to record the information that is explicitly present in the file that might be relevant to determination of the terms under which the file is licensed.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseInfo:"
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> | "FullLicense"-N
5.3b.7 Examples:
LicenseInfo: GPL-2.0
LicenseInfo: FullLicense-456
LicenseInfo: FullLicense-457
Where FullLicense-456 is "This file is licensed under the same terms as Perl."
where FullLicense-457 is "For license terms, see the file LICENSE."
-- Scott
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of kate.stewart@...
Sent: Thursday, January 13, 2011 2:47 PM
To: spdx@...
Subject: Re: Purpose of licensing info
Based on discussions on the SPDX call today, I think we are closing in on the following proposal for the file level to address the concerns raised by Open Logic.
There will be a special call tomorrow at 9am EST to get resolution on this issue. Please let Esteban Rockett or myself know, off-list, if you are interested in participating and were not in the legal call yesterday or the coordination call today.
Proposal: section 5.3 (License(s)) of the spec will become 3 fields:
5.3a Asserted License
5.3a.1 Purpose: This field contains the license governing the file if it can be determined. If no license information can be determined, the license is denoted as “Unknown”. The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a “disjunctive” license.
5.3a.2 Intent: Here, the intent is to have a uniform method to refer to the license that is determined to represent the file with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3a.3 Cardinality: Mandatory, one.
5.3a.4 Tag: "LicenseAsserted:"
5.3a.5 RDF: TBD (include Disjunctive form here)
5.3a.6 Data Format: <short form identifier in Appendix I> | "FullLicense"-N
5.3a.7 Example:
LicenseAsserted: GPL-2.0
5.3b Detected License(s)
5.3b.1 Purpose: This field contains the license governing the file if it is known. It will be explicit from the file header or other information found in the file’s source code. If no license information is found it should be denoted as “NotSpecified”. If no license information can be determined, the license is denoted as “Unknown”. The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a “disjunctive” license.
5.ba.2 Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.
5.3b.3 Cardinality: Mandatory, one or many.
5.3b.4 Tag: "LicenseDetected:"
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> | "FullLicense"-N
5.3b.7 Example:
LicenseDetected: GPL-2.0
LicenseDetected: FullLicense-2
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 making the asserted license for a file, if the asserted license does not match the detected license that the person creating the SPDX file wants to share with the reviewers.
5.3c.2 Intent: Here, the intent is to provide technical readers/reviewers with a detailed technical explanation of how the asserted license was determined if it does not match the detected license.
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 </text>.
5.3c.7 Example: LicenseComments: <text> The asserted license was taken from the package level that the file was included in. </text>
The above is preliminary at this point, so needs some polishing. I've entered it in bugzilla (http://bugs.linux-foundation.org/show_bug.cgi?id=625), so after the discussion tomorrow, feel free to subscribe, and make improvements there.
Kate
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
This all looks very good Scott. I think naming is really important. I suggest being even more explicit with the name of the field to avoid confusion all together and call it: "License Information in File"
L. Philip Odence Vice President of Business Development Black Duck Software, inc. 265 Winter Street, Waltham, MA 02451 Phone: 781.810.1819, Mobile: 781.258.9502
On Jan 14, 2011, at 9:45 AM, Peterson, Scott K (HP Legal) wrote: With the intent that I heard on the phone this morning, calling the second license field "Detected License" or "Declared License" will confuse people as to the intended meaning of the information in this field. This field is representing information that may be useful in determining the applicable license terms. The field itself is not necessarily representing a license. Thus I propose modifying 5.3b as follows: 5.3b Detected License Information 5.3b.1 Purpose: This field contains license information explicitly found in the file. If no license information is found it should be denoted as “NotSpecified”. This information could be represented using standard short form names. See Appendix I for standardized license short forms. If the detected license information is not one of the standardized license short forms, this field must contain a reference to the full text of the information found in the file included in this SPDX file in section 4. If more than one piece of license information is detected in the file, then each should be listed. 5.ba.2 Intent: Here, the intent is to record the information that is explicitly present in the file that might be relevant to determination of the terms under which the file is licensed. 5.3b.3 Cardinality: Mandatory, one or many. 5.3b.4 Tag: "LicenseInfo:" 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> | "FullLicense"-N 5.3b.7 Examples: LicenseInfo: GPL-2.0 LicenseInfo: FullLicense-456 LicenseInfo: FullLicense-457 Where FullLicense-456 is "This file is licensed under the same terms as Perl." where FullLicense-457 is "For license terms, see the file LICENSE." -- Scott -----Original Message----- From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of kate.stewart@...Sent: Thursday, January 13, 2011 2:47 PM To: spdx@...Subject: Re: Purpose of licensing info Based on discussions on the SPDX call today, I think we are closing in on the following proposal for the file level to address the concerns raised by Open Logic. There will be a special call tomorrow at 9am EST to get resolution on this issue. Please let Esteban Rockett or myself know, off-list, if you are interested in participating and were not in the legal call yesterday or the coordination call today. Proposal: section 5.3 (License(s)) of the spec will become 3 fields: 5.3a Asserted License 5.3a.1 Purpose: This field contains the license governing the file if it can be determined. If no license information can be determined, the license is denoted as “Unknown”. The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a “disjunctive” license. 5.3a.2 Intent: Here, the intent is to have a uniform method to refer to the license that is determined to represent the file with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD. 5.3a.3 Cardinality: Mandatory, one. 5.3a.4 Tag: "LicenseAsserted:" 5.3a.5 RDF: TBD (include Disjunctive form here) 5.3a.6 Data Format: <short form identifier in Appendix I> | "FullLicense"-N 5.3a.7 Example: LicenseAsserted: GPL-2.0 5.3b Detected License(s) 5.3b.1 Purpose: This field contains the license governing the file if it is known. It will be explicit from the file header or other information found in the file’s source code. If no license information is found it should be denoted as “NotSpecified”. If no license information can be determined, the license is denoted as “Unknown”. The licenses should use the standard short form names. See Appendix I for standardized license short forms. If a Detected License is not one of the standardized license short forms, this field must contain a reference to the full licenses text included in this SPDX file in section 4. If more than one license is detected in the file, then each should be listed. If any of the detected licenses offer the recipient a choice of licenses, then each of the choices will be declared as a “disjunctive” license. 5.ba.2 Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD. 5.3b.3 Cardinality: Mandatory, one or many. 5.3b.4 Tag: "LicenseDetected:" 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> | "FullLicense"-N 5.3b.7 Example: LicenseDetected: GPL-2.0 LicenseDetected: FullLicense-2 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 making the asserted license for a file, if the asserted license does not match the detected license that the person creating the SPDX file wants to share with the reviewers. 5.3c.2 Intent: Here, the intent is to provide technical readers/reviewers with a detailed technical explanation of how the asserted license was determined if it does not match the detected license. 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 </text>. 5.3c.7 Example: LicenseComments: <text> The asserted license was taken from the package level that the file was included in. </text> The above is preliminary at this point, so needs some polishing. I've entered it in bugzilla ( http://bugs.linux-foundation.org/show_bug.cgi?id=625), so after the discussion tomorrow, feel free to subscribe, and make improvements there. Kate _______________________________________________ Spdx mailing list Spdx@...https://fossbazaar.org/mailman/listinfo/spdx _______________________________________________ Spdx mailing list Spdx@... https://fossbazaar.org/mailman/listinfo/spdx
|
|
|
