Technical Team/Use Cases/2.0/Low cost SPDX file - Revision history

MartinMichlmayr: Convert to MediaWiki syntax

2013-03-07T13:22:20Z

Convert to MediaWiki syntax

Bschineller at 18:58, 17 July 2012

2012-07-17T18:58:35Z

Bschineller at 18:59, 10 July 2012

2012-07-10T18:59:42Z

Pezra at 18:46, 29 May 2012

2012-05-29T18:46:54Z

Pezra at 21:03, 23 May 2012

2012-05-23T21:03:59Z

Pezra at 20:59, 23 May 2012

2012-05-23T20:59:38Z

Pezra at 20:58, 23 May 2012

2012-05-23T20:58:08Z

Pezra at 20:57, 23 May 2012

2012-05-23T20:57:43Z

New page

<p>As a maintainer of an open source project i might be willing to create and maintain an SPDX file if it where simple and easy enough to do so. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. I would like to give my users the information they need to comply with my licensing, though. I would like to create an SPDX file that describes the package but omits all the file level information.</p>

<h3>Stakeholders and interests</h3>

<ul>
<li><strong>Project maintainer</strong
<p>Wants to produce machine readable licensing information so that users can more easily adopt the package but does not want to "waste" valuable time creating that data rather than implementing features.</p></li>

<li><strong>Lax SPDX consumer</strong>
<p>A person or organization that uses SPDX data to accomplish goals that do not require exhaustive file by file data.</p></li>

<li><strong>Strict SPDX consumer</strong>
<p>A person or organization that uses SPDX data to accomplish goals that require exhaustive data on every file.</p></li>

</ul>

<h3>Main scenario</h3>

<ol>
<li>Project maintainer hears about SPDX and decides to implement it for his project.</li>
<li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li>
<li>Project maintainer publishes limited SPDX file along side the tar ball.</li>
<li>Lax SPDX consumer downloads tar ball and its SPDX file.</li>
<li>Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.</li>
</ol>

← Older revision		Revision as of 13:22, 7 March 2013
Line 1:		Line 1:
−	~~<p>~~As a maintainer of an open source project in order to make complying with my licensing easier i want to publish the licensing in a machine readable format but i am not willing to "waste" much effort on such administrivia. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. An SPDX file that describes the package but omits all the file level information sounds just about right.~~</p><p><strong>~~NOTE:~~ </strong>~~Potential conflict between this Use Case and~~ http:~~//~~spdx~~.~~org~~/~~wiki/check-see-if-spdx-data-provided-matches-files-provided  ~~(if SPDX Lite doesn't involve any checksumming...)~~</p><p><strong>~~Note 2:~~ </strong>~~Still uncertain if the Use Case is about "package" or "project" (and the definition of package vs. project in th context of this Use Case). Hence " copyrightable artifact"~~</p><h3>~~Stakeholders and interests~~</h3><ul><li><strong>~~Project maintainer~~</strong><p>~~Wants to produce machine readable licensing information so that users can more easily adopt the package but does not want to "waste" valuable time creating that data rather than implementing features.~~</p></li><li><strong>~~Lax SPDX consumer~~</strong><p>~~A person or organization that uses SPDX data to accomplish goals that do not require exhaustive file by file data.~~</p></li><li><strong>~~Strict SPDX consumer~~</strong><p>~~A person or organization that uses SPDX data to accomplish goals that require exhaustive data on every file.~~</p></li></ul><h3>~~Main scenario~~</h3><ol><li>~~Project maintainer hears about SPDX and decides to implement it for his project.~~</li><li>~~Project maintainer creates SPDX file that describes his package (e.g. name, description, licenseDeclared, licenseConcluded, checksum (optional??), etc) but does not included information about the files in package and does not generate packageVerificationCode.~~</li><li>~~Project maintainer publishes limited SPDX data for the~~  ~~copyrightable artifact~~</li><li>~~Lax SPDX consumer downloads~~  ~~copyrightable artifact~~ ~~and its SPDX data.~~</li><li>~~Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.~~</li></ol><h3>~~Alternate scenario A~~</h3><ol><li>~~Project maintainer hears about SPDX and decides to implement it for his project.~~</li><li>~~Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.~~</li><li>~~Project maintainer publishes~~ ~~limited SPDX data for the copyrightable artifact~~</li><li>~~Strict SPDX consumer downloads~~  ~~copyrightable artifact~~ ~~and its SPDX file.~~</li><li>~~Strict SPDX consumer reads the SPDX file and notes its incompleteness.~~</li><li>~~Strict SPDX consumer initiates procedures to do a deeper analysis on the package so that its goals can be accomplished.~~</li></ol><h3>~~Success Scenario~~</h3><ol><li>~~Wider adoption of SPDX by project maintainers providing licensing information in a standard~~ ~~(albeit non-exhaustive)~~ ~~format~~</li><li>~~Consumers obtain licensing intentions of project maintainers in a standard (albeit non-exhaustive) format~~</li><li>~~Consumers are able to contribute / build upon the initial low cost SPDX data to flesh it out~~</li></ol><h3> </h3>~~	+	As a maintainer of an open source project in order to make complying with my licensing easier i want to publish the licensing in a machine readable format but i am not willing to "waste" much effort on such administrivia. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. An SPDX file that describes the package but omits all the file level information sounds just about right.
		+
		+	'''NOTE:''' Potential conflict between this Use Case and [[Technical_Team/Use_Cases/2.0/Check_to_see_if_the_SPDX_data_provided_matches_the_files_provided_and_is_trustworthy_and_most_current_for_package]] (if SPDX Lite doesn't involve any checksumming...)
		+
		+	'''Note 2: '''Still uncertain if the Use Case is about "package" or "project" (and the definition of package vs. project in th context of this Use Case). Hence " copyrightable artifact"
		+
		+	==Stakeholders and interests==
		+
		+	* '''Project maintainer'''Wants to produce machine readable licensing information so that users can more easily adopt the package but does not want to "waste" valuable time creating that data rather than implementing features.
		+	* '''Lax SPDX consumer'''A person or organization that uses SPDX data to accomplish goals that do not require exhaustive file by file data.
		+	* '''Strict SPDX consumer'''A person or organization that uses SPDX data to accomplish goals that require exhaustive data on every file.
		+
		+	==Main scenario==
		+
		+	# Project maintainer hears about SPDX and decides to implement it for his project.
		+	# Project maintainer creates SPDX file that describes his package (e.g. name, description, licenseDeclared, licenseConcluded, checksum (optional??), etc) but does not included information about the files in package and does not generate packageVerificationCode.
		+	# Project maintainer publishes limited SPDX data for the copyrightable artifact
		+	# Lax SPDX consumer downloads copyrightable artifact and its SPDX data.
		+	# Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.
		+
		+	==Alternate scenario A==
		+
		+	# Project maintainer hears about SPDX and decides to implement it for his project.
		+	# Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.
		+	# Project maintainer publishes limited SPDX data for the copyrightable artifact
		+	# Strict SPDX consumer downloads copyrightable artifact and its SPDX file.
		+	# Strict SPDX consumer reads the SPDX file and notes its incompleteness.
		+	# Strict SPDX consumer initiates procedures to do a deeper analysis on the package so that its goals can be accomplished.
		+
		+	==Success Scenario==
		+
		+	# Wider adoption of SPDX by project maintainers providing licensing information in a standard (albeit non-exhaustive) format
		+	# Consumers obtain licensing intentions of project maintainers in a standard (albeit non-exhaustive) format
		+	# Consumers are able to contribute / build upon the initial low cost SPDX data to flesh it out
		+
		+	[[Category:Technical]]

← Older revision		Revision as of 18:58, 17 July 2012
Line 1:		Line 1:
−	<p>As a maintainer of an open source project in order to make complying with my licensing easier i want to publish the licensing in a machine readable format but i am not willing to "waste" much effort on such administrivia. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. An SPDX file that describes the package but omits all the file level information sounds just about right.</p><h3>Stakeholders and interests</h3><ul><li><strong>Project maintainer</strong><p>Wants to produce machine readable licensing information so that users can more easily adopt the package but does not want to "waste" valuable time creating that data rather than implementing features.</p></li><li><strong>Lax SPDX consumer</strong><p>A person or organization that uses SPDX data to accomplish goals that do not require exhaustive file by file data.</p></li><li><strong>Strict SPDX consumer</strong><p>A person or organization that uses SPDX data to accomplish goals that require exhaustive data on every file.</p></li></ul><h3>Main scenario</h3><ol><li>Project maintainer hears about SPDX and decides to implement it for his project.</li><li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li><li>Project maintainer publishes limited SPDX data for the ~~project (package)~~</li><li>Lax SPDX consumer downloads ~~project~~ and its SPDX data.</li><li>Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.</li></ol><h3>Alternate scenario A</h3><ol><li>Project maintainer hears about SPDX and decides to implement it for his project.</li><li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li><li>Project maintainer publishes limited SPDX ~~file along side~~ the ~~tar ball.~~</li><li>Strict SPDX consumer downloads ~~tar ball~~ and its SPDX file.</li><li>Strict SPDX consumer reads the SPDX file and notes its incompleteness.</li><li>Strict SPDX consumer initiates procedures to do a deeper analysis on the package so that its goals can be accomplished.</li></ol><h3>Success Scenario</h3><ol><li>Wider adoption of SPDX by project maintainers providing licensing information in a standard (albeit non-exhaustive) format</li><li>Consumers obtain licensing intentions of project maintainers in a standard (albeit non-exhaustive) format</li><li>Consumers are able to contribute / build upon the initial low cost SPDX data to flesh it out</li></ol>	+	<p>As a maintainer of an open source project in order to make complying with my licensing easier i want to publish the licensing in a machine readable format but i am not willing to "waste" much effort on such administrivia. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. An SPDX file that describes the package but omits all the file level information sounds just about right.</p><p><strong>NOTE: </strong>Potential conflict between this Use Case and http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided  (if SPDX Lite doesn't involve any checksumming...)</p><p><strong>Note 2: </strong>Still uncertain if the Use Case is about "package" or "project" (and the definition of package vs. project in th context of this Use Case). Hence " copyrightable artifact"</p><h3>Stakeholders and interests</h3><ul><li><strong>Project maintainer</strong><p>Wants to produce machine readable licensing information so that users can more easily adopt the package but does not want to "waste" valuable time creating that data rather than implementing features.</p></li><li><strong>Lax SPDX consumer</strong><p>A person or organization that uses SPDX data to accomplish goals that do not require exhaustive file by file data.</p></li><li><strong>Strict SPDX consumer</strong><p>A person or organization that uses SPDX data to accomplish goals that require exhaustive data on every file.</p></li></ul><h3>Main scenario</h3><ol><li>Project maintainer hears about SPDX and decides to implement it for his project.</li><li>Project maintainer creates SPDX file that describes his package (e.g. name, description, licenseDeclared, licenseConcluded, checksum (optional??), etc) but does not included information about the files in package and does not generate packageVerificationCode.</li><li>Project maintainer publishes limited SPDX data for the  copyrightable artifact</li><li>Lax SPDX consumer downloads  copyrightable artifact and its SPDX data.</li><li>Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.</li></ol><h3>Alternate scenario A</h3><ol><li>Project maintainer hears about SPDX and decides to implement it for his project.</li><li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li><li>Project maintainer publishes limited SPDX data for the copyrightable artifact</li><li>Strict SPDX consumer downloads  copyrightable artifact and its SPDX file.</li><li>Strict SPDX consumer reads the SPDX file and notes its incompleteness.</li><li>Strict SPDX consumer initiates procedures to do a deeper analysis on the package so that its goals can be accomplished.</li></ol><h3>Success Scenario</h3><ol><li>Wider adoption of SPDX by project maintainers providing licensing information in a standard (albeit non-exhaustive) format</li><li>Consumers obtain licensing intentions of project maintainers in a standard (albeit non-exhaustive) format</li><li>Consumers are able to contribute / build upon the initial low cost SPDX data to flesh it out</li></ol><h3> </h3>

← Older revision		Revision as of 18:46, 29 May 2012
Line 1:		Line 1:
−	<p>As a maintainer of an open source project i ~~might be~~ willing to ~~create and maintain an SPDX file if it where simple and easy enough to do so~~. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot~~. I would like to give my users the information they need to comply with my licensing, though~~. An SPDX file that describes the package but omits all the file level information sounds just about right.</p>	+	<p>As a maintainer of an open source project
		+	in order to make complying with my licensing easier
		+	i want to publish the licensing in a machine readable format but i am not willing to "waste" much effort on such administrivia. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. An SPDX file that describes the package but omits all the file level information sounds just about right.</p>

	<h3>Stakeholders and interests</h3>		<h3>Stakeholders and interests</h3>

← Older revision		Revision as of 20:59, 23 May 2012
Line 1:		Line 1:
−	<p>As a maintainer of an open source project i might be willing to create and maintain an SPDX file if it where simple and easy enough to do so. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. I would like to give my users the information they need to comply with my licensing, though. ~~I would like to create an~~ SPDX file that describes the package but omits all the file level information.</p>	+	<p>As a maintainer of an open source project i might be willing to create and maintain an SPDX file if it where simple and easy enough to do so. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. I would like to give my users the information they need to comply with my licensing, though. An SPDX file that describes the package but omits all the file level information sounds just about right.</p>

	<h3>Stakeholders and interests</h3>		<h3>Stakeholders and interests</h3>

@@ Line 1: / Line 1: @@
-<p>As a maintainer of an open source project
+<p>As a maintainer of an open source project in order to make complying with my licensing easier i want to publish the licensing in a machine readable format but i am not willing to "waste" much effort on such administrivia. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. An SPDX file that describes the package but omits all the file level information sounds just about right.</p><h3>Stakeholders and interests</h3><ul><li><strong>Project maintainer</strong><p>Wants to produce machine readable licensing information so that users can more easily adopt the package but does not want to "waste" valuable time creating that data rather than implementing features.</p></li><li><strong>Lax SPDX consumer</strong><p>A person or organization that uses SPDX data to accomplish goals that do not require exhaustive file by file data.</p></li><li><strong>Strict SPDX consumer</strong><p>A person or organization that uses SPDX data to accomplish goals that require exhaustive data on every file.</p></li></ul><h3>Main scenario</h3><ol><li>Project maintainer hears about SPDX and decides to implement it for his project.</li><li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li><li>Project maintainer publishes limited SPDX data for the project (package)</li><li>Lax SPDX consumer downloads project and its SPDX data.</li><li>Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.</li></ol><h3>Alternate scenario A</h3><ol><li>Project maintainer hears about SPDX and decides to implement it for his project.</li><li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li><li>Project maintainer publishes limited SPDX file along side the tar ball.</li><li>Strict SPDX consumer downloads tar ball and its SPDX file.</li><li>Strict SPDX consumer reads the SPDX file and notes its incompleteness.</li><li>Strict SPDX consumer initiates procedures to do a deeper analysis on the package so that its goals can be accomplished.</li></ol><h3>Success Scenario</h3><ol><li>Wider adoption of SPDX by project maintainers providing licensing information in a standard&nbsp;(albeit non-exhaustive)&nbsp;format</li><li>Consumers obtain licensing intentions of project maintainers in a standard (albeit non-exhaustive) format</li><li>Consumers are able to contribute / build upon the initial low cost SPDX data to flesh it out</li></ol>
 in order to make complying with my licensing easier
 i want to publish the licensing in a machine readable format but i am not willing to "waste" much effort on such administrivia. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. An SPDX file that describes the package but omits all the file level information sounds just about right.</p>
-−
 <h3>Stakeholders and interests</h3>
-−
 <ul>
 <li><strong>Project maintainer</strong>
 <p>Wants to produce machine readable licensing information so that users can more easily adopt the package but does not want to "waste" valuable time creating that data rather than implementing features.</p></li>
-−
 <li><strong>Lax SPDX consumer</strong>
 <p>A person or organization that uses SPDX data to accomplish goals that do not require exhaustive file by file data.</p></li>
-−
 <li><strong>Strict SPDX consumer</strong>
 <p>A person or organization that uses SPDX data to accomplish goals that require exhaustive data on every file.</p></li>
-−
 </ul>
-−
 <h3>Main scenario</h3>
-−
 <ol>
 <li>Project maintainer hears about SPDX and decides to implement it for his project.</li>
 <li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li>
-<li>Project maintainer publishes limited SPDX file along side the tar ball.</li>
-<li>Lax SPDX consumer downloads tar ball and its SPDX file.</li>
 <li>Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.</li>
 </ol>
-−
 <h3>Alternate scenario A</h3>
-−
 <ol>
 <li>Project maintainer hears about SPDX and decides to implement it for his project.</li>
 <li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li>
 <li>Project maintainer publishes limited SPDX file along side the tar ball.</li>
 <li>Strict SPDX consumer downloads tar ball and its SPDX file.</li>
 <li>Strict SPDX consumer reads the SPDX file and notes its incompleteness.</li>
 <li>Strict SPDX consumer initiates procedures to do a deeper analysis on the package so that its goals can be accomplished.</li>
 </ol>