SPDX Wiki - User contributions [en]

Technical Team/Minutes

2022-06-09T16:10:36Z

Goneall:

NOTE: More recent meeting minutes are now available at https://github.com/spdx/meetings/tree/tech-2022-06-07/tech

{{#subpages:|limit=500|format=ul|kidsonly=no|pathstyle=none|sort=desc}}

[[Category:Technical|Minutes]]
[[Category:Minutes]]
[[Technical Team/Minutes/CollabSummitPhotos|White Boards from Collab Summit]]

General Meeting/Minutes/2021-08-05

2021-08-05T23:06:38Z

Goneall: Created page with "* Attendance: 29 * Lead by Gary O’Neall * Minutes of July meeting Approved == New License Matching Library == * Presented by Mikihito Matsuura * Slides: https://docs.googl..."

* Attendance: 29
* Lead by Gary O’Neall
* Minutes of July meeting Approved

== New License Matching Library ==

* Presented by Mikihito Matsuura
* Slides: https://docs.google.com/presentation/d/10n5CSE_LP0HDznhb6_P6zmyA4QpKJX3b_VhOvnF3nuk/edit?usp=sharing
* PyPI: https://pypi.org/project/yalm/
* GitHub repo: https://github.com/m1kit/yalm-python/
* GitHub resources repo: https://github.com/m1kit/yalm-resources/tree/dist
* Uses 2 step process, word matching, then regex
* Looking to extend beyond python, to ruby, etc.
* Proposal JSON format for template – Should we standardize JSON?
* Vulnerable regexes in templates – regex matches may match unintended text
* What about a ML engine? Its focus is actual match rather than detection.
** Goal is license matching, not license detection
* Which matching guidelines are covered and which still needs to be implemented
** Some are not covered
** Suggest documenting which matching guidelines are not implemented
** Perhaps tune the matching guidelines and license templates
* Use of the XML format
** XML is used as input
* Additional questions and follow-up on a joint technical-legal team
* Suggestion PyPI should have spdx- in the name -

== Validate and Generate multiple representations of specifications ==
* Presented by Nirmal Praveen Suthar
* Slides: https://docs.google.com/presentation/d/17xrxcJ-74DfFmdZl99ogZTWa-MOgKuKW1PH6Qq5C4sg/edit?usp=sharing
* Relevant links:
** Parser: https://github.com/spdx/spec-parser
** spec-v3-template example: https://github.com/spdx/spec-v3-template* Populates internal graph structure, namespace model. LALR is sufficient, but opportunity for improvement.
* Generate a JSON Representation of the Specification from Structured Markdown
* Transforms spec into “pretty markdown” and RDF OWL – the latter can be used to generate other schemas used by tools
* Validation and report of errors
* Reduce redundancy (e.g. handling defaults)
* Adds reference sections

== Outreach Team Report - Sebastian/Jack ==
* Weekly meetings – Moved to Wednesday
* Update WikiPedia entry – currently terribly out of day
* Will start with Podcasts
* Follow-up with RSS feeds
* Updates for the Wordpress website – will be a topic for the next meeting
* IRC is up and running and doing well
* Please take the SBOM readiness survey: https://www.linuxfoundation.org/press-release/linux-foundation-research-announces-software-bill-of-materials-sbom-readiness-survey/
* Upcoming “town hall” will discuss tooling – see https://events.linuxfoundation.org/supply-chain-town-hall/program/schedule/
* DOCFest September 16 – see https://lists.spdx.org/g/Spdx-tech/message/4142

== Legal Team Report - Jilayne/Paul/Steve ==
* Next team call today – issues pending for release
* Next release is expected Saturday or Sunday
* Nothing technical expected in this release

== Tech Team Report - Kate/Gary/Others ==
* Specification – continuing to work through element and document interaction and modeling as well as identifier naming
** Making progress on 3.0

== Other Topics ==
None

== Attendees ==

* Kate Stewart
* Maximilian Huber -
* Sebastian Crane
* Tony Aiuto
* David Edelsohn
* Gary O'Neall
* Christopher Lusk -
* Philippe-Emmanuel Douziech
* Mikihito Matsuura (GSoC student)
* Marc-Etienne Vargenal
* Brad Goldring
* Alexios Zavras
* Rich Steenwyk
* Nirmal Suthar (GSoC student)
* Joshua Marpet
* Andrew Jorgensen (AWS)
* Christian Long
* Tiberius Hefflin
* Paul Madick
* Anshul
* Jack Manbeck
* Christina
* Jeff Schutt (Cisco)
* Jilayne Lovejoy
* Steve Winslow
* Christian Long
* Emmerich
* 2 people on phone where we did not catch the names

[[Category:General|Minutes]]
[[Category:Minutes]]

GSOC/GSOC ProjectIdeas

2021-03-28T16:41:21Z

Goneall: /* Available Mentors */

'''Welcome to the 2021 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2021 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from 2019 can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

=== Migrate SPDX Online Tools to DJango3 ===
Migrate the SPDX online tools to later versions of Django and upgrade dependencies (such as Django Social Auth) to later version to support better / more secure authentication to Github. In addition to migrating to DJango 3, additional issues can be taken on to create a full GSoC project (see the list below).

====Skills Needed====
* Experience with Python3 programming
* Familiar with Django framework

====Background Information====
The SPDX Online Tools are currently being migrated to Python3. Several libraries can now be upgraded to more supportable versions including DJango. There are some known issues with the current version of Django Social Auth which would be resolved by upgrading the versions. There may be additional libraries which can be upgraded. There is also an opportunity to improve the structure and unit tests for the online tools if time allows. See the [https://github.com/spdx/spdx-online-tools/tree/rtgdk_python3 Python3 Branch] of the SPDX online tools for the current state of the Python3 migration.

Additional tasks and issues can can be included in a project (in priority order):
* Migrate project to python3 and Django3 [https://github.com/spdx/spdx-online-tools/issues/58 issue 50] and [https://github.com/spdx/spdx-online-tools/issues/24 issue 24]
* [https://github.com/spdx/spdx-online-tools/issues/287 Merge app and api code]
* Fix and improve test [https://github.com/spdx/spdx-online-tools/issues/201 issue 201] [https://github.com/spdx/spdx-online-tools/issues/282 issue 282], [https://github.com/spdx/spdx-online-tools/issues/202 issue 202] + others
* [https://github.com/spdx/spdx-online-tools/issues/299 Add a submit via mail functionality to license submittal]
* [https://github.com/spdx/spdx-online-tools/issues/218 Store license diff screenshot in database instead of uploading to github]
* [https://github.com/spdx/spdx-online-tools/issues/157 Improve error message when error received from the Java code]
* [https://github.com/spdx/spdx-online-tools/issues/186 Add a License Diff section to the SPDX Online Tool]
* [https://github.com/spdx/spdx-online-tools/issues/91 API documentation tool]
* API for license namespace
* [https://github.com/spdx/spdx-online-tools/issues/204 Move to Github Apps and improvement for production]

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:anshuldutt21@gmail.com Anshul Dutt Sharma] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Migrate Python Tools to Python 3 ===
Migrate the [https://github.com/spdx/tools-python SPDX Python Tools] to Python 3 including all unit testing. In addition, additional known issues raised on GitHub may be tackled.

====Skills Needed====
* Experience with Python3 programming
* Knowledge of parsing algorithms

====Background Information====
The Python tools are command-line tools and a library that implement reading and writing of SPDX files in different formats, as well as converting and validating SPDX files.
The current implementation uses Python 2, which is no longer supported.
In addition to migration, some additional tasks may be taken on to improve the supportability of the library. In particular, restructuring the code to separate out the different serialization formats (see [https://github.com/spdx/tools-python/issues/147 issue 147]).

====Available Mentors====
[mailto:santiago@nyu.edu Santiago Torres Arias] [mailto:alexios.zavras@intel.com Alexios Zavras] [mailto:anshuldutt21@gmail.com Anshul Dutt Sharma]

=== RDF Writer for Golang ===
Gordf supports writing rdf triples to rdf file. Create an interface that would take in a SPDX document and generate RDF triples out of it. Which will then be consumed by the gordf to generate a RDF/xml file.

====Skills Needed====
* Knowledge of RDF
* Skills in XML parsing
* Knowledge and experience in Golang

====Background Information====
RDF/XML is one of the supported formats for SPDX documents. Creating an RDFWriter would create a generally useful facility for Golang and provide a more modular structure for the SPDX Golang tools.

See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar]

=== YAML Support for Golang libraries ===
YAML is one of the supported formats for SPDX. This project is to add support for reading and writing YAML to the Golang libraries.

====Skills Needed====
* Knowledge of YAML
* Skills in YAML parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== JSON Support for Golang libraries ===
JSON is one of the supported formats for SPDX. This project is to add support for reading and writing JSON to the Golang libraries.

====Skills Needed====
* Knowledge of JSON
* Skills in JSON parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX specification.

=== Generate a JSON Representation of the Specification from Structured Markdown ===
Convert a consistently structured Markdown file into a JSON structure following a well defined schema. Changes to an existing Markdown file should update the JSON files. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the properties of the JSON file. The conversion will also validate that the Markdown follows the required specification. The conversion would be run as part of a Github action for the SPDX specification.

====Skills Needed====
* Skills in writing parsing algorithms (e.g. working with [https://en.wikipedia.org/wiki/Abstract_syntax_tree Abstract Syntax Tree])
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of Markdown and JSON syntax

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://github.github.com/gfm/ GitHub flavored Markdown]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== Generate RDF/OWL from from JSON specification format ===
Convert a set of JSON files into a Web Ontology Language XML document. The JSON file will map to the elements and attributes of the RDF/OWL XML file. The JSON schema will be defined prior to the project start and will be consistent with the "Generate a JSON Representation of the Specification from Structured Markdown" project described above.

====Skills Needed====
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of RDF/OWL/XML formats
* Knowledge of JSON parsers

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/ RDF OWL parsing notes from the W3C]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.owl.xml Current RDF/OWL document for SPDX spec]
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

GSOC/GSOC ProjectIdeas

2021-03-28T16:41:00Z

Goneall: /* Available Mentors */

'''Welcome to the 2021 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2021 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from 2019 can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

=== Migrate SPDX Online Tools to DJango3 ===
Migrate the SPDX online tools to later versions of Django and upgrade dependencies (such as Django Social Auth) to later version to support better / more secure authentication to Github. In addition to migrating to DJango 3, additional issues can be taken on to create a full GSoC project (see the list below).

====Skills Needed====
* Experience with Python3 programming
* Familiar with Django framework

====Background Information====
The SPDX Online Tools are currently being migrated to Python3. Several libraries can now be upgraded to more supportable versions including DJango. There are some known issues with the current version of Django Social Auth which would be resolved by upgrading the versions. There may be additional libraries which can be upgraded. There is also an opportunity to improve the structure and unit tests for the online tools if time allows. See the [https://github.com/spdx/spdx-online-tools/tree/rtgdk_python3 Python3 Branch] of the SPDX online tools for the current state of the Python3 migration.

Additional tasks and issues can can be included in a project (in priority order):
* Migrate project to python3 and Django3 [https://github.com/spdx/spdx-online-tools/issues/58 issue 50] and [https://github.com/spdx/spdx-online-tools/issues/24 issue 24]
* [https://github.com/spdx/spdx-online-tools/issues/287 Merge app and api code]
* Fix and improve test [https://github.com/spdx/spdx-online-tools/issues/201 issue 201] [https://github.com/spdx/spdx-online-tools/issues/282 issue 282], [https://github.com/spdx/spdx-online-tools/issues/202 issue 202] + others
* [https://github.com/spdx/spdx-online-tools/issues/299 Add a submit via mail functionality to license submittal]
* [https://github.com/spdx/spdx-online-tools/issues/218 Store license diff screenshot in database instead of uploading to github]
* [https://github.com/spdx/spdx-online-tools/issues/157 Improve error message when error received from the Java code]
* [https://github.com/spdx/spdx-online-tools/issues/186 Add a License Diff section to the SPDX Online Tool]
* [https://github.com/spdx/spdx-online-tools/issues/91 API documentation tool]
* API for license namespace
* [https://github.com/spdx/spdx-online-tools/issues/204 Move to Github Apps and improvement for production]

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:anshuldutt21@gmail.com Anshul Dutt Sharma] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Migrate Python Tools to Python 3 ===
Migrate the [https://github.com/spdx/tools-python SPDX Python Tools] to Python 3 including all unit testing. In addition, additional known issues raised on GitHub may be tackled.

====Skills Needed====
* Experience with Python3 programming
* Knowledge of parsing algorithms

====Background Information====
The Python tools are command-line tools and a library that implement reading and writing of SPDX files in different formats, as well as converting and validating SPDX files.
The current implementation uses Python 2, which is no longer supported.
In addition to migration, some additional tasks may be taken on to improve the supportability of the library. In particular, restructuring the code to separate out the different serialization formats (see [https://github.com/spdx/tools-python/issues/147 issue 147]).

====Available Mentors====
[mailto:santiago@nyu.edu Santiago Torres Arias] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== RDF Writer for Golang ===
Gordf supports writing rdf triples to rdf file. Create an interface that would take in a SPDX document and generate RDF triples out of it. Which will then be consumed by the gordf to generate a RDF/xml file.

====Skills Needed====
* Knowledge of RDF
* Skills in XML parsing
* Knowledge and experience in Golang

====Background Information====
RDF/XML is one of the supported formats for SPDX documents. Creating an RDFWriter would create a generally useful facility for Golang and provide a more modular structure for the SPDX Golang tools.

See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar]

=== YAML Support for Golang libraries ===
YAML is one of the supported formats for SPDX. This project is to add support for reading and writing YAML to the Golang libraries.

====Skills Needed====
* Knowledge of YAML
* Skills in YAML parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== JSON Support for Golang libraries ===
JSON is one of the supported formats for SPDX. This project is to add support for reading and writing JSON to the Golang libraries.

====Skills Needed====
* Knowledge of JSON
* Skills in JSON parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX specification.

=== Generate a JSON Representation of the Specification from Structured Markdown ===
Convert a consistently structured Markdown file into a JSON structure following a well defined schema. Changes to an existing Markdown file should update the JSON files. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the properties of the JSON file. The conversion will also validate that the Markdown follows the required specification. The conversion would be run as part of a Github action for the SPDX specification.

====Skills Needed====
* Skills in writing parsing algorithms (e.g. working with [https://en.wikipedia.org/wiki/Abstract_syntax_tree Abstract Syntax Tree])
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of Markdown and JSON syntax

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://github.github.com/gfm/ GitHub flavored Markdown]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== Generate RDF/OWL from from JSON specification format ===
Convert a set of JSON files into a Web Ontology Language XML document. The JSON file will map to the elements and attributes of the RDF/OWL XML file. The JSON schema will be defined prior to the project start and will be consistent with the "Generate a JSON Representation of the Specification from Structured Markdown" project described above.

====Skills Needed====
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of RDF/OWL/XML formats
* Knowledge of JSON parsers

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/ RDF OWL parsing notes from the W3C]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.owl.xml Current RDF/OWL document for SPDX spec]
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

GSOC/GSOC ProjectIdeas

2021-03-24T20:59:39Z

Goneall:

'''Welcome to the 2021 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2021 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from 2019 can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

=== Migrate SPDX Online Tools to DJango3 ===
Migrate the SPDX online tools to later versions of Django and upgrade dependencies (such as Django Social Auth) to later version to support better / more secure authentication to Github. In addition to migrating to DJango 3, additional issues can be taken on to create a full GSoC project (see the list below).

====Skills Needed====
* Experience with Python3 programming
* Familiar with Django framework

====Background Information====
The SPDX Online Tools are currently being migrated to Python3. Several libraries can now be upgraded to more supportable versions including DJango. There are some known issues with the current version of Django Social Auth which would be resolved by upgrading the versions. There may be additional libraries which can be upgraded. There is also an opportunity to improve the structure and unit tests for the online tools if time allows. See the [https://github.com/spdx/spdx-online-tools/tree/rtgdk_python3 Python3 Branch] of the SPDX online tools for the current state of the Python3 migration.

Additional tasks and issues can can be included in a project (in priority order):
* Migrate project to python3 and Django3 [https://github.com/spdx/spdx-online-tools/issues/58 issue 50] and [https://github.com/spdx/spdx-online-tools/issues/24 issue 24]
* [https://github.com/spdx/spdx-online-tools/issues/287 Merge app and api code]
* Fix and improve test [https://github.com/spdx/spdx-online-tools/issues/201 issue 201] [https://github.com/spdx/spdx-online-tools/issues/282 issue 282], [https://github.com/spdx/spdx-online-tools/issues/202 issue 202] + others
* [https://github.com/spdx/spdx-online-tools/issues/299 Add a submit via mail functionality to license submittal]
* [https://github.com/spdx/spdx-online-tools/issues/218 Store license diff screenshot in database instead of uploading to github]
* [https://github.com/spdx/spdx-online-tools/issues/157 Improve error message when error received from the Java code]
* [https://github.com/spdx/spdx-online-tools/issues/186 Add a License Diff section to the SPDX Online Tool]
* [https://github.com/spdx/spdx-online-tools/issues/91 API documentation tool]
* API for license namespace
* [https://github.com/spdx/spdx-online-tools/issues/204 Move to Github Apps and improvement for production]

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Migrate Python Tools to Python 3 ===
Migrate the [https://github.com/spdx/tools-python SPDX Python Tools] to Python 3 including all unit testing. In addition to migrating to Python 3, additional issues can be taken on to create a full GSoC project (See the issues in the Python Tools project).

====Skills Needed====
* Experience with Python3 programming
* Knowledge of parsing algorithms

====Background Information====
The current Python libraries use Python 2 which is no longer supported. In addition to migration, some additional tasks may be taken on to improve the supportability of the library. In particular, restructuring the code to separate out the different serialization formats (see [https://github.com/spdx/tools-python/issues/147 issue 147]).

====Available Mentors====
[mailto:santiago@nyu.edu Santiago Torres Arias] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== RDF Writer for Golang ===
Gordf supports writing rdf triples to rdf file. Create an interface that would take in a SPDX document and generate RDF triples out of it. Which will then be consumed by the gordf to generate a RDF/xml file.

====Skills Needed====
* Knowledge of RDF
* Skills in XML parsing
* Knowledge and experience in Golang

====Background Information====
RDF/XML is one of the supported formats for SPDX documents. Creating an RDFWriter would create a generally useful facility for Golang and provide a more modular structure for the SPDX Golang tools.

See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar]

=== YAML Support for Golang libraries ===
YAML is one of the supported formats for SPDX. This project is to add support for reading and writing YAML to the Golang libraries.

====Skills Needed====
* Knowledge of YAML
* Skills in YAML parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== JSON Support for Golang libraries ===
JSON is one of the supported formats for SPDX. This project is to add support for reading and writing JSON to the Golang libraries.

====Skills Needed====
* Knowledge of JSON
* Skills in JSON parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX specification.

=== Generate a JSON Representation of the Specification from Structured Markdown ===
Convert a consistently structured Markdown file into a JSON structure following a well defined schema. Changes to an existing Markdown file should update the JSON files. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the properties of the JSON file. The conversion will also validate that the Markdown follows the required specification. The conversion would be run as part of a Github action for the SPDX specification.

====Skills Needed====
* Skills in writing parsing algorithms (e.g. working with [https://en.wikipedia.org/wiki/Abstract_syntax_tree Abstract Syntax Tree])
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of Markdown and JSON syntax

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://github.github.com/gfm/ GitHub flavored Markdown]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== Generate RDF/OWL from from JSON specification format ===
Convert a set of JSON files into a Web Ontology Language XML document. The JSON file will map to the elements and attributes of the RDF/OWL XML file. The JSON schema will be defined prior to the project start and will be consistent with the "Generate a JSON Representation of the Specification from Structured Markdown" project described above.

====Skills Needed====
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of RDF/OWL/XML formats
* Knowledge of JSON parsers

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/ RDF OWL parsing notes from the W3C]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.owl.xml Current RDF/OWL document for SPDX spec]
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

GSOC/GSOC ProjectIdeas

2021-03-23T22:39:20Z

Goneall: /* Migrate SPDX Online Tools to DJango3 */

'''Welcome to the 2021 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2021 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from 2019 can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

=== Migrate SPDX Online Tools to DJango3 ===
Migrate the SPDX online tools to later versions of Django and upgrade dependencies (such as Django Social Auth) to later version to support better / more secure authentication to Github. In addition to migrating to DJango 3, additional issues can be taken on to create a full GSoC project (see the list below).

====Skills Needed====
* Experience with Python3 programming
* Familiar with Django framework

====Background Information====
The SPDX Online Tools are currently being migrated to Python3. Several libraries can now be upgraded to more supportable versions including DJango. There are some known issues with the current version of Django Social Auth which would be resolved by upgrading the versions. There may be additional libraries which can be upgraded. There is also an opportunity to improve the structure and unit tests for the online tools if time allows. See the [https://github.com/spdx/spdx-online-tools/tree/rtgdk_python3 Python3 Branch] of the SPDX online tools for the current state of the Python3 migration.

Additional tasks and issues can can be included in a project (in priority order):
* Migrate project to python3 and Django3 [https://github.com/spdx/spdx-online-tools/issues/58 issue 50] and [https://github.com/spdx/spdx-online-tools/issues/24 issue 24]
* [https://github.com/spdx/spdx-online-tools/issues/287 Merge app and api code]
* Fix and improve test [https://github.com/spdx/spdx-online-tools/issues/201 issue 201] [https://github.com/spdx/spdx-online-tools/issues/282 issue 282], [https://github.com/spdx/spdx-online-tools/issues/202 issue 202] + others
* [https://github.com/spdx/spdx-online-tools/issues/299 Add a submit via mail functionality to license submittal]
* [https://github.com/spdx/spdx-online-tools/issues/218 Store license diff screenshot in database instead of uploading to github]
* [https://github.com/spdx/spdx-online-tools/issues/157 Improve error message when error received from the Java code]
* [https://github.com/spdx/spdx-online-tools/issues/186 Add a License Diff section to the SPDX Online Tool]
* [https://github.com/spdx/spdx-online-tools/issues/91 API documentation tool]
* API for license namespace
* [https://github.com/spdx/spdx-online-tools/issues/204 Move to Github Apps and improvement for production]

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== RDF Writer for Golang ===
Gordf supports writing rdf triples to rdf file. Create an interface that would take in a SPDX document and generate RDF triples out of it. Which will then be consumed by the gordf to generate a RDF/xml file.

====Skills Needed====
* Knowledge of RDF
* Skills in XML parsing
* Knowledge and experience in Golang

====Background Information====
RDF/XML is one of the supported formats for SPDX documents. Creating an RDFWriter would create a generally useful facility for Golang and provide a more modular structure for the SPDX Golang tools.

See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar]

=== YAML Support for Golang libraries ===
YAML is one of the supported formats for SPDX. This project is to add support for reading and writing YAML to the Golang libraries.

====Skills Needed====
* Knowledge of YAML
* Skills in YAML parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== JSON Support for Golang libraries ===
JSON is one of the supported formats for SPDX. This project is to add support for reading and writing JSON to the Golang libraries.

====Skills Needed====
* Knowledge of JSON
* Skills in JSON parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX specification.

=== Generate a JSON Representation of the Specification from Structured Markdown ===
Convert a consistently structured Markdown file into a JSON structure following a well defined schema. Changes to an existing Markdown file should update the JSON files. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the properties of the JSON file. The conversion will also validate that the Markdown follows the required specification. The conversion would be run as part of a Github action for the SPDX specification.

====Skills Needed====
* Skills in writing parsing algorithms (e.g. working with [https://en.wikipedia.org/wiki/Abstract_syntax_tree Abstract Syntax Tree])
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of Markdown and JSON syntax

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://github.github.com/gfm/ GitHub flavored Markdown]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== Generate RDF/OWL from from JSON specification format ===
Convert a set of JSON files into a Web Ontology Language XML document. The JSON file will map to the elements and attributes of the RDF/OWL XML file. The JSON schema will be defined prior to the project start and will be consistent with the "Generate a JSON Representation of the Specification from Structured Markdown" project described above.

====Skills Needed====
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of RDF/OWL/XML formats
* Knowledge of JSON parsers

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/ RDF OWL parsing notes from the W3C]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.owl.xml Current RDF/OWL document for SPDX spec]
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

GSOC/GSOC ProjectIdeas

2021-03-10T19:31:55Z

Goneall: /* Background Information */

'''Welcome to the 2021 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2021 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from 2019 can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

=== Migrate SPDX Online Tools to DJango3 ===
Migrate the SPDX online tools to later versions of Django and upgrade dependencies (such as Django Social Auth) to later version to support better / more secure authentication to Github.

====Skills Needed====
* Experience with Python3 programming
* Familiar with Django framework

====Background Information====
The SPDX Online Tools are currently being migrated to Python3. Several libraries can now be upgraded to more supportable versions including DJango. There are some known issues with the current version of Django Social Auth which would be resolved by upgrading the versions. There may be additional libraries which can be upgraded. There is also an opportunity to improve the structure and unit tests for the online tools if time allows. See the [Python3 Branch https://github.com/spdx/spdx-online-tools/tree/rtgdk_python3] of the SPDX online tools for the current state of the Python3 migration.

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== RDF Writer for Golang ===
Gordf supports writing rdf triples to rdf file. Create an interface that would take in a SPDX document and generate RDF triples out of it. Which will then be consumed by the gordf to generate a RDF/xml file.

====Skills Needed====
* Knowledge of RDF
* Skills in XML parsing
* Knowledge and experience in Golang

====Background Information====
RDF/XML is one of the supported formats for SPDX documents. Creating an RDFWriter would create a generally useful facility for Golang and provide a more modular structure for the SPDX Golang tools.

See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar]

=== YAML Support for Golang libraries ===
YAML is one of the supported formats for SPDX. This project is to add support for reading and writing YAML to the Golang libraries.

====Skills Needed====
* Knowledge of YAML
* Skills in YAML parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== JSON Support for Golang libraries ===
JSON is one of the supported formats for SPDX. This project is to add support for reading and writing JSON to the Golang libraries.

====Skills Needed====
* Knowledge of JSON
* Skills in JSON parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX specification.

=== Generate a JSON Representation of the Specification from Structured Markdown ===
Convert a consistently structured Markdown file into a JSON structure following a well defined schema. Changes to an existing Markdown file should update the JSON files. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the properties of the JSON file. The conversion will also validate that the Markdown follows the required specification. The conversion would be run as part of a Github action for the SPDX specification.

====Skills Needed====
* Skills in writing parsing algorithms (e.g. working with [https://en.wikipedia.org/wiki/Abstract_syntax_tree Abstract Syntax Tree])
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of Markdown and JSON syntax

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://github.github.com/gfm/ GitHub flavored Markdown]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== Generate RDF/OWL from from JSON specification format ===
Convert a set of JSON files into a Web Ontology Language XML document. The JSON file will map to the elements and attributes of the RDF/OWL XML file. The JSON schema will be defined prior to the project start and will be consistent with the "Generate a JSON Representation of the Specification from Structured Markdown" project described above.

====Skills Needed====
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of RDF/OWL/XML formats
* Knowledge of JSON parsers

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/ RDF OWL parsing notes from the W3C]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.owl.xml Current RDF/OWL document for SPDX spec]
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

GSOC/GSOC ProjectIdeas

2021-03-10T19:31:17Z

Goneall: /* Background Information */

'''Welcome to the 2021 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2021 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from 2019 can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

=== Migrate SPDX Online Tools to DJango3 ===
Migrate the SPDX online tools to later versions of Django and upgrade dependencies (such as Django Social Auth) to later version to support better / more secure authentication to Github.

====Skills Needed====
* Experience with Python3 programming
* Familiar with Django framework

====Background Information====
The SPDX Online Tools are currently being migrated to Python3. Several libraries can now be upgraded to more supportable versions including DJango. There are some known issues with the current version of Django Social Auth which would be resolved by upgrading the versions. There may be additional libraries which can be upgraded. There is also an opportunity to improve the structure and unit tests for the online tools if time allows. See the [Python3 Branch https://github.com/spdx/spdx-online-tools/tree/rtgdk_python3] of the SPDX online tools for the current state of the Python3 migration.

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== RDF Writer for Golang ===
Gordf supports writing rdf triples to rdf file. Create an interface that would take in a SPDX document and generate RDF triples out of it. Which will then be consumed by the gordf to generate a RDF/xml file.

====Skills Needed====
* Knowledge of RDF
* Skills in XML parsing
* Knowledge and experience in Golang

====Background Information====
RDF/XML is one of the supported formats for SPDX documents. Creating an RDFWriter would create a generally useful facility for Golang and provide a more modular structure for the SPDX Golang tools.

See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar]

=== YAML Support for Golang libraries ===
YAML is one of the supported formats for SPDX. This project is to add support for reading and writing YAML to the Golang libraries.

====Skills Needed====
* Knowledge of YAML
* Skills in YAML parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== JSON Support for Golang libraries ===
JSON is one of the supported formats for SPDX. This project is to add support for reading and writing JSON to the Golang libraries.

====Skills Needed====
* Knowledge of JSON
* Skills in JSON parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX specification.

=== Generate a JSON Representation of the Specification from Structured Markdown ===
Convert a consistently structured Markdown file into a JSON structure following a well defined schema. Changes to an existing Markdown file should update the JSON files. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the properties of the JSON file. The conversion will also validate that the Markdown follows the required specification. The conversion would be run as part of a Github action for the SPDX specification.

====Skills Needed====
* Skills in writing parsing algorithms (e.g. working with [https://en.wikipedia.org/wiki/Abstract_syntax_tree Abstract Syntax Tree])
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of Markdown and JSON syntax

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://github.github.com/gfm/ GitHub flavored Markdown]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== Generate RDF/OWL from from JSON specification format ===
Convert a set of JSON files into a Web Ontology Language XML document. The JSON file will map to the elements and attributes of the RDF/OWL XML file. The JSON schema will be defined prior to the project start and will be consistent with the "Generate a JSON Representation of the Specification from Structured Markdown" project described above.

====Skills Needed====
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of RDF/OWL/XML formats
* Knowledge of JSON parsers

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in GitHub as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/ RDF OWL parsing notes from the W3C]
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.owl.xml Current RDF/OWL document for SPDX spec]
* [https://github.com/spdx/spdx-spec/tree/development/v3.0/chapters Markdown for version 3.0] - subject to change as we specify the markdown constraints for this project

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

GSOC/GSOC ProjectIdeas

2021-02-03T19:30:15Z

Goneall:

'''Welcome to the 2021 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2021 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from 2019 can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

=== Migrate SPDX Online Tools to DJango3 ===
Migrate the SPDX online tools to later versions of Django and upgrade dependencies (such as Django Social Auth) to later version to support better / more secure authentication to Github.

====Skills Needed====
* Experience with Python3 programming
* Familiar with Django framework

====Background Information====
The SPDX Online Tools are currently being migrated to Python3. Several libraries can now be upgraded to more supportable versions including DJango. There are some known issues with the current version of Django Social Auth which would be resolved by upgrading the versions. There may be additional libraries which can be upgraded. There is also an opportunity to improve the structure and unit tests for the online tools if time allows. See the [Python3 Branch https://github.com/spdx/spdx-online-tools/tree/rtgdk_python3] of the SPDX online tools for the current state of the Python3 migration.

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== RDF Writer for Golang ===
Gordf supports writing rdf triples to rdf file. Create an interface that would take in a SPDX document and generate RDF triples out of it. Which will then be consumed by the gordf to generate a RDF/xml file.

====Skills Needed====
* Knowledge of RDF
* Skills in XML parsing
* Knowledge and experience in Golang

====Background Information====
RDF/XML is one of the supported formats for SPDX documents. Creating an RDFWriter would create a generally useful facility for Golang and provide a more modular structure for the SPDX Golang tools.

See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar]

=== YAML Support for Golang libraries ===
YAML is one of the supported formats for SPDX. This project is to add support for reading and writing YAML to the Golang libraries.

====Skills Needed====
* Knowledge of YAML
* Skills in YAML parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== JSON Support for Golang libraries ===
JSON is one of the supported formats for SPDX. This project is to add support for reading and writing JSON to the Golang libraries.

====Skills Needed====
* Knowledge of JSON
* Skills in JSON parsing
* Knowledge and experience in Golang

====Background Information====
See the [https://github.com/spdx/tools-golang SPDX Golang tools repo] and the [https://github.com/spdx/gordf gordf library] for more details on the current implementations.

====Available Mentors====
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.

=== Generate a JSON Representation of the Specification from Structured Markdown ===
Convert a consistently structured Markdown file into a JSON structure following a well defined schema. Changes to an existing Markdown file should update the JSON files. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the properties of the JSON file. The conversion will also validate that the Markdown follows the required specification. The conversion would be run as part of a Github action for the SPDX specification.

====Skills Needed====
* Skills in writing parsing algorithms (e.g. working with [https://en.wikipedia.org/wiki/Abstract_syntax_tree Abstract Syntax Tree])
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of JSON parsers
* Knowledge of Markdown syntax

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in Github as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://github.github.com/gfm/ Github flavored Markdown]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://github.com/spdx/spdx-spec/tree/development/v3.0/chapters Markdown for version 3.0] - subject to change as we specify the markdown constraints for this project

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== Generate RDF/OWL from from JSON specification format ===
Convert a set of JSON files into a Web Ontology Language XML document. The JSON file will map to the elements and attributes of the RDF/OWL XML file. The JSON schema will be defined prior to the project start and will be consistent with the "Generate a JSON Representation of the Specification from Structured Markdown" project described above.

====Skills Needed====
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)
* Knowledge of RDF/OWL/XML formats
* Knowledge of JSON parsers

====Background Information====
The SPDX tech team works very collaboratively on the specification updates using markdown pages in Github as the primary documentation for the specification. RDF/OWL is used as the primary technical specification for the object model including relationships, cardinality, class structure, and other restrictions. There is a lot of overlap between the information in the Markdown and the information in the OWL document. To improve the quality and productivity of the specification work, the SPDX technical team has decided to add tooling for verification of the Markdown and conversion of any common information to the OWL document. The conversion will be in 2 stages:
* Convert from Markdown to an intermediate JSON format
* Convert from the JSON format to RDF/OWL

The specific schema for the JSON format is under development and planned to be available before the start of GSoC.

Below are some additional resources for this project:
* [https://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/ RDF OWL parsing notes from the W3C]
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)
* [https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.owl.xml Current RDF/OWL document for SPDX spec]
* [https://github.com/spdx/spdx-spec/tree/development/v3.0/chapters Markdown for version 3.0] - subject to change as we specify the markdown constraints for this project

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

GSOC/GSOC ProjectIdeas

2021-02-02T22:09:18Z

Goneall: /* Proposed 2021 Projects */

GSOC/GSOC ProjectIdeas

2021-02-02T18:02:05Z

Goneall: /* Proposed 2021 Projects */

GSOC/GSOC ProjectIdeas

2021-01-31T20:49:27Z

Goneall: /* SPDX Workgroup Tooling Projects */

GSOC/GSOC ProjectIdeas

2020-12-28T17:20:22Z

Goneall:

GSOC/GSOC ProjectIdeas

2020-12-28T17:20:01Z

Goneall:

GSOC/GSOC ProjectIdeas

2020-12-28T17:14:41Z

Goneall: /* Proposed 2020 Projects */

'''Welcome to the 2020 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2021 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from last year can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Generate Java SPDX Model Classes from XML XSD file ===
In SPDX 3.0, we will be generating an XML XSD schema to define the model. This project idea is to use the XSD schema to generate a set of Java classes which represent the complete SPDX model. The generated classes would be used as part of a re-designed Java tool for SPDX.

====Skills Needed====
* Java programming skills
* XML/XSD skills
* Skills in code generation practices
* Ability to work with the community in integrating results with other projects

====Background Information====
* A proposed XSD for SPDX can be found on [https://github.com/mil-oss/spdx-xsd github]. Note: This is a very early proposal and would likely change significantly.
* Current Java tools can be found on [https://github.com/spdx/tools SPDX Tools github page]
* A rewrite of the Java tools is in progress. The in progress work can be found at the [https://github.com/goneall/Spdx-Java-Library Spdx-Java-Library] github page.

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Validate License Cross-References ===
Enhance the SPDX LicenseListPublisher to validate the cross reference / seeAlso URL's for the license. One check would be to validate the link is still valid. This would need to be done in a way that has reasonably good performance (e.g. a long timeout would not work). Another check would be to identify the license text in the linked URL and compare it to the license text for the license itself to make sure they match. If either of these tests fail, a validity attribute should be added to the license output files (e.g. the license JSON files).

====Skills Needed====
* Java programming skills
* XML/XSD skills
* HTML parsing skills
* Ability to work with the community in integrating results with other projects

====Background Information====
The [https://spdx.org/licenses/ SPDX license list] is generated from a [https://github.com/spdx/license-list-XML git repository of XML files]. One of the fields maintained in the XML is the crossRef which is a URL cross reference for the license which may be valid or it may also be a "dead link". The [https://github.com/spdx/LicenseListPublisher LicenseListPublisher] is the tool that generates the web pages and the output formats. The output formats can be found in the [https://github.com/spdx/license-list-data SPDX license list data] git repository. [https://github.com/spdx/LicenseListPublisher/issues/60#issuecomment-570511697 Issue #60] for the LicenseListPublisher describes a request to include validity attribute.

Over the summer, we may be adding the XML format to the supported output data formats in the license list data repo.

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== Improve SPDX Golang tooling ===
The goal of this GSoC project would be to add support in the [https://github.com/spdx/tools-golang SPDX Golang tools] for SPDX documents in versions of the SPDX spec other than 2.1, including the upcoming 2.2 spec release which will add JSON, YAML and XML to the supported formats. Other work may include improving the validation and data model used by the Golang tools.

====Skills Needed====
* Go programming skills
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
The [https://github.com/spdx/tools-golang SPDX Golang tools] were initially designed to work with SPDX documents in tag-value format, for version 2.1 of [https://spdx.org/specifications the SPDX specification]. Currently it does not support earlier versions of the SPDX specification. Also, [https://github.com/spdx/spdx-spec/milestone/2 the upcoming 2.2 spec release], in addition to new data fields, will also add support for SPDX documents in JSON, YAML and XML formats. The Golang tools should (at a minimum) be updated to enable reading and writing in JSON and YAML.

The SPDX Golang tools currently do some validation when reading and parsing SPDX documents, but they do not currently do much validation of the content itself. For example, license fields are represented as strings, but the tools do not currently check to confirm that e.g. the license identifiers are valid SPDX license expressions. Additional validation support to improve this would be beneficial.

Additionally, the [https://github.com/spdx/tools-golang/tree/master/spdx data model used internally by the SPDX tools] to represent SPDX content is different in some ways from the data model used by other tools (e.g. [https://github.com/spdx/tools/tree/master/src/org/spdx/rdfparser/model Java], [https://github.com/spdx/tools-python/tree/master/spdx Python]). One goal for this project might be to evaluate the choices made by those other tools, and consider whether the Golang tools' data model should change to align with those.

====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]

=== GoLang Parallel RDF Parser ===
Implement a high performance RDF parser for GoLang to support the SPDX RDF/XML format parsing and production.

====Skills Needed====
* GoLang programming skills
* Knowledge of RDF
* Knowledge of parsing algorithms

====Background Information====
As of now, there are very few known libraries in GoLang which support RDF-Parsing and are Licensed to use with an open-source project. One of them is [https://godoc.org/github.com/knakk/rdf](knakk/rdf2go). This library uses the RDF serialization format. All the current projects claiming to parse RDF files have implemented it in a linear fashion(line by line parsing) making it a repetitive and time-consuming process. This project will aim to chunk the RDF files into appropriate blocks and parse them simultaneously to reduce the effective time required to parse the entire document. The parser must conform to the SPDX-2.x version standards and have proper tests for each procedure.

This project could be included as part of a larger project which includes other fixes to the GoLang tools (see the Improve GoLang tooling project idea above).
====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== SPDX Plugins for Package Managers ===
Create a native plug-in or extension to a well-known package manager to generate valid SPDX documents based on the information provided in the build metadata files. Examples of package managers include Node Package Manager (NPM), Gradle, Rust Cargo, Ruby Gems, Python pip, and Cocoa Pods. A plugin for Maven has already been developed and can be used as an example.

The plugin should generate a valid SPDX document with minimal configuration required by the user.
====Skills Needed====
* Programming languages skills will depend on the package manager (e.g. Ruby for Ruby Gems, JavaScript for NPM)
* Knowledge of package managers and build processes
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects
====Background Information====
SPDX produces a standard Bill of Materials for software containing package and license information. Package managers collect and manage much of the data needed to produce an SPDX document. Automatically generating SPDX documents in package managers will greatly increase the efficiency and adoption of SPDX.

The [Maven Plugin]( https://github.com/spdx/spdx-maven-plugin) is a prototype plugin developed for the Maven build system. It can be used as an example for creating plugins for other build environments.
====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:kstewart@linuxfoundation.org Kate Stewart]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

Technical Team/Minutes/2020-09-22

2020-09-22T17:59:42Z

Goneall: Created page with "September 22, 2020 == Attendees == * Kate Stewart * Rishabh Bhatnagar * Nisha Kumar * William Bartholomew * Gary O’Neall * Steve Winslow * Thomas Steenbergen * David Kemp..."

September 22, 2020
== Attendees ==
* Kate Stewart
* Rishabh Bhatnagar
* Nisha Kumar
* William Bartholomew
* Gary O’Neall
* Steve Winslow
* Thomas Steenbergen

* David Kemp
* Jim Hutchison
* Peter Shin

Topics:
* Base Profile

== Base Profile ==
* Other profiles (legal and vulnerabilities/defects) are currently blocked on documentation structure
* Need a basic structure to start from
* Need to core basically be defined
* How aligned is the spec with 3T?
* Don’t want to wait for the entire base to be specified
* We have a diagram for Base that is pretty close
* Should we have a diagram for the other profiles?
* Licensing isn’t currently blocked – using a Google doc with text to make progress
** Format looks similar to the 2.2 spec text
** Would like to move to Github which will require a format to be specified
* Need to follow the ISO profile as far as format
* How do we specify which profiles are in effect
** Clause 6 – Document information
* Should we use the 2.2 format?
* Document structure is in Google Docs at https://docs.google.com/document/d/19pAxCjXER5c_tdAjIIqK2Ipz5AvirH81GQuG5CsP8wk/edit
* Discussion on Artifact superclass
** Package, File and Snippet are concrete classes based on Artifact
** Artifact is abstract
* Should we check into 3.0 branch?
** Current 3.0 branch was done before Rex’s reformatting
** Rename 3.0 branch and create a new branch based on 2.2.1
** DCO BOT is enabled for the spec repo in the branch protection rules
** William will create a new branch
* Steve will start putting the license in the new branch once available
* If anyone has an issue blocking their profile, they will add an issue
* Nisha asked if the base profile fields are locked down or if they are open to changes
** Not locked down – can add
** Base will be rather minimal
** Profiles should work out what they need and raise issues when they need something to base
* Are we adding fields to relationships?
* Are annotations going to be used for defects?
* Need to describe problem statements as well as solutions
* Create a label “Blocked” if a team is blocked in making progress
* Create a label for each profile
* Create a meta-issue for each profile – optional
* Subteams would decide if they need a diagram – if so, extend the base diagram
* When the spec is complete, each profile will have its own diagram based on the base profile
** Uses draw.io (a.k.a. diagrams.net)
** Draw.io file can be saved

==Next Week==
* Thursday is a joint tech team legal call
* Tuesday may be a continuation of Thursday’s call
* How interoperate between profile teams – if times allow
** Diagrams
*** Python class diagrams
*** diagrams.net format
*** Plant UML

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-09-15

2020-09-15T18:48:21Z

Goneall: Created page with "September 15, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * Gary O’Neall * David Kemp * Jim Hutchison * Peter Shin Topics: * Demo of new online tools ** names..."

September 15, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* Gary O’Neall
* David Kemp
* Jim Hutchison
* Peter Shin

Topics:
* Demo of new online tools
** namespace followup with Mark, Philippe and Fossology
* Document generation / XSD/ XML
* Discussion on the capturing of facts vs opinions
** relationship property
** annotation type

== Demo of new online tools ==
* A test version of the online tools is available at http://52.32.53.255/
* Walked through the functionality
* Discussion on the namespace features
** Organizations – can only be added by authorized users
*** We could use this to help maintain who has the ability to add which organizations to license namespace
** Request Mark Atwoord (Amazon), Philippe (NexB), and FOSSology to review the new namespace functionality

==Schema Generation==
* Overview of current process
** RDF OWL document is the base format used to generate all other documents
** OWL document is kept manually in sync with spec with the spec being the source of record
* Desire to change process in the future
** Automatically keep document and OWL documents in sync
** Have a different mechanism for describing the constraints that is more convenient than OWL
*** OMG is using OWL and SHACL
*** SHAX is another possibility
*** David is working on a graph language that may help – will keep us up to date

==Facts vs Opinions in SPDX Documents==
* Currently, principle stated that documents are focused on facts
* Some of the proposals for new profile introduce things that are not necessary facts
* Proposal to extend Relationship to include things that may not be facts
* Proposal to add Annotations
* Example – expiration information

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-09-08

2020-09-08T18:05:39Z

Goneall: Created page with "September 8, 2020 == Attendees == * Thomas Steenbergen * Nisha Kumar * Gary O’Neall * David Kemp * William Bartholomew * Jim Hutchison * Steve Winslow Topics: * How do we..."

September 8, 2020
== Attendees ==
* Thomas Steenbergen
* Nisha Kumar
* Gary O’Neall
* David Kemp
* William Bartholomew
* Jim Hutchison
* Steve Winslow

Topics:
* How do we best proceed on documenting the different profiles
* Core 3T SBOM comparison

== Core 3T SBOM comparison ==
* Comparison of Core 3T model to Core SPDX model
* Slides available at https://docs.google.com/presentation/d/1dvGeCAbOUSD5qFQ6mt1WsnBEZvatnonYpKGdAQCIWZg/edit#slide=id.g95424fd354_0_0 (NOTE: presentation starts a slide 8)
* Similar models
* Proposed changes to SPDX
** Identity – add structured email field, add structured tool information
* Relationship
** Subclass of element – adds ID
** add completeness enum
*** Should completeness be put in a separate profile?
*** General consensus on the call 95% of use cases will not use this so should be added as a profile
*** Agreed to defer the decision until Kate is on the call – Kate has been working with NTIA on this
*** David raised the point that completeness is an optional enumeration and may not complicate the model
*** Desire to simplify by reducing the number of field definitions
** Make the object independent of the 2 items being related
* Package URL more fundamental – mandatory unique identifier
** Expanded the URL to be and ArtifactURL – superset of PackageURL which can include other types of artifacts including hardware etc.
** concern about representing non-public package distribution; PURL may not be mature enough for all use cases
*** add to the PURL or ArtifactURL if it is missing
*** Software heritage approach could be another alternative – less human readable
*** Could we use the SPDX reference ID as a package URL
* Additional HASH algorithms
* Suggestion to create examples for various scenarios (e.g. here’s the source repository a binary artifact was built from)
* Suggest that we also have “bad examples”
* Nisha created a mock-up for a container as part of defining the linking profile
** Describing the relationships between layers, manifests can be complicated
** Difficulty in representing URL for container metadata
** Dynamic systems that re-generate the artifacts
** Proposal that the SBOM travel with the artifacts in the distributed systems

==How to document different profiles==
* ran out of time for this topic – moved to next week

==Next Week==
* Linkage profile update
* Nisha to present challenges with adapting to the container / container registry work
* How to document different profiles

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-08-25

2020-08-25T18:04:44Z

Goneall: Created page with "August 25, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * Nisha Kumar * Gary O’Neall * Peter Shin * William Bartholomew * Jim Hutchison * Philippe Ombredanne T..."

August 25, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* Nisha Kumar
* Gary O’Neall
* Peter Shin
* William Bartholomew
* Jim Hutchison
* Philippe Ombredanne

Topics:
* Vulnerability Profiles
* Identity
* OpenChain Licensing group update – SPDX 3.0

==Call with OpenChain Automotive Workgroup==
* Thomas attended a meeting with the OpenChain Automotive Workgroup
* Led my Endo-san
* Proposal to create an automotive profile
* Created a PR: PR #468 https://github.com/spdx/spdx-spec/pull/468
* Several updates are in progress for the PR
* Several enhancements to 3.0 requested
** Need a product entity
** Need a condition entity
** Need defects
*** Defects go against conditions
** Which product is involved
** Where in the lifecycle (e.g. prototype)
* Questions on scope
** Initial proposal would use SPDX for specifications communications back to supplier
** Should that be in scope for SPDX?
* Discussion on defects
** Should we expand vulnerabilities to include functional defects, others?
** Thomas suggested vulnerabilities are very similar to other types of defects
** Relationship to patches
* Desire to communicate document expiration or other way to include the concept of time
** Should we have a time profile?
** Stating a future expectation like “I will release a new version on xxx” may violate the principle of stating facts
** would like to avoid modeling contractual relationship
* Audience – who is the intended recipient?
** Example OEM supplier may document information which is not intended to be communicated to end users
** Steve suggested that the process used for communicating documents may provide the mechanism for what is communicated to whom

==Identity==
* Came out of the 3T SBOM comparison to SPDX
* Current SPDX identity is a structured string (e.g. PERSON: (email))
* Proposal to structure this as a separate class in SPDX 3.0 using person, organization and tool as subclasses
** name and email would be properties
** There may have been an identity type in the linking profile
*** Nisha will check with Santiago
* Nisha asked if there was a process to propose promoting a field from a profile to the base profile
** Those proposals can be raised in the SPDX tech meeting
** Wait until we see commonalities between profiles before promoting
** This could be used for identity properties used in linking profile and perhaps vulnerabilities
* No concerns about adding structure to the identity

==Vulnerability Profiles==
* 3T SBOM put vulnerabilities in the defects
* Thomas presented the 3T defects spec
** Similar structure to SPDX
** Additional relationships
* Proposal to use defects rather than vulnerabilities
* Question on having defect types or subclasses
* Could use different profiles for security defects vs. other types of defects
* DefectRepsonse
** Not necessarily a fact like a defect is a fact
** Should have a relationship to defect
** Examples – isAffectedBy – this would be a relationship and more fact based
* Should state SPDX 3.0 design principles
** Could start with the spec statements about scope for SPDX 2.2
* Should Vulnerabilities be their own element or a “type” of defect?
* Source – specify the source
** Rating is likely related to the source
** Suggestion to move the rating to the source
** Score may change over time
** Vulnerability creation time may be different than document creating time
** From Peter: CVSS has an equation under the hood - Weight_for_base * base + weight_for_impact * impact + ….
* Dependency Tree Profile proposal

==Next Week==
* SPDX 3.0 design principles (e.g. facts based, scope related)
* Dependency Tree Profile proposal – or template

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-08-18

2020-08-18T18:06:21Z

Goneall: Created page with "August 18, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * John Horan * Gary O’Neall * Peter Shin * Philippe Ombredanne Topics: * Google Summer of Code * Legal..."

August 18, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* John Horan
* Gary O’Neall
* Peter Shin
* Philippe Ombredanne

Topics:
* Google Summer of Code
* Legal profile – continuing discussion
* Gitlab support of SPDX

==GSoC==
* Philip’s project should be able to present next General meeting – Kate will arrange
* Philippe will meet with Philip and check on progress

==Legal Profile==
* Communicating between tools
** Example: How well was the match to the license – would be helpful for a tool to tool relationship
** Issue – loss of information detail
** Snippets don’t really work – will capture the line range, but isn’t always correct
** Should it be simplified or include a lot of detail?
** Thomas: I found this license in this file at this line number
** Would like to communicate scanning results from Scancode to SW360
** Would help with audits and detecting errors/bugs
** All on the call it would be useful
** Kate created a Google doc to track the license scanning tooling profile: https://docs.google.com/document/d/1p24qf2uNk5b1rU0m_Tvj2cD-lioFaaeJKh9PmnPbhwo/edit
** Kate also added a dependency tree profiles: https://docs.google.com/document/d/1IfcSlrDou-8KLqkLr568DKGaQiHXmt_EFsZRfcf0Ej8/edit
** Kate also created a Google doc for the vulnerabilities profile: https://docs.google.com/document/d/11S8FTG5zSwmH-o_Conp9-mkzWyOuxC_KXx3VNHlhbws/edit
** Will also create an issue
* Question on how to represent a source file: I have a question on how to handle declared license. If it's a short reference to a license, for example, how should SPDX or tool handle "See the license file" snippet. Should the SPDX handle it as a declared and none?
** Thomas, Gary and Philippe think it would be declared, but the discussion in legal was interpreted as “None” or “LicenseRef-“ with the text found in the file
* Discussion on having a primary license for a package
** Philippe will propose an extension to the license expression
** Introduce “PLUS” operator with the same semantics as AND except the expression to the left of the operator is the primary license for the package

==Gitlab==
* Gitlab jobs do not support SPDX
* Issue logged at https://gitlab.com/gitlab-org/gitlab/-/issues/218521
* Thomas requested support and comments on the issue in support of SPDX
* Steve is active with Gitlab and should be able to help
* Kate will add some pointers in the issue

==DCO signoff on SPDX Spec==
* Currently not enabled for the spec
* Agreed we will enable the DCO BOT
* Will be turn on Sept. 1
* Kate will send out an email
* Thomas will submit a PR

==Next Week==
* Vulnerabilities Profile

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-08-11

2020-08-11T21:43:41Z

Goneall: Created page with "August 11, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * Steve Winslow * Jilayne Lovejoy * Steve Winslow * Gary O’Neall * Rose Judge * Peter Shin * Brad Goldri..."

August 11, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* Steve Winslow
* Jilayne Lovejoy
* Steve Winslow
* Gary O’Neall
* Rose Judge
* Peter Shin
* Brad Goldring
* John Horan
* Rose Judge
* Vicky Brasseur
* William Bartolomew
* Mark Atwood

Topics:
* Legal profile

==Legal Profile==
* Work being done in Google Docs https://docs.google.com/document/d/1k_2tSlFXvW_SbW-I1DcSEoCNBMQJd4FEFIQr6KCJuyU/edit#
* Tried to keep section numbers same
* Note: Has not been reviewed by the entire legal team – will review in upcoming legal team meeting
* Normalized naming (e.g. references to Spdx Document rather than Spdx File)
* Discussion on Declared License for Package – metadata
** Thomas raised question on if the Artifact includes the metadata or if it is different
** Discussion on the previous discussions
*** Maven POM files was discussed previously and general agreement that the POM license info would be declared but not concluded
*** POM file license information was not always accurate
** Different scenarios discussed, general agreement that a binary distribution would be a different artifact from the bundle of source
* Discussion on license information that is not completely in the file (e.g. jQuery which includes a link but not the license notice)
** Some tools will fill in the actual license referred to
* Should we document the examples for Declared and Concluded licenses?
** Valuable information
** More specific would be better, but would make it larger
*** Would be nice to have some additional documentation somewhere
** Generally agree to move from the specific fields to the intro for the section
* Discussion on None field for license
** Should the field be renamed NONE_FOUND?
*** Concern it would break tools
** General agreement that NONE means someone looked really hard for a license and couldn’t find one at all
** In the case of “No Rights Reserved”, one would create a LicenseRef-
* Discussion cookbook
** Could create hover over in the spec
*** Concern about accessibility
* Replacing references to Disjunctive license with “OR”
* Continue discussion on the Legal team this Thursday
* What is the name of the profile for licensing?
** “Licensing”
* Discussion on associating copyright owner with license
** Thomas has a requirement to associate the license with the copyright owners
** Current SPDX does not have a mechanism to retain the associations
** Could use snippets to retain the association between copyright owners and licenses for specific code

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-08-04

2020-08-04T18:08:39Z

Goneall: Created page with "August 4, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * William Bartholomew * Steve Winslow * Gary O’Neall * Rose Judge * Peter Shin Topics: * SPDX 3.0 Docume..."

August 4, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* William Bartholomew
* Steve Winslow
* Gary O’Neall
* Rose Judge
* Peter Shin

Topics:
* SPDX 3.0 Document Structure
* GSoC Update
* SPDX Online Tools
* Security related – LF security

==GSoC Update==
* All students passed
* Some issues making good progress on the generating Java code from XSD – more complex than we originally thought
* Some issues with communications
** Rishabh has been keeping a log on Google Docs which is a good practice
** Kate will

==SPDX Online Tools Web Application==
* Funding goal for the SPDX online tools was achieved through community bridge
** Enough funding for 14 months of hosting
* See meta issue for current status and progress https://github.com/spdx/spdx-online-tools/issues/199
* Request to add SPDX document – see issue https://github.com/spdx/spdx-online-tools/issues/209
* Thomas is also looking for funding through ACT for ORT
** Discussed possibility of sharing infrastructure
** Thomas suggested using Lightsail rather than RDS for the PostgreSQL database

==SPDX Document Structure==
* Update to model
** Added name to Artifact
* Document proposal to break down into clauses
** Constrained by ISO to not having sub-sections or clauses
* Structure on subclasses
** Suggested we having a naming standard for the clauses that indicate the subclasses
* Structure
* Moving external document references to the linking profile
** Concern about requiring all the requirements of linking profile
*** Possible 2 profiles, one for document linking and a stronger one for InToto
** Concern about having required information for being able to link to a document
*** General agreement
*** Would like to simplify the approach language
*** Several possible solutions including the PURL
** SPDX Lite – should it be part of licensing or separate profile?
** Suggestion to introduce pre-requisite profiles

==Next Week==
* Continue discussion on container SBOM relationships
* Aug 11 Legal profile

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-07-28

2020-07-28T20:17:34Z

Goneall:

July 28, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* Rose Judge
* Nisha Kumar
* William Bartholomew
* Steve Winslow
* Gary O’Neall
* Jim Hutchison
* Peter Shin

Topics:
SPDX 3.0 Base Profile

==SPDX 3.0 Base Profile==
* Continuing discussion from last week on the model
* relationship Model as it relates to container
** There will be a large number of external references
** Potential issue of sharability across different deployment
** Keep the SBOM with the artifact – so there will be a lot of external document references
* Snippets simplification proposal
** Do we relax the guiding principles for using external definitions (e.g. pointer model)?
*** Proposal to relax guiding principle to review existing standards but only adopt those that do not overly complicate the SPDX standard
* Overview of Template for profiles
** Discussion on how we represent the mandatory/optional requirements
** Only change for an existing field is to make the field mandatory
* Should we allow any arbitrary additional tools?
** Allows for easy extension
** Most tools will ignore what they don’t understand
** Possible issue with allowing proprietary extensions which may not be helpful to the open standard
** Validation may break
** Different design principle from 2.0 where extensions are only in annotations and comments
** Proposal to allow adding new profiles and new fields in point release
*** General agreement
** Appendix should be added to describe how the fields should be added
* Model update – replaced string field of PackageName with “FromFile”
** General agreement the update made sense – but is different from 2.0
** Agreed on a different name – packageFile
** Checksum would be in the file and can be removed from the Package as a property
* Relationship model for containers (continued)
** Do we support the decomposition of SBOM’s as described by Nisha
*** General agreement and support
*** Suggestion to add external reference location information to find the external documents

==Next Week==
* Continue discussion on container SBOM relationships
* Aug 11 Legal profile

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-07-28

2020-07-28T20:17:10Z

Goneall: Created page with "July 28, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * Rose Judge * Nisha Kumar * William Bartholomew * Steve Winslow * Gary O’Neall * Jim Hutchison Topics: S..."

July 28, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* Rose Judge
* Nisha Kumar
* William Bartholomew
* Steve Winslow
* Gary O’Neall
* Jim Hutchison

Topics:
SPDX 3.0 Base Profile

==SPDX 3.0 Base Profile==
* Continuing discussion from last week on the model
* relationship Model as it relates to container
** There will be a large number of external references
** Potential issue of sharability across different deployment
** Keep the SBOM with the artifact – so there will be a lot of external document references
* Snippets simplification proposal
** Do we relax the guiding principles for using external definitions (e.g. pointer model)?
*** Proposal to relax guiding principle to review existing standards but only adopt those that do not overly complicate the SPDX standard
* Overview of Template for profiles
** Discussion on how we represent the mandatory/optional requirements
** Only change for an existing field is to make the field mandatory
* Should we allow any arbitrary additional tools?
** Allows for easy extension
** Most tools will ignore what they don’t understand
** Possible issue with allowing proprietary extensions which may not be helpful to the open standard
** Validation may break
** Different design principle from 2.0 where extensions are only in annotations and comments
** Proposal to allow adding new profiles and new fields in point release
*** General agreement
** Appendix should be added to describe how the fields should be added
* Model update – replaced string field of PackageName with “FromFile”
** General agreement the update made sense – but is different from 2.0
** Agreed on a different name – packageFile
** Checksum would be in the file and can be removed from the Package as a property
* Relationship model for containers (continued)
** Do we support the decomposition of SBOM’s as described by Nisha
*** General agreement and support
*** Suggestion to add external reference location information to find the external documents

==Next Week==
* Continue discussion on container SBOM relationships
* Aug 11 Legal profile

[[Category:Technical|Minutes]]

General Meeting/Minutes/2020-07-02

2020-07-08T01:12:17Z

Goneall: Created page with "* Attendance: 11 * Lead by Gary O'Neall == Presentation - Google Summer of Code Project Concurrent RDF Parser - Rishabh Bhatnagar== * Presentation available at https://docs...."

* Attendance: 11
* Lead by Gary O'Neall

== Presentation - Google Summer of Code Project Concurrent RDF Parser - Rishabh Bhatnagar==

* Presentation available at https://docs.google.com/presentation/d/17LSMZMi6GXwmrCv7qIpQz6pbGdRjjdQQDdOqbVPqpR0/edit#slide=id.g822549bbf3_1_0
* Demo available at https://gordf.herokuapp.com/
* Rishabh-walked through the architecture of the plan for his GSoC project and how its going to work with golang
* Can be used as a general RDF parser as well.

== Tech Team Report - Kate / Gary ==
* Spec update - Kate
** 2.2.1 —> ISO see: https://spdx.github.io/spdx-spec/v2-draft/
*** Any remaining issues please submit by 7/7, frozen after that.
** 3.0 progress moving forward in joint calls.
* Tools - Gary
** 1st phase of coding for GSOC
** Added community bridge program with 2 additional project
*** 2 CB projects started - Python libraries and license matching algorithm in Python

== Legal Team Report - Steve/Paul ==
* Experimenting to use etherpad —> github repo. for the meeting minutes
* Working towards 3.10 next release of License list
* Joint meetings with tech on SPDX 3.0 licensing profile.

== Outreach Team Report – Steve (Jack unable to attend) ==
* Some issues for website has been fixed
* Please log any issues into https://github.com/spdx/spdx-website/issues
* Help is requested for review and any suggested fixes

== Attendees ==

* Gary O’Neall
* Kate Stewart
* Alexios Zavras
* Steve Winslow
* Rishabh Bhatnagar
* Brad Goldring
* Mark Atwood
* Paul Madick
* Rohit Lodha
* Anisha Srivastava
* Mark Baushke

[[Category:General|Minutes]]
[[Category:Minutes]]

Technical Team/Minutes/2020-07-07

2020-07-08T00:59:49Z

Goneall: Created page with "July 7, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * Rex Jaeschke * Rose Judge * Jim Hutchison * David Kemp * Peter Shin * William Bartholomew * Steve Winslow *..."

July 7, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* Rex Jaeschke
* Rose Judge
* Jim Hutchison
* David Kemp
* Peter Shin
* William Bartholomew
* Steve Winslow
* Gary O’Neall

Topics:
GSoC Update
Update on 2.2.1

==GSoC Update==
* All evalutations were turned in on time
* All students passed
* Two community bridge projects has started
* Additional work being done on deployment for the SPDX online tools by students who had applied but not accepted
* Kate mentioned a community bridge volunteer to help with UI related code
** Smith’s project could use some help
** Kate will introduce to Gary who will introduce to Smith

==SPDX 2.2.1==
* Thomas had a couple of issues
* Steve created an issue with a number of cleanup items
** Need to update the RDF OWL document and other ontology documents with the updated texts from 2.2.1
*** Gary will update once everything is complete on the 2.2.1 text
** Details recorded in Issue #424 https://github.com/spdx/spdx-spec/issues/454
** Inconsistency in naming of section definitions
*** Agreed to add “information section” to annotation and relationship sections both titles and definitions
** Update cardinality
** Differences from 2.2 to 2.1 is incorrect – Kate will update
** Are meta tags referenced?
*** Currently in bibliography
* Discussion on Normative references – no change to spec
* Issue with template text being inconsistent with what was used (Alexios submitted an issue)
** Decided not to change it for 2.2.1 – we will address in 3.0

==3.0 Base Update==
* William presented update on Profiles and Linking
* Question on if you can add fields from profiles that are not declared?
** Additional fields would be allowed, but not required for profiles not declared

==Next Week==
* 3.0 Base Profile discussion

Following week – joint legal call
Week following that - Vulnerabilities

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-06-23

2020-06-24T00:04:31Z

Goneall: Created page with "June 23, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * Rex Jaeschke * Takashi Ninjouji * Karsten Klein * Rose Judge * Nisha Kumar * Steve Winslow * Gary O’Neal..."

June 23, 2020
== Attendees ==
* Kate Stewart
* Thomas Steenbergen
* Rex Jaeschke
* Takashi Ninjouji
* Karsten Klein
* Rose Judge
* Nisha Kumar
* Steve Winslow
* Gary O’Neall

Topics:
Update on 2.2.1

==SPDX 2.2.1==
* Spec available at https://spdx.github.io/spdx-spec/v2-draft/
* Nearly complete
* Rex provided an overview of the current state
* Tables are now number
** Need to add to the release checklist to renumber the tables before release
* HTML tables styling was added
** Thomas requested the styling be put in CSS rather than inline
* ISO process may take up to a year
** 3.0 may well be ready to release at the time 2.2.1 is ISO approved
* Reviews for 2.2.1 – comments due by Tuesday 30 June
** Preference to pull requests or add issue
** File issue in the spec tagged with 2.2.1
* SPDX 2.2 ontology diagram need to update to 2.2.1 in section 5.1
* C.1 data model needs to update to 2.2.1
* D.1 grammar needs to go in a code block
* Gary will add a PR for the definitions section 3.x

==SPDX as a Package Manifest==
* Thomas added issue #439
* Minimal version of SPDX that can be included in the root of a directory for code that does not use a standard package manager (e.g. C/C++ projects that use makefiles)
* What do we use for the document namespace?
* What if we want to add a PackageVerificationCode or have FilesAnalyzed=true?
* Could it be applied to Go binaries?
* Can we use SPDX lite?
** Different use cases, are the fields the same?
* This will not be an additional section of the spec, but more guidance to the users of ORT
* Thomas also worked on an example for 3.0
** An issue and PR will be added to the spec

==Next Week==
* No call next week due to Linux conference North America

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-06-16

2020-06-16T20:47:23Z

Goneall: Created page with "June 16, 2020 == Attendees == * Kate Stewart * Jim Hutchison * Thomas Steenbergen * Rose Judge * Nisha Kumar * Peter Shin * Steve Winslow * Gary O’Neall Topics: Update on 2..."

June 16, 2020
== Attendees ==
* Kate Stewart
* Jim Hutchison
* Thomas Steenbergen
* Rose Judge
* Nisha Kumar
* Peter Shin
* Steve Winslow
* Gary O’Neall

Topics:
Update on 2.2.1
GSoC
SPDX Tools

==SPDX 2.2.1==
* Spec available at https://spdx.github.io/spdx-spec/v2-draft/
* Kate gave a quick overview of the changes made so far
* Mostly renumbering, reformatting to ISO specs
* A lot of external references were broken – changed to local references
* All – Please review the 2.2.1 spec and open issues for any problems found
* Overall structure is now in place – we can start basing our 3.0 work on the 2.2.1 work

==GSoC==
* coding continues in Summer of Code.
* Python expertise - active request for reviews. ** more bandwidth needed.
** Kate will provide Daniel Beard intro to Philippe ang Gary to possibly help with the Python libraries
* Rohit, Alexios, Gary - mentors for Community Bridge.

==Serialization Formats==
* non normative changes to sample/examples for bugs in 2.2
* Serialization formats outside of RDF/XML;
* some different assumptions were being made.
* Better to document this in the specification itself.
* Approach and assumptions being made - examples applying.
* Serialization examples and principles.
* Bugs ok in 2.2.1 & enhancements `
* Goal - use native format of JSON & YAML when possible
** same vocabulary across all.
** Exact case and spelling may differ due to different formats.
** Stem of term would be consistent.
** UML object model is abstract and not specific to any format.
** Want JSON to look like “JSON” not something else.
* Nisha: concern over incompatiblity with tool compatibility with different cases.
** JSON allows plural forms on some array terms.
** Singular to plural are not easy to code
** Consistent casing structure.
** Any tools that support more than one serialization format will have to deal with this.
** Nisha: Question on the overall model.
***Using RDF/XML document as source, but Alexios wrote a translator to standard OMG UML.
*** TODO: Annex C needs to be updated from RDF —> UML Object Model; and include the diagram from Alexios.
https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/SPDX-2.2-Simplified.png
* Agreed on the following guiding principles for the different serialization formats
** Consistent vocabulary across format
** Consistent object model across formats (where feasible)
** Serialization formats are optimized to for the formats (e.g. JSON will look natural to someone familiar with JSON)
* We will document the different serialization formats in the spec in 3.0 in a similar fashion to tag/value and RDF/XML
* We will add JSON and YAML examples to 2.2.1 or a 2.2.2 version of the spec depending on timing

==Next Week’s Agenda==
* June 23 - Security - Thomas “unblock thomas"
* June 30 - Cancelled.
* July 7 - BASE 3.0 - William
* July 14 - Licensing Profile - Steve

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-06-09

2020-06-11T21:06:23Z

Goneall: Created page with "June 9, 2020 == Attendees == * Kate Stewart * Jack Manbeck * John Mudge * Rex Jaeschke * 12066042189 * Brad Goldring * Emmanuel * Jilayne Lovejoy * Matija Suklje * Nisha Kumar..."

June 9, 2020
== Attendees ==
* Kate Stewart
* Jack Manbeck
* John Mudge
* Rex Jaeschke
* 12066042189
* Brad Goldring
* Emmanuel
* Jilayne Lovejoy
* Matija Suklje
* Nisha Kumar
* Peter Shin
* Rose Judge
* Santiago Torres
* Vicky Brasseur
* Gary O’Neall
* Mark Atwood

Topics:
Rex/John update on 2.2.1
GSoC
SPDX Tools

==SPDX 2.2.1==
* Update from Rex
** 6 remaining issues
*** Will be covered in a follow-up call with Kate. Any remaining issues will be brought to the group for next week
** Question on formatting for the headings and the links
*** Jack, Kate, Thomas, Rex and John will discuss offline

==GSoC==
* coding has started

==Licensing Profile==
* Meta issue #386 is tracking all the license profile related issues
* Consolidating issues for license profile issue #385
** Collection of fields for license
* Do we need a distributed license?
** Both Jilayne and Steve believe that concluded license can be used
*** This was the original intent of concluded license
** Thomas expressed an interest in clearly declaring a non-disjunctive license at the point of distribution
*** Different distributed licenses may be chosen for different customers
** Documentation currently doesn’t capture the disjunctive choice scenario for concluded license
** Concluded is currently used for both adding a reviewed conclusion on the license data and for the choice of disjunctive licenses
** Brad suggested teasing apart the document creator and the artifact creator when defining distributed license
* General support for moving to 2 fields for every artifact DeclaredLicense and ConcludedLicense
* Use of the DistributedLicense needs more discussion
** Description of use cases for DistributedLicense
** Updated documentation for ConcludedLicense to include disjunctive choice
** Documentation on Artifact

==Next Week’s Agenda==
* 2.2.1 update
* GSoC

[[Category:Technical|Minutes]]

CommunityBridge

2020-06-07T20:27:06Z

Goneall: /* Summer 2020 Process and Selection Criteria */

= Community Bridge =

These pages are dedicated to Community Bridge projects for SPDX.

== Summer 2020 Process and Selection Criteria ==
We now have funding and mentors available for up to 2 students. With over 50 applications, we will need to be very selective.

Below is the process and the criteria we will use for selecting the student for this project:
* Applications are now open for any student with proof of enrollment
* The project is scheduled to start July 1 and run through end of September
** Since the project workload is equivalent to full-time work, applicants should make sure that no other obligations (e.g. to school) would prevent them for dedicating this time to their project
* Applicants should upload a project proposal to community bridge with the following information before June 15:
** A description of the project and how it improves the SPDX online tools and benefits the SPDX community
** A workplan describing the deliverables
** 4 specific milestones at 25% 50%, 75% and 100% of the project timeline – these milestones will be basis for paying the student stipends throughout the project
* Project ideas can be found on the Community Bridge Mentoring Project Ideas Page: https://wiki.spdx.org/view/CommunityBridge/CommunityBridge_ProjectIdeas
** These reflect our current priorities, but are not restricting: we are open to any other project ideas applicants may propose
* Selection will be based on 3 factors:
** The project proposal
** Contributions to any of the SPDX projects (all located under the SPDX GitHub organization): https://github.com/spdx
** Contributions to other publicly available projects which use similar technologies (e.g. Python or Django projects)
* A short list of candidates will be selected on the week of 15-19 June
** Applicants not selected will be notified, so that they are freed to apply to other Community Bridge projects
* The final candidates will be selected on the week of 22-26 June

== SPDX Mentoring Projects ==

The following are mentoring projects available on the Linux Foundation Community Bridge
* [https://funding.communitybridge.org/projects/spdx-online-tools SPDX Online Tools]

Project ideas can be found on the [[/CommunityBridge_ProjectIdeas | Community Bridge project ideas page]]

CommunityBridge

2020-06-05T16:07:54Z

Goneall:

= Community Bridge =

These pages are dedicated to Community Bridge projects for SPDX.

== Summer 2020 Process and Selection Criteria ==
We now have funding and mentors available for up to 2 students. With over 50 applications, we will need to be very selective. Below is the process and the criteria we will use for selecting the student for this project:
* Applications are now open for any student with proof of enrollment
* The project is scheduled to start July 1 and run through end of September
** Since the project workload is equivalent to full-time work, applicants should make sure that no other obligations (e.g. to school) would prevent them for dedicating this time to their project
* Applicants should submit a project proposal with the following information:
** A description of the project and how it improves the SPDX online tools and benefits the SPDX community
** A workplan describing the deliverables
** 4 specific milestones at 25% 50%, 75% and 100% of the project timeline – these milestones will be basis for paying the student stipends throughout the project
* Project ideas can be found on the Community Bridge Mentoring Project Ideas Page: https://wiki.spdx.org/view/CommunityBridge/CommunityBridge_ProjectIdeas
** These reflect our current priorities, but are not restricting: we are open to any other project ideas applicants may propose
* Selection will be based on 3 factors:
** The project proposal
** Contributions to any of the SPDX projects (all located under the SPDX GitHub organization): https://github.com/spdx
** Contributions to other publicly available projects which use similar technologies (e.g. Python or Django projects)
* A short list of candidates will be selected on the week of 15-19 June
** Applicants not selected will be notified, so that they are freed to apply to other Community Bridge projects
* The final candidates will be selected on the week of 22-26 June

== SPDX Mentoring Projects ==

The following are mentoring projects available on the Linux Foundation Community Bridge
* [https://funding.communitybridge.org/projects/spdx-online-tools SPDX Online Tools]

Project ideas can be found on the [[/CommunityBridge_ProjectIdeas | Community Bridge project ideas page]]

CommunityBridge/CommunityBridge ProjectIdeas

2020-06-04T17:55:30Z

Goneall:

'''Welcome to the 2020 SPDX Community Bridge Project Ideas Page'''

Proposals can use the [https://rtgdk.github.io/spdx-gsoc-proposal.html Google Summer of Code proposal template] as a general guide for community bridge projects.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]
* [https://github.com/spdx SPDX Git Repository]

=Proposed 2020 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

==SPDX Workgroup Tooling Projects==

These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

=== Replace Java Functions in the SPDX Online Tools with Python Library Functions ===
Improve the performance and reliability of the SPDX Online Tools by replacing functions implemented in Java with native Python implementations.
====Skills Needed====
* Development skills in the Python
* Based understanding of Java
* Development skills in Django
* Ability to work with the community in integrating results with other projects
====Background Information====
The [https://github.com/spdx/tools-python Python Tools] library can be used but will need to be extended and improved to replace the features. The Java implementations can be found in the [https://github.com/spdx/tools SPDX Java tools implementation]
====Available Mentors====
TBD

=== Improve the Python Libraries ===
The Python Libraries need to be updated to the SPDX 2.2 spec and there are several issues outstanding.
====Skills Needed====
* Development skills in the Python
* Ability to work with the community in integrating results with other projects
====Background Information====
See the [https://github.com/spdx/tools-python/issues SPDX Python Tools Issues List] for more information.
====Available Mentors====
TBD

=== Improve the Deployment Infrastructure for the SPDX Online Tools ===
Improve the reliability, security and deployability of the SPDX online tools including container management, deployment testing and monitoring.
====Skills Needed====
* Development skills in Python and Django
* Experience with containers
* Understanding of software as a service deployment
====Background Information====
The current SPDX online tools is deployed manually on an Amazon AWS EC2 Linux instance. The current process is error prone and labor intensive. We would like to move to a more automated and reliable mechanism. There is a variety of possible deployment architectures including a container based approach using Kubernetes.
====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] TBD

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

CommunityBridge/CommunityBridge ProjectIdeas

2020-06-04T17:06:24Z

Goneall:

'''Welcome to the 2020 SPDX Community Bridge Project Ideas Page'''

Proposals can use the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] as a guide for community bridge projects.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2020 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

==SPDX Workgroup Tooling Projects==

=== Replace Java Functions in the SPDX Online Tools with Python Library Functions ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

=== Improve the Python Libraries ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

=== Improve the Deployment Infrastructure for the SPDX Online Tools ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

CommunityBridge/CommunityBridge ProjectIdeas

2020-06-04T17:05:24Z

Goneall:

'''Welcome to the 2020 SPDX Community Bridge Project Ideas Page'''

Proposals can use the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] as a guide for community bridge projects.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2020 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

==SPDX Workgroup Tooling Projects==

=== Replace Java Functions in the SPDX Online Tools with Python Library Functions ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

=== Improve the Python Libraries ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

=== Improve the Deployment Infrastructure for the SPDX Online Tools ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

CommunityBridge/CommunityBridge ProjectIdeas

2020-06-04T17:04:19Z

Goneall:

'''Welcome to the 2020 SPDX Community Bridge Project Ideas Page'''

Proposals can use the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] as a guide for community bridge projects.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2020 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

==SPDX Workgroup Tooling Projects==

=== Replace Java Functions in the SPDX Online Tools with Python Library Functions ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

=== Improve the Python Libraries ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

=== Improve the Deployment Infrastructure for the SPDX Online Tools ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

CommunityBridge/CommunityBridge ProjectIdeas

2020-06-04T16:58:30Z

Goneall: Created page with " '''Welcome to the 2020 SPDX Google Summer of Code Project Page''' See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposa..."

'''Welcome to the 2020 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2020 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from last year can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Generate Java SPDX Model Classes from XML XSD file ===
In SPDX 3.0, we will be generating an XML XSD schema to define the model. This project idea is to use the XSD schema to generate a set of Java classes which represent the complete SPDX model. The generated classes would be used as part of a re-designed Java tool for SPDX.

====Skills Needed====
* Java programming skills
* XML/XSD skills
* Skills in code generation practices
* Ability to work with the community in integrating results with other projects

====Background Information====
* A proposed XSD for SPDX can be found on [https://github.com/mil-oss/spdx-xsd github]. Note: This is a very early proposal and would likely change significantly.
* Current Java tools can be found on [https://github.com/spdx/tools SPDX Tools github page]
* A rewrite of the Java tools is in progress. The in progress work can be found at the [https://github.com/goneall/Spdx-Java-Library Spdx-Java-Library] github page.

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Validate License Cross-References ===
Enhance the SPDX LicenseListPublisher to validate the cross reference / seeAlso URL's for the license. One check would be to validate the link is still valid. This would need to be done in a way that has reasonably good performance (e.g. a long timeout would not work). Another check would be to identify the license text in the linked URL and compare it to the license text for the license itself to make sure they match. If either of these tests fail, a validity attribute should be added to the license output files (e.g. the license JSON files).

====Skills Needed====
* Java programming skills
* XML/XSD skills
* HTML parsing skills
* Ability to work with the community in integrating results with other projects

====Background Information====
The [https://spdx.org/licenses/ SPDX license list] is generated from a [https://github.com/spdx/license-list-XML git repository of XML files]. One of the fields maintained in the XML is the crossRef which is a URL cross reference for the license which may be valid or it may also be a "dead link". The [https://github.com/spdx/LicenseListPublisher LicenseListPublisher] is the tool that generates the web pages and the output formats. The output formats can be found in the [https://github.com/spdx/license-list-data SPDX license list data] git repository. [https://github.com/spdx/LicenseListPublisher/issues/60#issuecomment-570511697 Issue #60] for the LicenseListPublisher describes a request to include validity attribute.

Over the summer, we may be adding the XML format to the supported output data formats in the license list data repo.

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== Improve SPDX Golang tooling ===
The goal of this GSoC project would be to add support in the [https://github.com/spdx/tools-golang SPDX Golang tools] for SPDX documents in versions of the SPDX spec other than 2.1, including the upcoming 2.2 spec release which will add JSON, YAML and XML to the supported formats. Other work may include improving the validation and data model used by the Golang tools.

====Skills Needed====
* Go programming skills
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
The [https://github.com/spdx/tools-golang SPDX Golang tools] were initially designed to work with SPDX documents in tag-value format, for version 2.1 of [https://spdx.org/specifications the SPDX specification]. Currently it does not support earlier versions of the SPDX specification. Also, [https://github.com/spdx/spdx-spec/milestone/2 the upcoming 2.2 spec release], in addition to new data fields, will also add support for SPDX documents in JSON, YAML and XML formats. The Golang tools should (at a minimum) be updated to enable reading and writing in JSON and YAML.

The SPDX Golang tools currently do some validation when reading and parsing SPDX documents, but they do not currently do much validation of the content itself. For example, license fields are represented as strings, but the tools do not currently check to confirm that e.g. the license identifiers are valid SPDX license expressions. Additional validation support to improve this would be beneficial.

Additionally, the [https://github.com/spdx/tools-golang/tree/master/spdx data model used internally by the SPDX tools] to represent SPDX content is different in some ways from the data model used by other tools (e.g. [https://github.com/spdx/tools/tree/master/src/org/spdx/rdfparser/model Java], [https://github.com/spdx/tools-python/tree/master/spdx Python]). One goal for this project might be to evaluate the choices made by those other tools, and consider whether the Golang tools' data model should change to align with those.

====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]

=== GoLang Parallel RDF Parser ===
Implement a high performance RDF parser for GoLang to support the SPDX RDF/XML format parsing and production.

====Skills Needed====
* GoLang programming skills
* Knowledge of RDF
* Knowledge of parsing algorithms

====Background Information====
As of now, there are very few known libraries in GoLang which support RDF-Parsing and are Licensed to use with an open-source project. One of them is [https://godoc.org/github.com/knakk/rdf](knakk/rdf2go). This library uses the RDF serialization format. All the current projects claiming to parse RDF files have implemented it in a linear fashion(line by line parsing) making it a repetitive and time-consuming process. This project will aim to chunk the RDF files into appropriate blocks and parse them simultaneously to reduce the effective time required to parse the entire document. The parser must conform to the SPDX-2.x version standards and have proper tests for each procedure.

This project could be included as part of a larger project which includes other fixes to the GoLang tools (see the Improve GoLang tooling project idea above).
====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== SPDX Plugins for Package Managers ===
Create a native plug-in or extension to a well-known package manager to generate valid SPDX documents based on the information provided in the build metadata files. Examples of package managers include Node Package Manager (NPM), Gradle, Rust Cargo, Ruby Gems, Python pip, and Cocoa Pods. A plugin for Maven has already been developed and can be used as an example.

The plugin should generate a valid SPDX document with minimal configuration required by the user.
====Skills Needed====
* Programming languages skills will depend on the package manager (e.g. Ruby for Ruby Gems, JavaScript for NPM)
* Knowledge of package managers and build processes
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects
====Background Information====
SPDX produces a standard Bill of Materials for software containing package and license information. Package managers collect and manage much of the data needed to produce an SPDX document. Automatically generating SPDX documents in package managers will greatly increase the efficiency and adoption of SPDX.

The [Maven Plugin]( https://github.com/spdx/spdx-maven-plugin) is a prototype plugin developed for the Maven build system. It can be used as an example for creating plugins for other build environments.
====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:kstewart@linuxfoundation.org Kate Stewart]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

CommunityBridge

2020-06-04T16:57:53Z

Goneall: /* SPDX Mentoring Projects */

= Community Bridge =

These pages are dedicated to Community Bridge projects for SPDX.

== SPDX Mentoring Projects ==

The following are mentoring projects available on the Linux Foundation Community Bridge
* [https://funding.communitybridge.org/projects/spdx-online-tools SPDX Online Tools]

Project ideas can be found on the [[/CommunityBridge_ProjectIdeas | Community Bridge project ideas page]]

CommunityBridge

2020-06-04T16:56:13Z

Goneall: Created page with "= Community Bridge = These pages are dedicated to Community Bridge projects for SPDX. == SPDX Mentoring Projects == The following are mentoring projects available on the Li..."

Technical Team/Minutes/2020-06-02

2020-06-02T18:03:13Z

Goneall: Created page with "June 2, 2020 == Attendees == * Jim Hutchison * Rex Jaeschke * Kate Stewart * William Bartholomew * Gary O’Neall * Nisha Kumar * Steve Winslow * John Mudge * Takashi Ninjouji..."

June 2, 2020
== Attendees ==
* Jim Hutchison
* Rex Jaeschke
* Kate Stewart
* William Bartholomew
* Gary O’Neall
* Nisha Kumar
* Steve Winslow
* John Mudge
* Takashi Ninjouji
* Peter Shin
* Rose Judge
* Thomas Steenbergen

Topics:
Rex/John update on 2.2.1
GSoC
SPDX Tools

==SPDX 2.2.1==
* Update from Rex
** Help wanted on a few issues
** Making progress
** Would like to target next week

==GSoC==
* Met with all the students
* coding has started

==SPDX Tools in the Repo==
* Java Classic
* Java Tools
* Python
** Need an update from Philippe
** Gary offered to help
** Needs be brought up to 2.2
** Tern could use the Python library for as a validator
** Could use the community bridge mentoring program to help – Gary will follow-up on the mentoring call
* GoLang
** Currently 2.1
** Next working on 2.2
** Summer of code project to implement RDF format
* JavaScript
** Summer of Code project but needs some work
** Could potentially use Kotlin as a substitute
* Kotlin
** ORT uses SPDX
** Could separate out a separate library
* License mapping
** Left off on how to map the ID’s to the aliases
** Each language can implement
** Future topic

==SPDX 3.0==
* Steve provided an overview of meta-issues
** Different projects use different terms – agreement to use Meta issue
** Suggestion to use Github template for the meta issues
*** Steve will create a template for META issues
** We could use templates for the different profiles
* Labels
** suggest “profile licensing”
** suggest “profile base”
** suggest “profile security”
** Kate will add some additional profile labels
* No meta issue for security for now – will use labels

==Next Week’s Agenda==
* 2.2.1 update
* GSoC
* License profile – joint call with legal starting at 15 minutes after the hours

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-05-19

2020-05-19T19:38:15Z

Goneall: Created page with "May 19, 2020 == Attendees == * Jim Hutchison * Rex Jaeschke * GogginsS * John Mudge * Nisha Kumar * Steve Winslow * Kate Stewart * William Bartholomew * Gary O’Neall * Rose..."

May 19, 2020
== Attendees ==
* Jim Hutchison
* Rex Jaeschke
* GogginsS
* John Mudge
* Nisha Kumar
* Steve Winslow
* Kate Stewart
* William Bartholomew
* Gary O’Neall
* Rose Judge
* Takashi Ninjouji
* Santiago Torres
* Peter Shin
* Vicky Brasseur
* Thomas Steenbergen
* Rishabh Bhatnagar

==SPDX 2.2==
* Question on how to submit new features beyond 2.2
** Consensus to add issues in Github
* SPDX 2.2 wrap up - status of .pdf generation, next steps
** Kate & Gary - follow up, still some issues outstanding.
==SPDX 2.2.1==
* update from Rex
** A new numbering scheme
** An appendix will be added to translate from the old to new numbering
** John gave an update on new format
* Line breaks discussion
** Thomas recommended line breaks be made post production rather than explicitly
** Agreed to not add explicit line breaks
* Discussion on changing Intent to Description
** Agreed to change to Description
* Possible issue with the word Example
** May have to change to a different word such as sample
** Thomas raised an issue with changing to sample
* Embedded HTML in the examples may cause issues
** Suggest removing the HTML except for anchors
** May also be an issue with 3.0
* Major issues have been resolved
* Expect to have a list of remaining issues by the end of the week

==GSoC==
* Anisha, Rohit & Gary - had call, researching alternatives
* Rishab, Steve & Gary - golang, discussion
* Philip - Kate, Santiago & Philippe - pending
* Tenjong - license cross ref, already engaging.
* reasonable activitity on gitter.
* Bringing back one of student proposals through community bridge, update June 1.

==Automation for the Spec==
* Level of Automation for 3.0
** OWL document —> Schema’s work —> Sample code, etc.
** Two sources of errors: tools doing translations, copy paste error
** Can we look at automating the creation from everything from one source of record.
** Having mark down be the source of record.
* Automation Proposals:
* Pick a source of record, everything else is automated from there.
** Diagram - how can this work with markdown.
** Possibly not include generated artifacts in repo.
** Could be added into a github action to generate diagram. Not store in repo itself, since its generated.
** Everytime PR, get new OWL document
** William’s diagrams are already generated by plugin
** Software generate example files, and then they are included in markdown.
* Concern: How fragile are the tools?
** Gary - will handcode in Java, specific to SPDX. Subsection & schemas. Tool dependency.
** Thomas - Companies do this, but we need to make sure.
* Sections will have to be very much tied to the formatting.
* Breaking formatting may break build. PR requested via breaking build. More of burden for submitters.
* Nisha, Kate, William, are a favor in trying this.
* Gary looking for collaboration on the tools. Nisha & Rose willing to work with Python.
** Gary ok to do it in Python, if Rose able to help out here. Separate Sync up in 2 or 3 weeks.
** William ok mentor. Thomas ok to review.
* Revisit in 3 weeks - status of tooling

==SPDX 3.0==
* How do we submit proposals for 3.0?
** Use Github Issues
** Proposal to add Github labels for the profiles
** Add Tech Team review as a label to schedule a call
* Annotations and/or Relationships have YAML samples for review
** Kate will help with the examples
* Suggest we start a mapping spreadsheet
** Kate will start the sheet
* Wait for 2.2.1 template completion from John
** After template, William will create 3.0
* Need a way to specify which profiles are in effect
** Suggest adding a field to the base
** Base is always listed, additional profiles are also listed
** Defer versioning
* Discussed if you can use fields from other profiles
** OK to re-use fields from other profiles
** Profiles define which fields are mandatory
** To be further discussed

==Next Week’s Agenda==
* Thomas to lead discussion on Security profile

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-05-12

2020-05-12T18:04:03Z

Goneall: Created page with "May 12, 2020 == Attendees == * Alexios Zavras * Nisha Kumar * Steve Winslow * Kate Stewart * William Bartholomew * Gary O’Neall * Rose Judge * Thomas Steenbergen * Takashi..."

May 12, 2020
== Attendees ==
* Alexios Zavras
* Nisha Kumar
* Steve Winslow
* Kate Stewart
* William Bartholomew
* Gary O’Neall
* Rose Judge
* Thomas Steenbergen
* Takashi Ninjouji
* Santiago Torres
* Peter Shin

==2.2 - Publishing Spec==
* Jack provided an update
* Issue with links within the document
** Pandoc is interpreting the links between docs as URL
** It appears that there is an incompatibility between Pandocs and the web page generation
** Thomas knows of a redirect plugin – will attempt to find this to resolve the issue

==SPDX 2.2.1==
* Some issues with cross-references, similar to the 2.2 publishing spec
* Horizontal scrollbars for the XML examples don’t render well in .docx format
** Rex will put in breaks
* Inconsistency in Annex sub-clause numbering
** Rex suggested numbering in a consistent formatting as chapters
** Rex and Kate will follow-up
* Marking annexes as normative or informative (issue 256)
** Steve will take this one
* Need help with Conformance Clause
* Need help with Composition of an SPDX document (issue 330)
** Rose volunteered to take a look
* Overall, good progress on implementation
* Kate has a backlog of PR’s to review and merge

==GSoC==
* Gary welcomed all the students
* Mentors should be reaching out to students and setup meetings

==New Website==
* New URL for the main website spdx.dev
** spdx.org/rdf and spdx.org/licenses will remain the same
* 1 to 2 weeks we should be “throwing the switch”
* Content for the website should be updated
* Moving the SPDX wiki over to github
** Proposal to create a new Github wiki “Governance”
** One repo for all SPDX with folders for each team
** Attempt to copy all Wiki content over
** Thomas suggested automating the conversion
** No one objected to move over

==SPDX 3.0==
* Merging changes from 2.2 and 2.2.1 into 3.0
** Proposal to reset the 3.0 branch
** Take a snapshot of the current 3.0
** Re-branch from 2.2 into 3.0 and re-update
* Over the next week, update the YAML and JSON examples into 2.X
* 2.2.1 to become more stable
* Then reset the branch
* Discussion on automating creating of markdown or OWL schema
** Will discuss in more detail on next week’s call
** General consensus to have the markdown as the source since it is easier to edit
* Santiago will share a doc with the linkage profile ideas
* Should we have a separate mailing list?
** Security may not want to be on the same general mailing list
** If any of the profile leads would like to have a separate mail list, contact Kate
* Peter is pulling together a use case document for 3.0
** Currently includes Nisha’s use cases
** Will be a Google Doc for now

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-05-05

2020-05-06T04:31:00Z

Goneall: Created page with "May 5, 2020 == Attendees == * Alexios Zavras * Nisha Kumar * Steve Winslow * Kate Stewart * William Bartholomew * Gary O’Neall * Sean Goggins * Jim Hutchison * Karsten Klei..."

May 5, 2020
== Attendees ==
* Alexios Zavras
* Nisha Kumar
* Steve Winslow
* Kate Stewart
* William Bartholomew
* Gary O’Neall
* Sean Goggins
* Jim Hutchison
* Karsten Klein
* Vicky Brasseur
* Rose Judge
* Thomas Steenbergen
* Takashi Ninjouji
* Santiago Torres

==GSoC==
* 4 projects selected
* Looking for mentoring possibility for one of the students who should have been selected but wasn’t
* Currently in community bonding
* Active coding about a month away, will start having the students join the call at that time
* Discussion on the approach for repos:
** Up to student and mentor – Gary can create a repo in SPDX, can use a branch in an existing SPDX repo, or can use the student’s repo and transfer to SPDX at the end of the project
* Question on Gitter
** We’ll use the public SPDX channel for most communications

==SPDX 2.2==
* Release done over the weekend
* development/v2.2.1 branch created and made the default branch
* Thanks to the many contributors and reviewers – especially Alexios, Steve, Thomas, William, Kate and Gary
* Rendering for the v2 draft has some problems – William is looking into

==SPDX 2.2.1==
* Focused on the ISO standard
* Conversion to the standard as first phase and move to word for submission as a second phase

==Containers==
* See slides for the overview presented by Nisha
* Issue with download URL not being a URL
* Issue with the size – 7MB for the example shown
* Issue with difference in representation in the layer descriptions and in the flattened image
** Name are based on the SHA checksum, not a natural filename
* Is it possible to define an SPDX document for each layer
** Yes – external document refs can be used
** Discussion on tooling support
* Discussion on different relationship types for the manifest.json and config.json
* How do we account for content addressable “Packages”?
* What does an external reference look like for deployments?
* Can we compose/decompose SPDX documents?
* Can we provide pipeline context?
* General agreement that the relationships between docs and pipeline is related to the linking proposal Santiago is working on

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-04-28

2020-04-29T02:20:01Z

Goneall: Created page with "April 28, 2020 == Attendees == * Alexios Zavras * Nisha Kumar * Steve Winslow * Kate Stewart * William Bartholomew * Gary O’Neall * Rose Judge * Thomas Steenbergen * Takash..."

April 28, 2020
== Attendees ==
* Alexios Zavras
* Nisha Kumar
* Steve Winslow
* Kate Stewart
* William Bartholomew
* Gary O’Neall
* Rose Judge
* Thomas Steenbergen
* Takashi Ninjouji
* Santiago Torres
* Matt Germonprez
* Rohit Lodha
* Sean Goggins

==SPDX 2.2==
* Review of pull requests
* Reviewed issues
* Went through checklist
** Kate will work on a blog post
** Meeting this Friday to review final checklist – Kate is organizing. William, Thomas, Gary, and

==3.0 Attesting==
* Issue on over-using relationships
** For a reader of a document, important information is not present since it is referred to in a relationship
** Potential issue of cycles in the graph
** Suggestion that tooling can flatten out and verify the graph into something readable and/or greppable
* Should we have separate relationship types – each with their own relationship types
** Between artifacts
** Between artifacts and identities
** Between identities
* Should it be part of the base profiles?
** William proposed it would be and no one disagreed
* Discussion on “integration use cases”
* Question on relationship between links and relationship
** Many to many? 1:1? 1:*, *:1?
* Santiago will progress the discussion forward and propose some naming alternatives to “linking”

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-04-21

2020-04-21T21:51:27Z

Goneall: Created page with "April 21, 2020 == Attendees == * David Kemp * Alexios Zavras * Nisha Kumar * Steve Winslow * Kate Stewart * Rex Jaeschke * Jack Manbeck * William Bartholomew * Gary O’Neall..."

April 21, 2020
== Attendees ==
* David Kemp
* Alexios Zavras
* Nisha Kumar
* Steve Winslow
* Kate Stewart
* Rex Jaeschke
* Jack Manbeck
* William Bartholomew
* Gary O’Neall
* Rose Judge
* Thomas Steenbergen
* Takashi Ninjouji

==Container SPDX==
* Nisha requested a discussion on some of the issues when generating SPDX documents for containers
* Discussion schedule for the 6 May tech call

==SPDX 2.2==
* Issues reviewed and updated

==SPDX 2.2.1==
* Rex discussed restructuring the document for ISO conformance
* Issue with numbering – will need to be renumbered to conform to ISO Standards
** Converting to word would automatically renumber
** Proposal to keep a permanent number in parallel with the section numbers
** Non-English documentation refers to numbers
** Other documentation refers to number (including code comments)
** Can create an informative annex mapping old section numbers to the new
* Issue with hanging paragraphs at the beginning of the sections – not allowed, will need to move to one of
** Conformance section – things such as cardinality
** Introductory section at the beginning of the document
** General or introductory subsection

==3.0 Security Section==
* Thomas provided an overview presentation at https://docs.google.com/document/d/1GyUMEcv4G8ZUGbXB8T_-pkDFxYUAbP0W0Tuts2cpZiw/edit?ts=5e9de64a
* Combination of several standards including CycloneDX, IonChannel, NVD, CVE, etc.
* Nisha will ask for a review from some of the security specialists she works with
* Future, we’ll bring in others for review – Thomas will guide the timing as the document matures
* Moving the document from Google Docs to MD

[[Category:Technical|Minutes]]

Technical Team/Minutes/2020-03-31

2020-04-20T18:34:31Z

Goneall: Created page with "March 31, 2020 == Attendees == * Santiago Torres Arias * Gary O’Neall * Jack Manbeck * Jim Hutchinson * Peter Shin * Alexios Zavras * Andrea Denisse Gomez (new) * Nisha Kuma..."

March 31, 2020
== Attendees ==
* Santiago Torres Arias
* Gary O’Neall
* Jack Manbeck
* Jim Hutchinson
* Peter Shin
* Alexios Zavras
* Andrea Denisse Gomez (new)
* Nisha Kumar
* Steve Winsolw
* William Bartholmew
* Kate Stewart
* Vicfred Petrelli
* Jiyun Kang

==3.0==
* Santiago provide overview of linking profile being proposed for 3.0
Recording of the presentation can be found at https://zoom.us/rec/share/-90lL_Lo03hOfLPv2QbZAa8kH5j4X6a8hihKqaBczEpJTJHaMzbGpfUcPBpgfz7y
* 8 locations in abstract supply chain can be compromised
* Looking for people to participate in work group on this.
* Nisha: what's the difference between relationships vs. links?
** Looking for these artifacts come from build stage.
* Alexios: Multiple inputs/outputs - love this idea of documenting what is happening, very much in favor of having this information. Only objection with name "linking profile" - points to something else.
** Santiago receptive for changing the name if we can find a better idea.
* Gary: The way I'm thinking about it is relationships are static - the state how the artifacts are related at the time the SPDX document is created. Links are more dynamic, they describe an action taken which probably creates a relationship - including the who and how in addition to the "what" of the relationship.
* Nisha Kumar: Post build state vs build time state?
* Steve Winslow:
* I think that's right, Gary. A relationship just describes "this thing is this way", e.g. "Package A depends on Package B". A Link goes further to assert who does what, e.g. "I added Package B as a dependency for Package A, I got B's source code and built it"
* Peter Shin: Which words do you use to describe "link" in the in-toto process? Do you use the word, "link" or multiple words?
* Gary - very interested in participating in these discussions, and interested to do some object modeling here. Linking relating to relationships.
* - Santiago interested in making this an SPDX native concept. Possibly extend relationships.
* Explicit Interest in making this a focus of 3.0 from: Santiago, WIlliam, Gary, Rose, Nitsha, Alexios, Kate, Steve
** Decision to work on spdx-tech mail list. Then possibly dedicate some weekly call.

==2.2 issues==
* https://github.com/spdx/spdx-spec/issues/97
* Other issues recorded in Github

[[Category:Technical|Minutes]]
[[Category:Minutes]]

Technical Team/Minutes/2020-04-14

2020-04-14T18:07:04Z

Goneall: Created page with "April 14, 2020 == Attendees == * Alexios Zavras * Nisha Kumar * Steve Winslow * Kate Stewart * Santiago * William Bartholomew * Gary O’Neall * Peter Shin * Thomas Steenberg..."

April 14, 2020
== Attendees ==
* Alexios Zavras
* Nisha Kumar
* Steve Winslow
* Kate Stewart
* Santiago
* William Bartholomew
* Gary O’Neall
* Peter Shin
* Thomas Steenbergen

==SPDX 2.2==
* Broken diagrams
** Kate is fixing the first the first one
** Gary will update the model next week, we can go ahead and send out before the update if needed
* ISO write onboard
** Will do formatting
** Need to add examples
** Will invite the text writer into next call

==Profiles==
* Add an array at the document level with profiles; don’t need base since it is implied
* Enum would require update spec, having a String would be more flexible
* Another possibility is to assume a profile based on the “namespace” or what items
* Consensus Profiles “set” with enumeration
* Versioning of profiles
** Should each profile have a version – similar to the license list?
** Would we release different profiles at different times?
** Thomas expressed interest in keeping it simple, only use SPDX versions – keep profile versions synchronized with SPDX version
** Nisha raised the possibility of keeping a document manifest
** We could support manifests using external document references
* Discussion on simplicity
** All agree this should be a guiding principle – we would want 3.0 to be less complex than 2.2
** Discussion on how important human writable/readable
** Are there requirements to make sure we don’t make it “too simple”?
*** We can use the use cases to confirm?
*** Peter will create a document

==Linking and relationships==
* Links will be part of the base profile
* Provenance elements part of the relationship
* Consider having provenance information as properties of the relationships
* Profiles could still describe the relationship required properties
* Concept of strong and weak relationships
** Strong relationship would include the provenance information
* Inheritance vs containing
** Inheritance would be less disruptive
** Signing could be impacted
** Should we pull in Grafeas to verify use cases and deployability
** Schedule 2 Tuesday’s from now

==Software lifecycle proposal==
* Proposal for a format for SCM proposal
* Similar to software product lifecycle
* Very similar to work being done by Santiago
* Scope is not just license compatibility, but also contractual compatibility
* Would be a profile
* Design principle – prefer SPDX stick to facts

[[Category:Technical|Minutes]]
[[Category:Minutes]]

Technical Team/Minutes/2020-04-07

2020-04-07T19:43:28Z

Goneall: Created page with "April 7, 2020 == Attendees == * William Bartholomew * Kate Stewart * Steve Winslow * Alexios Zavras * Gary O’Neall * Peter Shin * Rose Judge * Santiago * Thomas Steenbergen..."

April 7, 2020
== Attendees ==
* William Bartholomew
* Kate Stewart
* Steve Winslow
* Alexios Zavras
* Gary O’Neall
* Peter Shin
* Rose Judge
* Santiago
* Thomas Steenbergen

==GSoC==
* Santiago interested
* Alexios interested in the Python
* 8 total mentors – we can probably do 5 projects
* Gary to schedule a meeting before the 21st to choose the number of slots

==2.2 issues==
* Resolved all open issues and pull requests

[[Category:Technical|Minutes]]
[[Category:Minutes]]

GSOC/GSOC ProjectIdeas

2020-03-24T23:08:17Z

Goneall: /* Available Mentors */

'''Welcome to the 2020 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2020 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from last year can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Generate Java SPDX Model Classes from XML XSD file ===
In SPDX 3.0, we will be generating an XML XSD schema to define the model. This project idea is to use the XSD schema to generate a set of Java classes which represent the complete SPDX model. The generated classes would be used as part of a re-designed Java tool for SPDX.

====Skills Needed====
* Java programming skills
* XML/XSD skills
* Skills in code generation practices
* Ability to work with the community in integrating results with other projects

====Background Information====
* A proposed XSD for SPDX can be found on [https://github.com/mil-oss/spdx-xsd github]. Note: This is a very early proposal and would likely change significantly.
* Current Java tools can be found on [https://github.com/spdx/tools SPDX Tools github page]
* A rewrite of the Java tools is in progress. The in progress work can be found at the [https://github.com/goneall/Spdx-Java-Library Spdx-Java-Library] github page.

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Validate License Cross-References ===
Enhance the SPDX LicenseListPublisher to validate the cross reference / seeAlso URL's for the license. One check would be to validate the link is still valid. This would need to be done in a way that has reasonably good performance (e.g. a long timeout would not work). Another check would be to identify the license text in the linked URL and compare it to the license text for the license itself to make sure they match. If either of these tests fail, a validity attribute should be added to the license output files (e.g. the license JSON files).

====Skills Needed====
* Java programming skills
* XML/XSD skills
* HTML parsing skills
* Ability to work with the community in integrating results with other projects

====Background Information====
The [https://spdx.org/licenses/ SPDX license list] is generated from a [https://github.com/spdx/license-list-XML git repository of XML files]. One of the fields maintained in the XML is the crossRef which is a URL cross reference for the license which may be valid or it may also be a "dead link". The [https://github.com/spdx/LicenseListPublisher LicenseListPublisher] is the tool that generates the web pages and the output formats. The output formats can be found in the [https://github.com/spdx/license-list-data SPDX license list data] git repository. [https://github.com/spdx/LicenseListPublisher/issues/60#issuecomment-570511697 Issue #60] for the LicenseListPublisher describes a request to include validity attribute.

Over the summer, we may be adding the XML format to the supported output data formats in the license list data repo.

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:swinslow@linuxfoundation.org Steve Winslow]

=== Improve SPDX Golang tooling ===
The goal of this GSoC project would be to add support in the [https://github.com/spdx/tools-golang SPDX Golang tools] for SPDX documents in versions of the SPDX spec other than 2.1, including the upcoming 2.2 spec release which will add JSON, YAML and XML to the supported formats. Other work may include improving the validation and data model used by the Golang tools.

====Skills Needed====
* Go programming skills
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
The [https://github.com/spdx/tools-golang SPDX Golang tools] were initially designed to work with SPDX documents in tag-value format, for version 2.1 of [https://spdx.org/specifications the SPDX specification]. Currently it does not support earlier versions of the SPDX specification. Also, [https://github.com/spdx/spdx-spec/milestone/2 the upcoming 2.2 spec release], in addition to new data fields, will also add support for SPDX documents in JSON, YAML and XML formats. The Golang tools should (at a minimum) be updated to enable reading and writing in JSON and YAML.

The SPDX Golang tools currently do some validation when reading and parsing SPDX documents, but they do not currently do much validation of the content itself. For example, license fields are represented as strings, but the tools do not currently check to confirm that e.g. the license identifiers are valid SPDX license expressions. Additional validation support to improve this would be beneficial.

Additionally, the [https://github.com/spdx/tools-golang/tree/master/spdx data model used internally by the SPDX tools] to represent SPDX content is different in some ways from the data model used by other tools (e.g. [https://github.com/spdx/tools/tree/master/src/org/spdx/rdfparser/model Java], [https://github.com/spdx/tools-python/tree/master/spdx Python]). One goal for this project might be to evaluate the choices made by those other tools, and consider whether the Golang tools' data model should change to align with those.

====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]

=== GoLang Parallel RDF Parser ===
Implement a high performance RDF parser for GoLang to support the SPDX RDF/XML format parsing and production.

====Skills Needed====
* GoLang programming skills
* Knowledge of RDF
* Knowledge of parsing algorithms

====Background Information====
As of now, there are very few known libraries in GoLang which support RDF-Parsing and are Licensed to use with an open-source project. One of them is [https://godoc.org/github.com/knakk/rdf](knakk/rdf2go). This library uses the RDF serialization format. All the current projects claiming to parse RDF files have implemented it in a linear fashion(line by line parsing) making it a repetitive and time-consuming process. This project will aim to chunk the RDF files into appropriate blocks and parse them simultaneously to reduce the effective time required to parse the entire document. The parser must conform to the SPDX-2.x version standards and have proper tests for each procedure.

This project could be included as part of a larger project which includes other fixes to the GoLang tools (see the Improve GoLang tooling project idea above).
====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== SPDX Plugins for Package Managers ===
Create a native plug-in or extension to a well-known package manager to generate valid SPDX documents based on the information provided in the build metadata files. Examples of package managers include Node Package Manager (NPM), Gradle, Rust Cargo, Ruby Gems, Python pip, and Cocoa Pods. A plugin for Maven has already been developed and can be used as an example.

The plugin should generate a valid SPDX document with minimal configuration required by the user.
====Skills Needed====
* Programming languages skills will depend on the package manager (e.g. Ruby for Ruby Gems, JavaScript for NPM)
* Knowledge of package managers and build processes
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects
====Background Information====
SPDX produces a standard Bill of Materials for software containing package and license information. Package managers collect and manage much of the data needed to produce an SPDX document. Automatically generating SPDX documents in package managers will greatly increase the efficiency and adoption of SPDX.

The [Maven Plugin]( https://github.com/spdx/spdx-maven-plugin) is a prototype plugin developed for the Maven build system. It can be used as an example for creating plugins for other build environments.
====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:kstewart@linuxfoundation.org Kate Stewart]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

=== ClearlyDefined exporting and importing SPDX documents ===
The goal of this GSoC project would be to add support in the [https://https://github.com/clearlydefined ClearlyDefined project] to export curated data into SPDX 2.2 documents. Once that is accomplished, being able to import SPDX documents into the curated database would be the next step.

====Skills Needed====
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
Export a ClearlyDefined workspace as a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* Add one or more components to the workspace through any of the existing means,
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).
which would result in an SPDX document is exported containing all of the components that were in the workspace.
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.

To populate a workspace from a SPDX document:
* user to navigate to https://clearlydefined.io/workspace
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.

There are some discrepancies between the content in ClearlyDefined and that SPDX documents, so work would be needed with both communities to figure out: what to do if license information in the SPDX disagrees with what ClearlyDefined has and how to handle pending curations?

====Available Mentors====
[mailto:kstewart@linuxfoundation.org Kate Stewart]
[mailto:IAMWILLBAR@github.com William Bartholomew]

GSOC/GSOC ProjectIdeas

2020-03-04T17:26:42Z

Goneall:

'''Welcome to the 2020 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2020 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from last year can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Generate Java SPDX Model Classes from XML XSD file ===
In SPDX 3.0, we will be generating an XML XSD schema to define the model. This project idea is to use the XSD schema to generate a set of Java classes which represent the complete SPDX model. The generated classes would be used as part of a re-designed Java tool for SPDX.

====Skills Needed====
* Java programming skills
* XML/XSD skills
* Skills in code generation practices
* Ability to work with the community in integrating results with other projects

====Background Information====
* A proposed XSD for SPDX can be found on [https://github.com/mil-oss/spdx-xsd github]. Note: This is a very early proposal and would likely change significantly.
* Current Java tools can be found on [https://github.com/spdx/tools SPDX Tools github page]
* A rewrite of the Java tools is in progress. The in progress work can be found at the [https://github.com/goneall/Spdx-Java-Library Spdx-Java-Library] github page.

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Validate License Cross-References ===
Enhance the SPDX LicenseListPublisher to validate the cross reference / seeAlso URL's for the license. One check would be to validate the link is still valid. This would need to be done in a way that has reasonably good performance (e.g. a long timeout would not work). Another check would be to identify the license text in the linked URL and compare it to the license text for the license itself to make sure they match. If either of these tests fail, a validity attribute should be added to the license output files (e.g. the license JSON files).

====Skills Needed====
* Java programming skills
* XML/XSD skills
* HTML parsing skills
* Ability to work with the community in integrating results with other projects

====Background Information====
The [https://spdx.org/licenses/ SPDX license list] is generated from a [https://github.com/spdx/license-list-XML git repository of XML files]. One of the fields maintained in the XML is the crossRef which is a URL cross reference for the license which may be valid or it may also be a "dead link". The [https://github.com/spdx/LicenseListPublisher LicenseListPublisher] is the tool that generates the web pages and the output formats. The output formats can be found in the [https://github.com/spdx/license-list-data SPDX license list data] git repository. [https://github.com/spdx/LicenseListPublisher/issues/60#issuecomment-570511697 Issue #60] for the LicenseListPublisher describes a request to include validity attribute.

Over the summer, we may be adding the XML format to the supported output data formats in the license list data repo.

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall]

=== Improve SPDX Golang tooling ===
The goal of this GSoC project would be to add support in the [https://github.com/spdx/tools-golang SPDX Golang tools] for SPDX documents in versions of the SPDX spec other than 2.1, including the upcoming 2.2 spec release which will add JSON, YAML and XML to the supported formats. Other work may include improving the validation and data model used by the Golang tools.

====Skills Needed====
* Go programming skills
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
The [https://github.com/spdx/tools-golang SPDX Golang tools] were initially designed to work with SPDX documents in tag-value format, for version 2.1 of [https://spdx.org/specifications the SPDX specification]. Currently it does not support earlier versions of the SPDX specification. Also, [https://github.com/spdx/spdx-spec/milestone/2 the upcoming 2.2 spec release], in addition to new data fields, will also add support for SPDX documents in JSON, YAML and XML formats. The Golang tools should (at a minimum) be updated to enable reading and writing in JSON and YAML.

The SPDX Golang tools currently do some validation when reading and parsing SPDX documents, but they do not currently do much validation of the content itself. For example, license fields are represented as strings, but the tools do not currently check to confirm that e.g. the license identifiers are valid SPDX license expressions. Additional validation support to improve this would be beneficial.

Additionally, the [https://github.com/spdx/tools-golang/tree/master/spdx data model used internally by the SPDX tools] to represent SPDX content is different in some ways from the data model used by other tools (e.g. [https://github.com/spdx/tools/tree/master/src/org/spdx/rdfparser/model Java], [https://github.com/spdx/tools-python/tree/master/spdx Python]). One goal for this project might be to evaluate the choices made by those other tools, and consider whether the Golang tools' data model should change to align with those.

====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]

=== GoLang Parallel RDF Parser ===
Implement a high performance RDF parser for GoLang to support the SPDX RDF/XML format parsing and production.

====Skills Needed====
* GoLang programming skills
* Knowledge of RDF
* Knowledge of parsing algorithms

====Background Information====
As of now, there are very few known libraries in GoLang which support RDF-Parsing and are Licensed to use with an open-source project. One of them is [https://godoc.org/github.com/knakk/rdf](knakk/rdf2go). This library uses the RDF serialization format. All the current projects claiming to parse RDF files have implemented it in a linear fashion(line by line parsing) making it a repetitive and time-consuming process. This project will aim to chunk the RDF files into appropriate blocks and parse them simultaneously to reduce the effective time required to parse the entire document. The parser must conform to the SPDX-2.x version standards and have proper tests for each procedure.

This project could be included as part of a larger project which includes other fixes to the GoLang tools (see the Improve GoLang tooling project idea above).
====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== SPDX Plugins for Package Managers ===
Create a native plug-in or extension to a well-known package manager to generate valid SPDX documents based on the information provided in the build metadata files. Examples of package managers include Node Package Manager (NPM), Gradle, Rust Cargo, Ruby Gems, Python pip, and Cocoa Pods. A plugin for Maven has already been developed and can be used as an example.

The plugin should generate a valid SPDX document with minimal configuration required by the user.
====Skills Needed====
* Programming languages skills will depend on the package manager (e.g. Ruby for Ruby Gems, JavaScript for NPM)
* Knowledge of package managers and build processes
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects
====Background Information====
SPDX produces a standard Bill of Materials for software containing package and license information. Package managers collect and manage much of the data needed to produce an SPDX document. Automatically generating SPDX documents in package managers will greatly increase the efficiency and adoption of SPDX.

The [Maven Plugin]( https://github.com/spdx/spdx-maven-plugin) is a prototype plugin developed for the Maven build system. It can be used as an example for creating plugins for other build environments.
====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:kstewart@linuxfoundation.org Kate Stewart]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]

GSOC/GSOC ProjectIdeas

2020-03-04T17:24:37Z

Goneall:

'''Welcome to the 2020 SPDX Google Summer of Code Project Page'''

See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.

Should you have questions please do not hesitate to contact one of the mentors directly.

 

__TOC__

 

== What is SPDX ? ==

First and foremost we are a community dedicated to solving the issues and problems around Open Source licensing and compliance. The SPDX work group (part of the Linux Foundation) consists of individuals, community members, and representatives from companies, foundations and organizations who use or are considering using the SPDX standard. The work group operates much like a meritocratic, consensus-based community project; that is, anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision-making process. We come from many different backgrounds including open source developers, lawyers, consultants and business professionals, many of who have been involved with license compliance and identification for years.

As part of this effort we have developed a set of collateral that can be used:

* [https://spdx.org/using-spdx License List and Short Identifiers]
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]
* [https://spdx.org/using-spdx License Identifiers in source]

== Why choose an SPDX Project? ==

Contributing to one of the SPDX projects below will provide a valuable contribution to developers and/or users of open source software. We believe you will find the projects both technically challenging and rewarding. In essence we believe you will be able to look back one day and I say I was part of that effort.

 

= Getting Involved =

Beyond working with your mentor(s) we highly encourage students who select one of these projects to get involved with the SPDX community via our technical working group. Interaction with the technical team is primarily done via its mailing list and on gitter (see resources). There is however a weekly call you could join as well. .

== Resources ==

* [http://spdx.org SPDX website]
* [https://spdx.org/specifications SPDX Specification]
* [https://spdx.org/tools SPDX Workgroup Tools webpage]
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]

=Proposed 2020 Projects=

Mentors: please fill out the following template for any projects you wish to propose.

=== Project Name ===
add overview of project here
====Skills Needed====
what skills should the student have to do the coding exercises
====Background Information====
context for the project and references to be studied
====Available Mentors====
list individuals who are willing to mentor and provide information about the project proposal.

(The projects from last year can be found on the [https://summerofcode.withgoogle.com/organizations/4532099550281728/#5727887162867712 2019 Google Summer of Code projects page for SPDX] ).

==SPDX Workgroup Tooling Projects==
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX documents and increase the accuracy of them.

===Implement SPDX License Matching in Python===
Implement as much of the SPDX License Matching Guidelines as practical in Python. This could replace the current Java implementation for the [http://13.57.134.254/app/check_license/ Check License] SPDX Online license checking tool.

Following is a list of suggested features:
* Provide an interface which will check text against a license template using the license matching guidelines
* Provide an interface which will check text and return all matching SPDX listed license ID's
* Provide an interface which takes 2 license texts as input and returns a boolean indicating if the 2 licenses match per the license matching guidelines
* When there is not a match, provide a return value making it possible to describe where and why the license does not match

====Background Information====
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines
* A technical description of the templates and license matching can be found in [https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe Appendix II] of the SPDX specification
* A Java implementation can be found in Github [https://github.com/spdx/tools/blob/master/src/org/spdx/compare/LicenseCompareHelper.java SPDX Tools LicenseCompareHelper.java]
* It's harder than you may think - the template language is a challenge to implement. Performance can be a challenge when matching a single text against hundreds of potential licenses. Reporting back where the missmatch occurs can also be a challenge.

====Skills Needed====
* Development skills in the Python
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Generate Java SPDX Model Classes from XML XSD file ===
In SPDX 3.0, we will be generating an XML XSD schema to define the model. This project idea is to use the XSD schema to generate a set of Java classes which represent the complete SPDX model. The generated classes would be used as part of a re-designed Java tool for SPDX.

====Skills Needed====
* Java programming skills
* XML/XSD skills
* Skills in code generation practices
* Ability to work with the community in integrating results with other projects

====Background Information====
* A proposed XSD for SPDX can be found on [https://github.com/mil-oss/spdx-xsd github]. Note: This is a very early proposal and would likely change significantly.
* Current Java tools can be found on [https://github.com/spdx/tools SPDX Tools github page]
* A rewrite of the Java tools is in progress. The in progress work can be found at the [https://github.com/goneall/Spdx-Java-Library Spdx-Java-Library] github page.

====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== Validate License Cross-References ===
Enhance the SPDX LicenseListPublisher to validate the cross reference / seeAlso URL's for the license. One check would be to validate the link is still valid. This would need to be done in a way that has reasonably good performance (e.g. a long timeout would not work). Another check would be to identify the license text in the linked URL and compare it to the license text for the license itself to make sure they match. If either of these tests fail, a validity attribute should be added to the license output files (e.g. the license JSON files).

====Skills Needed====
* Java programming skills
* XML/XSD skills
* HTML parsing skills
* Ability to work with the community in integrating results with other projects

====Background Information====
The [https://spdx.org/licenses/ SPDX license list] is generated from a [https://github.com/spdx/license-list-XML git repository of XML files]. One of the fields maintained in the XML is the crossRef which is a URL cross reference for the license which may be valid or it may also be a "dead link". The [https://github.com/spdx/LicenseListPublisher LicenseListPublisher] is the tool that generates the web pages and the output formats. The output formats can be found in the [https://github.com/spdx/license-list-data SPDX license list data] git repository. [https://github.com/spdx/LicenseListPublisher/issues/60#issuecomment-570511697 Issue #60] for the LicenseListPublisher describes a request to include validity attribute.

Over the summer, we may be adding the XML format to the supported output data formats in the license list data repo.

====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall]

=== Improve SPDX Golang tooling ===
The goal of this GSoC project would be to add support in the [https://github.com/spdx/tools-golang SPDX Golang tools] for SPDX documents in versions of the SPDX spec other than 2.1, including the upcoming 2.2 spec release which will add JSON, YAML and XML to the supported formats. Other work may include improving the validation and data model used by the Golang tools.

====Skills Needed====
* Go programming skills
* Experience with JSON and YAML (XML a plus)
* Ability to interpret and implement the SPDX specification and related community documentation
* Ability to work with the community in integrating results with other projects
* Willingness to learn about open source licensing and related technical matters

====Background Information====
The [https://github.com/spdx/tools-golang SPDX Golang tools] were initially designed to work with SPDX documents in tag-value format, for version 2.1 of [https://spdx.org/specifications the SPDX specification]. Currently it does not support earlier versions of the SPDX specification. Also, [https://github.com/spdx/spdx-spec/milestone/2 the upcoming 2.2 spec release], in addition to new data fields, will also add support for SPDX documents in JSON, YAML and XML formats. The Golang tools should (at a minimum) be updated to enable reading and writing in JSON and YAML.

The SPDX Golang tools currently do some validation when reading and parsing SPDX documents, but they do not currently do much validation of the content itself. For example, license fields are represented as strings, but the tools do not currently check to confirm that e.g. the license identifiers are valid SPDX license expressions. Additional validation support to improve this would be beneficial.

Additionally, the [https://github.com/spdx/tools-golang/tree/master/spdx data model used internally by the SPDX tools] to represent SPDX content is different in some ways from the data model used by other tools (e.g. [https://github.com/spdx/tools/tree/master/src/org/spdx/rdfparser/model Java], [https://github.com/spdx/tools-python/tree/master/spdx Python]). One goal for this project might be to evaluate the choices made by those other tools, and consider whether the Golang tools' data model should change to align with those.

====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]

=== GoLang Parallel RDF Parser ===
Implement a high performance RDF parser for GoLang to support the SPDX RDF/XML format parsing and production.

====Skills Needed====
* GoLang programming skills
* Knowledge of RDF
* Knowledge of parsing algorithms

====Background Information====
As of now, there are very few known libraries in GoLang which support RDF-Parsing and are Licensed to use with an open-source project. One of them is [https://godoc.org/github.com/knakk/rdf](knakk/rdf2go). This library uses the RDF serialization format. All the current projects claiming to parse RDF files have implemented it in a linear fashion(line by line parsing) making it a repetitive and time-consuming process. This project will aim to chunk the RDF files into appropriate blocks and parse them simultaneously to reduce the effective time required to parse the entire document. The parser must conform to the SPDX-2.x version standards and have proper tests for each procedure.

This project could be included as part of a larger project which includes other fixes to the GoLang tools (see the Improve GoLang tooling project idea above).
====Available Mentors====
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]

=== SPDX Plugins for Package Managers ===
Create a native plug-in or extension to a well-known package manager to generate valid SPDX documents based on the information provided in the build metadata files. Examples of package managers include Node Package Manager (NPM), Gradle, Rust Cargo, Ruby Gems, Python pip, and Cocoa Pods. A plugin for Maven has already been developed and can be used as an example.

The plugin should generate a valid SPDX document with minimal configuration required by the user.
====Skills Needed====
* Programming languages skills will depend on the package manager (e.g. Ruby for Ruby Gems, JavaScript for NPM)
* Knowledge of package managers and build processes
* Skills in parsing and pattern matching
* Ability to work with the community in integrating results with other projects
====Background Information====
SPDX produces a standard Bill of Materials for software containing package and license information. Package managers collect and manage much of the data needed to produce an SPDX document. Automatically generating SPDX documents in package managers will greatly increase the efficiency and adoption of SPDX.

The [Maven Plugin]( https://github.com/spdx/spdx-maven-plugin) is a prototype plugin developed for the Maven build system. It can be used as an example for creating plugins for other build environments.
====Available Mentors====
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:kstewart@linuxfoundation.org Kate Stewart]

==SPDX Specification Projects==
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.

=== SPDX Specification Views for legal counsels and developers ===
The proposal is to see if it possible to deduct large SPDX documents into a small subset SPDX document providing a specific reduced "views" on larger data.
====Skills Needed====
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX
====Background Information====
SPDX documents commonly contain 100s, if not 1000s of entries making it hard for a human to make manual corrections or draw conclusions. No scanner can provide 100% complete data human corrections are usual needed. The aim from this proposal is twofold:
1. Enable developers with a "code view" of tool-generated SPDX document close to the code they work on to enable them to make corrections to the SPDX data. For instance amend SPDX package tag values or model package dependencies not detected by used scanner.
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions
====Available Mentors====
[mailto:swinslow@linuxfoundation.org Steve Winslow]
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]