Legal Team/Decisions/Inclusion Guidelines (Background) - Revision history

Jlovejoy at 06:49, 8 July 2014

2014-07-08T06:49:50Z

Jlovejoy: Jlovejoy moved page Legal Team/License List/Inclusion Guidelines (Background) to Legal Team/Decisions/Inclusion Guidelines (Background)

2013-05-21T16:33:24Z

Jlovejoy moved page Legal Team/License List/Inclusion Guidelines (Background) to Legal Team/Decisions/Inclusion Guidelines (Background)

Jlovejoy at 15:03, 9 May 2013

2013-05-09T15:03:21Z

MartinMichlmayr: Convert to MediaWiki syntax

2013-04-11T10:24:04Z

Convert to MediaWiki syntax

Jlovejoy at 18:44, 14 March 2013

2013-03-14T18:44:43Z

MartinMichlmayr: Convert to MediaWiki syntax

2013-03-05T19:39:10Z

Convert to MediaWiki syntax

Jlovejoy at 17:34, 31 January 2013

2013-01-31T17:34:57Z

Jlovejoy at 17:31, 31 January 2013

2013-01-31T17:31:26Z

Jlovejoy at 04:00, 8 January 2013

2013-01-08T04:00:45Z

Jlovejoy at 04:55, 5 December 2012

2012-12-05T04:55:36Z

New page

Background:   Work on the SPDX License List (SPDX-LL) began sometime in 2010. The first SPDX-LL had approximately one hundred licenses on it. The initial set of licenses were included based on informal discussion and consensus. Although various "guidelines" were identified in regards to which licenses to include or not during this time, formal guidelines were not recorded beyond the meeting minutes. We had to start somewhere, and the obvious was the easy beginning point. Decisions or guidelines that evolved out of discussion or by implication included the following:<ul><li>include commonly found open source licenses. Although discussion was not explicit in regards to how to define an "open source license," this was always an implicit guiding principle</li><li>include all OSI approved licenses, both current and those approved but now deprecated. Rationale being that once OSI-approved, always OSI-approved and deprecated licenses still appear "in the wild"</li><li>in regards to "public domain": public domain dedications (because, it cannot technically be a "license"...) that are commonly found, well-established, or associated with a commonly found packages will be included on the SPDX-LL (e.g., ANTLR, Sax, CC-0). However, the idea of having a "generic" identifier for something that it released into the public domain was rejected after some discussion. This would not be practical for a number of reasons:<ol><li>1) the concept of public domain does not necessarily translate across jurisdictions and some argue whether one can even release something into the public domain under US law as it is. Thus, having a short identifier could potentially only introduce ambiguity as to what that short identifier precisely means (and ambiguity - at least insofar as it comes to accurately identifying a license - is not the goal)</li><li>2) where something is noted with a public domain dedication, it can be captured the same was as any (other) license. That is, if it is something is part of the SPDX License List, it will have a short identifier, like the examples above, and if it is not on the SPDX License List, if can be captured the same way as any (other) license not on the list via a license reference.</li></ol></li><li>recognized the need for a more formal process for requesting new licenses to be added to the SPDX-LL. Such a process was discussed in terms of an ideal goal and pragmatic approach for the current reality. A process that bridged the former, with more weight on the latter was implemented in April 2012.</li></ul>Current State:  And that brings us to the waning days of 2012 when the need to make it clear and transparent to the world what criteria we are using to maintain this list in terms of determining when to "accept" or "reject" a request to add a license to the SPDX-LL became impossible to ignore. Repeated abbreviated discussions around the issue of "freeware" or open source-ish licenses came up on a multiple occasions and so discussion ensued and a first draft and one round of revisions were completed by December 2012.Goal: The goal here is to come up with a set of guiding principles for licenses to be added or not added to the SPDX-LL. This way, when a license request is submitted the guidelines can be referenced (instead of one-off rationales for each license, which is inefficient), thus providing some consistency and reliable expectations for what the SPDX-LL includes.Please review the meeting minutes on the following dates for a summary of discussion thus far:<ul><li>initially brought up briefly (and in regards to Sun/Oracle licenses which are commonly found, but not really "open source" licenses) in mid-August 2012.  We discussed briefly on a few calls, but tabled for a later date due to other priorities or pre-determined agenda items.  </li><li>Request for addition of FLohttp://spdx.org/wiki/legal-team-meeting-minutes-2012-10-31</li><li>http://spdx.org/wiki/legal-team-meeting-minutes-2012-11-13</li><li>subsequent email discussion centered around the need for the guidelines to also comment on the addition of such things as public domain notices or other notices that do not, per se, constitute a "license" but may otherwise fit the existing/initial criteria (commonly found/common package)</li></ul>Also see the attached document below for the second draft, which includes some comments and track changes.Additional discussion has been ongoing via the mailing list at legal at spdx.org. Alternatively, you can comment on this page below.

@@ Line 5: / Line 5: @@
 * include commonly found open source licenses. Although discussion was not explicit in regards to how to define an "open source license," this was always an implicit guiding principle
 * include all OSI approved licenses, both current and those approved but now deprecated. Rationale being that once OSI-approved, always OSI-approved and deprecated licenses still appear "in the wild"
-* in regards to "public domain": public domain dedications (because, it cannot technically be a "license"...) that are commonly found, well-established, or associated with a commonly found packages will be included on the SPDX-LL (e.g., ANTLR, Sax, CC-0). However, the idea of having a "generic" identifier for something that it released into the public domain was rejected after some discussion. This would not be practical for a number of reasons:
+* in regards to "public domain": public domain dedications (because, it cannot technically be a "license"...) that are commonly found, well-established, or associated with a commonly found packages will be included on the SPDX-LL (e.g., ANTLR, Sax, CC-0). However, the idea of having a "generic" identifier for something that it released into the public domain was rejected after some discussion. (For more on public domain, see http://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files_(DRAFT) .) This would not be practical for a number of reasons:
 *# the concept of public domain does not necessarily translate across jurisdictions and the conditions under which a work can be released to the public domain vary on an country-by-country basis. Thus, having a short identifier could potentially only introduce ambiguity as to what that short identifier precisely means (and ambiguity - at least insofar as it comes to accurately identifying a license - is not the goal)
 *# where something is noted with a public domain dedication, it can be captured the same was as any (other) license. That is, if it is something is part of the SPDX License List, it will have a short identifier, full name and exact text match like the examples above, and if it is not on the SPDX License List, it can be captured the same way as any (other) license not on the list via a license reference.
 * recognition that the need for a more formal process for requesting new licenses to be added to the SPDX-LL. Such a process was discussed in terms of an ideal goal and pragmatic approach for the current reality. A process that bridged the former, with more weight on the latter was implemented in April 2012.

@@ Line 18: / Line 18: @@
 The goal here is to come up with a set of guiding principles for licenses to be added or not added to the SPDX-LL. This way, when a license request is submitted the guidelines can be referenced (instead of one-off rationales for each license, which is inefficient), thus providing some consistency and reliable expectations for what the SPDX-LL includes.
-Please review the meeting minutes on the following dates for a summary of discussion thus far:
+This goal was completed in early 2013; the guidelines are included on the License List Overview page here: http://spdx.org/spdx-license-list/license-list-overview
-−
-* initially brought up briefly (and in regards to Sun/Oracle licenses which are commonly found, but not really "open source" licenses) in mid-August 2012. We discussed briefly on a few calls, but tabled for a later date due to other priorities or pre-determined agenda items.
-* Request for addition of FLora license [[Legal_Team/Minutes/2012-10-31]]
-* [[Legal_Team/Minutes/2012-11-13]]
-* subsequent email discussion centered around the need for the guidelines to also comment on the addition of such things as public domain dedications or other notices that do not, per se, constitute a "license" but may otherwise fit the existing/initial criteria (commonly found/common package)
-−
-Also see the attached document below for the second draft, which includes some comments and track changes.
-−
-Additional discussion has been ongoing via the mailing list at legal at spdx.org. Alternatively, you can comment on this page below.
 [[Category:Legal]]

← Older revision	Revision as of 10:24, 11 April 2013
(One intermediate revision by one other user not shown)
(No difference)

← Older revision	Revision as of 18:44, 14 March 2013
(One intermediate revision by the same user not shown)
(No difference)

← Older revision		Revision as of 19:39, 5 March 2013
Line 1:		Line 1:
−	~~<p><strong>~~Background~~</strong>:  ~~ Work on the SPDX License List (SPDX-LL) began sometime in 2010. The first SPDX-LL had approximately one hundred licenses on it. The initial set of licenses was included based on informal discussion and consensus. Although various "guidelines" were identified in regards to which licenses to include or not during this time, formal guidelines were not recorded beyond the meeting minutes. We had to start somewhere, and the obvious was the easy beginning point. Decisions or guidelines that evolved out of discussion or by implication included the following:~~</p><ul><li>~~include commonly found open source licenses. Although discussion was not explicit in regards to how to define an "open source license," this was always an implicit guiding principle~~</li><li>~~include all OSI approved licenses, both current and those approved but now deprecated. Rationale being that once OSI-approved, always OSI-approved and deprecated licenses still appear "in the wild"~~</li><li>~~in regards to "public domain": public domain dedications (because, it cannot technically be a "license"...) that are commonly found, well-established, or associated with a commonly found packages will be included on the SPDX-LL (e.g., ANTLR, Sax, CC-0). However, the idea of having a "generic" identifier for something that it released into the public domain was rejected after some discussion. This would not be practical for a number of reasons:~~<ol><li>1)~~ the concept of public domain does not necessarily translate across jurisdictions and the conditions under which a work can be released to the public domain vary on an country-by-country basis. Thus, having a short identifier could potentially only introduce ambiguity as to what that short identifier precisely means (and ambiguity - at least insofar as it comes to accurately identifying a license - is not the goal)~~</li><li>2)~~ where something is noted with a public domain dedication, it can be captured the same was as any (other) license. That is, if it is something is part of the SPDX License List, it will have a short identifier, full name and exact text match like the examples above, and if it is not on the SPDX License List, it can be captured the same way as any (other) license not on the list via a license reference.~~</li></ol></li><li>~~recognition that the need for a more formal process for requesting new licenses to be added to the SPDX-LL. Such a process was discussed in terms of an ideal goal and pragmatic approach for the current reality. A process that bridged the former, with more weight on the latter was implemented in April 2012.~~</li></ul><p><strong>~~Current State~~:</strong>  ~~And that brings us to the waning days of 2012 when the need to make it clear and transparent to the world what criteria we are using to maintain this list in terms of determining when to "accept" or "reject" a request to add a license to the SPDX-LL became impossible to ignore. Repeated abbreviated discussions around the issue of "freeware" or open source-ish licenses came up on a multiple occasions and so discussion ensued and a first draft and one round of revisions were completed by December 2012.~~</p><p><strong>~~Goal~~:</strong>~~ The goal here is to come up with a set of guiding principles for licenses to be added or not added to the SPDX-LL. This way, when a license request is submitted the guidelines can be referenced (instead of one-off rationales for each license, which is inefficient), thus providing some consistency and reliable expectations for what the SPDX-LL includes.~~</p><p>~~Please review the meeting minutes on the following dates for a summary of discussion thus far:~~</p><ul><li>~~initially brought up briefly (and in regards to Sun/Oracle licenses which are commonly found, but not really "open source" licenses) in mid-August 2012. ~~ ~~We discussed briefly on a few calls, but tabled for a later date due to other priorities or pre-determined agenda items. ~~ </li><li>~~Request for addition of FLora license ~~http:~~//~~spdx.org/wiki/legal-team-meeting-minutes-~~2012-10-31</~~li><li>http:~~/~~/spdx.org/wiki/legal-team-meeting-minutes-~~2012-11-13~~</li><li>~~subsequent email discussion centered around the need for the guidelines to also comment on the addition of such things as public domain dedications or other notices that do not, per se, constitute a "license" but may otherwise fit the existing/initial criteria (commonly found/common package)~~</li></ul><p>~~Also see the attached document below for the second draft, which includes some comments and track changes.~~</p><p>~~Additional discussion has been ongoing via the mailing list at legal at spdx.org. Alternatively, you can comment on this page below.~~</p>~~	+	== Background ==
		+
		+	Work on the SPDX License List (SPDX-LL) began sometime in 2010. The first SPDX-LL had approximately one hundred licenses on it. The initial set of licenses was included based on informal discussion and consensus. Although various "guidelines" were identified in regards to which licenses to include or not during this time, formal guidelines were not recorded beyond the meeting minutes. We had to start somewhere, and the obvious was the easy beginning point. Decisions or guidelines that evolved out of discussion or by implication included the following:
		+
		+	* include commonly found open source licenses. Although discussion was not explicit in regards to how to define an "open source license," this was always an implicit guiding principle
		+	* include all OSI approved licenses, both current and those approved but now deprecated. Rationale being that once OSI-approved, always OSI-approved and deprecated licenses still appear "in the wild"
		+	* in regards to "public domain": public domain dedications (because, it cannot technically be a "license"...) that are commonly found, well-established, or associated with a commonly found packages will be included on the SPDX-LL (e.g., ANTLR, Sax, CC-0). However, the idea of having a "generic" identifier for something that it released into the public domain was rejected after some discussion. This would not be practical for a number of reasons:
		+	*# the concept of public domain does not necessarily translate across jurisdictions and the conditions under which a work can be released to the public domain vary on an country-by-country basis. Thus, having a short identifier could potentially only introduce ambiguity as to what that short identifier precisely means (and ambiguity - at least insofar as it comes to accurately identifying a license - is not the goal)
		+	*# where something is noted with a public domain dedication, it can be captured the same was as any (other) license. That is, if it is something is part of the SPDX License List, it will have a short identifier, full name and exact text match like the examples above, and if it is not on the SPDX License List, it can be captured the same way as any (other) license not on the list via a license reference.
		+	* recognition that the need for a more formal process for requesting new licenses to be added to the SPDX-LL. Such a process was discussed in terms of an ideal goal and pragmatic approach for the current reality. A process that bridged the former, with more weight on the latter was implemented in April 2012.
		+
		+	== Current State ==
		+
		+	And that brings us to the waning days of 2012 when the need to make it clear and transparent to the world what criteria we are using to maintain this list in terms of determining when to "accept" or "reject" a request to add a license to the SPDX-LL became impossible to ignore. Repeated abbreviated discussions around the issue of "freeware" or open source-ish licenses came up on a multiple occasions and so discussion ensued and a first draft and one round of revisions were completed by December 2012.
		+
		+	== Goal ==
		+
		+	The goal here is to come up with a set of guiding principles for licenses to be added or not added to the SPDX-LL. This way, when a license request is submitted the guidelines can be referenced (instead of one-off rationales for each license, which is inefficient), thus providing some consistency and reliable expectations for what the SPDX-LL includes.
		+
		+	Please review the meeting minutes on the following dates for a summary of discussion thus far:
		+
		+	* initially brought up briefly (and in regards to Sun/Oracle licenses which are commonly found, but not really "open source" licenses) in mid-August 2012. We discussed briefly on a few calls, but tabled for a later date due to other priorities or pre-determined agenda items.
		+	* Request for addition of FLora license [[Legal_Team/Minutes/2012-10-31]]
		+	* [[Legal_Team/Minutes/2012-11-13]]
		+	* subsequent email discussion centered around the need for the guidelines to also comment on the addition of such things as public domain dedications or other notices that do not, per se, constitute a "license" but may otherwise fit the existing/initial criteria (commonly found/common package)
		+
		+	Also see the attached document below for the second draft, which includes some comments and track changes.
		+
		+	Additional discussion has been ongoing via the mailing list at legal at spdx.org. Alternatively, you can comment on this page below.
		+
		+	[[Category:Legal]]

← Older revision	Revision as of 16:33, 21 May 2013
(No difference)

← Older revision	Revision as of 17:34, 31 January 2013
(No difference)

← Older revision	Revision as of 17:31, 31 January 2013
(No difference)

← Older revision		Revision as of 04:00, 8 January 2013
Line 1:		Line 1:
−	<p><strong>Background</strong>:   Work on the SPDX License List (SPDX-LL) began sometime in 2010. The first SPDX-LL had approximately one hundred licenses on it. The initial set of licenses ~~were~~ included based on informal discussion and consensus. Although various "guidelines" were identified in regards to which licenses to include or not during this time, formal guidelines were not recorded beyond the meeting minutes. We had to start somewhere, and the obvious was the easy beginning point. Decisions or guidelines that evolved out of discussion or by implication included the following:</p><ul><li>include commonly found open source licenses. Although discussion was not explicit in regards to how to define an "open source license," this was always an implicit guiding principle</li><li>include all OSI approved licenses, both current and those approved but now deprecated. Rationale being that once OSI-approved, always OSI-approved and deprecated licenses still appear "in the wild"</li><li>in regards to "public domain": public domain dedications (because, it cannot technically be a "license"...) that are commonly found, well-established, or associated with a commonly found packages will be included on the SPDX-LL (e.g., ANTLR, Sax, CC-0). However, the idea of having a "generic" identifier for something that it released into the public domain was rejected after some discussion. This would not be practical for a number of reasons:<ol><li>1) the concept of public domain does not necessarily translate across jurisdictions and ~~some argue whether one~~ can ~~even release something into~~ the public domain ~~under US law as it is~~. Thus, having a short identifier could potentially only introduce ambiguity as to what that short identifier precisely means (and ambiguity - at least insofar as it comes to accurately identifying a license - is not the goal)</li><li>2) where something is noted with a public domain dedication, it can be captured the same was as any (other) license. That is, if it is something is part of the SPDX License List, it will have a short identifier, like the examples above, and if it is not on the SPDX License List, if can be captured the same way as any (other) license not on the list via a license reference.</li></ol></li><li>~~recognized~~ the need for a more formal process for requesting new licenses to be added to the SPDX-LL. Such a process was discussed in terms of an ideal goal and pragmatic approach for the current reality. A process that bridged the former, with more weight on the latter was implemented in April 2012.</li></ul><p><strong>Current State:</strong>  And that brings us to the waning days of 2012 when the need to make it clear and transparent to the world what criteria we are using to maintain this list in terms of determining when to "accept" or "reject" a request to add a license to the SPDX-LL became impossible to ignore. Repeated abbreviated discussions around the issue of "freeware" or open source-ish licenses came up on a multiple occasions and so discussion ensued and a first draft and one round of revisions were completed by December 2012.</p><p><strong>Goal:</strong> The goal here is to come up with a set of guiding principles for licenses to be added or not added to the SPDX-LL. This way, when a license request is submitted the guidelines can be referenced (instead of one-off rationales for each license, which is inefficient), thus providing some consistency and reliable expectations for what the SPDX-LL includes.</p><p>Please review the meeting minutes on the following dates for a summary of discussion thus far:</p><ul><li>initially brought up briefly (and in regards to Sun/Oracle licenses which are commonly found, but not really "open source" licenses) in mid-August 2012.  We discussed briefly on a few calls, but tabled for a later date due to other priorities or pre-determined agenda items.  </li><li>Request for addition of ~~FLohttp~~://spdx.org/wiki/legal-team-meeting-minutes-2012-10-31</li><li>http://spdx.org/wiki/legal-team-meeting-minutes-2012-11-13</li><li>subsequent email discussion centered around the need for the guidelines to also comment on the addition of such things as public domain ~~notices~~ or other notices that do not, per se, constitute a "license" but may otherwise fit the existing/initial criteria (commonly found/common package)</li></ul><p>Also see the attached document below for the second draft, which includes some comments and track changes.</p><p>Additional discussion has been ongoing via the mailing list at legal at spdx.org. Alternatively, you can comment on this page below.</p>	+	<p><strong>Background</strong>:   Work on the SPDX License List (SPDX-LL) began sometime in 2010. The first SPDX-LL had approximately one hundred licenses on it. The initial set of licenses was included based on informal discussion and consensus. Although various "guidelines" were identified in regards to which licenses to include or not during this time, formal guidelines were not recorded beyond the meeting minutes. We had to start somewhere, and the obvious was the easy beginning point. Decisions or guidelines that evolved out of discussion or by implication included the following:</p><ul><li>include commonly found open source licenses. Although discussion was not explicit in regards to how to define an "open source license," this was always an implicit guiding principle</li><li>include all OSI approved licenses, both current and those approved but now deprecated. Rationale being that once OSI-approved, always OSI-approved and deprecated licenses still appear "in the wild"</li><li>in regards to "public domain": public domain dedications (because, it cannot technically be a "license"...) that are commonly found, well-established, or associated with a commonly found packages will be included on the SPDX-LL (e.g., ANTLR, Sax, CC-0). However, the idea of having a "generic" identifier for something that it released into the public domain was rejected after some discussion. This would not be practical for a number of reasons:<ol><li>1) the concept of public domain does not necessarily translate across jurisdictions and the conditions under which a work can be released to the public domain vary on an country-by-country basis. Thus, having a short identifier could potentially only introduce ambiguity as to what that short identifier precisely means (and ambiguity - at least insofar as it comes to accurately identifying a license - is not the goal)</li><li>2) where something is noted with a public domain dedication, it can be captured the same was as any (other) license. That is, if it is something is part of the SPDX License List, it will have a short identifier, full name and exact text match like the examples above, and if it is not on the SPDX License List, it can be captured the same way as any (other) license not on the list via a license reference.</li></ol></li><li>recognition that the need for a more formal process for requesting new licenses to be added to the SPDX-LL. Such a process was discussed in terms of an ideal goal and pragmatic approach for the current reality. A process that bridged the former, with more weight on the latter was implemented in April 2012.</li></ul><p><strong>Current State:</strong>  And that brings us to the waning days of 2012 when the need to make it clear and transparent to the world what criteria we are using to maintain this list in terms of determining when to "accept" or "reject" a request to add a license to the SPDX-LL became impossible to ignore. Repeated abbreviated discussions around the issue of "freeware" or open source-ish licenses came up on a multiple occasions and so discussion ensued and a first draft and one round of revisions were completed by December 2012.</p><p><strong>Goal:</strong> The goal here is to come up with a set of guiding principles for licenses to be added or not added to the SPDX-LL. This way, when a license request is submitted the guidelines can be referenced (instead of one-off rationales for each license, which is inefficient), thus providing some consistency and reliable expectations for what the SPDX-LL includes.</p><p>Please review the meeting minutes on the following dates for a summary of discussion thus far:</p><ul><li>initially brought up briefly (and in regards to Sun/Oracle licenses which are commonly found, but not really "open source" licenses) in mid-August 2012.  We discussed briefly on a few calls, but tabled for a later date due to other priorities or pre-determined agenda items.  </li><li>Request for addition of FLora license http://spdx.org/wiki/legal-team-meeting-minutes-2012-10-31</li><li>http://spdx.org/wiki/legal-team-meeting-minutes-2012-11-13</li><li>subsequent email discussion centered around the need for the guidelines to also comment on the addition of such things as public domain dedications or other notices that do not, per se, constitute a "license" but may otherwise fit the existing/initial criteria (commonly found/common package)</li></ul><p>Also see the attached document below for the second draft, which includes some comments and track changes.</p><p>Additional discussion has been ongoing via the mailing list at legal at spdx.org. Alternatively, you can comment on this page below.</p>