https://wiki.spdx.org/api.php?action=feedcontributions&user=Rockett&feedformat=atomSPDX Wiki - User contributions [en]2024-03-29T05:59:31ZUser contributionsMediaWiki 1.23.13https://wiki.spdx.org/view/Legal_Team/Minutes/2011-03-02Legal Team/Minutes/2011-03-022011-05-11T13:04:52Z<p>Rockett: </p>
<hr />
<div><p><p>SPDX Legal Worksteam Meeting Minutes – 02-March-2011</p><p>&nbsp;</p><p>Attendees:</p><p>Esteban Rockett (Motorola)</p><p>Karen Copenhaver (LF/Choate)</p><p>Kim Weins (OpenLogic)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Tom Incorvia (Microfocus)</p><p>Phil Odence (Blackduck) Paul Madick (HP)</p><p>Kate Stewart (Canonical)</p><p>Michael Herzog (NexB)</p><p>Scott Peterson (HP)</p><p>&nbsp;</p><p>**</p><p>- At Kate's suggestion, in revised Section 5.3, the following changes were agreed: &nbsp;</p><p>(1) change "License Information in File" TAG VALUE from "License Information:" to "LicenseInfoInFile:"; and</p><p>(2) normalize "Standard and Non-Standard License Information" across all Section 5.3 fields.</p><p>- Other minor suggested revisions to the Section 5.3 "field names" were discussed, but then withdrawn.</p><p>***</p></p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-03-09Legal Team/Minutes/2011-03-092011-05-11T13:02:19Z<p>Rockett: </p>
<hr />
<div><p><p>SPDX Legal Worksteam Meeting Minutes – 09-March-2011</p><p>&nbsp;</p><p>Attendees:</p><p>Esteban Rockett (Motorola)</p><p>Karen Copenhaver (LF/Choate)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Tom Incorvia (Microfocus)</p><p>Phil Odence (Blackduck)</p><p>Andy Wilson (Intel)</p><p>Michael Herzog (NexB)</p><p>Scott Peterson (HP)</p><p>&nbsp;</p><p>**</p><p>- This meeting was limited to discussion of the below proposals:</p><p>- The Apache 2.0 license was proposed as the license for all tools created by the SPDX group, inclusive of shell scripts.&nbsp;</p><p>- Further, the Apache 2.0 license was proposed as the suggested license to 3rd parties for any 3rd party desiring to open source a SPDX tool.</p><p>- All in attendance were in agreement to the above. &nbsp;No objections.</p><p>***</p></p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-03-23Legal Team/Minutes/2011-03-232011-05-11T13:00:54Z<p>Rockett: </p>
<hr />
<div><p><p>SPDX Legal Worksteam Meeting Minutes – 23-March-2011</p><p>&nbsp;</p><p>Attendees:</p><p>Esteban Rockett (Motorola)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Karen Copenhaver (LF/Choate)</p><p>Tom Incorvia (Microfocus)</p><p>Phil Odence (Blackduck) Paul Madick (HP)</p><p>Kate Stewart (Canonical)</p><p>Michael Herzog (NexB)</p><p>Scott Peterson (HP)</p><p>&nbsp;</p><p>**</p><p>&nbsp;</p><p>Minutes:</p><p>- The group re-reported that the SPDX Tools License is concluded to be Apache 2.0. &nbsp;Further, the SPDX team will recommend that any 3rd party desiring to open source SPDX tools, also license such 3rd party tools under the Apache 2.0 license. &nbsp;No objections.</p><p>- Kate confirmed that revised section 5.3 was being placed into the SPDX Beta Specification.</p><p>- Discussions began on "whether there is a need for the Author/Creator" field. &nbsp;</p><p>- A changelog approach to revisions of SPDX metadata was initially suggested by Kate. &nbsp;Tom and others substantially added.</p><p>- The "Confidentiality Statement/Field" was discussed, and generally agreed, but no specific implementation(s) was been concluded.</p><p>- Update on the "Templatizing" effort was given. &nbsp;See http://spdx.org/wiki/guidelines-templatizing-licenses</p><p>- It was suggested that we provide a public facing site of all known SPDX tools, when such tools are available.</p><p>***</p><div></div></p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-04-13Legal Team/Minutes/2011-04-132011-05-11T12:59:18Z<p>Rockett: </p>
<hr />
<div><p><p>SPDX Legal Worksteam Meeting Minutes – 13-April-2011</p><p>&nbsp;</p><p>Attendees:</p><p>Esteban Rockett (Motorola)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Karen Copenhaver (LF/Choate)</p><p>Tom Incorvia (Microfocus)</p><p>Phil Odence (Blackduck) Paul Madick (HP)</p><p>Kate Stewart (Canonical)</p><p>Michael Herzog (NexB)</p><p>Scott Peterson (HP)</p><p>Andy Wilson (Intel)</p><p>&nbsp;</p><p>**</p><p>&nbsp;</p><p>Minutes:</p><p>- Reports from FSFE Conference (Amsterdam) and Linux Foundation Summit (San Francisco) were given by workstream representatives. &nbsp;Comments, reactions, and support from all events was extremely positive. &nbsp;Most notably, Eben Moglen, Mark Radcliff, and Bradley Kuhn have also given their support for SPDX.</p><p>- The 3 big issues for the next few months were then opened for discussion. &nbsp;Those issues are:</p><p>(1) The "licensing/legal terms/disclaimer" for the SPDX meta-data;</p><p>(2) Method to revise SPDX metadata, including the option of using a changelog; and</p><p>(3) Confidentiality-state of SPDX metadata.&nbsp;</p><p>- Discussion on all 3 of the above began. &nbsp;</p><p>- Karen and Rockett introduced the team to the Open Data Commons PDDL 1.0&nbsp;(http://www.opendatacommons.org/licenses/pddl/1.0/) as a potential candidate to resolve #1 above.</p><p>- Discussion of the above topics to be continued at the next meeting.</p><p>***</p><div></div></p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-04-20Legal Team/Minutes/2011-04-202011-05-11T12:56:22Z<p>Rockett: </p>
<hr />
<div><p>&nbsp;</p><p>SPDX Legal Worksteam Meeting Minutes – 20-April-2011</p><p>&nbsp;</p><p>Attendees:</p><p>Esteban Rockett (Motorola)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Karen Copenhaver (LF/Choate)</p><p>Tom Incorvia (Microfocus)</p><p>Phil Odence (Blackduck)</p><p>Paul Madick (HP)</p><p>Kate Stewart (Canonical)</p><p>Michael Herzog (NexB)</p><p>Scott Peterson (HP)</p><p>Andy Wilson (Intel)</p><p>&nbsp;</p><p>**</p><p>&nbsp;</p><p>Minutes:</p><p>- The group continued to drive on the below key issues:</p><p>(1) The "licensing/legal terms/disclaimer" for the SPDX meta-data;</p><p>(2) Method to revise SPDX metadata, including the option of using a changelog; and</p><p>(3) Confidentiality-state of SPDX metadata.&nbsp;</p><p>- For #3 above, the group concluded that both a mandatory "radio-button" style confidentiality feature should be included in the specification, with an optional open text field for additional text, if needed.</p><p>- For #2, the group began discussing the Open Data Commons PDDL 1.0&nbsp;(http://www.opendatacommons.org/licenses/pddl/1.0/), and other alternative approaches. &nbsp;Creative Commons was re-visited and explained that CC is problematic if the author/creator can be anonymous as previously agreed.</p><p>***</p><p>&nbsp;</p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-04-20Legal Team/Minutes/2011-04-202011-05-11T12:55:31Z<p>Rockett: </p>
<hr />
<div><p><p>SPDX Legal Worksteam Meeting Minutes – 20-April-2011</p><p>&nbsp;</p><p>Attendees:</p><p>Esteban Rockett (Motorola)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Karen Copenhaver (LF/Choate)</p><p>Tom Incorvia (Microfocus)</p><p>Phil Odence (Blackduck)</p><p>Paul Madick (HP)</p><p>Kate Stewart (Canonical)</p><p>Michael Herzog (NexB)</p><p>Scott Peterson (HP)</p><p>Any Wilson (Intel)</p><p>&nbsp;</p><p>**</p><p>&nbsp;</p><p>Minutes:</p><p>- The group continued to drive on the below key issues:</p><p>(1) The "licensing/legal terms/disclaimer" for the SPDX meta-data;</p><p>(2) Method to revise SPDX metadata, including the option of using a changelog; and</p><p>(3) Confidentiality-state of SPDX metadata.&nbsp;</p><p>- For #3 above, the group concluded that both a mandatory "radio-button" style confidentiality feature should be included in the specification, with an optional open text field for additional text, if needed.</p><p>- For #2, the group began discussing the Open Data Commons PDDL 1.0&nbsp;(http://www.opendatacommons.org/licenses/pddl/1.0/), and other alternative approaches. &nbsp;Creative Commons was re-visited and explained that CC is problematic if the author/creator can be anonymous as previously agreed.</p><p>***</p><div></div></p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-02-09Legal Team/Minutes/2011-02-092011-03-02T13:16:36Z<p>Rockett: </p>
<hr />
<div><p>Legal Worksteam Meeting Minutes - 20110209<br /><br /><br />SPDX Legal Worksteam Meeting Minutes – 9-February-2011<br /><br /><br />Attendees:<br /><br />Esteban Rockett (Motorola)<br /><br />Karen Copenhaver (LF/Choate)<br /> Jilayne Lovejoy (OpenLogic)<br /><br />Kim Weins (OpenLogic)<br /><br />Tom Incorvia (Microfocus)<br /><br />Mark Gisi (WindRiver)<br /><br />Kate Stewart (Canonical)<br /><br />Phil Odence (BlackDuck)<br /><br />Scott Peterson (HP)<br /><br /></p><p><br />Minutes:<br />- This meeting focused on finalizing the text of Section 5.3.&nbsp; The final text is below. &nbsp;<br />- Lastly, logistics for "housekeeping matters", namely the License Template, default license for the SPDX metadata, and suggested license for SPDX tools, were discussed.&nbsp; More to come on those items in the meetings to follow.<br />- The next meeting is scheduled for 2-March-2011, when many will be in Boston for the Project Harmony meeting.<br /><br />***<br /><br />Final Draft:&nbsp; Section 5.3 (License(s)) of the SPDX Specification will become 3 fields:<br /><br /><br />5.3a Concluded License(s)<br /><br />5.3a.1 Purpose:&nbsp; This field contains the license the reviewer has concluded as governing the file, if it can be determined.&nbsp; 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.&nbsp; With respect to “a” and “b” above, if there is more than one concluded license, all should be recited.&nbsp; If the recipient has a choice of multiple licenses, then each of the choices should be recited as a "disjunctive" license.&nbsp; With respect to “c”, a written explanation must be provided in the License Comments field below.&nbsp; 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.<br /><br />5.3a.2 Intent:&nbsp; 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.<br /><br />5.3a.3 Cardinality:&nbsp; Mandatory, one or many.<br /><br />5.3a.4 Tag: "LicenseConcluded:"<br /><br />5.3a.5 RDF: TBD&nbsp; (include Disjunctive form here)<br /><br />5.3a.6 Data Format: &lt;short form identifier in Appendix I&gt; | "LicenseConcluded"-N | UNDETERMINED | (left blank)<br /><br />5.3a.7 Example:<br /><br />LicenseConcluded: GPL-2.0<br /><br />LicenseConcluded: FullLicenseInformation<br /><br /><br />5.3b License Information in File<br /><br />5.3b.1 Purpose: This field contains the license information actually recited in the file, if any.&nbsp; Any license information not actually in the file, e.g., “COPYING FILE”, etc., should not be reflected in this field.&nbsp; 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.&nbsp; 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.&nbsp; If the license information offers the recipient a choice of licenses, then each of the choices should be recited as a "disjunctive" licenses.<br /><br />5.ba.2 Intent:&nbsp; Here, the intent is to provide the reader with the license information actually in the file, as compared to the Concluded License field.<br /><br />5.3b.3 Cardinality:&nbsp; Mandatory, one or many.<br /><br />5.3b.4 Tag: "LicenseInfoInFile:" <br /><br />5.3b.5 RDF: TBD (not including disjunctive form, if multiple many should be specified )<br /><br />5.3b.6 Data Format: &lt;short form identifier in Appendix I&gt; | "LicenseInfoInFile"-N | NONE | (left blank)<br /><br />5.3b.7 Example:<br /><br />LicenseInfoInFile: GPL-2.0<br /><br />LicenseInfoInFile: FullLicenseInformation<br /><br /><br />5.3c License Comments<br /><br />5.3c.1 Purpose: This field is a detailed description of the analysis and any relevant background references that went in to arriving at the Concluded License(s) for a file.&nbsp; 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).<br /><br />5.3c.2 Intent:&nbsp; 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.<br /><br />5.3c.3 Cardinality: Optional, single instance<br /><br />5.3c.4 Tag: "LicenseComments:" <br /><br />5.3c.5 RDF: TBD<br /><br />5.3c.6 Data Format: free form text than can span multiple lines, preceded with &lt;text&gt; and ending with &lt;/text&gt;.<br /><br />5.3c.7 Example: LicenseComments: &lt;text&gt; The Concluded License(s) was taken from the package level that the file was included in.&nbsp; This information was found in the COPYING.txt file in the xyz directory. &lt;/text&gt;<br /><br /><br />***</p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-02-09Legal Team/Minutes/2011-02-092011-03-02T13:16:14Z<p>Rockett: </p>
<hr />
<div><p>Legal Worksteam Meeting Minutes - 20110209<br /><br /><br />SPDX Legal Worksteam Meeting Minutes – 9-February-2011<br /><br /><br />Attendees:<br /><br />Esteban Rockett (Motorola)<br /><br />Karen Copenhaver (LF/Choate)<br /> Jilayne Lovejoy (OpenLogic)<br /><br />Kim Weins (OpenLogic)<br /><br />Tom Incorvia (Microfocus)<br /><br />Mark Gisi (WindRiver)<br /><br />Kate Stewart (Canonical)<br /><br />Phil Odence (BlackDuck)<br /><br />Scott Peterson (HP)<br /><br /><br />Minutes:<br />- This meeting focused on finalizing the text of Section 5.3.&nbsp; The final text is below. &nbsp;<br />- Lastly, logistics for "housekeeping matters", namely the License Template, default license for the SPDX metadata, and suggested license for SPDX tools, were discussed.&nbsp; More to come on those items in the meetings to follow.<br />- The next meeting is scheduled for 2-March-2011, when many will be in Boston for the Project Harmony meeting.<br /><br />***<br /><br />Final Draft:&nbsp; Section 5.3 (License(s)) of the SPDX Specification will become 3 fields:<br /><br /><br />5.3a Concluded License(s)<br /><br />5.3a.1 Purpose:&nbsp; This field contains the license the reviewer has concluded as governing the file, if it can be determined.&nbsp; 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.&nbsp; With respect to “a” and “b” above, if there is more than one concluded license, all should be recited.&nbsp; If the recipient has a choice of multiple licenses, then each of the choices should be recited as a "disjunctive" license.&nbsp; With respect to “c”, a written explanation must be provided in the License Comments field below.&nbsp; 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.<br /><br />5.3a.2 Intent:&nbsp; 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.<br /><br />5.3a.3 Cardinality:&nbsp; Mandatory, one or many.<br /><br />5.3a.4 Tag: "LicenseConcluded:"<br /><br />5.3a.5 RDF: TBD&nbsp; (include Disjunctive form here)<br /><br />5.3a.6 Data Format: &lt;short form identifier in Appendix I&gt; | "LicenseConcluded"-N | UNDETERMINED | (left blank)<br /><br />5.3a.7 Example:<br /><br />LicenseConcluded: GPL-2.0<br /><br />LicenseConcluded: FullLicenseInformation<br /><br /><br />5.3b License Information in File<br /><br />5.3b.1 Purpose: This field contains the license information actually recited in the file, if any.&nbsp; Any license information not actually in the file, e.g., “COPYING FILE”, etc., should not be reflected in this field.&nbsp; 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.&nbsp; 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.&nbsp; If the license information offers the recipient a choice of licenses, then each of the choices should be recited as a "disjunctive" licenses.<br /><br />5.ba.2 Intent:&nbsp; Here, the intent is to provide the reader with the license information actually in the file, as compared to the Concluded License field.<br /><br />5.3b.3 Cardinality:&nbsp; Mandatory, one or many.<br /><br />5.3b.4 Tag: "LicenseInfoInFile:" <br /><br />5.3b.5 RDF: TBD (not including disjunctive form, if multiple many should be specified )<br /><br />5.3b.6 Data Format: &lt;short form identifier in Appendix I&gt; | "LicenseInfoInFile"-N | NONE | (left blank)<br /><br />5.3b.7 Example:<br /><br />LicenseInfoInFile: GPL-2.0<br /><br />LicenseInfoInFile: FullLicenseInformation<br /><br /><br />5.3c License Comments<br /><br />5.3c.1 Purpose: This field is a detailed description of the analysis and any relevant background references that went in to arriving at the Concluded License(s) for a file.&nbsp; 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).<br /><br />5.3c.2 Intent:&nbsp; 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.<br /><br />5.3c.3 Cardinality: Optional, single instance<br /><br />5.3c.4 Tag: "LicenseComments:" <br /><br />5.3c.5 RDF: TBD<br /><br />5.3c.6 Data Format: free form text than can span multiple lines, preceded with &lt;text&gt; and ending with &lt;/text&gt;.<br /><br />5.3c.7 Example: LicenseComments: &lt;text&gt; The Concluded License(s) was taken from the package level that the file was included in.&nbsp; This information was found in the COPYING.txt file in the xyz directory. &lt;/text&gt;<br /><br /><br />***</p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-01-26Legal Team/Minutes/2011-01-262011-02-07T17:25:21Z<p>Rockett: </p>
<hr />
<div><p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Legal Worksteam Meeting Minutes - 20110126</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">SPDX Legal Worksteam Meeting Minutes – 26-January-2011</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Attendees:</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Esteban Rockett (Motorola)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;"><br /><br />
Jilayne Lovejoy (OpenLogic)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Tom Incorvia (Microfocus)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Mark Gisi (WindRiver)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Steve Grandchamp (OpenLogic)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Andy Wilson (Intel)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Steve Mc (OpenLogic)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Paul Madick (HP)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Kate Stewart (Canonical)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Phil Odence (BlackDuck)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Michael Herzog (NexB)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Helvetica;">Minutes:</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Helvetica;">- This meeting focused on revising the text of Section 5.3 consistent with the meeting of 14-January-2011.</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Helvetica;">- The text discussed is below. &nbsp;</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Helvetica;">- Workstream members are requested to review and provided comments and/or bring comments to the next meeting scheduled for 9-February-2011.</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">***</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">Proposal:&nbsp; Section 5.3 (License(s)) of the SPDX Specification will become 3 fields:</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3a Concluded License(s)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3a.1 Purpose:&nbsp; This field contains the license the reviewer has concluded as governing the file, if it can be determined.&nbsp; 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.&nbsp; With respect to “a” and “b” above, if there is more than one concluded license, all should be recited.&nbsp; If the recipient has a choice of multiple licenses, then each of the choices should be recited as a "disjunctive" license.&nbsp; With respect to “c”, a written explanation must be provided in the License Comments field below.&nbsp; 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.</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3a.2 Intent:&nbsp; 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.</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3a.3 Cardinality:&nbsp; Mandatory, one or many.</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3a.4 Tag: "LicenseConcluded:"</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3a.5 RDF: TBD&nbsp; (include Disjunctive form here)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3a.6 Data Format: &lt;short form identifier in Appendix I&gt; | "FullLicense"-N | UNDETERMINED | (left blank)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3a.7 Example:</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">LicenseConcluded: GPL-2.0</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3b License Information in File</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3b.1 Purpose: This field contains the license information actually recited in the file, if any.&nbsp; Any license information not actually in the file, e.g., “COPYING FILE”, etc., should not be reflected in this field.&nbsp; This information is most commonly found in the header of the file, although it may be in other areas of the actual file.&nbsp; 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.&nbsp; 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.&nbsp; If the license information offers the recipient a choice of licenses, then each of the choices should be recited as a "disjunctive" licenses.</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.ba.2 Intent:&nbsp; Here, the intent is to provide the reader with the license information actually in the file, as compared to the Concluded License field.</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3b.3 Cardinality:&nbsp; Mandatory, one or many.</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3b.4 Tag: "LicenseInformation:"&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3b.5 RDF: TBD (not including disjunctive form, if multiple many should be specified )</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3b.6 Data Format: &lt;short form identifier in Appendix I&gt; | "FullLicenseInformation"-N | NONE | (left blank)</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3b.7 Example:</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">LicenseInformation: GPL-2.0</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">LicenseInformation: FullLicenseInformation</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3c License Comments</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">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.&nbsp; If the Concluded License(s) does not match the License Information in File, such rationale must be recited by the reviewer in this field.&nbsp; This field is also where an explanation must be recited if the reviewer placed “UNDETERMINED” as the Conclude License(s).</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3c.2 Intent:&nbsp; 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.</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3c.3 Cardinality: Optional, single instance</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3c.4 Tag: "LicenseComments:"&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3c.5 RDF: TBD</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3c.6 Data Format: free form text than can span multiple lines, preceded with &lt;text&gt; and ending with &lt;/text&gt;.</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">5.3c.7 Example: LicenseComments: &lt;text&gt; The Concluded License(s) was taken from the package level that the file was included in.&nbsp; This information was found in the COPYING.txt file in the xyz directory. &lt;/text&gt;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica;">***</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px;">&nbsp;</p></p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-01-14Legal Team/Minutes/2011-01-142011-02-07T17:20:18Z<p>Rockett: </p>
<hr />
<div><p>&nbsp;</p><p><strong>Legal Worksteam Meeting Minutes - 20110114</strong></p><p>&nbsp;</p><p><strong>SPDX Legal Worksteam Meeting Minutes – 14-January-2011</strong></p><p>&nbsp;</p><p><strong>Attendees:</strong></p><p>Esteban Rockett (Motorola)</p><p> Kate Stewart (Canonical)</p><p>Kim Weins (OpenLogic)</p><p>Peter Williams (OpenLogic)</p><p>Scott Peterson (HP)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Tom Incorvia (Microfocus)</p><p>Michael Herzog (NexB)</p><p>Phil Odence (BlackDuck)</p><p>&nbsp;</p><p><strong>Minutes:</strong></p><p>&nbsp;</p><p>- This meeting was a continuation of "Item E" from the regular Legal Workstream Meeting of 12-Jan-2011.</p><p>- Subject to refining terminology (where attendees will email terminology/minor revisions or do so on Bugzilla), attendees agreed to the following:</p><p>&nbsp;</p><p>***</p><p>(minor edits consistent with meeting done below by Rockett)</p><p>&nbsp;</p><p>Proposal: &nbsp;section 5.3 (License(s)) of the spec will</p><p>become 3 fields:</p><p>&nbsp;</p><p>5.3a Asserted/Concluded License</p><p>&nbsp;</p><p>5.3a.1 Purpose: This field contains the license</p><p>governing the file if it can be determined. &nbsp;If no license</p><p>information can be determined, the license is denoted as</p><p>"Unknown". &nbsp; The licenses should use the standard short</p><p>form names. &nbsp; See Appendix I for standardized license short</p><p>forms. &nbsp;If a Asserted/Concluded License is not one of the</p><p>standardized license short forms, this field must contain a</p><p>reference to the full licenses text included in this SPDX</p><p>file in section 4. &nbsp;If more than one license is asserted/concluded in</p><p>the file, then each should be listed. &nbsp;If any of the</p><p>asserted/concluded licenses offer the recipient a choice of licenses,</p><p>then each of the choices will be declared as a "disjunctive"</p><p>license.</p><p>&nbsp;</p><p>5.3a.2 Intent: Here, the intent is to have a uniform</p><p>method to refer to the license that is determined to</p><p>represent the file with specificity to eliminate any license</p><p>confusion. &nbsp;For example, the 3 clause BSD would have a</p><p>different license identifier then the 4 clause BSD.</p><p>&nbsp;</p><p>5.3a.3 Cardinality: &nbsp;Mandatory, one.</p><p>&nbsp;</p><p>5.3a.4 Tag: "LicenseAsserted:"</p><p>&nbsp;</p><p>5.3a.5 RDF: TBD &nbsp;(include Disjunctive form here)</p><p>&nbsp;</p><p>5.3a.6 Data Format: &lt;short form identifier in</p><p>Appendix I&gt; | "FullLicense"-N</p><p>&nbsp;</p><p>5.3a.7 Example:</p><p>LicenseAsserted: GPL-2.0</p><p>&nbsp;</p><p>&nbsp;</p><p>5.3b Detected License(s)</p><p>&nbsp;</p><p>5.3b.1 Purpose: This field contains the license recited&nbsp;</p><p>in the file, if any. &nbsp;It will be explicit</p><p>from the file header or other information found in the</p><p>file's source code. &nbsp; &nbsp;If no license information is found</p><p>it should be denoted as "NotSpecified". &nbsp;If no license</p><p>information can be determined, the license is denoted as</p><p>"Unknown". &nbsp; The licenses should use the standard short</p><p>form names. &nbsp; See Appendix I for standardized license short</p><p>forms. &nbsp;If a Detected License is not one of the</p><p>standardized license short forms, this field must contain a</p><p>reference to the full licenses text included in this SPDX</p><p>file in section 4. &nbsp;If more than one license is detected in</p><p>the file, then each should be listed. &nbsp;If any of the</p><p>detected licenses offer the recipient a choice of licenses,</p><p>then each of the choices will be declared as a "disjunctive"</p><p>license.</p><p>&nbsp;</p><p>5.ba.2 Intent: Here, the intent is to have a uniform</p><p>method to refer to each license with specificity to</p><p>eliminate any license confusion. &nbsp;For example, the 3 clause</p><p>BSD would have a different license identifier then the 4</p><p>clause BSD.</p><p>&nbsp;</p><p>5.3b.3 Cardinality: &nbsp;Mandatory, one or many.</p><p>&nbsp;</p><p>5.3b.4 Tag: "LicenseDetected:"</p><p>&nbsp;</p><p>5.3b.5 RDF: TBD (not including disjunctive form, if</p><p>multiple many should be specified )</p><p>&nbsp;</p><p>5.3b.6 Data Format: &lt;short form identifier in</p><p>Appendix I&gt; | "FullLicense"-N</p><p>&nbsp;</p><p>5.3b.7 Example:</p><p>LicenseDetected: GPL-2.0</p><p>LicenseDetected: FullLicense-2</p><p>&nbsp;</p><p>&nbsp;</p><p>5.3c License Comments</p><p>&nbsp;</p><p>5.3c.1 Purpose: This field is a detailed description</p><p>of the analysis and any relevent background references that</p><p>went in to making the asserted license for a file, if the</p><p>asserted/concluded license does not match the detected license that</p><p>the person creating the SPDX file wants to share with the</p><p>reviewers.</p><p>&nbsp;</p><p>5.3c.2 Intent: &nbsp;Here, the intent is to provide</p><p>technical readers/reviewers with a detailed technical</p><p>explanation of how the asserted license was determined if it</p><p>does not match the detected license.</p><p>&nbsp;</p><p>5.3c.3 Cardinality: Optional, single instance</p><p>&nbsp;</p><p>5.3c.4 Tag: "LicenseComments:"</p><p>&nbsp;</p><p>5.3c.5 RDF: TBD</p><p>&nbsp;</p><p>5.3c.6 Data Format: free form text than can span</p><p>multiple lines, preceded with &lt;text&gt; and ending with</p><p>&lt;/text&gt;.</p><p>&nbsp;</p><p>5.3c.7 Example: LicenseComments: &lt;text&gt; The</p><p>asserted license was taken from the package level that the</p><p>file was included in. &nbsp;&lt;/text&gt;</p><p>***</p><p>&nbsp;</p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-01-14Legal Team/Minutes/2011-01-142011-01-20T17:27:51Z<p>Rockett: </p>
<hr />
<div><p>&nbsp;</p><p><strong>Legal Worksteam Meeting Minutes - 20110114</strong></p><p>&nbsp;</p><p><strong>SPDX Legal Worksteam Meeting Minutes – 14-January-2011</strong></p><p>&nbsp;</p><p><strong>Attendees:</strong></p><p>Esteban Rockett (Motorola) Kate Stewart (Canonical)</p><p>Kim Weins (OpenLogic)</p><p>Peter Williams (OpenLogic)</p><p>Scott Peterson (HP)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Tom Incorvia (Microfocus)</p><p>Michael Herzog (NexB)</p><p>Phil Odence (BlackDuck)</p><p>&nbsp;</p><p><strong>Minutes:</strong></p><p>&nbsp;</p><p>- This meeting was a continuation of "Item E" from the regular Legal Workstream Meeting of 12-Jan-2011.</p><p>- Subject to refining terminology (where attendees will email terminology/minor revisions or do so on Bugzilla), attendees agreed to the following:</p><p>&nbsp;</p><p>***</p><p>(minor edits consistent with meeting done below by Rockett)</p><p>&nbsp;</p><p>Proposal: &nbsp;section 5.3 (License(s)) of the spec will</p><p>become 3 fields:</p><p>&nbsp;</p><p>5.3a Asserted/Concluded License</p><p>&nbsp;</p><p>5.3a.1 Purpose: This field contains the license</p><p>governing the file if it can be determined. &nbsp;If no license</p><p>information can be determined, the license is denoted as</p><p>"Unknown". &nbsp; The licenses should use the standard short</p><p>form names. &nbsp; See Appendix I for standardized license short</p><p>forms. &nbsp;If a Asserted/Concluded License is not one of the</p><p>standardized license short forms, this field must contain a</p><p>reference to the full licenses text included in this SPDX</p><p>file in section 4. &nbsp;If more than one license is asserted/concluded in</p><p>the file, then each should be listed. &nbsp;If any of the</p><p>asserted/concluded licenses offer the recipient a choice of licenses,</p><p>then each of the choices will be declared as a "disjunctive"</p><p>license.</p><p>&nbsp;</p><p>5.3a.2 Intent: Here, the intent is to have a uniform</p><p>method to refer to the license that is determined to</p><p>represent the file with specificity to eliminate any license</p><p>confusion. &nbsp;For example, the 3 clause BSD would have a</p><p>different license identifier then the 4 clause BSD.</p><p>&nbsp;</p><p>5.3a.3 Cardinality: &nbsp;Mandatory, one.</p><p>&nbsp;</p><p>5.3a.4 Tag: "LicenseAsserted:"</p><p>&nbsp;</p><p>5.3a.5 RDF: TBD &nbsp;(include Disjunctive form here)</p><p>&nbsp;</p><p>5.3a.6 Data Format: &lt;short form identifier in</p><p>Appendix I&gt; | "FullLicense"-N</p><p>&nbsp;</p><p>5.3a.7 Example:</p><p>LicenseAsserted: GPL-2.0</p><p>&nbsp;</p><p>&nbsp;</p><p>5.3b Detected License(s)</p><p>&nbsp;</p><p>5.3b.1 Purpose: This field contains the license recited&nbsp;</p><p>in the file, if any. &nbsp;It will be explicit</p><p>from the file header or other information found in the</p><p>file's source code. &nbsp; &nbsp;If no license information is found</p><p>it should be denoted as "NotSpecified". &nbsp;If no license</p><p>information can be determined, the license is denoted as</p><p>"Unknown". &nbsp; The licenses should use the standard short</p><p>form names. &nbsp; See Appendix I for standardized license short</p><p>forms. &nbsp;If a Detected License is not one of the</p><p>standardized license short forms, this field must contain a</p><p>reference to the full licenses text included in this SPDX</p><p>file in section 4. &nbsp;If more than one license is detected in</p><p>the file, then each should be listed. &nbsp;If any of the</p><p>detected licenses offer the recipient a choice of licenses,</p><p>then each of the choices will be declared as a "disjunctive"</p><p>license.</p><p>&nbsp;</p><p>5.ba.2 Intent: Here, the intent is to have a uniform</p><p>method to refer to each license with specificity to</p><p>eliminate any license confusion. &nbsp;For example, the 3 clause</p><p>BSD would have a different license identifier then the 4</p><p>clause BSD.</p><p>&nbsp;</p><p>5.3b.3 Cardinality: &nbsp;Mandatory, one or many.</p><p>&nbsp;</p><p>5.3b.4 Tag: "LicenseDetected:"</p><p>&nbsp;</p><p>5.3b.5 RDF: TBD (not including disjunctive form, if</p><p>multiple many should be specified )</p><p>&nbsp;</p><p>5.3b.6 Data Format: &lt;short form identifier in</p><p>Appendix I&gt; | "FullLicense"-N</p><p>&nbsp;</p><p>5.3b.7 Example:</p><p>LicenseDetected: GPL-2.0</p><p>LicenseDetected: FullLicense-2</p><p>&nbsp;</p><p>&nbsp;</p><p>5.3c License Comments</p><p>&nbsp;</p><p>5.3c.1 Purpose: This field is a detailed description</p><p>of the analysis and any relevent background references that</p><p>went in to making the asserted license for a file, if the</p><p>asserted/concluded license does not match the detected license that</p><p>the person creating the SPDX file wants to share with the</p><p>reviewers.</p><p>&nbsp;</p><p>5.3c.2 Intent: &nbsp;Here, the intent is to provide</p><p>technical readers/reviewers with a detailed technical</p><p>explanation of how the asserted license was determined if it</p><p>does not match the detected license.</p><p>&nbsp;</p><p>5.3c.3 Cardinality: Optional, single instance</p><p>&nbsp;</p><p>5.3c.4 Tag: "LicenseComments:"</p><p>&nbsp;</p><p>5.3c.5 RDF: TBD</p><p>&nbsp;</p><p>5.3c.6 Data Format: free form text than can span</p><p>multiple lines, preceded with &lt;text&gt; and ending with</p><p>&lt;/text&gt;.</p><p>&nbsp;</p><p>5.3c.7 Example: LicenseComments: &lt;text&gt; The</p><p>asserted license was taken from the package level that the</p><p>file was included in. &nbsp;&lt;/text&gt;</p><p>***</p><p>&nbsp;</p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-01-14Legal Team/Minutes/2011-01-142011-01-20T15:57:51Z<p>Rockett: </p>
<hr />
<div><p><p><strong>Legal Worksteam Meeting Minutes - 20110114</strong></p><p>&nbsp;</p><p><strong>SPDX Legal Worksteam Meeting Minutes – 14-January-2011</strong></p><p>&nbsp;</p><p><strong>Attendees:</strong></p><p>Esteban Rockett (Motorola) Kate Stewart (Canonical)</p><p>Kim Weins (OpenLogic)</p><p>Peter Williams (OpenLogic)</p><p>Scott Peterson (HP)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Tom Incorvia (Microfocus)</p><p>Michael Herzog (NexB)</p><p>&nbsp;</p><p>&nbsp;</p><p><strong>Minutes:</strong></p><p>&nbsp;</p><p>- This meeting was a continuation of "Item E" from the regular Legal Workstream Meeting of 12-Jan-2011.</p><p>- Subject to refining terminology (where attendees will email terminology/minor revisions or do so on Bugzilla), attendees agreed to the following:</p><p>&nbsp;</p><p>***</p><p>(minor edits consistent with meeting done below by Rockett)</p><p>&nbsp;</p><p>Proposal: &nbsp;section 5.3 (License(s)) of the spec will</p><p>become 3 fields:</p><p>&nbsp;</p><p>5.3a Asserted/Concluded License</p><p>&nbsp;</p><p>5.3a.1 Purpose: This field contains the license</p><p>governing the file if it can be determined. &nbsp;If no license</p><p>information can be determined, the license is denoted as</p><p>"Unknown". &nbsp; The licenses should use the standard short</p><p>form names. &nbsp; See Appendix I for standardized license short</p><p>forms. &nbsp;If a Asserted/Concluded License is not one of the</p><p>standardized license short forms, this field must contain a</p><p>reference to the full licenses text included in this SPDX</p><p>file in section 4. &nbsp;If more than one license is asserted/concluded in</p><p>the file, then each should be listed. &nbsp;If any of the</p><p>asserted/concluded licenses offer the recipient a choice of licenses,</p><p>then each of the choices will be declared as a "disjunctive"</p><p>license.</p><p>&nbsp;</p><p>5.3a.2 Intent: Here, the intent is to have a uniform</p><p>method to refer to the license that is determined to</p><p>represent the file with specificity to eliminate any license</p><p>confusion. &nbsp;For example, the 3 clause BSD would have a</p><p>different license identifier then the 4 clause BSD.</p><p>&nbsp;</p><p>5.3a.3 Cardinality: &nbsp;Mandatory, one.</p><p>&nbsp;</p><p>5.3a.4 Tag: "LicenseAsserted:"</p><p>&nbsp;</p><p>5.3a.5 RDF: TBD &nbsp;(include Disjunctive form here)</p><p>&nbsp;</p><p>5.3a.6 Data Format: &lt;short form identifier in</p><p>Appendix I&gt; | "FullLicense"-N</p><p>&nbsp;</p><p>5.3a.7 Example:</p><p>LicenseAsserted: GPL-2.0</p><p>&nbsp;</p><p>&nbsp;</p><p>5.3b Detected License(s)</p><p>&nbsp;</p><p>5.3b.1 Purpose: This field contains the license recited&nbsp;</p><p>in the file, if any. &nbsp;It will be explicit</p><p>from the file header or other information found in the</p><p>file's source code. &nbsp; &nbsp;If no license information is found</p><p>it should be denoted as "NotSpecified". &nbsp;If no license</p><p>information can be determined, the license is denoted as</p><p>"Unknown". &nbsp; The licenses should use the standard short</p><p>form names. &nbsp; See Appendix I for standardized license short</p><p>forms. &nbsp;If a Detected License is not one of the</p><p>standardized license short forms, this field must contain a</p><p>reference to the full licenses text included in this SPDX</p><p>file in section 4. &nbsp;If more than one license is detected in</p><p>the file, then each should be listed. &nbsp;If any of the</p><p>detected licenses offer the recipient a choice of licenses,</p><p>then each of the choices will be declared as a "disjunctive"</p><p>license.</p><p>&nbsp;</p><p>5.ba.2 Intent: Here, the intent is to have a uniform</p><p>method to refer to each license with specificity to</p><p>eliminate any license confusion. &nbsp;For example, the 3 clause</p><p>BSD would have a different license identifier then the 4</p><p>clause BSD.</p><p>&nbsp;</p><p>5.3b.3 Cardinality: &nbsp;Mandatory, one or many.</p><p>&nbsp;</p><p>5.3b.4 Tag: "LicenseDetected:"</p><p>&nbsp;</p><p>5.3b.5 RDF: TBD (not including disjunctive form, if</p><p>multiple many should be specified )</p><p>&nbsp;</p><p>5.3b.6 Data Format: &lt;short form identifier in</p><p>Appendix I&gt; | "FullLicense"-N</p><p>&nbsp;</p><p>5.3b.7 Example:</p><p>LicenseDetected: GPL-2.0</p><p>LicenseDetected: FullLicense-2</p><p>&nbsp;</p><p>&nbsp;</p><p>5.3c License Comments</p><p>&nbsp;</p><p>5.3c.1 Purpose: This field is a detailed description</p><p>of the analysis and any relevent background references that</p><p>went in to making the asserted license for a file, if the</p><p>asserted/concluded license does not match the detected license that</p><p>the person creating the SPDX file wants to share with the</p><p>reviewers.</p><p>&nbsp;</p><p>5.3c.2 Intent: &nbsp;Here, the intent is to provide</p><p>technical readers/reviewers with a detailed technical</p><p>explanation of how the asserted license was determined if it</p><p>does not match the detected license.</p><p>&nbsp;</p><p>5.3c.3 Cardinality: Optional, single instance</p><p>&nbsp;</p><p>5.3c.4 Tag: "LicenseComments:"</p><p>&nbsp;</p><p>5.3c.5 RDF: TBD</p><p>&nbsp;</p><p>5.3c.6 Data Format: free form text than can span</p><p>multiple lines, preceded with &lt;text&gt; and ending with</p><p>&lt;/text&gt;.</p><p>&nbsp;</p><p>5.3c.7 Example: LicenseComments: &lt;text&gt; The</p><p>asserted license was taken from the package level that the</p><p>file was included in. &nbsp;&lt;/text&gt;</p><p>***</p></p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2011-01-12Legal Team/Minutes/2011-01-122011-01-20T15:46:01Z<p>Rockett: </p>
<hr />
<div><p><p><strong>Legal Worksteam Meeting Minutes - 20110112</strong></p><p>&nbsp;</p><p><strong>SPDX Legal Worksteam Meeting Minutes – 12-January-2011</strong></p><p><strong><br /></strong></p><p><strong>Attendees:</strong></p><p>Esteban Rockett (Motorola) Kate Stewart (Canonical)</p><p>Kim Weins (OpenLogic)</p><p>Peter Williams (OpenLogic)</p><p>Mark Gisi (WindRiver)</p><p>Paul Madick (HP)</p><p>Scott Peterson (HP)</p><p>Jilayne Lovejoy (OpenLogic)</p><p>Tom Incorvia (Microfocus)</p><p>Andy Wilson (Intel)</p><p>Scott Lamons (OpenLogic)</p><p>Michael Herzog (NexB)</p><p>Karen Copenhaver (Linux Foundation)</p><p>&nbsp;</p><p><strong>Minutes:</strong></p><p>A. &nbsp;Review of December Meeting Minutes - Team was asked to review December meeting minutes by 20-Jan-2011; for approval at meeting scheduled for 26-Jan-2011.</p><p>B. "Create Process/Method to Add Licenses" - Team agreed with moving the process/method to created/add new licenses (to the standard SPDX license list) to the SPDX Business Workstream.</p><p>C. SPDX Metadata License - Team agreed to pick a default license for the SPDX metadata, such default license to be agreed by this team and Linux Foundation Member counsel. &nbsp;BSD-based/MIT-like was the general consensus. &nbsp;Whether additional proprietary licenses would be allowed was tabled, pending the decision on the default metadata license. &nbsp;Rockett and Karen Copenhaver to lead.</p><p>D. Required use of Standard License Acronyms - Michael Herzog proposed that this requirement be limited to those publishing SPDX metadata. &nbsp;No objections from the team.</p><p>E. Issue raised from Tech Workstream on the need for a Legal Policy on "SPDX Not Validating License Recited" - This topic lead into a detailed discussion of "objective" verse "subjective" metadata. &nbsp; A second meeting was scheduled for 14-Jan-2011 to conclude this issue. &nbsp;See minutes from 14-Jan-2011 meeting.</p></p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2010-12-15Legal Team/Minutes/2010-12-152011-01-12T16:37:50Z<p>Rockett: </p>
<hr />
<div><p>&nbsp;</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 24.0px Arial; color: #4d4d4d;">Legal Worksteam Meeting Minutes - 20101215</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 24.0px Arial; color: #4d4d4d; min-height: 28.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 15.0px Verdana; color: #666666;">SPDX Legal Worksteam Meeting Minutes – 15-December-2010</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 15.0px Verdana; color: #666666;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Attendees:</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">&nbsp;</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Esteban Rockett (Motorola) </p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Kate Stewart (Canonical)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;"> Kim Weins (OpenLogic)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Phil Odence (Blackduck)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Amanda Brock (Canonical)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Andrew Sinclair (Canonical)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Karen Copenhaver (Linux Foundation)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Scott Peterson (HP)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Tom Incorvia (Microfocus)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Allison Randal (Python Software Foundation, The Perl Foundation, Canonical)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Mansour Ghomeshi (Motorola)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">McCoy Smith (Intel)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Soeren Rabenstein (Asus)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Paul Madick (HP)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Jilayne Lovejoy (OpenLogic) Andy Wilson (Intel)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Terry Ilardi (IBM)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Michael Herzog (NexB)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">&nbsp;</p><p>&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Minutes:</p><br />
<ol style="list-style-type: decimal;"><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px Verdana; color: #4d4d4d;"><span style="text-decoration: underline;">Introductions</span> - Since this was the kick-off meeting for the SPDX Legal Workstream, all attendees introduced themselves in a descriptive manner.&nbsp; Many attendees were physically in a conference room at Choate et al. (Boston), others joined via the tele-conference.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px Verdana; color: #4d4d4d;"><span style="text-decoration: underline;">Bridge from Licensing Interim Workstream</span> - Rockett and Kim provided an explanation of how this Legal Workstream was bridging over the work done in the prior Licensing Subteam, with thanks to Kate, Jilayne and Tom.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Reviewed minutes/issues from last Licensing Subteam Meeting</span> - The last Licensing Subteam Meeting Minutes were actively explained by Kate, Kim and Rockett.&nbsp; Attendees were also encouraged to review and ask any further questions. &nbsp;Lead by Jilayne, the Licensing Subteam's treatment of zlib/libpng was discussed, and generally agreed to be managed as two separate licenses.&nbsp; Kim explained which GPL v3 exceptions were currently listed as separate entries on the SPDX standard license list. &nbsp;</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Discussed Current License List &amp; Review</span> - Attendees were asked to review the current SPDX Standard License List.&nbsp; There was some confusion over the URL for the active list.&nbsp; Rockett to work with Phil and Martin to resolve.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Discussed License Template Creation</span> - Volunteers were requested to work on the License Template for the SPDX Standard Licenses.&nbsp; Sorenson, Jilayne and Rockett volunteered to lead the effort.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Discussed Temporary Freeze of License List (30 days)</span> - A temporary freeze, e.g. 30 days, of the current working SPDX License List was proposed in order to allow for some cleanup, as well as license template creation (please see above).</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Creation of a Process/Method to Add Licenses</span> - An interactive discussion on how to add licenses occurred.&nbsp; Kim, Paul and Soeren volunteered to lead the effort in such a proposed method.&nbsp; This discussion then expanded into "if use of the standard license acronyms would be required" to be used for SPDX.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;">Next meeting was announced to be after the holidays in 2011; at the normal bi-weekly time slot.</li></ol><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; text-align: center; font: 13.0px Arial; color: #003f69;"><a href="http://spdx.org/wiki/spdx/legal/minutes">up</a></p><p>&nbsp;</p></div>Rocketthttps://wiki.spdx.org/view/Legal_Team/Minutes/2010-12-15Legal Team/Minutes/2010-12-152011-01-12T15:16:56Z<p>Rockett: </p>
<hr />
<div><p>&nbsp;</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 24.0px Arial; color: #4d4d4d;">Legal Worksteam Meeting Minutes - 20101215</p><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 24.0px Arial; color: #4d4d4d; min-height: 28.0px;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 15.0px Verdana; color: #666666;">SPDX Legal Worksteam Meeting Minutes – 15-December-2010</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 15.0px Verdana; color: #666666;">&nbsp;</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Attendees:</p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;"><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Esteban Rockett (Motorola) </p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Kate Stewart (Canonical)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;"> Kim Weins (OpenLogic)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Phil Odence (Blackduck)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Amanda Brock (Canonical)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Andrew Sinclair (Canonical)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Karen Copenhaver (Linux Foundation)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Scott Peterson (HP)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Tom Incorvia (Microfocus)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Allison Randal (Python Software Foundation, The Perl Foundation, Canonical)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Mansour Ghomeshi (Motorola)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">McCoy Smith (Intel)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Soeren Rabenstein (Asus)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Paul Madick (HP)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Jilayne Lovejoy (OpenLogic) Andy Wilson (Intel)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Terry Ilardi (IBM)</p><p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">&nbsp;</p></p><br />
<p style="margin: 0.0px 0.0px 10.0px 0.0px; line-height: 18.0px; font: 12.0px Arial; color: #666666;">Minutes:</p><br />
<ol style="list-style-type: decimal;"><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px Verdana; color: #4d4d4d;"><span style="text-decoration: underline;">Introductions</span> - Since this was the kick-off meeting for the SPDX Legal Workstream, all attendees introduced themselves in a descriptive manner.&nbsp; Many attendees were physically in a conference room at Choate et al. (Boston), others joined via the tele-conference.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px Verdana; color: #4d4d4d;"><span style="text-decoration: underline;">Bridge from Licensing Interim Workstream</span> - Rockett and Kim provided an explanation of how this Legal Workstream was bridging over the work done in the prior Licensing Subteam, with thanks to Kate, Jilayne and Tom.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Reviewed minutes/issues from last Licensing Subteam Meeting</span> - The last Licensing Subteam Meeting Minutes were actively explained by Kate, Kim and Rockett.&nbsp; Attendees were also encouraged to review and ask any further questions. &nbsp;Lead by Jilayne, the Licensing Subteam's treatment of zlib/libpng was discussed, and generally agreed to be managed as two separate licenses.&nbsp; Kim explained which GPL v3 exceptions were currently listed as separate entries on the SPDX standard license list. &nbsp;</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Discussed Current License List &amp; Review</span> - Attendees were asked to review the current SPDX Standard License List.&nbsp; There was some confusion over the URL for the active list.&nbsp; Rockett to work with Phil and Martin to resolve.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Discussed License Template Creation</span> - Volunteers were requested to work on the License Template for the SPDX Standard Licenses.&nbsp; Sorenson, Jilayne and Rockett volunteered to lead the effort.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Discussed Temporary Freeze of License List (30 days)</span> - A temporary freeze, e.g. 30 days, of the current working SPDX License List was proposed in order to allow for some cleanup, as well as license template creation (please see above).</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;"><span style="text-decoration: underline;">Creation of a Process/Method to Add Licenses</span> - An interactive discussion on how to add licenses occurred.&nbsp; Kim, Paul and Soeren volunteered to lead the effort in such a proposed method.&nbsp; This discussion then expanded into "if use of the standard license acronyms would be required" to be used for SPDX.</li><br />
<li style="margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px 'Lucida Grande'; color: #4d4d4d;">Next meeting was announced to be after the holidays in 2011; at the normal bi-weekly time slot.</li></ol><br />
<p style="margin: 0.0px 0.0px 0.0px 0.0px; text-align: center; font: 13.0px Arial; color: #003f69;"><a href="http://spdx.org/wiki/spdx/legal/minutes">up</a></p><p>&nbsp;</p></div>Rocketthttps://wiki.spdx.org/view/IFOSSLR_Tech_Watch_SubmissionIFOSSLR Tech Watch Submission2010-11-19T19:29:55Z<p>Rockett: </p>
<hr />
<div><h1>Software Package Data Exchange(SPDX) Specification</h1><p><br />
<br />Kate Stewart, Phil Odence, Esteban Rockett<br /><br />
<br />
<br />(a) Kate Stewart works as the Ubuntu Release Manager at Canonical, Inc. After reviewing way too many standard projects for license and copyright info in her prior job at Freescale Semiconductor, Inc. she found a group of folk equally fustrated, and set out collaborating with them on defining a specification for sharing package licensing and copyright facts between projects and organizations.<br /><br />
<br />(a) Phil Odence is Vice President of Business Development for Black Duck Software, makers of enterprise application development tools that address management, compliance and security challenges associated with open source. In that role, he is responsible for expanding Black Duck’s reach, image and product breadth by developing partnerships in the multi-source development, legal and open source ecosystem.<br /><br />
<br />(a) Esteban Rockett is a Senior Counsel at Motorola Mobility, Inc.&nbsp; He is Mobility's lead software intellectual property counsel, including serving as legal lead for its open source contributions and compliance, mobile application stores, and digital content licensing and delivery.</p><br />
<br />
<h3>Abstract</h3><br />
<p>The goal of the Software Package Data Exchange (SPDX(TM)) specification is to enable companies and organizations to share license and component information (metadata) for software package and related content with the aim of facilitating license and other policy compliance. The specification is being developed through collaboration between technical, business and legal professionals from a range of organizations to create a standard that addressess the needs of various partcipants in the software supply chain.<br />
</p><br />
<br />
<h3>Background</h3><br />
<p>Companies at all points in the software supply chain are becoming conscious of the need to treat open source just like any other third party code. They need to know and document the components in the products and software they are consuming and distributing. There are a variety of reasons for this, not the least of which is to make sure they understand their legal obligations. Thus the need for a common approach to sharing information about software packages and their related content has never been greater. Breaking down information silos is still a work in progress. The Software Package Data Exchange working group was formed originally as FOSSBazaar sponsored effort and is now a part of the Linux Foundation's Open Compliance Program[3]. The working group's goal is to define a way to share copyright and license information about a software packages and common licenses in that package down to the file level.<br />
</p><br />
<br />
<h3>Why is a standardized specification needed?</h3><br />
<p>Innovation happens very rapidly in the open source ecosystem, often by developers by building on top of the work of other developers. To do this, source code files, that have been created as part of one project under a specific license may be copied and reused in another project that may be under a different license. This mixing and matching of licenses, creates problems for those companies reusing and redistributing software packages that contain this combined software. It becomes a real challenge for them to figure out what they need to do to comply with the licenses that govern their software packages. By creating a standard way of summarizing the licensing and copyright information to the file level and providing a way to double check that the summary actually matches the code, a standard makes the task of figuring out what license are in effect much easier. This permits creation of a software "bill of materials" that can be passed with the actual software, throughout the supply chain, saving considerable analysis effort at every step. Simply saying your company is doing the right thing is not enough: Savvy consumers in the supply chain want proof to limit the risk of non-compliance with licenses. Suppliers themselves welcome a single standard format for disclosing open source rather than having to respond to each customers’s request using a unique format.<br />
</p><br />
<br />
<h3>What does the SPDX specification consist of?</h3><br />
<p>The SPDX(TM) effort has focused on coming up with a way to summarize discoverable facts about code content and ownership. By providing a ‘defined format of file to accompany any software package,’ the effort eases the burden of exchange of license information between companies. The standard defines a format for sharing: Facts that deal with identification, facts that provide overview information, and facts that provide file-specific information about the software package.<br />
</p><br />
<br />
<p>Facts that deal with a software package’s identification (metadata) included in the specification are:<br />
</p><ul><br />
<li> Version of the SPDX specification is in use<br />
</li><li> Unique identifier (based on a cryptographic hash algorithm) representing a unique identifier that correlates with this specific software package<br />
</li><li> Method by which information was generated (who, when, tools used, etc.)<br />
</li><li>Independent audit information (signoff/reviewed by)</li></ul><br />
<br />
<p>Facts that provide overview information about a software package’s content include:<br />
</p><ul><br />
<li> Formal Name<br />
</li><li> Package File Name<br />
</li><li> Download Location<br />
</li><li> Declared License(s)<br />
</li><li> Detected License(s)<br />
</li><li> Copyrights and Dates</li></ul><br />
<br />
<p>Facts that are specific to a software package’s file-specific properties:<br />
</p><ul><br />
<li> File Name (including subdirectory)<br />
</li><li> File Type (source or binary)<br />
</li><li> Detected license(s) governing file (from file)<br />
</li><li> Copyright owners and dates (if listed)</li></ul><br />
<br />
<p>Because of the license orientation of the specification, the Working Group is also committed to providing standardized license references. The spec includes:<br />
</p><ul><br />
<li> License names<br />
</li><li> Unique identifiers for common open source licenses<br />
</li><li> Mechanisms for handling non-standard licenses.</li></ul><br />
<br />
<p>The SPDX(TM) specification does not attempt to allow for legal judgment, but rather provides a format for a summary of the facts from which professionals (perhaps using other tools) may make judgements.<br />
</p><br />
<br />
<h3>How far along is the development and what are the next steps?</h3><br />
<p>The Version 1.0 beta form of the specification is available for download at [1], but it is just a starting point. It has had some road testing, but has not been driven by the public, so the group's focus is shifting to driving practical applications and incorporating the inevitable feedback before we release the official version 1.0. The group is assembling a list of key projects for which to create SPDX(TM) reports, and to get create those reports by any method possible. Initially we expect members of the group to roll up their sleves on this live testing, but we are also working hard with tool vendors (proprietary and open source) to create other options for generating these reports. We anticipate the need to develop new tools (e.g. syntax checkers and reading and displaying tools) to enable this development, as well as training materials for educating others on using the standard.<br />
</p><br />
<br />
<h3>Interested in Learning More and Helping out?</h3><br />
<p>If you want to join our volunteer effort, and help make it better, there is information on how to participate available on our web site [1],[2]. Sub-groups with their own mail lists have recently formed around technical, business, and legal issues, and depending where your interests are, all are open and welcome new members to collaborate on the specific topic areas.<br />
</p><br />
<br />
<h3>Conclusion</h3><br />
<p>Getting the SPDX(TM) specification adopted across the ecosystem will be a challenge. We need participation and support from key Linux distros and package maintainers, legal experts, tool developers (commercial and open source) and package consuming organizations as well. With major players in all those categories already on board, and with the support from FOSSbazaar and the Linux Foundation[3], the pieces are finally coming together to let us achieve our goal of a useful specification.<br />
</p><br />
<br />
<h3>References</h3><p><br />
[1] http://www.spdx.org/<br /><br />
[2] http://www.spdx.org/wiki/spdx/participation-guidelines<br /><br />
[3] http://www.linuxfoundation.org/programs/legal/compliance</p></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-25T13:29:11Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p><strong>***</strong></p><br />
<p><span style="text-decoration: underline;"><strong>Disclaimer: The following is a draft of the Software Package Data eXchange (SDPX) Specification. &nbsp;This draft is provided as a public courtesy to illustrate the progress of the project. &nbsp;Please be advised that in addition to the licensing terms recited below, no reliance should be made regarding this draft, including any reliance that this draft represents any particular standard for any particular purpose. &nbsp;When the official SPDX specification is released, it will be clearly be labeled "official", and its purpose and recommended use will be clearly stated at that time.</strong></span></p><br />
<p><strong>***</strong></p><br />
<p><strong>Software Package Data eXchange (SPDX) Specification Version: DRAFT 20100505</strong></p><br />
<p><strong>(c) Copyright 2010. &nbsp;</strong><strong>Andrew Back, Bill Schineller, Brad Dixon, Bruno Cornec, Ciaran Farrell, Daniel German, Debra McGlade, Eran Strod, Eric Thomas, Esteban Rockett, Gary O'Neall, Guillaume Rousseau, Jack Manbeck, Jeff Luszcz, John Ellis, Kate Stewart, Kim Weins, Marshall Clow, Martin Miclmayr , Martin von Willebrand, Michael J. Herzog, Michel Ruffin, Phil Robb, Philip Odence, Philp Koltun, Scott K Peterson, Shane Coughlan, Stuart Hughes, Tom Callaway, and Tom Incorvia.</strong></p><br />
<p><strong>Licensed under the Creative Commons Attribution License 3.0 (reproduced in Appendix III herein).</strong></p><br />
<p><strong>All other rights are expressly reserved.</strong></p><br />
<p>&nbsp;</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent: Here, by providing a freeform field, reviewers can provide any additional information to describe any anomalies, or discoveries, in the their determination of the origin of the package.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are declared at the package level.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture all licenses within the package detected by any scanning tools used by the package reviewer.</p><br />
<p style="padding-left: 90px;">(PLEASE CONFIRM THIS IS ACCURATE -- 20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent: &nbsp;Here, we seek to identify in whole or in part portions of the package which are licensed under unfamiliar and/or uncommon licenses.</p><br />
<p style="padding-left: 90px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE -- 20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent: &nbsp;Here, the actual license text included in the package serves as confirmation that the license, and version, named in the header files of the package is correct.</p><br />
<p style="padding-left: 60px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE --&nbsp;20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"> </span></h2><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; line-height: 16px;">(font (below) needs to be unified) </span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution License 3.0</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"> </span></p><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-25T13:28:08Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p><span style="text-decoration: underline;"><strong>Disclaimer: The following is a draft of the Software Package Data eXchange (SDPX) Specification. &nbsp;This draft is provided as a public courtesy to illustrate the progress of the project. &nbsp;Please be advised that in addition to the licensing terms recited below, no reliance should be made regarding this draft, including any reliance that this draft represents any particular standard for any particular purpose. &nbsp;When the official SPDX specification is released, it will be clearly be labeled "official", and its purpose and recommended use will be clearly stated at that time.</strong></span></p><br />
<p>&nbsp;</p><br />
<p><strong>Software Package Data eXchange (SPDX) Specification Version: DRAFT 20100505</strong></p><br />
<p><strong>(c) Copyright 2010. &nbsp;</strong><strong>Andrew Back, Bill Schineller, Brad Dixon, Bruno Cornec, Ciaran Farrell, Daniel German, Debra McGlade, Eran Strod, Eric Thomas, Esteban Rockett, Gary O'Neall, Guillaume Rousseau, Jack Manbeck, Jeff Luszcz, John Ellis, Kate Stewart, Kim Weins, Marshall Clow, Martin Miclmayr , Martin von Willebrand, Michael J. Herzog, Michel Ruffin, Phil Robb, Philip Odence, Philp Koltun, Scott K Peterson, Shane Coughlan, Stuart Hughes, Tom Callaway, and Tom Incorvia.</strong></p><br />
<p><strong>Licensed under the Creative Commons Attribution License 3.0 (reproduced in Appendix III herein).</strong></p><br />
<p><strong>All other rights are expressly reserved.</strong></p><br />
<p>&nbsp;</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent: Here, by providing a freeform field, reviewers can provide any additional information to describe any anomalies, or discoveries, in the their determination of the origin of the package.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are declared at the package level.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture all licenses within the package detected by any scanning tools used by the package reviewer.</p><br />
<p style="padding-left: 90px;">(PLEASE CONFIRM THIS IS ACCURATE -- 20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent: &nbsp;Here, we seek to identify in whole or in part portions of the package which are licensed under unfamiliar and/or uncommon licenses.</p><br />
<p style="padding-left: 90px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE -- 20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent: &nbsp;Here, the actual license text included in the package serves as confirmation that the license, and version, named in the header files of the package is correct.</p><br />
<p style="padding-left: 60px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE --&nbsp;20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"> </span></h2><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; line-height: 16px;">(font (below) needs to be unified) </span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution License 3.0</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"> </span></p><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-25T13:17:10Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p><span style="text-decoration: underline;"><strong>Disclaimer: The following is a draft of the Software Package Data eXchange (SDPX) Specification. &nbsp;This draft is provided as a public courtesy to illustrate the progress of the project. &nbsp;Please be advised that in addition to the licensing terms recited below, no reliance should be made regarding this draft, including any reliance that this draft represents any particular standard for any particular purpose. &nbsp;When the official SPDX specification is released, it will be clearly be labeled "official", and its purpose and recommended use will be clearly stated at that time.</strong></span></p><br />
<p>&nbsp;</p><br />
<p><strong>Software Package Data eXchange (SPDX) Specification Version: DRAFT 20100505</strong></p><br />
<p><strong>(c) Copyright 2010. &nbsp;</strong><strong>Andrew Back, Bill Schineller, Brad Dixon, Bruno Cornec, Ciaran Farrell, Daniel German, Debra McGlade, Eran Strod, Eric Thomas, Esteban Rockett, Gary O'Neall, Guillaume Rousseau, Jack Manbeck, Jeff Luszcz, John Ellis, Kate Stewart, Kim Weins, Marshall Clow, Martin Miclmayr , Martin von Willebrand, Michael J. Herzog, Michel Ruffin, Phil Robb, Philip Odence, Philp Koltun, Scott K Peterson, Shane Coughlan, Stuart Hughes, Tom Callaway, and Tom Incorvia.</strong></p><br />
<p><strong>Licensed under the Creative Commons Attribution License 3.0 (reproduced in Appendix III herein).</strong></p><br />
<p><strong>All other rights are expressly reserved.</strong></p><br />
<p>&nbsp;</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent: Here, by providing a freeform field, reviewers can provide any additional information to describe any anomalies, or discoveries, in the their determination of the origin of the package.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are declared at the package level.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture the licenses actually provided in full text with the package.</p><br />
<p style="padding-left: 90px;">(PLEASE CONFIRM THIS IS ACCURATE -- 20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent: &nbsp;Here, we seek to identify in whole or in part portions of the package which are licensed under unfamiliar and/or uncommon licenses.</p><br />
<p style="padding-left: 90px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE -- 20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent: &nbsp;Here, the actual license text included in the package serves as confirmation that the license, and version, named in the header files of the package is correct.</p><br />
<p style="padding-left: 60px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE --&nbsp;20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"> </span></h2><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; line-height: 16px;">(font (below) needs to be unified) </span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution License 3.0</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"> </span></p><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-25T13:16:17Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p><span style="text-decoration: underline;"><strong>Disclaimer: The following is a draft of the Software Package Data eXchange (SDPX) Specification. &nbsp;This draft is provided as a public courtesy to illustrate the progress of the project. &nbsp;Please be advised that in addition to the licensing terms recited below, no reliance should be made regarding this draft, including any reliance that this draft represents any particular standard for any particular purpose. &nbsp;When the official SPDX specification is released, it will be clearly be labeled "official", and its purpose and recommended use will be clearly stated.</strong></span></p><br />
<p>&nbsp;</p><br />
<p><strong>Software Package Data eXchange (SPDX) Specification Version: DRAFT 20100505</strong></p><br />
<p><strong>(c) Copyright 2010. &nbsp;</strong><strong>Andrew Back, Bill Schineller, Brad Dixon, Bruno Cornec, Ciaran Farrell, Daniel German, Debra McGlade, Eran Strod, Eric Thomas, Esteban Rockett, Gary O'Neall, Guillaume Rousseau, Jack Manbeck, Jeff Luszcz, John Ellis, Kate Stewart, Kim Weins, Marshall Clow, Martin Miclmayr , Martin von Willebrand, Michael J. Herzog, Michel Ruffin, Phil Robb, Philip Odence, Philp Koltun, Scott K Peterson, Shane Coughlan, Stuart Hughes, Tom Callaway, and Tom Incorvia.</strong></p><br />
<p><strong>Licensed under the Creative Commons Attribution License 3.0 (reproduced in Appendix III herein).</strong></p><br />
<p><strong>All other rights are expressly reserved.</strong></p><br />
<p>&nbsp;</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent: Here, by providing a freeform field, reviewers can provide any additional information to describe any anomalies, or discoveries, in the their determination of the origin of the package.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are declared at the package level.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture the licenses actually provided in full text with the package.</p><br />
<p style="padding-left: 90px;">(PLEASE CONFIRM THIS IS ACCURATE -- 20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent: &nbsp;Here, we seek to identify in whole or in part portions of the package which are licensed under unfamiliar and/or uncommon licenses.</p><br />
<p style="padding-left: 90px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE -- 20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent: &nbsp;Here, the actual license text included in the package serves as confirmation that the license, and version, named in the header files of the package is correct.</p><br />
<p style="padding-left: 60px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE --&nbsp;20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"> </span></h2><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; line-height: 16px;">(font (below) needs to be unified) </span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution License 3.0</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"> </span></p><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-14T17:53:09Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>Software Package Data eXchange (SPDX) Specification Version: DRAFT 20100505</strong></p><br />
<p><strong>(c) Copyright 2010. &nbsp;</strong></p><br />
<p><strong>(List of all package-facts contributors)</strong></p><br />
<p><strong>Licensed under the Creative Commons Attribution License 3.0 (reproduced in Appendix III herein).</strong></p><br />
<p><strong>All other rights are expressly reserved.</strong></p><br />
<p>&nbsp;</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent: Here, by providing a freeform field, reviewers can provide any additional information to describe any anomalies, or discoveries, in the their determination of the origin of the package.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are declared at the package level.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture the licenses actually provided in full text with the package.</p><br />
<p style="padding-left: 90px;">(PLEASE CONFIRM THIS IS ACCURATE -- 20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent: &nbsp;Here, we seek to identify in whole or in part portions of the package which are licensed under unfamiliar and/or uncommon licenses.</p><br />
<p style="padding-left: 90px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE -- 20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent: &nbsp;Here, the actual license text included in the package serves as confirmation that the license, and version, named in the header files of the package is correct.</p><br />
<p style="padding-left: 60px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE --&nbsp;20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
</span></h2><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; line-height: 16px;">(font (below) needs to be unified) </span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution License 3.0</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"> </span></p><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-14T17:23:02Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>Software Package Data Exchange (SPDX) Specification Version: DRAFT 20100505</strong></p><br />
<p><strong>(c) Copyright 2010. &nbsp;</strong></p><br />
<p><strong>(List of all package-facts contributors)</strong></p><br />
<p><strong>Licensed under the Creative Commons Attribution License 3.0 (reproduced in Appendix III herein).</strong></p><br />
<p><strong>All other rights are expressly reserved.</strong></p><br />
<p>&nbsp;</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent: Here, by providing a freeform field, reviewers can provide any additional information to describe any anomalies, or discoveries, in the their determination of the origin of the package.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are declared at the package level.</p><br />
<p style="padding-left: 90px;">(DONE -- 20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture the licenses actually provided in full text with the package.</p><br />
<p style="padding-left: 90px;">(PLEASE CONFIRM THIS IS ACCURATE -- 20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent: &nbsp;Here, we seek to identify in whole or in part portions of the package which are licensed under unfamiliar and/or uncommon licenses.</p><br />
<p style="padding-left: 90px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE -- 20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent: &nbsp;Here, the actual license text included in the package serves as confirmation that the license, and version, named in the header files of the package is correct.</p><br />
<p style="padding-left: 60px;">(PLEASE REVIEW AND CONFIRM IF ACCURATE --&nbsp;20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
</span></h2><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; line-height: 16px;">(font (below) needs to be unified) </span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution License 3.0</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"> </span></p><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-14T17:00:31Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>Software Package Data Exchange (SPDX) Specification Version: DRAFT 20100505</strong></p><br />
<p><strong>(c) Copyright 2010. &nbsp;</strong></p><br />
<p><strong>(List of all package-facts individuals)</strong></p><br />
<p><strong>Licensed under the Creative Commons Attribution License 3.0 (reproduced in Appendix III herein).</strong></p><br />
<p><strong>All other rights are expressly reserved.</strong></p><br />
<p>&nbsp;</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent:</p><br />
<p style="padding-left: 90px;">(20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are recited in the source code files of the package.</p><br />
<p style="padding-left: 90px;">(20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture additional licenses under which the package is licensed. &nbsp;The license(s) for this field are licenses which are not visibly identifiable in the actual source code, but rather identified by other means, e.g., scanning tools, by the reviewer.</p><br />
<p style="padding-left: 90px;">(20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent:</p><br />
<p style="padding-left: 90px;">(20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent:</p><br />
<p style="padding-left: 60px;">(20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
</span></h2><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; line-height: 16px;">(font (below) needs to be unified) </span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution License 3.0</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"> </span></p><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol><br />
<p style="padding-left: 30px;"><em><span style="font-style: normal;"><br /></span></em></p></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-14T16:29:28Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>SPDX Specification Version: DRAFT 20100505</strong></p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent:</p><br />
<p style="padding-left: 90px;">(20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are recited in the source code files of the package.</p><br />
<p style="padding-left: 90px;">(20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture additional licenses under which the package is licensed. &nbsp;The license(s) for this field are licenses which are not visibly identifiable in the actual source code, but rather identified by other means, e.g., scanning tools, by the reviewer.</p><br />
<p style="padding-left: 90px;">(20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent:</p><br />
<p style="padding-left: 90px;">(20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent:</p><br />
<p style="padding-left: 60px;">(20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
</span></h2><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; line-height: 16px;">(font needs to be unified) </span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution 3.0 License</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"> </span></p><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol><br />
<p style="padding-left: 30px;"><em><span style="font-style: normal;"><br /></span></em></p></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-06-14T16:27:28Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>SPDX Specification Version: DRAFT 20100505</strong></p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?&nbsp;) <strong>RESOLUTION</strong>:&nbsp;CC license has text; put at the start of doc. Create/publish delimeter formatting - <strong>Rockett</strong></em></p><br />
<p><em>(20100422 CALL &nbsp;List of authors for CC license will be folks on thread and are registered users of the Wiki. Martin will need to update as new folks register. <strong>Martin</strong>- Are you OK with this? Also, please send initial list to <strong>Rockett</strong>.)</em></p><br />
<p><em>(20100210 MVW Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) &nbsp;<strong>RESOLUTION</strong>: Need more info from <strong>MVW</strong></em></p><br />
<p><em>(20100310 JM General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it.) <strong>RESOLUTION</strong>: Add boilerplate disclaimer with regard to copyright of instance of facts file. Creative C header file including authorship assignment. Plan is to preserve as sidecar, but it may make sense to create a version of SPDX for inclusion in package (issue is checksum...should it be optional?). - <strong>Rockett</strong> &nbsp;Set up call with CC folks with regards to boilerplate - <strong>Bradley</strong></em></p><br />
<p><em>(20100310 JM General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? ) <strong>RESOLUTION: </strong>&nbsp;Agreed: Extensibility is desirable. Propose mechanism to mailing list - <strong>Philippe, Michael, and Gary</strong>. GARY AND PHILIPPE HAVE BEEN GOING BACK AND FORTH. USING RDF VOCABULARIES. (SIMPLE XML-BASED FORMAT FOR DEFINING VOCABULARY. www.w3.org/rdf) CLOSE TO READY FOR SHARING PROPOSAL.&nbsp;</em></p><br />
<p><em>Provide ITU/IETF examples to the list- <strong>John</strong>. <strong>Jack </strong>will create an appendix on use of spec including aggregation and history.</em></p><br />
<p><em>(20100415 FacetoFace General- Should we extend spec to describe streams and usage of streams? Only at file level?) <strong>RESOLUTION:</strong>&nbsp;&nbsp;Assess whether extensibility proposal accommodates. <strong>Jeff L </strong>IN PROCESS</em></p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for release by active participants in this specification effort, as indicated by name and email id)</p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;"><em>(20100415 Face to Face - Add proposed text regarding extensibility.) - <strong>MichaelH</strong></em></p><br />
<p style="padding-left: 30px;"><strong>1.4. What is not covered in the written standard?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used.&nbsp;</p><br />
<p style="padding-left: 60px;">1.4.3. Any identification of any patent(s) which may or may not relate to the package.</p><br />
<p style="padding-left: 30px;"><strong>1.5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in human readable form.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. Character set to be used in the SPDX file shall support UTF-8 encoding. <em>(<strong>Philippe</strong> to provide example of potentially problematic issue with filepath.)</em></p><br />
<p style="padding-left: 60px;">1.5.5 Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed. <em>Deferred to mailing list. <strong>Philippe</strong> to write up DOAP alternative.</em></p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">2.1. One instance per package instance.</p><br />
<p style="padding-left: 30px;">2.2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. SPDX Specification Version Number</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification version information to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F Generate language for meaning of major/minor versions -&nbsp;<strong>Jack</strong>)</span></p><br />
<p style="padding-left: 90px;">2.2.1.2 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 90px;">2.2.1.3 &nbsp;Tag: "SPDXversion"</p><br />
<p style="padding-left: 90px;">2.2.1.4. Data Format: &nbsp;SPDX-N.N &nbsp;</p><br />
<p style="padding-left: 90px;">where: N is [0-9].</p><br />
<p style="padding-left: 90px;">2.2.1.5. Example: SPDXversion: SPDX-1.0</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed in a verifiable way.</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100422 - Push issue to mail list. <strong>Michael and Philippe</strong> to propose s</span><em><span>olution incorporating such concerns as crypto export, internationalization and line endings. )</span></em></p><br />
<p style="padding-left: 90px;"><em><span><span style="font-style: normal;">2.2.2.2. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</span><br /></span></em></p><br />
<p style="padding-left: 90px;">2.2.2.3. Tag: "UniqueID"</p><br />
<p style="padding-left: 90px;">2.2.2.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">2.2.2.5. Example: UniqueID: ?</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 90px;">2.2.3.3. Tag: "CreatedBy"</p><br />
<p style="padding-left: 90px;">2.2.3.4. Data Format: ”Person: person name” or "Company: company" (depending on which is accountable) or "Tool: tool identifier - version”.</p><br />
<p style="padding-left: 90px;">2.2.3.5. Examples: CreatedBy: Person: Kim Weins</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic; font-weight: bold;">(20100415 RESOLUTION: </span><span style="font-style: italic;">Push to mailing list. <strong>Kim</strong> to propose language. Concept: Include who worked on it and what tools were used. &nbsp;<strong>20100505:</strong> Kate proposed CreatedBy Tag &amp; some data format options above, &nbsp;need to discuss, &nbsp;as well as syntax still for supporting multiple contributors (people, tools, etc.), some variation on and/or. &nbsp;Or should we just consider that person who created file is listed, and drop company/tool/etc. )</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100505 -KS do we want to include email information? )</span></p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done. &nbsp;This is to be specified according to combined data and time in UTC as specified in ISO 8601 standard.&nbsp;</p><br />
<p style="padding-left: 90px;">2.2.4.2 &nbsp;Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 90px;">2.2.4.3 &nbsp;Tag: "Created"</p><br />
<p style="padding-left: 90px;">2.2.4.4. Data Format: YYYY-MM-DDThh:mm:ssZ</p><br />
<p style="padding-left: 90px;">where: YYYY is year, MM is month with leading zero, DD is day with leading zero, T is deliminter for time, hh is hours with leading zero in 24 hour time, mm is minutes with leading zero, ss is second with leading zero, and Z is universal time indicator.</p><br />
<p style="padding-left: 90px;">2.2.4.5. Example: Created: 2010-01-29T18:30:22Z</p><br />
<p style="padding-left: 90px;">&nbsp;</p><br />
<p style="padding-left: 60px;">2.2.5. Review</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.2. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</span></em></p><br />
<p style="padding-left: 90px;"><em><span style="font-style: normal;">2.2.5.3. Tag: "ReviewedBy"</span></em></p><br />
<p style="padding-left: 90px;">2.2.5.4. Data Format: "Person: person name”</p><br />
<p style="padding-left: 90px;">2.2.5.5. Example: ReviewedBy: Person: Bradley Kuhn</p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(20100415 F2F RESOLUTION: Bradley K</strong> to rework section including such issues as defining "reviewed by," date, partial review or caveats, etc. Make optional field and include multiple, down the supply chain reviewed bys.)</span></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>) <em><strong>RESOLUTION: </strong>No longer applicable unless <strong>MVW</strong> says otherwise.</em></p><br />
<p style="padding-left: 30px;">3.1. One instance per package instance</p><br />
<p style="padding-left: 30px;">3.2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name of package as given by originator with version information included if available.</p><br />
<p style="padding-left: 90px;">3.2.1.2. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 90px;">3.2.1.3 &nbsp;Tag: "DeclaredName"</p><br />
<p style="padding-left: 90px;">3.2.1.4. Data Format: &lt;text string of full name&gt; &lt;version info if avilable&gt;</p><br />
<p style="padding-left: 90px;">3.2.1.5. Example: DeclaredName: glibc 2.11.1</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package File Name</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: File name of package instance.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 90px;">3.2.2.3. &nbsp;Tag: FileName:</p><br />
<p style="padding-left: 90px;">3.2.2.4. &nbsp;Data Format: identifier</p><br />
<p style="padding-left: 90px;">where identifier is the machine generated file name and version typically includes the packaging and compression methods used.</p><br />
<p style="padding-left: 90px;">3.2.2.5. Examples: FileName: glibc-2.11.1.tar.gz</p><br />
<p style="padding-left: 60px;">3.2.3. Download URL</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify exact download URL of the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 90px;">3.2.3.3. Tag: URL:</p><br />
<p style="padding-left: 90px;">3.2.3.4. Format: URL or "unknown"</p><br />
<p style="padding-left: 90px;">3.2.3.5. Example: URL:&nbsp;http://ftp.gnu.org/gnu/glibc/</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100414 &nbsp;F2F<em><strong> Debra M</strong>- Begin section on Wiki cataloging various SPDX doc use cases. IN PROCESS)</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;"><strong>(</strong></span>20100414 F2F<span style="font-style: italic;"><strong> Philippe, David M, Bradley</strong> taking a stab at developing tool that utilizes format.)</span></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100506 BillS- Concern raised that standard XML checkers would have a hard time validating a field with URL or string="unknown".)</span></p><br />
<p style="padding-left: 60px;">3.2.4 &nbsp;Source Additional Information</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: Freeform source commentary to add clarity to origins. For instance whether its been pulled from SCM or has been repackaged.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Intent:</p><br />
<p style="padding-left: 90px;">(20100505 KS - <em><strong>Rockett</strong> can you fill this in?</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "SourceInfo"</p><br />
<p style="padding-left: 90px;">3.2.4.4. Data Format: &lt;string without line separator&gt;</p><br />
<p style="padding-left: 90px;">3.2.4.5. Example: SourceInfo: use glibc-2_11-branch from&nbsp;git://sourceware.org/git/glibc.git.</p><br />
<p style="padding-left: 60px;">3.2.5. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: use a standard way of referring to license and its version. See Appendix I for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.5.2. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are recited in the source code files of the package.</p><br />
<p style="padding-left: 90px;">(20100505 KS&nbsp;<em><strong>Rockett</strong></em> - should the wording be "This field may have multiple declared licenses, if multiple licenses are declared at the package level.")</p><br />
<p style="padding-left: 90px;">3.2.4.3. Tag: "DeclaredLicense"</p><br />
<p style="padding-left: 90px;">3.2.5.4. Data Format: &lt;short form identifier&gt; | "FullLicense"-N</p><br />
<p style="padding-left: 90px;">3.2.5.5. Example: DeclaredLicense: GPL2.0</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong> will revise 3.2.5 section and Appendix I based on comments received on short form terminology that merges best from Debian and Fedora)</em></p><br />
<p style="padding-left: 60px;">3.2.6. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.6.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.6.2. Intent: Here, we intend to capture additional licenses under which the package is licensed. &nbsp;The license(s) for this field are licenses which are not visibly identifiable in the actual source code, but rather identified by other means, e.g., scanning tools, by the reviewer.</p><br />
<p style="padding-left: 90px;">(20100415 F2F <em><strong>Rockett </strong>- Update intent</em>.)</p><br />
<p style="padding-left: 90px;">3.2.6.3. Tag: "DetectedLicense"</p><br />
<p style="padding-left: 90px;">3.2.6.4. Data Format: ((&lt;short form identifier&gt; | "FullLicense"-N)",")*&nbsp;</p><br />
<p style="padding-left: 90px;">where it is either a single license identifier, or a comma separated list of identifiers. &nbsp; The identifier can be a short form identifier from Appendix I or a reference to the section of Full License texts (that are included in a numerical detection order (each unique denoted by N).</p><br />
<p style="padding-left: 90px;">3.2.6.5. Example: DetectedLicense: GPL2.0, FullLicense-1, FullLicense-2, GPL2.0+</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> Kim</strong>- Propose optional field for identifying packages from which files come.)</em></p><br />
<p style="padding-left: 90px;"><em><span>(20100506 Bill- consider adding count per license)</span></em></p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 90px;">3.2.7.3. Tag "DeclaredCopyright"</p><br />
<p style="padding-left: 90px;">3.2.7.4. Data Format: ?</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em><strong> Kate</strong>- Update. Needs to accommodate multiple copyright holders and dates. Include None as possible.)&nbsp;</em></p><br />
<p style="padding-left: 90px;">3.2.7.5. Example: ?</p><br />
<p style="padding-left: 60px;">3.2.8. Declared Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 90px;">3.2.8.3. Tag: CopyrightDate</p><br />
<p style="padding-left: 90px;">3.2.8.4. Format: YYYY&nbsp;</p><br />
<p style="padding-left: 90px;">where YYYY is the year.</p><br />
<p style="padding-left: 90px;">3.2.8.5. Example: CopyrightDate: 2010</p><br />
<p style="padding-left: 60px;">3.2.9. Pithy Description Field</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 - F2F<em><strong> Jeff</strong>- Propose to mailing list.)</em></p><br />
<p style="padding-left: 60px;"><em><br /></em></p><br />
<h2>4. Index of Non Standard License(s) Detected</h2><br />
<p style="padding-left: 30px;">4.1 One instance for every unique license detected in package that does not match one of the standard license short forms from Appendix I.</p><br />
<p style="padding-left: 30px;">4.2 Fields:</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.1 Identifier</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: Provide a unique identifier for the packages and files sections to refer to non standard license text detected in the package and reproduced here to aid analysis.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Intent:</p><br />
<p style="padding-left: 90px;">(20100505 KS -<em> <strong>Rockett</strong> can you fill this in? )</em></p><br />
<p style="padding-left: 90px;">4.2.1.3. Tag: "LicenseID"</p><br />
<p style="padding-left: 90px;">4.2.1.4. Data Format: "License-"N where N is a unique ascending numeric value.</p><br />
<p style="padding-left: 90px;">4.2.1.5. Example: &nbsp;LicenseID: License-1</p><br />
<p style="padding-left: 30px;"><span style="white-space: pre;"> </span>4.2.2 Extracted Text</p><br />
<p style="padding-left: 30px;">&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.2.1. Purpose: Provide a copy of the actual text of the license extracted from the package to aid in analysis.</p><br />
<p style="padding-left: 60px;">4.2.2.2. Intent:</p><br />
<p style="padding-left: 60px;">(20100505 KS -<em>&nbsp;<strong>Rockett</strong>&nbsp;can you fill this in? )</em></p><br />
<p style="padding-left: 60px;">4.2.1.3. Tag: "LicenseText"</p><br />
<p style="padding-left: 60px;">4.2.1.4. Data Format: &lt;multiline text&gt; "***EOLT***"&nbsp;</p><br />
<p style="padding-left: 60px;">4.2.1.5. Example: &nbsp;LicenseText: &lt;multiline text&gt; ***EOLT***</p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<p>&nbsp;</p><br />
<h2>5. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.)</em></p><br />
<p style="padding-left: 30px;"><em>(20100310 JM&nbsp;4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Should we allow inferred or best guesses for file licenses with an indication that it was not clear?)</em></p><br />
<p style="padding-left: 30px;">5.1. One entry for every file in package instance</p><br />
<p style="padding-left: 30px;"><em>(20100415 F2F Consider aggregation.)</em></p><br />
<p style="padding-left: 30px;">5.2. Fields:</p><br />
<p style="padding-left: 60px;">5.2.1. Full File Name</p><br />
<p style="padding-left: 90px;">5.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">5.2.1.2. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 90px;">5.2.1.3. Tag: "FileName"</p><br />
<p style="padding-left: 90px;">5.2.1.4. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">5.2.1.5. Example: FileName: /bar/foo.c</p><br />
<p style="padding-left: 90px;"><em>(</em>20100415 F2F<em> Consider short file name as well. </em>20100505 KS<em> - any one remember why we wouldn't want to include the directory information if it exists?)</em></p><br />
<p style="padding-left: 60px;">5.2.2. File Type (optional)</p><br />
<p style="padding-left: 90px;">5.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, etc.</p><br />
<p style="padding-left: 90px;">5.2.2.2. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">5.2.2.3. Tag: "FileType"</p><br />
<p style="padding-left: 90px;">5.2.2.4. Data Format: "source" | "binary" | "other"</p><br />
<p style="padding-left: 90px;">5.2.2.5. Example: FileType: binary</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 90px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kate</strong>- Change to optional field. Limit types to binary, source, other. &nbsp;</em>20100505 KS&nbsp;<em>- Done, see above )</em></p><br />
<p style="padding-left: 90px;"><span style="font-style: italic;">(20100415 F2F - Discuss on mail list how to deal with archives, consider in scope / out of scope. &nbsp;20100505 - KS - assign<strong> Kate</strong> as owner )</span></p><br />
<p style="padding-left: 60px;">5.2.3. License(s)</p><br />
<p style="padding-left: 90px;">5.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">5.2.3.2. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.3. Tag: "FileLicense"</p><br />
<p style="padding-left: 90px;">5.2.3.4. Data Format: ( [identier,]* [identifier])|"unknown"</p><br />
<p style="padding-left: 90px;">where identifier is either one of the short forms from Appendix I or LicenseID from section 4. &nbsp; If no license detected, &nbsp;should have "unknown".&nbsp;</p><br />
<p style="padding-left: 90px;">5.2.3.5. Example: FileLicense: GPL-2.0,License-5</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 90px;">(20100415 F2F<em>&nbsp;&nbsp;Resolve to follow what we do for package level.<strong>- Kim</strong> will own updating once defined.)</em></p><br />
<p style="padding-left: 60px;">5.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">5.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">5.2.4.2. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 90px;">5.2.4.3. Tag: "FileCopyright"</p><br />
<p style="padding-left: 90px;">5.2.4.2. Data Format: (“copyright holder”:&lt;date(s)&gt; ";")*</p><br />
<p style="padding-left: 90px;">where date(s) are of form (YYYY["-"|","])* YYYY</p><br />
<p style="padding-left: 90px;">5.2.4.3. Example: FileCopyright: “Linus Torvalds”:”1996-2010”;</p><br />
<p style="padding-left: 90px;"><em>(20100415 F2F - Use this format at package level. &nbsp;Mail list to discuss do we want "none" vs. "none found." Ex Disclaim copyrights. Aggregation of redundant copyrights. &nbsp;</em>20100505 KS<em> - Need owner clarified )</em></p><br />
<p style="padding-left: 60px;">5.2.5. Package(s) (optional)</p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Kim</strong> to implement same as at package level.)</em></p><br />
<p style="padding-left: 60px;"><span>5.2.6 Hash on File (optional)</span></p><br />
<p style="padding-left: 60px;"><em><strong>(</strong></em>20100415 F2F<em><strong> - Jeff L</strong> to make proposal.)</em></p><br />
<p style="padding-left: 60px;">&nbsp;</p><br />
<h2><span style="font-size: 10px; font-weight: normal;"><br />
<h2 style="font-size: 1.5em;">6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p><br />
<p style="padding-left: 30px;"><span style="font-style: italic;">(20100415 F2F Legal question: Do we want to capitalize terms that are defined here as in a legal agreement.)</span></p><br />
<p style="padding-left: 30px;"><em><strong>(</strong></em>20100415 F2F<em><strong>&nbsp;All</strong>- Add terms here that seem ambiguous above.)</em></p><br />
<p><em>(20100505 KS reshuffle sections to put this earlier in the specification?&nbsp;</em></p><br />
<p><em><br /></em></p><br />
</span></h2><br />
<h2>Appendix I. Standard License Short Forms</h2><br />
<p style="padding-left: 30px;">https://fossbazaar.org/wiki/standard-license-short-forms</p><br />
<p style="padding-left: 30px;"><span style="font-size: 15px; font-weight: bold;"><em><span style="font-size: 10px; font-weight: normal;">(20100415 F2F Consider moving this section to SPDX website. </span></em><span style="font-size: 10px; font-weight: normal;">20100505 K</span><em><span style="font-size: 10px; font-weight: normal;">S this will be reference information in spec with its own syntax - <strong>Kate</strong> to own first draft &nbsp;</span></em><span style="font-size: 10px; font-weight: normal;">20100506 KS -&nbsp;</span><em><span style="font-size: 10px; font-weight: normal;">new link created - forrmatting in progress)</span></em></span></p><br />
<p>&nbsp;</p><br />
<h2 style="font-size: 1.5em;">Appendix II. &nbsp;Examples</h2><br />
<p style="padding-left: 30px;">(20100505 KS - <em><strong>Kate</strong></em> - <em>create links to child pages with examples </em>)&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 17px; color: #333333; font-weight: bold; line-height: 16px;">Appendix III. &nbsp;Creative Commons Attribution 3.0 License</span></p><br />
<p><span style="font-family: arial, verdana, sans-serif; font-size: 12px; color: #333333; line-height: 16px;"><br />
<p>THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.</p><br />
<p>BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.</p><br />
<p><strong>1. Definitions</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Adaptation"</strong>&nbsp;means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Collection"</strong>&nbsp;means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Distribute"</strong>&nbsp;means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Licensor"</strong>&nbsp;means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Original Author"</strong>&nbsp;means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Work"</strong>&nbsp;means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"You"</strong>&nbsp;means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Publicly Perform"</strong>&nbsp;means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">"Reproduce"</strong>&nbsp;means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.</li><br />
</ol><br />
<p><strong>2. Fair Dealing Rights.</strong>&nbsp;Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.</p><br />
<p><strong>3. License Grant.</strong>&nbsp;Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;</li><br />
<li style="margin-bottom: 8px;">to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform the Work including as incorporated in Collections; and,</li><br />
<li style="margin-bottom: 8px;">to Distribute and Publicly Perform Adaptations.</li><br />
<li style="margin-bottom: 8px;"><br />
<p>For the avoidance of doubt:</p><br />
<ol type="i"><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Non-waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Waivable Compulsory License Schemes</strong>. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,</li><br />
<li style="margin-bottom: 8px;"><strong style="color: #222222;">Voluntary License Schemes</strong>. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.</li><br />
</ol></li><br />
</ol><br />
<p>The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.</p><br />
<p><strong>4. Restrictions.</strong>&nbsp;The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:</p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.</li><br />
<li style="margin-bottom: 8px;">If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.</li><br />
<li style="margin-bottom: 8px;">Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.</li><br />
</ol><br />
<p><strong>5. Representations, Warranties and Disclaimer</strong></p><br />
<p>UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.</p><br />
<p><strong>6. Limitation on Liability.</strong>&nbsp;EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p><br />
<p><strong>7. Termination</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.</li><br />
<li style="margin-bottom: 8px;">Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.</li><br />
</ol><br />
<p><strong>8. Miscellaneous</strong></p><br />
<ol type="a"><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.</li><br />
<li style="margin-bottom: 8px;">If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.</li><br />
<li style="margin-bottom: 8px;">No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.</li><br />
<li style="margin-bottom: 8px;">This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.</li><br />
<li style="margin-bottom: 8px;">The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.</li><br />
</ol></span></p><br />
<p><span style="font-style: italic;"><br /></span></p><br />
<p style="padding-left: 30px;">&nbsp;</p></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-04-15T17:19:01Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>SPDX Specification Version: DRAFT 20100407</strong></p><br />
<p>(20100310 JM <em>General - Can we add a date or version to the document? &nbsp;We should probably add a revision table when it goes live but in my view not necessary to have right now</em>) (20100407 KS done)</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?</em> )</p><br />
<p>(20100210 MVW <em> Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) </em></p><br />
<p>(20100310 JM <em>General – I would add a standard disclaimer (i.e. we tried to get this right but there may be mistakes) to the Package facts that travel with it. Perhaps in the Identification Information section. See my next comment on License since it may solve that.)</em></p><br />
<p>(20100310 JM <em>General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it</em>.)</p><br />
<p>(20100310 JM <em>General – In the final version should have an examples section that shows a completed Package Facts document or maybe examples per section or both? Perhaps we can use some of use cases that we are working on for this. </em>)</p><br />
<p>(20100310 JM <em> General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?</em>) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? )</p><br />
<p>(20100310 JM <em>General – Are all these fields required or are some optional?</em>)</p><br />
<p>(20100310 JM <em>General – How do we represent different Packages in a single distribution of something? I can see where some projects are very singular and would have just an application or a library. What happens, as an example, if that project offers an application, kernel patch, library, etc in one download? Would we use one package facts to cover them all, one per piece, etc?</em>)</p><br />
<p>&nbsp;</p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for use by active participants in this specification effort, as indicated by name and email id)</p><br />
<p>(20100310 JM <em> General – I would like to see the definition of Signed Off mean “approved for release” vs. “approved for use” since I think that’s what we mean and use could possibly be construed to mean something else. )</em></p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;">(20100210 MVW 1.2<em> Should probably reflect the idea behind package specifig and use case specific data)(</em>20100407 KS<em> - use case specific data was removed - so not sure if this still needs to be addressed?)</em></p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;">1.3.5. ?</p><br />
<p style="padding-left: 30px;"><strong>4. What is not covered?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used. After we agree on what should be specified; discussions on how it can be used, who will generate it, how it will be published, audited, etc., will happen outside the scope of this document.</p><br />
<p style="padding-left: 60px;">1.4.3. ? Any identification of any patent(s) which may or may not read on the package.</p><br />
<p style="padding-left: 30px;"><strong>5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in a syntax that humans can read and write.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. ? Character set to be used to support international naming. (follow Debian precedent?)</p><br />
<p style="padding-left: 60px;">1.5.5. ? Actual specification of fields – below is illustrative rather than agreed on.</p><br />
<p style="padding-left: 60px;">1.5.6. ? Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed.</p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. Version Number for the instance of the SPDX specification.</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;">2.2.1.2. Format: Version: N.N</p><br />
<p style="padding-left: 90px;">2.2.1.3. Example: 1.0</p><br />
<p style="padding-left: 90px;">2.2.1.4 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed. Options under consideration: SHA256, ?</p><br />
<p style="padding-left: 90px;">(20100210 MVW <em>2.2.2 MD5 or PGP are also quite widely used for security, allowing e.g. to check that the downloaded package corresponds to the one distributed by the projects. There could be a signal, if the signum has been checked from file source too. If the file source did not provide a signum, it can be generated. Probably needs to allow variance for different signums (or more background knowledge, if a certain method is to be promoted</em>.)</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.2.1 – Should we add MD5? That seems to be very common as a signature as well. If we allow multiple signature types would there be a preferred one? We should also have a URL to where the keys are posted so we can check against them. I would add a field here for that. That said, problems sometimes don’t appear right away and some considerable amount of time may have elapsed. In that case, whoever posted the checksums to validate against may have taken them down for whatever reason (i.e. it’s an older version, project folded, etc).&nbsp;&nbsp;Do we want the keys to still be around in this situation? If so, we need to comprehend that.</em>)</p><br />
<p style="padding-left: 90px;">2.2.2.2. Format: UniqueID: ?</p><br />
<p style="padding-left: 90px;">2.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.2.4. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Format: Manual: ”person name” | Tool: ”tool id - version”</p><br />
<p style="padding-left: 90px;">2.2.3.3. Examples: ?</p><br />
<p style="padding-left: 90px;">2.2.3.4. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done.</p><br />
<p style="padding-left: 90px;">2.2.4.2. Format: Created: YYYYMMDD-HH:MM:SS</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>2.2.4 – Should we add a time zone or say it’s based on GMT? Alternatively we could adopt a date/time format from an RFC but I’m okay with this one.</em>)</p><br />
<p style="padding-left: 90px;">2.2.4.3. Example: Created: 20100129-18:30:22</p><br />
<p style="padding-left: 90px;">2.2.4.4. Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 60px;">2.2.5. Independent Review/Audit</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;">2.2.5.2. Format: Reviewed by: “person name”</p><br />
<p style="padding-left: 90px;">2.2.5.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.5.4. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</p><br />
<p style="padding-left: 60px;">2.2.6. ??</p><br />
<p style="padding-left: 60px;">(20100310 JM&nbsp;<em>2.0 – Would it be useful to have a marker or token at the top of the facts file that shows it uses the Package Facts format? This may make life easier for tools which are likely going to have to process different file formats. It would be the first thing that must appear in the file.)</em></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>)</p><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name given by originator with version information. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.1.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.1.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.1.4. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package Identifier</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: Machine name of package.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Format: identifier.suffix</p><br />
<p style="padding-left: 90px;">3.2.2.3. Examples: foo.tar, foo.rpm, ?</p><br />
<p style="padding-left: 90px;">3.2.2.4. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package's&nbsp;Identification Information.</p><br />
<p style="padding-left: 60px;">3.2.3. Official Source Location</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify where the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Format: download URL</p><br />
<p style="padding-left: 90px;">3.2.3.3. Example: ?</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>3.2.3 – We should allow usage of git, svn, etc values</em>)</p><br />
<p style="padding-left: 90px;">3.2.3.4. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 60px;">3.2.4. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: use a standard way of referring to license and its version. See Section 5.0 for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Format: identifier | other</p><br />
<p style="padding-left: 90px;">3.2.4.3. Example: ? (something like GPL2.0)</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;<em>3.2.4: At Validos, we call this the “main license”, i.e. the license the project itself is applying. (The term is not the best, since most of the code can be under some other license.) However, the license the project is using is a sort of top-level license (compliance and license compatibility review can often be needed between sub-packages too, so this is also more a terminology question). Perhaps this item should state the “License Applied by Project” and then indicate if other licenses are present too</em> ) (20100407 KS <em>MVW's comments were against original term of "Formal", which has been under discussion. I think they've been addressed, but replicating here for completeness. &nbsp; Currently suggesting use of "Declared" terminology so updated field to have this.</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.4. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are recited in the source code files of the package.</p><br />
<p style="padding-left: 60px;">3.2.5. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.5.2. Format: identifier (see section 5) | other; &nbsp;one per line.</p><br />
<p style="padding-left: 90px;">3.2.5.3. Example: GPLv3.0</p><br />
<p style="padding-left: 90px;">3.2.5.4. Intent: Here, we intend to capture additional licenses under which the package is licensed. &nbsp;The license(s) for this field are licenses which are not visibly identifiable in the actual source code, but rather identified by other means, e.g., scanning tools, by the reviewer.</p><br />
<p style="padding-left: 60px;">3.2.6. –removed-</p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.7.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.7.4. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 60px;">3.2.8. Formal Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Format: YYYY</p><br />
<p style="padding-left: 90px;">3.2.8.3. Example: 2010</p><br />
<p style="padding-left: 90px;">3.2.8.4. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 60px;">3.2.9. ???</p><br />
<h2>4. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.</em>)</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;">4.1. One instance for every file in package</p><br />
<p style="padding-left: 30px;">4.2. Fields:</p><br />
<p style="padding-left: 60px;">4.2.1. File Name</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">4.2.1.3. Example: bar/foo.c</p><br />
<p style="padding-left: 90px;">4.2.1.4. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 60px;">4.2.2. File Type</p><br />
<p style="padding-left: 90px;">4.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, ??</p><br />
<p style="padding-left: 90px;">4.2.2.2. Format: ?</p><br />
<p style="padding-left: 90px;">4.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">4.2.2.4. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 60px;">4.2.3. License(s)</p><br />
<p style="padding-left: 90px;">4.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">4.2.3.2. Format: ? [identier,]* [identifier | “string“]</p><br />
<p style="padding-left: 90px;">4.2.3.3. Example: GPL2.0,BSD,”xyz license type”</p><br />
<p style="padding-left: 90px;">4.2.3.4. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 60px;">4.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">4.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">4.2.4.2. Format: [ “copyright holder”:”date(s)”]*</p><br />
<p style="padding-left: 90px;">4.2.4.3. Example: “Linus Torvalds”:”1996-2010”</p><br />
<p style="padding-left: 90px;">4.2.4.4. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 60px;">4.2.5. ?</p><br />
<h2>5. Standard License Identifiers</h2><br />
<p style="padding-left: 30px;">5.1. Rationale for licenses to choose to standardize identifiers. Focus on standardizing the most commonly used rather than all. Align with any other standardization efforts underway here that will meet the need.</p><br />
<p style="padding-left: 30px;">5.2. Table of standard licenses and their identifiers</p><br />
<table border="1" cellspacing="0" cellpadding="0" width="542"><br />
<tbody><br />
<tr><br />
<td width="69" valign="top"><br />
<p>Identifier</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>Full name</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>Official Source Text</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL2.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>GNU General Public License (GPL) Ver. 2, June 1991</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>http://www.gnu.org/copyleft/gpl.hmtl</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL3.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>...</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
</tbody><br />
</table><br />
<h2>6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-04-15T17:17:35Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>SPDX Specification Version: DRAFT 20100407</strong></p><br />
<p>(20100310 JM <em>General - Can we add a date or version to the document? &nbsp;We should probably add a revision table when it goes live but in my view not necessary to have right now</em>) (20100407 KS done)</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?</em> )</p><br />
<p>(20100210 MVW <em> Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) </em></p><br />
<p>(20100310 JM <em>General – I would add a standard disclaimer (i.e. we tried to get this right but there may be mistakes) to the Package facts that travel with it. Perhaps in the Identification Information section. See my next comment on License since it may solve that.)</em></p><br />
<p>(20100310 JM <em>General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it</em>.)</p><br />
<p>(20100310 JM <em>General – In the final version should have an examples section that shows a completed Package Facts document or maybe examples per section or both? Perhaps we can use some of use cases that we are working on for this. </em>)</p><br />
<p>(20100310 JM <em> General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?</em>) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? )</p><br />
<p>(20100310 JM <em>General – Are all these fields required or are some optional?</em>)</p><br />
<p>(20100310 JM <em>General – How do we represent different Packages in a single distribution of something? I can see where some projects are very singular and would have just an application or a library. What happens, as an example, if that project offers an application, kernel patch, library, etc in one download? Would we use one package facts to cover them all, one per piece, etc?</em>)</p><br />
<p>&nbsp;</p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for use by active participants in this specification effort, as indicated by name and email id)</p><br />
<p>(20100310 JM <em> General – I would like to see the definition of Signed Off mean “approved for release” vs. “approved for use” since I think that’s what we mean and use could possibly be construed to mean something else. )</em></p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;">(20100210 MVW 1.2<em> Should probably reflect the idea behind package specifig and use case specific data)(</em>20100407 KS<em> - use case specific data was removed - so not sure if this still needs to be addressed?)</em></p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;">1.3.5. ?</p><br />
<p style="padding-left: 30px;"><strong>4. What is not covered?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used. After we agree on what should be specified; discussions on how it can be used, who will generate it, how it will be published, audited, etc., will happen outside the scope of this document.</p><br />
<p style="padding-left: 60px;">1.4.3. ? Any identification of any patent(s) which may or may not read on the package.</p><br />
<p style="padding-left: 30px;"><strong>5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in a syntax that humans can read and write.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. ? Character set to be used to support international naming. (follow Debian precedent?)</p><br />
<p style="padding-left: 60px;">1.5.5. ? Actual specification of fields – below is illustrative rather than agreed on.</p><br />
<p style="padding-left: 60px;">1.5.6. ? Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed.</p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. Version Number for the instance of the SPDX specification.</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;">2.2.1.2. Format: Version: N.N</p><br />
<p style="padding-left: 90px;">2.2.1.3. Example: 1.0</p><br />
<p style="padding-left: 90px;">2.2.1.4 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed. Options under consideration: SHA256, ?</p><br />
<p style="padding-left: 90px;">(20100210 MVW <em>2.2.2 MD5 or PGP are also quite widely used for security, allowing e.g. to check that the downloaded package corresponds to the one distributed by the projects. There could be a signal, if the signum has been checked from file source too. If the file source did not provide a signum, it can be generated. Probably needs to allow variance for different signums (or more background knowledge, if a certain method is to be promoted</em>.)</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.2.1 – Should we add MD5? That seems to be very common as a signature as well. If we allow multiple signature types would there be a preferred one? We should also have a URL to where the keys are posted so we can check against them. I would add a field here for that. That said, problems sometimes don’t appear right away and some considerable amount of time may have elapsed. In that case, whoever posted the checksums to validate against may have taken them down for whatever reason (i.e. it’s an older version, project folded, etc).&nbsp;&nbsp;Do we want the keys to still be around in this situation? If so, we need to comprehend that.</em>)</p><br />
<p style="padding-left: 90px;">2.2.2.2. Format: UniqueID: ?</p><br />
<p style="padding-left: 90px;">2.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.2.4. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Format: Manual: ”person name” | Tool: ”tool id - version”</p><br />
<p style="padding-left: 90px;">2.2.3.3. Examples: ?</p><br />
<p style="padding-left: 90px;">2.2.3.4. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done.</p><br />
<p style="padding-left: 90px;">2.2.4.2. Format: Created: YYYYMMDD-HH:MM:SS</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>2.2.4 – Should we add a time zone or say it’s based on GMT? Alternatively we could adopt a date/time format from an RFC but I’m okay with this one.</em>)</p><br />
<p style="padding-left: 90px;">2.2.4.3. Example: Created: 20100129-18:30:22</p><br />
<p style="padding-left: 90px;">2.2.4.4. Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 60px;">2.2.5. Independent Review/Audit</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;">2.2.5.2. Format: Reviewed by: “person name”</p><br />
<p style="padding-left: 90px;">2.2.5.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.5.4. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</p><br />
<p style="padding-left: 60px;">2.2.6. ??</p><br />
<p style="padding-left: 60px;">(20100310 JM&nbsp;<em>2.0 – Would it be useful to have a marker or token at the top of the facts file that shows it uses the Package Facts format? This may make life easier for tools which are likely going to have to process different file formats. It would be the first thing that must appear in the file.)</em></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>)</p><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name given by originator with version information. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.1.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.1.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.1.4. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package Identifier</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: Machine name of package.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Format: identifier.suffix</p><br />
<p style="padding-left: 90px;">3.2.2.3. Examples: foo.tar, foo.rpm, ?</p><br />
<p style="padding-left: 90px;">3.2.2.4. Intent: Here, the actual&nbsp;filename of the&nbsp;compressed file (containing the package) is a significant technical element that needs to be carried with each package.</p><br />
<p style="padding-left: 60px;">3.2.3. Official Source Location</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify where the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Format: download URL</p><br />
<p style="padding-left: 90px;">3.2.3.3. Example: ?</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>3.2.3 – We should allow usage of git, svn, etc values</em>)</p><br />
<p style="padding-left: 90px;">3.2.3.4. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 60px;">3.2.4. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: use a standard way of referring to license and its version. See Section 5.0 for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Format: identifier | other</p><br />
<p style="padding-left: 90px;">3.2.4.3. Example: ? (something like GPL2.0)</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;<em>3.2.4: At Validos, we call this the “main license”, i.e. the license the project itself is applying. (The term is not the best, since most of the code can be under some other license.) However, the license the project is using is a sort of top-level license (compliance and license compatibility review can often be needed between sub-packages too, so this is also more a terminology question). Perhaps this item should state the “License Applied by Project” and then indicate if other licenses are present too</em> ) (20100407 KS <em>MVW's comments were against original term of "Formal", which has been under discussion. I think they've been addressed, but replicating here for completeness. &nbsp; Currently suggesting use of "Declared" terminology so updated field to have this.</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.4. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are recited in the source code files of the package.</p><br />
<p style="padding-left: 60px;">3.2.5. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.5.2. Format: identifier (see section 5) | other; &nbsp;one per line.</p><br />
<p style="padding-left: 90px;">3.2.5.3. Example: GPLv3.0</p><br />
<p style="padding-left: 90px;">3.2.5.4. Intent: Here, we intend to capture additional licenses under which the package is licensed. &nbsp;The license(s) for this field are licenses which are not visibly identifiable in the actual source code, but rather identified by other means, e.g., scanning tools, by the reviewer.</p><br />
<p style="padding-left: 60px;">3.2.6. –removed-</p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.7.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.7.4. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 60px;">3.2.8. Formal Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Format: YYYY</p><br />
<p style="padding-left: 90px;">3.2.8.3. Example: 2010</p><br />
<p style="padding-left: 90px;">3.2.8.4. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 60px;">3.2.9. ???</p><br />
<h2>4. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.</em>)</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;">4.1. One instance for every file in package</p><br />
<p style="padding-left: 30px;">4.2. Fields:</p><br />
<p style="padding-left: 60px;">4.2.1. File Name</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">4.2.1.3. Example: bar/foo.c</p><br />
<p style="padding-left: 90px;">4.2.1.4. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 60px;">4.2.2. File Type</p><br />
<p style="padding-left: 90px;">4.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, ??</p><br />
<p style="padding-left: 90px;">4.2.2.2. Format: ?</p><br />
<p style="padding-left: 90px;">4.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">4.2.2.4. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 60px;">4.2.3. License(s)</p><br />
<p style="padding-left: 90px;">4.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">4.2.3.2. Format: ? [identier,]* [identifier | “string“]</p><br />
<p style="padding-left: 90px;">4.2.3.3. Example: GPL2.0,BSD,”xyz license type”</p><br />
<p style="padding-left: 90px;">4.2.3.4. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 60px;">4.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">4.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">4.2.4.2. Format: [ “copyright holder”:”date(s)”]*</p><br />
<p style="padding-left: 90px;">4.2.4.3. Example: “Linus Torvalds”:”1996-2010”</p><br />
<p style="padding-left: 90px;">4.2.4.4. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 60px;">4.2.5. ?</p><br />
<h2>5. Standard License Identifiers</h2><br />
<p style="padding-left: 30px;">5.1. Rationale for licenses to choose to standardize identifiers. Focus on standardizing the most commonly used rather than all. Align with any other standardization efforts underway here that will meet the need.</p><br />
<p style="padding-left: 30px;">5.2. Table of standard licenses and their identifiers</p><br />
<table border="1" cellspacing="0" cellpadding="0" width="542"><br />
<tbody><br />
<tr><br />
<td width="69" valign="top"><br />
<p>Identifier</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>Full name</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>Official Source Text</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL2.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>GNU General Public License (GPL) Ver. 2, June 1991</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>http://www.gnu.org/copyleft/gpl.hmtl</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL3.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>...</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
</tbody><br />
</table><br />
<h2>6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-04-15T17:16:11Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>SPDX Specification Version: DRAFT 20100407</strong></p><br />
<p>(20100310 JM <em>General - Can we add a date or version to the document? &nbsp;We should probably add a revision table when it goes live but in my view not necessary to have right now</em>) (20100407 KS done)</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?</em> )</p><br />
<p>(20100210 MVW <em> Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) </em></p><br />
<p>(20100310 JM <em>General – I would add a standard disclaimer (i.e. we tried to get this right but there may be mistakes) to the Package facts that travel with it. Perhaps in the Identification Information section. See my next comment on License since it may solve that.)</em></p><br />
<p>(20100310 JM <em>General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it</em>.)</p><br />
<p>(20100310 JM <em>General – In the final version should have an examples section that shows a completed Package Facts document or maybe examples per section or both? Perhaps we can use some of use cases that we are working on for this. </em>)</p><br />
<p>(20100310 JM <em> General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?</em>) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? )</p><br />
<p>(20100310 JM <em>General – Are all these fields required or are some optional?</em>)</p><br />
<p>(20100310 JM <em>General – How do we represent different Packages in a single distribution of something? I can see where some projects are very singular and would have just an application or a library. What happens, as an example, if that project offers an application, kernel patch, library, etc in one download? Would we use one package facts to cover them all, one per piece, etc?</em>)</p><br />
<p>&nbsp;</p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for use by active participants in this specification effort, as indicated by name and email id)</p><br />
<p>(20100310 JM <em> General – I would like to see the definition of Signed Off mean “approved for release” vs. “approved for use” since I think that’s what we mean and use could possibly be construed to mean something else. )</em></p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;">(20100210 MVW 1.2<em> Should probably reflect the idea behind package specifig and use case specific data)(</em>20100407 KS<em> - use case specific data was removed - so not sure if this still needs to be addressed?)</em></p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;">1.3.5. ?</p><br />
<p style="padding-left: 30px;"><strong>4. What is not covered?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used. After we agree on what should be specified; discussions on how it can be used, who will generate it, how it will be published, audited, etc., will happen outside the scope of this document.</p><br />
<p style="padding-left: 60px;">1.4.3. ? Any identification of any patent(s) which may or may not read on the package.</p><br />
<p style="padding-left: 30px;"><strong>5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in a syntax that humans can read and write.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. ? Character set to be used to support international naming. (follow Debian precedent?)</p><br />
<p style="padding-left: 60px;">1.5.5. ? Actual specification of fields – below is illustrative rather than agreed on.</p><br />
<p style="padding-left: 60px;">1.5.6. ? Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed.</p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. Version Number for the instance of the SPDX specification.</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;">2.2.1.2. Format: Version: N.N</p><br />
<p style="padding-left: 90px;">2.2.1.3. Example: 1.0</p><br />
<p style="padding-left: 90px;">2.2.1.4 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed. Options under consideration: SHA256, ?</p><br />
<p style="padding-left: 90px;">(20100210 MVW <em>2.2.2 MD5 or PGP are also quite widely used for security, allowing e.g. to check that the downloaded package corresponds to the one distributed by the projects. There could be a signal, if the signum has been checked from file source too. If the file source did not provide a signum, it can be generated. Probably needs to allow variance for different signums (or more background knowledge, if a certain method is to be promoted</em>.)</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.2.1 – Should we add MD5? That seems to be very common as a signature as well. If we allow multiple signature types would there be a preferred one? We should also have a URL to where the keys are posted so we can check against them. I would add a field here for that. That said, problems sometimes don’t appear right away and some considerable amount of time may have elapsed. In that case, whoever posted the checksums to validate against may have taken them down for whatever reason (i.e. it’s an older version, project folded, etc).&nbsp;&nbsp;Do we want the keys to still be around in this situation? If so, we need to comprehend that.</em>)</p><br />
<p style="padding-left: 90px;">2.2.2.2. Format: UniqueID: ?</p><br />
<p style="padding-left: 90px;">2.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.2.4. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Format: Manual: ”person name” | Tool: ”tool id - version”</p><br />
<p style="padding-left: 90px;">2.2.3.3. Examples: ?</p><br />
<p style="padding-left: 90px;">2.2.3.4. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done.</p><br />
<p style="padding-left: 90px;">2.2.4.2. Format: Created: YYYYMMDD-HH:MM:SS</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>2.2.4 – Should we add a time zone or say it’s based on GMT? Alternatively we could adopt a date/time format from an RFC but I’m okay with this one.</em>)</p><br />
<p style="padding-left: 90px;">2.2.4.3. Example: Created: 20100129-18:30:22</p><br />
<p style="padding-left: 90px;">2.2.4.4. Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 60px;">2.2.5. Independent Review/Audit</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;">2.2.5.2. Format: Reviewed by: “person name”</p><br />
<p style="padding-left: 90px;">2.2.5.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.5.4. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</p><br />
<p style="padding-left: 60px;">2.2.6. ??</p><br />
<p style="padding-left: 60px;">(20100310 JM&nbsp;<em>2.0 – Would it be useful to have a marker or token at the top of the facts file that shows it uses the Package Facts format? This may make life easier for tools which are likely going to have to process different file formats. It would be the first thing that must appear in the file.)</em></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>)</p><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name given by originator with version information. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.1.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.1.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.1.4. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package Identifier</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: Machine name of package.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Format: identifier.suffix</p><br />
<p style="padding-left: 90px;">3.2.2.3. Examples: foo.tar, foo.rpm, ?</p><br />
<p style="padding-left: 90px;">3.2.2.4. Intent: Here, the actual compressed filename is a conventional technical element that needs to be carried with each package.</p><br />
<p style="padding-left: 60px;">3.2.3. Official Source Location</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify where the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Format: download URL</p><br />
<p style="padding-left: 90px;">3.2.3.3. Example: ?</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>3.2.3 – We should allow usage of git, svn, etc values</em>)</p><br />
<p style="padding-left: 90px;">3.2.3.4. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 60px;">3.2.4. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: use a standard way of referring to license and its version. See Section 5.0 for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Format: identifier | other</p><br />
<p style="padding-left: 90px;">3.2.4.3. Example: ? (something like GPL2.0)</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;<em>3.2.4: At Validos, we call this the “main license”, i.e. the license the project itself is applying. (The term is not the best, since most of the code can be under some other license.) However, the license the project is using is a sort of top-level license (compliance and license compatibility review can often be needed between sub-packages too, so this is also more a terminology question). Perhaps this item should state the “License Applied by Project” and then indicate if other licenses are present too</em> ) (20100407 KS <em>MVW's comments were against original term of "Formal", which has been under discussion. I think they've been addressed, but replicating here for completeness. &nbsp; Currently suggesting use of "Declared" terminology so updated field to have this.</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.4. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are recited in the source code files of the package.</p><br />
<p style="padding-left: 60px;">3.2.5. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.5.2. Format: identifier (see section 5) | other; &nbsp;one per line.</p><br />
<p style="padding-left: 90px;">3.2.5.3. Example: GPLv3.0</p><br />
<p style="padding-left: 90px;">3.2.5.4. Intent: Here, we intend to capture additional licenses under which the package is licensed. &nbsp;The license(s) for this field are licenses which are not visibly identifiable in the actual source code, but rather identified by other means, e.g., scanning tools, by the reviewer.</p><br />
<p style="padding-left: 60px;">3.2.6. –removed-</p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.7.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.7.4. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 60px;">3.2.8. Formal Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Format: YYYY</p><br />
<p style="padding-left: 90px;">3.2.8.3. Example: 2010</p><br />
<p style="padding-left: 90px;">3.2.8.4. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 60px;">3.2.9. ???</p><br />
<h2>4. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.</em>)</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;">4.1. One instance for every file in package</p><br />
<p style="padding-left: 30px;">4.2. Fields:</p><br />
<p style="padding-left: 60px;">4.2.1. File Name</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">4.2.1.3. Example: bar/foo.c</p><br />
<p style="padding-left: 90px;">4.2.1.4. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 60px;">4.2.2. File Type</p><br />
<p style="padding-left: 90px;">4.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, ??</p><br />
<p style="padding-left: 90px;">4.2.2.2. Format: ?</p><br />
<p style="padding-left: 90px;">4.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">4.2.2.4. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 60px;">4.2.3. License(s)</p><br />
<p style="padding-left: 90px;">4.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">4.2.3.2. Format: ? [identier,]* [identifier | “string“]</p><br />
<p style="padding-left: 90px;">4.2.3.3. Example: GPL2.0,BSD,”xyz license type”</p><br />
<p style="padding-left: 90px;">4.2.3.4. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 60px;">4.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">4.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">4.2.4.2. Format: [ “copyright holder”:”date(s)”]*</p><br />
<p style="padding-left: 90px;">4.2.4.3. Example: “Linus Torvalds”:”1996-2010”</p><br />
<p style="padding-left: 90px;">4.2.4.4. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 60px;">4.2.5. ?</p><br />
<h2>5. Standard License Identifiers</h2><br />
<p style="padding-left: 30px;">5.1. Rationale for licenses to choose to standardize identifiers. Focus on standardizing the most commonly used rather than all. Align with any other standardization efforts underway here that will meet the need.</p><br />
<p style="padding-left: 30px;">5.2. Table of standard licenses and their identifiers</p><br />
<table border="1" cellspacing="0" cellpadding="0" width="542"><br />
<tbody><br />
<tr><br />
<td width="69" valign="top"><br />
<p>Identifier</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>Full name</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>Official Source Text</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL2.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>GNU General Public License (GPL) Ver. 2, June 1991</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>http://www.gnu.org/copyleft/gpl.hmtl</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL3.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>...</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
</tbody><br />
</table><br />
<h2>6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-04-15T13:34:29Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>SPDX Specification Version: DRAFT 20100407</strong></p><br />
<p>(20100310 JM <em>General - Can we add a date or version to the document? &nbsp;We should probably add a revision table when it goes live but in my view not necessary to have right now</em>) (20100407 KS done)</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?</em> )</p><br />
<p>(20100210 MVW <em> Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) </em></p><br />
<p>(20100310 JM <em>General – I would add a standard disclaimer (i.e. we tried to get this right but there may be mistakes) to the Package facts that travel with it. Perhaps in the Identification Information section. See my next comment on License since it may solve that.)</em></p><br />
<p>(20100310 JM <em>General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it</em>.)</p><br />
<p>(20100310 JM <em>General – In the final version should have an examples section that shows a completed Package Facts document or maybe examples per section or both? Perhaps we can use some of use cases that we are working on for this. </em>)</p><br />
<p>(20100310 JM <em> General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?</em>) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? )</p><br />
<p>(20100310 JM <em>General – Are all these fields required or are some optional?</em>)</p><br />
<p>(20100310 JM <em>General – How do we represent different Packages in a single distribution of something? I can see where some projects are very singular and would have just an application or a library. What happens, as an example, if that project offers an application, kernel patch, library, etc in one download? Would we use one package facts to cover them all, one per piece, etc?</em>)</p><br />
<p>&nbsp;</p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for use by active participants in this specification effort, as indicated by name and email id)</p><br />
<p>(20100310 JM <em> General – I would like to see the definition of Signed Off mean “approved for release” vs. “approved for use” since I think that’s what we mean and use could possibly be construed to mean something else. )</em></p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;">(20100210 MVW 1.2<em> Should probably reflect the idea behind package specifig and use case specific data)(</em>20100407 KS<em> - use case specific data was removed - so not sure if this still needs to be addressed?)</em></p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;">1.3.5. ?</p><br />
<p style="padding-left: 30px;"><strong>4. What is not covered?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used. After we agree on what should be specified; discussions on how it can be used, who will generate it, how it will be published, audited, etc., will happen outside the scope of this document.</p><br />
<p style="padding-left: 60px;">1.4.3. ? Any identification of any patent(s) which may or may not read on the package.</p><br />
<p style="padding-left: 30px;"><strong>5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in a syntax that humans can read and write.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. ? Character set to be used to support international naming. (follow Debian precedent?)</p><br />
<p style="padding-left: 60px;">1.5.5. ? Actual specification of fields – below is illustrative rather than agreed on.</p><br />
<p style="padding-left: 60px;">1.5.6. ? Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed.</p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. Version Number for the instance of the SPDX specification.</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;">2.2.1.2. Format: Version: N.N</p><br />
<p style="padding-left: 90px;">2.2.1.3. Example: 1.0</p><br />
<p style="padding-left: 90px;">2.2.1.4 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed. Options under consideration: SHA256, ?</p><br />
<p style="padding-left: 90px;">(20100210 MVW <em>2.2.2 MD5 or PGP are also quite widely used for security, allowing e.g. to check that the downloaded package corresponds to the one distributed by the projects. There could be a signal, if the signum has been checked from file source too. If the file source did not provide a signum, it can be generated. Probably needs to allow variance for different signums (or more background knowledge, if a certain method is to be promoted</em>.)</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.2.1 – Should we add MD5? That seems to be very common as a signature as well. If we allow multiple signature types would there be a preferred one? We should also have a URL to where the keys are posted so we can check against them. I would add a field here for that. That said, problems sometimes don’t appear right away and some considerable amount of time may have elapsed. In that case, whoever posted the checksums to validate against may have taken them down for whatever reason (i.e. it’s an older version, project folded, etc).&nbsp;&nbsp;Do we want the keys to still be around in this situation? If so, we need to comprehend that.</em>)</p><br />
<p style="padding-left: 90px;">2.2.2.2. Format: UniqueID: ?</p><br />
<p style="padding-left: 90px;">2.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.2.4. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Format: Manual: ”person name” | Tool: ”tool id - version”</p><br />
<p style="padding-left: 90px;">2.2.3.3. Examples: ?</p><br />
<p style="padding-left: 90px;">2.2.3.4. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done.</p><br />
<p style="padding-left: 90px;">2.2.4.2. Format: Created: YYYYMMDD-HH:MM:SS</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>2.2.4 – Should we add a time zone or say it’s based on GMT? Alternatively we could adopt a date/time format from an RFC but I’m okay with this one.</em>)</p><br />
<p style="padding-left: 90px;">2.2.4.3. Example: Created: 20100129-18:30:22</p><br />
<p style="padding-left: 90px;">2.2.4.4. Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 60px;">2.2.5. Independent Review/Audit</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;">2.2.5.2. Format: Reviewed by: “person name”</p><br />
<p style="padding-left: 90px;">2.2.5.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.5.4. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</p><br />
<p style="padding-left: 60px;">2.2.6. ??</p><br />
<p style="padding-left: 60px;">(20100310 JM&nbsp;<em>2.0 – Would it be useful to have a marker or token at the top of the facts file that shows it uses the Package Facts format? This may make life easier for tools which are likely going to have to process different file formats. It would be the first thing that must appear in the file.)</em></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>)</p><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name given by originator with version information. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.1.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.1.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.1.4. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package Identifier</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: Machine name of package.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Format: identifier.suffix</p><br />
<p style="padding-left: 90px;">3.2.2.3. Examples: foo.tar, foo.rpm, ?</p><br />
<p style="padding-left: 90px;">3.2.2.4. Intent: Here, the extension is an important conventional technical element to be carried with each package, particularly given the occasional loss of extension.</p><br />
<p style="padding-left: 60px;">3.2.3. Official Source Location</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify where the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Format: download URL</p><br />
<p style="padding-left: 90px;">3.2.3.3. Example: ?</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>3.2.3 – We should allow usage of git, svn, etc values</em>)</p><br />
<p style="padding-left: 90px;">3.2.3.4. Intent: Here, where to download the exact package being referenced is a critical verification and tracking datum.</p><br />
<p style="padding-left: 60px;">3.2.4. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: use a standard way of referring to license and its version. See Section 5.0 for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Format: identifier | other</p><br />
<p style="padding-left: 90px;">3.2.4.3. Example: ? (something like GPL2.0)</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;<em>3.2.4: At Validos, we call this the “main license”, i.e. the license the project itself is applying. (The term is not the best, since most of the code can be under some other license.) However, the license the project is using is a sort of top-level license (compliance and license compatibility review can often be needed between sub-packages too, so this is also more a terminology question). Perhaps this item should state the “License Applied by Project” and then indicate if other licenses are present too</em> ) (20100407 KS <em>MVW's comments were against original term of "Formal", which has been under discussion. I think they've been addressed, but replicating here for completeness. &nbsp; Currently suggesting use of "Declared" terminology so updated field to have this.</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.4. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are recited in the source code files of the package.</p><br />
<p style="padding-left: 60px;">3.2.5. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.5.2. Format: identifier (see section 5) | other; &nbsp;one per line.</p><br />
<p style="padding-left: 90px;">3.2.5.3. Example: GPLv3.0</p><br />
<p style="padding-left: 90px;">3.2.5.4. Intent: Here, we intend to capture additional licenses under which the package is licensed. &nbsp;The license(s) for this field are licenses which are not visibly identifiable in the actual source code, but rather identified by other means, e.g., scanning tools, by the reviewer.</p><br />
<p style="padding-left: 60px;">3.2.6. –removed-</p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.7.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.7.4. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 60px;">3.2.8. Formal Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Format: YYYY</p><br />
<p style="padding-left: 90px;">3.2.8.3. Example: 2010</p><br />
<p style="padding-left: 90px;">3.2.8.4. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 60px;">3.2.9. ???</p><br />
<h2>4. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.</em>)</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;">4.1. One instance for every file in package</p><br />
<p style="padding-left: 30px;">4.2. Fields:</p><br />
<p style="padding-left: 60px;">4.2.1. File Name</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">4.2.1.3. Example: bar/foo.c</p><br />
<p style="padding-left: 90px;">4.2.1.4. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 60px;">4.2.2. File Type</p><br />
<p style="padding-left: 90px;">4.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, ??</p><br />
<p style="padding-left: 90px;">4.2.2.2. Format: ?</p><br />
<p style="padding-left: 90px;">4.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">4.2.2.4. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 60px;">4.2.3. License(s)</p><br />
<p style="padding-left: 90px;">4.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">4.2.3.2. Format: ? [identier,]* [identifier | “string“]</p><br />
<p style="padding-left: 90px;">4.2.3.3. Example: GPL2.0,BSD,”xyz license type”</p><br />
<p style="padding-left: 90px;">4.2.3.4. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 60px;">4.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">4.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">4.2.4.2. Format: [ “copyright holder”:”date(s)”]*</p><br />
<p style="padding-left: 90px;">4.2.4.3. Example: “Linus Torvalds”:”1996-2010”</p><br />
<p style="padding-left: 90px;">4.2.4.4. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 60px;">4.2.5. ?</p><br />
<h2>5. Standard License Identifiers</h2><br />
<p style="padding-left: 30px;">5.1. Rationale for licenses to choose to standardize identifiers. Focus on standardizing the most commonly used rather than all. Align with any other standardization efforts underway here that will meet the need.</p><br />
<p style="padding-left: 30px;">5.2. Table of standard licenses and their identifiers</p><br />
<table border="1" cellspacing="0" cellpadding="0" width="542"><br />
<tbody><br />
<tr><br />
<td width="69" valign="top"><br />
<p>Identifier</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>Full name</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>Official Source Text</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL2.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>GNU General Public License (GPL) Ver. 2, June 1991</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>http://www.gnu.org/copyleft/gpl.hmtl</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL3.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>...</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
</tbody><br />
</table><br />
<h2>6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p></div>Rocketthttps://wiki.spdx.org/view/Technical_Team/SPDX_Specification_VersionsTechnical Team/SPDX Specification Versions2010-04-15T13:33:08Z<p>Rockett: </p>
<hr />
<div><p>For anyone wanting to add comments/questions/etc. directly in the document, so they get tracked without having to do a lot of version reference, please put your comments on a new line and use the following syntax:</p><br />
<p><em>(</em>yyyymmdd initials<em> comments) &nbsp;</em></p><br />
<p><em>for</em>&nbsp;example:</p><br />
<p>(20100407 KS <em>does this make sense?</em>)</p><br />
<p>&nbsp;</p><br />
<p>&nbsp;</p><br />
<p><strong>SPDX Specification Version: DRAFT 20100407</strong></p><br />
<p>(20100310 JM <em>General - Can we add a date or version to the document? &nbsp;We should probably add a revision table when it goes live but in my view not necessary to have right now</em>) (20100407 KS done)</p><br />
<p>(20100211 KS <em>The intent from the discussions so far is that this document is licensed under the CC-BY (allow derivatives) - where should we add license text?</em> )</p><br />
<p>(20100210 MVW <em> Package specific v. Project Specific - One aspect that may need some consideration is whether some part of the data is project specific (i.e. specific to many packages of the same project). However, the current standard seems to have – with first view - only package specific data.) </em></p><br />
<p>(20100310 JM <em>General – I would add a standard disclaimer (i.e. we tried to get this right but there may be mistakes) to the Package facts that travel with it. Perhaps in the Identification Information section. See my next comment on License since it may solve that.)</em></p><br />
<p>(20100310 JM <em>General – Is the Package Facts file licensed (the use of a Formal Copyright Holder in 3.2.7 seems to imply that)? If so, do we want to say it should be under the same license as the specification?&nbsp;&nbsp;I like the idea of a permissive license or possibly even public domain. However, we could allow people to license the file or not license it according to their project or tastes. My only concern with this is the inevitable are these licenses compatible mess if I try to take 10 or 20 of these files and roll them up into (or even take info from them) a nice neat re-distributable document. I would suggest at a minimum, if someone can license this content that we have a block to capture it</em>.)</p><br />
<p>(20100310 JM <em>General – In the final version should have an examples section that shows a completed Package Facts document or maybe examples per section or both? Perhaps we can use some of use cases that we are working on for this. </em>)</p><br />
<p>(20100310 JM <em> General – Do we want a way for people to extend the format of this file and if so in a controlled way? Do we want people to add new fields in any section they wish? What if someone takes a package then modifies it and re-distributes it? Would they add or remove form the package facts? Would it be worthwhile to capture that delta in its own section? I noticed that we want the document to be signed so maybe we don’t envision it being modified in this way?</em>) (20100407 KS first entry in file is version field for specification itself - 2.2.1 is meant to handle this, &nbsp;is something else needed? )</p><br />
<p>(20100310 JM <em>General – Are all these fields required or are some optional?</em>)</p><br />
<p>(20100310 JM <em>General – How do we represent different Packages in a single distribution of something? I can see where some projects are very singular and would have just an application or a library. What happens, as an example, if that project offers an application, kernel patch, library, etc in one download? Would we use one package facts to cover them all, one per piece, etc?</em>)</p><br />
<p>&nbsp;</p><br />
<p><strong>Signed off:</strong></p><br />
<p>(Approved for use by active participants in this specification effort, as indicated by name and email id)</p><br />
<p>(20100310 JM <em> General – I would like to see the definition of Signed Off mean “approved for release” vs. “approved for use” since I think that’s what we mean and use could possibly be construed to mean something else. )</em></p><br />
<h2>1. Rationale</h2><br />
<p style="padding-left: 30px;"><strong>1.1. Charter</strong></p><br />
<p style="padding-left: 30px;">Create a set of data exchange standards to enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><br />
<p style="padding-left: 30px;"><strong>1.2. Why is a common format for data exchange needed?</strong></p><br />
<p style="padding-left: 30px;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><br />
<p style="padding-left: 30px;">(20100210 MVW 1.2<em> Should probably reflect the idea behind package specifig and use case specific data)(</em>20100407 KS<em> - use case specific data was removed - so not sure if this still needs to be addressed?)</em></p><br />
<p style="padding-left: 30px;"><strong>1.3. What does this specification cover?</strong></p><br />
<p style="padding-left: 60px;">1.3.1. Identification Information: Meta data to associate analysis results with a specific package. This includes a unique identifier to permit correlation of a specific instance of this data with a specific package.</p><br />
<p style="padding-left: 60px;">1.3.2. Overview Information: Facts that are common properties for the entire package.</p><br />
<p style="padding-left: 60px;">1.3.3. File Specific Information: Facts that are specific to each file (copyrights, licenses) that are included in the package.</p><br />
<p style="padding-left: 60px;">1.3.4. Common Licenses: standardized way of referring to the common licenses likely to be encountered.</p><br />
<p style="padding-left: 60px;">1.3.5. ?</p><br />
<p style="padding-left: 30px;"><strong>4. What is not covered?</strong></p><br />
<p style="padding-left: 60px;">1.4.1. Information that cannot be derived from a visual inspection of the package to be analyzed.</p><br />
<p style="padding-left: 60px;">1.4.2. How the data stored in this file format is used. After we agree on what should be specified; discussions on how it can be used, who will generate it, how it will be published, audited, etc., will happen outside the scope of this document.</p><br />
<p style="padding-left: 60px;">1.4.3. ? Any identification of any patent(s) which may or may not read on the package.</p><br />
<p style="padding-left: 30px;"><strong>5. Format Requirements:</strong></p><br />
<p style="padding-left: 60px;">1.5.1. Needs to be in a syntax that humans can read and write.</p><br />
<p style="padding-left: 60px;">1.5.2. Needs to be a syntax that tools can read and write.</p><br />
<p style="padding-left: 60px;">1.5.3. Needs to be suitable to be checked for syntactic correctness independent of how it was generated (human or tool).</p><br />
<p style="padding-left: 60px;">1.5.4. ? Character set to be used to support international naming. (follow Debian precedent?)</p><br />
<p style="padding-left: 60px;">1.5.5. ? Actual specification of fields – below is illustrative rather than agreed on.</p><br />
<p style="padding-left: 60px;">1.5.6. ? Discussion: XML vs. simple text to represent fields. Extent human understandable without tool still needs to be discussed.</p><br />
<h2>2. Identification Information</h2><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">2.2.1. Version Number for the instance of the SPDX specification.</p><br />
<p style="padding-left: 90px;">2.2.1.1. Purpose: version of SPDX specification to use to parse the rest of the file. This will permit future changes to the specification, and retain backwards compatibility.</p><br />
<p style="padding-left: 90px;">2.2.1.2. Format: Version: N.N</p><br />
<p style="padding-left: 90px;">2.2.1.3. Example: 1.0</p><br />
<p style="padding-left: 90px;">2.2.1.4 &nbsp;Intent: Here, parties exchanging Identification Information in accordance with SPDX need to provide 100% transparency as to which SPDX specification such&nbsp;Identification Information&nbsp;is conforming to.</p><br />
<p style="padding-left: 60px;">2.2.2. Unique Identifier</p><br />
<p style="padding-left: 90px;">2.2.2.1. Purpose: Need an independently reproducible mechanism that is agreed will permit unique identification of a specific package with this data. It must be able to determine if any file in the original package has been changed. Options under consideration: SHA256, ?</p><br />
<p style="padding-left: 90px;">(20100210 MVW <em>2.2.2 MD5 or PGP are also quite widely used for security, allowing e.g. to check that the downloaded package corresponds to the one distributed by the projects. There could be a signal, if the signum has been checked from file source too. If the file source did not provide a signum, it can be generated. Probably needs to allow variance for different signums (or more background knowledge, if a certain method is to be promoted</em>.)</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.2.1 – Should we add MD5? That seems to be very common as a signature as well. If we allow multiple signature types would there be a preferred one? We should also have a URL to where the keys are posted so we can check against them. I would add a field here for that. That said, problems sometimes don’t appear right away and some considerable amount of time may have elapsed. In that case, whoever posted the checksums to validate against may have taken them down for whatever reason (i.e. it’s an older version, project folded, etc).&nbsp;&nbsp;Do we want the keys to still be around in this situation? If so, we need to comprehend that.</em>)</p><br />
<p style="padding-left: 90px;">2.2.2.2. Format: UniqueID: ?</p><br />
<p style="padding-left: 90px;">2.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.2.4. Intent: Here, by providing an unique identifier of each package, confusion over which version/modification of a specific package the Identification Information references should be eliminated.</p><br />
<p style="padding-left: 60px;">2.2.3. Generation Method</p><br />
<p style="padding-left: 90px;">2.2.3.1. Purpose: identify how this information was generated. If manual – who, if tool – identifier and version.</p><br />
<p style="padding-left: 90px;">2.2.3.2. Format: Manual: ”person name” | Tool: ”tool id - version”</p><br />
<p style="padding-left: 90px;">2.2.3.3. Examples: ?</p><br />
<p style="padding-left: 90px;">2.2.3.4. Intent: Here, the generation method will assist the reader of the Identification Information in self determining the general reliability/accuracy of the Identification Information.</p><br />
<p style="padding-left: 60px;">2.2.4. Creation Time Stamp</p><br />
<p style="padding-left: 90px;">2.2.4.1. Purpose: Identify when the analysis was done.</p><br />
<p style="padding-left: 90px;">2.2.4.2. Format: Created: YYYYMMDD-HH:MM:SS</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>2.2.4 – Should we add a time zone or say it’s based on GMT? Alternatively we could adopt a date/time format from an RFC but I’m okay with this one.</em>)</p><br />
<p style="padding-left: 90px;">2.2.4.3. Example: Created: 20100129-18:30:22</p><br />
<p style="padding-left: 90px;">2.2.4.4. Intent: Here, the Time Stamp can serve as a verification as to whether the analysis needs to be updated. &nbsp;For example, changes in the software industry may require a different reading of a particular license identification, post a certain fixed date, due to a court holding.</p><br />
<p style="padding-left: 60px;">2.2.5. Independent Review/Audit</p><br />
<p style="padding-left: 90px;">2.2.5.1. Purpose: reviewers of tool result, or other reviewer of original – equivalent to “signed off” or “reviewed by”.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>2.2.5 – This one makes me a little nervous. If someone puts something there what does it mean? Have they verified all the information is factual? Independent Audit implies to me that someone other than the Package creator or even the project (?) has looked at this and said the information is &lt;?&gt;. )</em></p><br />
<p style="padding-left: 90px;">2.2.5.2. Format: Reviewed by: “person name”</p><br />
<p style="padding-left: 90px;">2.2.5.3. Example: ?</p><br />
<p style="padding-left: 90px;">2.2.5.4. Intent: Here, as time progress certain reviewers will begin to gain creditability as reliable. &nbsp;This field intends to make such information transparent.</p><br />
<p style="padding-left: 60px;">2.2.6. ??</p><br />
<p style="padding-left: 60px;">(20100310 JM&nbsp;<em>2.0 – Would it be useful to have a marker or token at the top of the facts file that shows it uses the Package Facts format? This may make life easier for tools which are likely going to have to process different file formats. It would be the first thing that must appear in the file.)</em></p><br />
<h2>3. Common Overview Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW&nbsp;<em>License Applied by Project&nbsp;- At Validos, we record also the license applied by the project from the projects website and then (store that information as a pdf-printout and) compare that information with the package information. Sometimes the package doesn’t have any information,(For conflicts, we use a set of “approved conclusions”.) Consider adding a section where there is the url of the page of the project’s statement on its license and even add a separate pdf-printout to the metadata info?</em>)</p><br />
<p style="padding-left: 30px;">1. One instance per package</p><br />
<p style="padding-left: 30px;">2. Fields:</p><br />
<p style="padding-left: 60px;">3.2.1. Formal Name</p><br />
<p style="padding-left: 90px;">3.2.1.1. Purpose: Full name given by originator with version information. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.1.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.1.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.1.4. Intent: Here, the formal name of each package is an important conventional technical identifier to be maintained for each package.</p><br />
<p style="padding-left: 60px;">3.2.2. Specific Package Identifier</p><br />
<p style="padding-left: 90px;">3.2.2.1. Purpose: Machine name of package.</p><br />
<p style="padding-left: 90px;">3.2.2.2. Format: identifier.suffix</p><br />
<p style="padding-left: 90px;">3.2.2.3. Examples: foo.tar, foo.rpm, ?</p><br />
<p style="padding-left: 90px;">3.2.2.4. Intent: Here, the extension is an important conventional technical element to be carried with each package, particularly given the occasional loss of extension.</p><br />
<p style="padding-left: 60px;">3.2.3. Official Source Location</p><br />
<p style="padding-left: 90px;">3.2.3.1. Purpose: identify where the original version of this package resides (at time of analysis).</p><br />
<p style="padding-left: 90px;">3.2.3.2. Format: download URL</p><br />
<p style="padding-left: 90px;">3.2.3.3. Example: ?</p><br />
<p style="padding-left: 90px;">(20100310 JM <em>3.2.3 – We should allow usage of git, svn, etc values</em>)</p><br />
<p style="padding-left: 90px;">3.2.3.4. Intent: Here, where to download the exact package being referenced is an critical verification and tracking datum.</p><br />
<p style="padding-left: 60px;">3.2.4. Declared License for Package</p><br />
<p style="padding-left: 90px;">3.2.4.1. Purpose: use a standard way of referring to license and its version. See Section 5.0 for standardized license short forms. If more than one in effect, list license package defaults to and indicate alternate license is present.</p><br />
<p style="padding-left: 90px;">3.2.4.2. Format: identifier | other</p><br />
<p style="padding-left: 90px;">3.2.4.3. Example: ? (something like GPL2.0)</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;<em>3.2.4: At Validos, we call this the “main license”, i.e. the license the project itself is applying. (The term is not the best, since most of the code can be under some other license.) However, the license the project is using is a sort of top-level license (compliance and license compatibility review can often be needed between sub-packages too, so this is also more a terminology question). Perhaps this item should state the “License Applied by Project” and then indicate if other licenses are present too</em> ) (20100407 KS <em>MVW's comments were against original term of "Formal", which has been under discussion. I think they've been addressed, but replicating here for completeness. &nbsp; Currently suggesting use of "Declared" terminology so updated field to have this.</em> )</p><br />
<p style="padding-left: 90px;">3.2.4.4. Intent: This is simply the license identified in text in the actual package source code files (typically in the header of each package file.) &nbsp;This field may have multiple declared licenses, if multiple licenses are recited in the source code files of the package.</p><br />
<p style="padding-left: 60px;">3.2.5. License(s) Present</p><br />
<p style="padding-left: 90px;">3.2.5.1. Purpose: list of all licenses found in files in package by scanning</p><br />
<p style="padding-left: 90px;">3.2.5.2. Format: identifier (see section 5) | other; &nbsp;one per line.</p><br />
<p style="padding-left: 90px;">3.2.5.3. Example: GPLv3.0</p><br />
<p style="padding-left: 90px;">3.2.5.4. Intent: Here, we intend to capture additional licenses under which the package is licensed. &nbsp;The license(s) for this field are licenses which are not visibly identifiable in the actual source code, but rather identified by other means, e.g., scanning tools, by the reviewer.</p><br />
<p style="padding-left: 60px;">3.2.6. –removed-</p><br />
<p style="padding-left: 60px;">3.2.7. Declared Copyright Holder of Package</p><br />
<p style="padding-left: 90px;">3.2.7.1. Purpose: identify the author and licensor of package itself. ? Permit international extended characters in character string or restrict ?</p><br />
<p style="padding-left: 90px;">3.2.7.2. Format: ?</p><br />
<p style="padding-left: 90px;">3.2.7.3. Example: ?</p><br />
<p style="padding-left: 90px;">3.2.7.4. Intent: Here, by identifying the actual author(s), some ambiguities, e.g., under which license the author(s) were intending to license the package, may be resolvable by knowing who to contact for clarity.</p><br />
<p style="padding-left: 60px;">3.2.8. Formal Copyright Date of Package</p><br />
<p style="padding-left: 90px;">3.2.8.1. Purpose: Identify the date this package was created. Individual files inside package may have different copyright dates.</p><br />
<p style="padding-left: 90px;">3.2.8.2. Format: YYYY</p><br />
<p style="padding-left: 90px;">3.2.8.3. Example: 2010</p><br />
<p style="padding-left: 90px;">3.2.8.4. Intent: Here, we can now begin to track when copyright protection expires, for example, and the package falls into the public domain.</p><br />
<p style="padding-left: 60px;">3.2.9. ???</p><br />
<h2>4. File Specific Information</h2><br />
<p style="padding-left: 30px;">(20100210 MVW <em>File Level Data&nbsp;- One instance per file seems overwhelming if these instances are separate files. On the other hand, if they are within one file, it should be ok. &nbsp;- The practical result of one instance should be as short as possible. &nbsp;- There will be repetition (same copyright holder, same years, same license for many files); how about a standardized method of combining this info: e.g. only a list of path+file for all files falling under the same license and then separations under the license for copyright holders and then lastly for differences in years. This will avoid repetition.&nbsp;- As an option, the standard could standardize the license headers (or part of them) in the files themselves. This has the benefit of not creating another database (the database would be the source files), and can easily use the same version control systems as for the rest of the source code. Projects would be more likely to accept this: a standard for adding the license information in the beginning of the file could help them in practice and not just create another work step. Separate package meta-data would then be required only for files containing no license headers. Of course, this is not an option for existing packages that need to be used. However, once the file package is analysed and there is separate meta-data, that information could be then dropped (if decided by the project) into the source files themselves. Removes all repetition and can be machine read.</em> )</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0- Would files that do not have licensing information be present in this block? I would think so and the relevant fields would be blank. We may want to have an explicit statement versus leaving blank.&nbsp;&nbsp; Interested in others thoughts.</em>)</p><br />
<p style="padding-left: 30px;">(20100310 JM&nbsp;<em>4.0 – Do we need an exceptions field to capture exceptions that are written in to a license? Likely difficult to farm from existing code per my comment in 4.2.2 but seems useful. )</em></p><br />
<p style="padding-left: 30px;">4.1. One instance for every file in package</p><br />
<p style="padding-left: 30px;">4.2. Fields:</p><br />
<p style="padding-left: 60px;">4.2.1. File Name</p><br />
<p style="padding-left: 90px;">4.2.1.1. Purpose: identify path to file that corresponds to this summary information. version of this standard to use to parse the rest of the file.</p><br />
<p style="padding-left: 90px;">4.2.1.2. Format: [directory/]filename.suffix</p><br />
<p style="padding-left: 90px;">4.2.1.3. Example: bar/foo.c</p><br />
<p style="padding-left: 90px;">4.2.1.4. Intent: &nbsp;Here, any confusion over where a file needs to&nbsp;hierarchically&nbsp;be placed for proper functionality is mitigated.</p><br />
<p style="padding-left: 60px;">4.2.2. File Type</p><br />
<p style="padding-left: 90px;">4.2.2.1. Purpose: Identify common types of files where there may be different treatment of copyright and license information: source, binary, machine generated, ??</p><br />
<p style="padding-left: 90px;">4.2.2.2. Format: ?</p><br />
<p style="padding-left: 90px;">4.2.2.3. Example: ?</p><br />
<p style="padding-left: 90px;">4.2.2.4. Intent: Here, this field is basically the "best available" format field, from a developer perspective.</p><br />
<p style="padding-left: 90px;">(20100310 JM&nbsp;<em>4.2.2 – I like the field but I’m struggling with whether it will be difficult to automate the generation of this information if that’s there and whether to be concerned about that. Specifically I am wondering about auto generated files that come from tools. Here is my thought process. I can see where a project could farm everything in 4.0 from existing source except for possibly this field. If so that means they have to either answer this manually for every file (think of the Linux kernel)&nbsp;&nbsp;or try and adopt (as an example) a keyword approach and add it to files</em>.)</p><br />
<p style="padding-left: 60px;">4.2.3. License(s)</p><br />
<p style="padding-left: 90px;">4.2.3.1. Purpose: License governing file if known. This will either be explicit in file, or be expected to default to package license. Use a standard way of referring to license and its version. See Section 5.0 for standardized license references. If more than one in effect, list all licenses.</p><br />
<p style="padding-left: 90px;">4.2.3.2. Format: ? [identier,]* [identifier | “string“]</p><br />
<p style="padding-left: 90px;">4.2.3.3. Example: GPL2.0,BSD,”xyz license type”</p><br />
<p style="padding-left: 90px;">4.2.3.4. Intent: Here, the intent is to have a uniform method to refer to each license with specificity to eliminate any license confusion. &nbsp;For example, the 3 clause BSD would have a different license identifier then the 4 clause BSD.&nbsp;</p><br />
<p style="padding-left: 90px;">(20100210 MVW&nbsp;4.2.3 <em>A package may contain sub-packages, which may have their own “main license”. As an “approved conclusion” we default a file with no license information to the closest package level license (not necessarily the license of the package under inspection, but the license of a sub-package), unless there is contrary information. The distinction of package and sub-packages is relevant here.</em>)</p><br />
<p style="padding-left: 60px;">4.2.4. Copyright(s)</p><br />
<p style="padding-left: 90px;">4.2.4.1. Purpose: identify the copyright holders and associated dates of their copyright that are in this specific file if known. Note: Copyright holder identifier may have developer names, companies, email addresses, so we’ll probably need a generic string mechanism (including international characters). Since there may be multiple per file, need a way of having separators between them.</p><br />
<p style="padding-left: 90px;">4.2.4.2. Format: [ “copyright holder”:”date(s)”]*</p><br />
<p style="padding-left: 90px;">4.2.4.3. Example: “Linus Torvalds”:”1996-2010”</p><br />
<p style="padding-left: 90px;">4.2.4.4. Intent: Here, similar to identifying the actual author(s) (above), by identifying the copyright holder(s), the copyright holder(s) may be contact if licensing issues exist with the package, or to request distribution under another license more compatible with a given implementation, for example.</p><br />
<p style="padding-left: 60px;">4.2.5. ?</p><br />
<h2>5. Standard License Identifiers</h2><br />
<p style="padding-left: 30px;">5.1. Rationale for licenses to choose to standardize identifiers. Focus on standardizing the most commonly used rather than all. Align with any other standardization efforts underway here that will meet the need.</p><br />
<p style="padding-left: 30px;">5.2. Table of standard licenses and their identifiers</p><br />
<table border="1" cellspacing="0" cellpadding="0" width="542"><br />
<tbody><br />
<tr><br />
<td width="69" valign="top"><br />
<p>Identifier</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>Full name</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>Official Source Text</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL2.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>GNU General Public License (GPL) Ver. 2, June 1991</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>http://www.gnu.org/copyleft/gpl.hmtl</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>GPL3.0</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>...</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
<tr><br />
<td width="69" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="216" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
<td width="256" valign="top"><br />
<p>&nbsp;</p><br />
</td><br />
</tr><br />
</tbody><br />
</table><br />
<h2>6. Definitions</h2><br />
<p style="padding-left: 30px;">1. Package: ...</p><br />
<p style="padding-left: 30px;">2. Date range: [YYYY,]*[YYYY-]YYYY syntax for multiple ranges needed.</p></div>Rockett