THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Legal Team/Decisions/Inclusion Guidelines (Background)"

From SPDX Wiki
Jump to: navigation, search
(Convert to MediaWiki syntax)
Line 1: Line 1:
−
<p><strong>Background</strong>: &nbsp; 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> &nbsp;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. &nbsp;We discussed briefly on a few calls, but tabled for a later date due to other priorities or pre-determined agenda items. &nbsp;</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]]

Revision as of 19:39, 5 March 2013

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:
    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)
    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.
  • 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.

Retrieved from "https://wiki.spdx.org/index.php?title=Legal_Team/Decisions/Inclusion_Guidelines_(Background)&oldid=2277"