<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapcontinue="SPDXReports2016" />
  </query-continue>
  <query>
    <pages>
      <page pageid="897" ns="0" title="SPDXReports">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">
== Program Overview ==

The objective of the SPDX Report program is to create a repository of articles to capture and share community knowledge about anything and everything SPDX.  For example, this knowledge base covers a diverse collection of topics including (but not limited to): technical issues, best practices, relevant legal topics, tool proposals, adoption strategies and analysis, license compliance considerations, position papers and so forth. Periodically one of the SPDX working groups may select an article for publication on the SPDX website (spdx.org).

== SPDX Report Library ==
The current list of reports can be found here: 

* [[SPDXReports2014|2014]]
* 2015 (None)
* [[SPDXReports2016|2016]]

== Publication Checklist ==

# For consideration author(s) need to publish their work under one of the following Creative Common Licenses:
#* '''Attribution-NoDerivs CC BY-ND''' - This license allows for redistribution, commercial and non-commercial, as long as it is passed along unchanged and in whole, with credit to the author(s). [http://creativecommons.org/licenses/by-nd/3.0/ See:]
#* '''Attribution CC BY''' - This license lets others distribute, remix, tweak, and build upon the work, even commercially, as long as they credit the author(s) for the original creation. [http://creativecommons.org/licenses/by/3.0/ See:]
#* '''Attribution-ShareAlike CC BY-SA''' - This license lets others remix, tweak, and build upon the work even for commercial purposes, as long as they credit the author(s) and license their new creations under the identical terms. [http://creativecommons.org/licenses/by-sa/3.0/ See:]
# Author(s) should submit an abstract to: press@spdx.org.
# The SPDX Business Working Group will review the abstract proposal at an upcoming reoccurring bi-weekly meeting.
# The author(s) will be informed via email if their proposal was accepted or rejected. If accepted the author(s) will be given a deadline for final submission.
# If the final draft is received by the designated deadline in .docx format, it will be reviewed in its entirety by at least two reviewers. It will either be accepted or sent back to the author(s) for revision. This process repeats itself until the report is either formally accepted by 51% of reviewers, rejected by at 51% of reviewers or withdrawn by the author(s). 
# Once a report is accepted for publication:
#* The report will be assigned a unique tech report number (e.g., SPDX TR 2013-004)
#* Formatted by the authors using the standard SPDX tech report template
#* Entered into the SPDX tech report database
#* An announcement made to the SPDX general list about the reports availability along with the abstract and a link.
# Periodically an SPDX working group may select certain reports for publication on the main website spdx.org.

== Peer Review Acceptance Criteria ==
* Must be reviewed by at least two members from two different working groups (Technical, Legal and Business).
* At least 51% of the reviewers must approve. 
* Author(s) of the article cannot be reviewers.
* The following review criteria includes:
** The content is relevant to the SPDX community
** The content is easy to understand (sufficiently well written)
** No obvious grammar or spelling mistakes present
** It has been formatted using the SPDX tech report template and all the major sections have been include (where applicable). For example, includes an Abstract, Introduction, Main Content, Summary, References and About Author sections. 
** Appropriate disclaimers are included (e.g., not legal advice, not necessary opinions of the SPDX project or the Linux Foundation).
** There is no length requirement.

== Tech Report Queue ==
{| class=&quot;wikitable sortable&quot; border=&quot;1&quot;
|+
! align=&quot;left&quot; width=9% | TR #
! align=&quot;left&quot; width=25% | Topic
! width=10% |Status
! width=10% |Who
! width=10% | Date Submitted
! class=&quot;unsortable&quot; | Comments
|-
| SPDX-TR-2014-1
| Rationale for Choosing the CC0 1.0 for SPDX File Data 
| Published
| Mark Gisi
| 2013-10-03
| Decision Summary behind choosing CC0 1.0 for SPDX File Data.
|-
| SPDX-TR-2014-2
| Accessing the SPDX License List
| Preparing for publication
| Gary O'Neall
| 2014-03-15
| License List Technical Discussion.
|-
| SPDX-TR-2014-3
| SPDX Version 2.0 – Requirements and User Stories
| Preparing for publication
| Kirsten Newcomer
| 2014-03-26
| Spex 2.0 high level Requirements doc.
|-
| SPDX-TR-2016-1
| Accessing the SPDX License List
| UPloaded updated version of the TR-2014-2 document
| Gary O'Neall
| 2016-10-11
| License List Technical Discussion.
|-
|}

== For Assistance ==
If you would like to learn more about the SPDX Tech Publication program, provide feedback on the current process or make recommendation on how to improve the process contact:
: press@spdx.org</rev>
        </revisions>
      </page>
      <page pageid="898" ns="0" title="SPDXReports2014">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">__TOC__

&lt;br&gt;

== Rationale for Choosing the CC0 1.0 for SPDX File Data (SPDX-TR-2014-1)==
{|style=&quot;border-style: dotted; border-color:black; border-width: 1px; background-color:WhiteSmoke&quot;
|
'''Title''': ''Rationale for Choosing the CC0 1.0 for SPDX File Data''
&lt;br&gt;'''Author(s)''': Mark Gisi, Wind River
&lt;br&gt;'''Report Id:''': SPDX-TR-2014-1 
&lt;br&gt;'''Report''': [[media:SPDX-TR-2014-1.v1.1.pdf| PDF link]]
&lt;br&gt;'''Abstract''': 
&lt;blockquote&gt; 
The SPDX Legal working group evaluated several license candidates that could be used to cover the data contained in a SPDX file and selected the Creative Commons CC0 1.0 - Universal Public Domain Dedication license. We present the license candidates that were considered and the respective pros and cons of each.
&lt;/blockquote&gt;
|}

&lt;br&gt;

== Accessing SPDX Licenses (SPDX-TR-2014-2)==
{|style=&quot;border-style: dotted; border-color:black; border-width: 1px; background-color:WhiteSmoke&quot;
|
'''Title''': ''Accessing SPDX Licenses''
&lt;br&gt;'''Author(s)''': Gary O'Neall, Source Auditor
&lt;br&gt;'''Report Id:''': SPDX-TR-2014-2 
&lt;br&gt;'''Report''': [[media:SPDX-TR-2014-2.v1.0.pdf| PDF link]]
&lt;br&gt;'''Abstract''': 
&lt;blockquote&gt; 
The Software Products Data Exchange (SPDX) maintains a list of standard licenses commonly used in open source software.  This document describes various methods of accessing the current and previous versions of the list.  Several methods of accessing the license list are provided ranging from simply reading the license list on the website to programmatically accessing the license list information online.
This document is organized from the easiest method of access targeted at more casual users to the most sophisticated access targeted at software programmers.
This document does not go into any details on how to submit new licenses or suggest changes to existing licenses.  Information on the license list process and additional information on SPDX licenses can be found at http://spdx.org/spdx-license-list.
&lt;/blockquote&gt;
|}

&lt;br&gt;

== SPDX Version 2.0 – Requirements and User Stories (SPDX-TR-2014-3)==
{|style=&quot;border-style: dotted; border-color:black; border-width: 1px; background-color:WhiteSmoke&quot;
|
'''Title''': ''SPDX Version 2.0 – Requirements and User Stories''
&lt;br&gt;'''Author(s)''': Kirsten Newcomer, Black Duck Software
&lt;br&gt;'''Report Id:''': SPDX-TR-2014-3 
&lt;br&gt;'''Report''': [[media:SPDX-TR-2014-3.v1.0.pdf| PDF link]]
&lt;br&gt;'''Abstract''': 
&lt;blockquote&gt; 
The goal of this document is to provide a high-level view of the features targeted for v2.0 of the SPDX specification and to provide a mapping of use cases to features. Certain terminology in the document is taken from the Scrum software development methodology. Scrum is a form of agile software development. The use of the term Epic is one such example. An Agile Epic is a group of related user stories. A User story is an independent, testable requirement.
&lt;/blockquote&gt;
|}

&lt;br&gt;</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>