https://wiki.spdx.org/api.php?action=feedcontributions&user=Swinslow&feedformat=atomSPDX Wiki - User contributions [en]2024-03-28T22:18:58ZUser contributionsMediaWiki 1.23.13https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2022-03-31T17:36:57Z<p>Swinslow: Add Golang RDF Saver project</p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2022 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
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. .<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
= Ideas for 2022 Projects =<br />
<br />
== SBOM Conformance Checker ==<br />
The goal of this project is to create a simple tool that<br />
checks whether an SBOM (in SPDX format)<br />
conforms to NTIA's minimum elements guidance.<br />
=== Description ===<br />
The SPDX Specification defines a number of fields (elements) that may appear in an SBOM (Software Bill of Materials).<br />
Not all of them are mandatory, however, so SBOMs in SPDX format can vary greatly.<br />
<br />
While researching the attributes that have to be present in an SBOM,<br />
NTIA came up with a guidance about the minimum elements that must appear therein:<br />
https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf<br />
<br />
It would, therefore, be useful to have a tool that can determine whether an SBOM stored in SPDX format<br />
fulfills all such minimum obligations.<br />
<br />
The tool should make use of the already existing libraries for reading SPDX documents<br />
=== Technologies ===<br />
Python<br />
=== Duration ===<br />
This will be a short (175 hours) project.<br />
It might be extended to a long (350 hours) project if integration<br />
with the existing SPDX handling tools (e.g., the Validation tool)<br />
is also implemented.<br />
=== Mentors ===<br />
Dick Brooks, Kate Stewart<br />
<br />
== Private license management system ==<br />
A web-based system for managing license texts; similar to the SPDX License List but oriented towards other private collections of licenses.<br />
=== Description ===<br />
The goal of the project would be to create a simple web application<br />
for people to upload license texts<br />
and automatically create a license repository.<br />
The initial rough "functional specifications" describe it as<br />
mainly an input form, where the information is entered.<br />
There will be some automatic processing (e.g., canonicalization, duplicate avoidance, etc.),<br />
a review/approval (and naming) step,<br />
and then publishing in a specified format.<br />
<br />
It should be noted that the specification is not yet finalized<br />
regarding naming namespaces, way to publish licenses, etc.<br />
If the SPDX project has already advanced in these definitions,<br />
this project will obviously implement the decisions taken.<br />
=== Technologies ===<br />
Python (any framework) for the back-end; JavaScript (any framework) for the minimal front-end.<br />
=== Duration ===<br />
This can be either a short (175 hours) project, implementing only the basic functionality;<br />
or a long (350 hours) one, implementing more functionality and automation.<br />
=== Mentors ===<br />
Alexios Zavras; more TBD<br />
<br />
== SBOM combiner ==<br />
The project will result in a simple command-line tool that will be able to “combine” information from a number of SBOMs into a comprehensive SBOM that includes all the information of the provided ones.<br />
An actual use case would be the generation of an SBOM for an actual software delivery that is comprised by a number of components, each one of which has its own correct SBOM.<br />
=== Description ===<br />
The primary purpose of this tool would be<br />
to stitch together smaller component-level SPDX documents<br />
and amalgamate them into one top-level SPDX document<br />
representing a "sum of parts" piece of software.<br />
As an initial pass for implementation, the component-level SBOMs would have to be provided by the caller<br />
until the tool was advanced enough to fetch SPDX Documents referenced by ExternalDocumenRef reliably. <br />
=== Technologies ===<br />
Python (preferably); or Go.<br />
=== Duration ===<br />
This will be a short (175 hours) project.<br />
=== Mentors ===<br />
Rose Judge; others TBD<br />
<br />
== Update of Java SPDX libraries to handle latest spec ==<br />
=== Description ===<br />
The SPDX Project maintains a library, written in Java, for working with SPDX data.<br />
The development of the library does not always follow the development of the specification immediately.<br />
Since the specification has evolved<br />
and a newer version is expected to be published<br />
right before the timeframe of the project,<br />
it would be useful to have the standard Java libraries<br />
capable of handling the latest spec.<br />
<br />
The project will involve obviously understanding deeply<br />
the existing libraries<br />
and extending them to handle the latest additions<br />
of the specification (to the point of the published version).<br />
=== Technologies ===<br />
Java; see https://github.com/spdx/Spdx-Java-Library<br />
=== Duration ===<br />
This will be a short (175 hours) project.<br />
=== Mentors ===<br />
TBD<br />
<br />
== Update of Go SPDX libraries to handle latest spec ==<br />
=== Description ===<br />
The SPDX Project maintains a library, written in Go, for working with SPDX data.<br />
The development of the library does not always follow the development of the specification immediately.<br />
Since the specification has evolved<br />
and a newer version is expected to be published<br />
right before the timeframe of the project,<br />
it would be useful to have the standard Go libraries<br />
capable of handling the latest spec.<br />
<br />
The project will involve obviously understanding deeply<br />
the existing libraries<br />
and extending them to handle the latest additions<br />
of the specification (to the point of the published version).<br />
=== Technologies ===<br />
Go; see https://github.com/spdx/tools-golang<br />
=== Duration ===<br />
This will be a short (175 hours) project.<br />
=== Mentors ===<br />
TBD<br />
<br />
== SPDX Golang RDF Saver ==<br />
=== Description ===<br />
SPDX already has a Golang library to save RDF triples into a file/string<br />
using the gordf project: https://github.com/spdx/gordf<br />
<br />
The aim of this GSoC project would be to write an adapter in the<br />
SPDX Golang Tools (the tools-golang repository at https://github.com/spdx/tools-golang) that<br />
would take an SPDX Document struct (see https://github.com/spdx/tools-golang/blob/main/spdx/document.go) as<br />
an input, and serialize it and its child elements into RDF triples to be consumed by the<br />
aforementioned gordf rdf-writer.<br />
=== Technologies ===<br />
Golang; RDF<br />
=== Duration ===<br />
This will be a short (175 hours) project. If the project requires less than 175 hours, remaining time can be spent on<br />
additional improvements to the Golang tools.<br />
=== Mentors ===<br />
Rishabh Bhatnagar; Steve Winslow as secondary / backup<br />
<br />
<br />
== Update of Python SPDX libraries to handle latest spec ==<br />
=== Description ===<br />
The SPDX Project maintains a library, written in Python, for working with SPDX data.<br />
The development of the library does not always follow the development of the specification immediately.<br />
Since the specification has evolved<br />
and a newer version is expected to be published<br />
right before the timeframe of the project,<br />
it would be useful to have the standard Python libraries<br />
capable of handling the latest spec.<br />
<br />
The project will involve obviously understanding deeply<br />
the existing libraries<br />
and extending them to handle the latest additions<br />
of the specification (to the point of the published version).<br />
=== Technologies ===<br />
Python; see https://github.com/spdx/tools-python<br />
=== Duration ===<br />
This will be a short (175 hours) project.<br />
=== Mentors ===<br />
TBD<br />
<br />
<br />
== More to come... ==<br />
Mentors: please fill out the following template for any projects you wish to propose. <br />
<br />
=== Project Name ===<br />
add overview of project here<br />
====Skills Needed====<br />
what skills should the student have to do the coding exercises<br />
====Duration===<br />
whether this is a short or a long project<br />
====Background Information====<br />
context for the project and references to be studied<br />
====Available Mentors====<br />
list individuals who are willing to mentor and provide information about the project proposal.<br />
<br />
= Historical info =<br />
<br />
[[GSOC/PastProjectIdeas]]</div>Swinslowhttps://wiki.spdx.org/view/General_Meeting/Minutes/2021-03-04General Meeting/Minutes/2021-03-042021-04-01T12:57:04Z<p>Swinslow: added links to presentation materials</p>
<hr />
<div>* Attendance: 18<br />
* Lead by Phil Odence<br />
* Minutes of Feb meeting Approved<br />
<br />
*Housekeeping<br />
** Zoom - Will be migrating to Zoom for these meetings; working with LF<br />
** Phil will need to cut out early; Steve will take over notes<br />
<br />
== SPDX BOM for CMake Project ==<br />
<br />
* Materials:<br />
** Slides: https://github.com/swinslow/slides/blob/main/2021-02-fosdem/2021-02-07-FOSDEM-2021-SPDX-CMake.pdf<br />
** POC repo: https://github.com/swinslow/cmake-spdx<br />
<br />
* Background<br />
** Presented previously at FOSDEM<br />
** Used Zephyr, lightweight RTOS<br />
** Goal in parallel with CMake build generate an SPDX file<br />
*** including relationships<br />
*** fully automated<br />
*** not pull from external sources (license data for example)<br />
*** make is Zephyr-agnostic, so could be reusable<br />
* POC<br />
** On GHub<br />
** Used File-based API on CMake<br />
*** to tell CMake to dump JSON meta-data files for each artifact<br />
*** and then build<br />
** Created SPDX<br />
*** Pull from <br />
**** Sources directory<br />
**** Artifacts directory<br />
**** Pull SPDX short form license names from files<br />
**** Create relationships <br />
*** Output is two files<br />
**** Sources<br />
**** Build artifacts<br />
**** w links between<br />
* Findings<br />
** Some limitations to the CMake API data, missing some info that CMake seems to “know”<br />
** Some invalid IDs<br />
** Graphiz was helpful in visualize the relationships represented in JSON files<br />
* Next Steps<br />
** Takeaways: the concept basically works; start small and can be improved<br />
** Working w Zephyr community<br />
*** may have made it overly agnostic<br />
*** could tailor to Z build system<br />
*** but generalized version is a great starting point<br />
** Michael Herzog: developed TraceCode as a tool to similarly look at details during the build process; more generalized, but extremely hard to use for anything sizeable b/c creates so much data<br />
** Also looked at Yocto as a way to gather this information<br />
** Kate: Richard Purdie interested in this also from the Yocto side – perhaps get together a working group focused on this. Yocto also doing work around reproducible builds, and has been adopting SPDX identifiers.<br />
<br />
** Kay: thoughts on a “Build” profile for SPDX 3.0 to incorporate build-time data about e.g. the call used to start the compilation, the environment / compilation settings, etc. We should get various compiler people talking about how to align practices for this<br />
** Kate: agreed, let’s get a working group together on this<br />
<br />
<br />
== Legal Team Report - Jilayne/Paul/Steve ==<br />
<br />
* Gary and William got the license list CI system moved from Travis to GitHub Actions – thank you!<br />
* 3.12 – aiming to release this weekend; will tie up remaining issues in call after this meeting<br />
* Jilayne and Steve looking at getting some bigger projects going<br />
* Invite to all to jump into the conversations in issue threads - https://github.com/spdx/license-list-XML/issues<br />
<br />
== Tech Team Report - Kate/Gary/Others ==<br />
<br />
* Model and Process update – Gary<br />
** William leading discussions on Base profile model – reconciling feedback<br />
** Template for how to draft and write the profile specifications<br />
* Google Summer of Code – Gary<br />
** Should be hearing back shortly whether SPDX was accepted for 2021<br />
<br />
* Spec – Kate<br />
** Defects / Security – Thomas<br />
*** currently revising what was discussed on prior meetings<br />
*** worked with William on expressing vulnerabilities<br />
*** also looking at: whether / how to express mitigation measures<br />
** Linking – Nisha<br />
*** Sounds like people do want a Linking / Linkage profile<br />
*** Currently described in the spec as an “External Map” from 3T discussions, but not sure what this means – looking for more details<br />
** Integrity – Kay<br />
*** Working on creating POC for taking an SBOM, serializing it to binary, signing it using the COSI (?) standard<br />
*** could be signed in other ways, but using this for POC b/c small format and usable for small devices<br />
*** expect to have this the week after next<br />
*** spec for document integrity – “here’s how you sign SBOMs” – after having that as an example, plan to start reviewing with broader group<br />
*** may be a month before ready to discuss on a tech team call<br />
** Usage – Yoshiyuki Ito<br />
*** discussing what info to include in usage profile<br />
*** looking at using external map to refer to external information sources<br />
** Pedigree / Build / Creation – Kate<br />
*** can start those meetings happening, flesh out ideas<br />
*** reach out to in-toto folks to align with them<br />
<br />
* SPDX 2.2.1 – Kate:<br />
** ISO balloting has finished on the specification, via JDF<br />
** Approved from balloting, so should be getting an ISO number in the next few months<br />
** May have some tweaks to the 2.2.1 repo coming in, based on comments from ISO reviewers<br />
<br />
<br />
== Outreach Team Report ==<br />
<br />
* No Report<br />
<br />
<br />
== Attendees ==<br />
<br />
* Phil Odence, Black Duck/Synopsys<br />
* Steve Winslow, LF<br />
* Michael Herzog- nexB<br />
* Gary O’Neall, SourceAuditor<br />
* David Edelsohn<br />
* Jeff Schutt<br />
* Rose Judge, VMware<br />
* Nisha Kumar, VMware<br />
* Jilayne Lovejoy, Red Hat<br />
* Kate Stewart, Linux Foundation<br />
* Emmanuel Tournier, Black Duck/Synopsys<br />
* Jorge Rodriguez-Moreno<br />
* Alfredo Espinosa<br />
* Kay Williams, Microsoft<br />
* Paul Madick, Jenzabar<br />
* William Cox, Synopsys<br />
* Bob Martin, Mitre<br />
* Thomas Steenbergen, HERE<br />
<br />
<br />
[[Category:General|Minutes]]<br />
[[Category:Minutes]]</div>Swinslowhttps://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2021-02-02T18:13:12Z<p>Swinslow: cleaned up links and capitalization for Golang projects</p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2021 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
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. .<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
=Proposed 2021 Projects=<br />
<br />
Mentors: please fill out the following template for any projects you wish to propose. <br />
<br />
=== Project Name ===<br />
add overview of project here<br />
====Skills Needed====<br />
what skills should the student have to do the coding exercises<br />
====Background Information====<br />
context for the project and references to be studied<br />
====Available Mentors====<br />
list individuals who are willing to mentor and provide information about the project proposal. <br />
<br />
(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] ).<br />
<br />
==SPDX Workgroup Tooling Projects== <br />
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.<br />
<br />
=== Generate RDF/OWL/XML from Structured Markdown ===<br />
Convert a consistently structured Markdown file into a Web Ontology Language XML document. Changes to an existing Markdown file should update the OWL document. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the elements and attributes of the RDF/OWL XML 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.<br />
<br />
====Skills Needed====<br />
* Skills in writing parsing algorithms (e.g. working with [https://en.wikipedia.org/wiki/Abstract_syntax_tree Abstract Syntax Tree])<br />
* Knowledge and experience in the programming language chosen for the project (e.g. Java, JavaScript, Python)<br />
* Knowledge of RDF/OWL/XML formats<br />
* Knowledge of Markdown syntax<br />
<br />
====Background Information====<br />
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.<br />
<br />
Below are some additional resources for this project:<br />
* [https://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/ RDF OWL parsing notes from the W3C]<br />
* [https://github.github.com/gfm/ Github flavored Markdown]<br />
* [https://docs.google.com/document/d/13PojpaFPdoKZ9Gyh_DEY-Rp7lldyMbSiGE3vCRQhR9M/edit# Results of process discussion]<br />
* [https://docs.google.com/document/d/1EGoAmKxPfmmlF3XV6fXwNmsCiFKLH83Bhh8_xrmGhko Analysis of RDF/OWL fields relative to Markdown] (work in progress)<br />
* [https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.owl.xml Current RDF/OWL document for SPDX spec]<br />
* [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<br />
<br />
====Available Mentors====<br />
[mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
=== RDF Writer for Golang ===<br />
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.<br />
<br />
====Skills Needed====<br />
* Knowledge of RDF<br />
* Skills in XML parsing<br />
* Knowledge and experience in Golang<br />
<br />
====Background Information====<br />
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.<br />
<br />
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.<br />
<br />
====Available Mentors====<br />
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar]<br />
<br />
=== JSON Support for Golang libraries ===<br />
JSON is one of the supported formats for SPDX. This project is to add support for reading and writing JSON to the Golang libraries.<br />
<br />
====Skills Needed====<br />
* Knowledge of JSON<br />
* Skills in JSON parsing<br />
* Knowledge and experience in Golang<br />
<br />
====Background Information====<br />
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.<br />
<br />
====Available Mentors====<br />
[mailto:bhatnagarrishabh4@gmail.com Rishabh Bhatnagar] [mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
<br />
==SPDX Specification Projects==<br />
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.<br />
<br />
=== SPDX Specification Views for legal counsels and developers ===<br />
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.<br />
====Skills Needed====<br />
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX<br />
====Background Information====<br />
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:<br />
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.<br />
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
<br />
=== ClearlyDefined exporting and importing SPDX documents ===<br />
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.<br />
<br />
====Skills Needed====<br />
* Experience with JSON and YAML (XML a plus)<br />
* Ability to interpret and implement the SPDX specification and related ClearlyDefined community documentation<br />
* Ability to work with the community in integrating results with other projects<br />
* Willingness to learn about open source licensing and related technical matters<br />
<br />
====Background Information====<br />
Export a ClearlyDefined workspace as a SPDX document:<br />
* user to navigate to https://clearlydefined.io/workspace<br />
* Add one or more components to the workspace through any of the existing means, <br />
* then click Share, and then slick SPDX (choice of 2.2 supported output formats).<br />
which would result in an SPDX document is exported containing all of the components that were in the workspace.<br />
Note: If there is mandatory information required by SPDX that ClearlyDefined does not have we will need to determine how to accommodate that.<br />
<br />
To populate a workspace from a SPDX document:<br />
* user to navigate to https://clearlydefined.io/workspace<br />
* drag a SPDX document into the workspace and then all of the components in the SPDX document are added to the workspace.<br />
<br />
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?<br />
<br />
====Available Mentors====<br />
[mailto:kstewart@linuxfoundation.org Kate Stewart]<br />
[mailto:IAMWILLBAR@github.com William Bartholomew]</div>Swinslowhttps://wiki.spdx.org/view/Technical_Team/Minutes/2020-05-26Technical Team/Minutes/2020-05-262020-05-28T13:28:33Z<p>Swinslow: posted minutes for Gary</p>
<hr />
<div>May 26, 2020<br />
== Attendees ==<br />
* Rex Jaeschke<br />
* Kate Stewart<br />
* William Bartholomew<br />
* Gary O’Neall<br />
* Nisha Kumar<br />
* Steve Winslow<br />
* John Mudge<br />
* Takashi Ninjouji<br />
* Peter Shin<br />
* Rose Judge<br />
* Thomas Steenbergen<br />
* Jim Hutchison<br />
* GogginsS<br />
* Santiago Torres<br />
* Vicky Brasseur<br />
* Rishabh Bhatnagar<br />
<br />
Topics:<br />
<br />
Document namespaces and download URL’s using PUURL – issue https://github.com/spdx/spdx-spec/issues/372<br />
<br />
==SPDX 2.2==<br />
<br />
==SPDX 2.2.1==<br />
* Update from Rex<br />
** Steady progress<br />
** a few issues still open<br />
** John updating template so that there is no requirement for formatting<br />
* Discussion on proposal to add footnotes for XML<br />
** Agreed to remove the tables for the examples rather than go to footnotes<br />
** Still an issue with conciseness of the examples<br />
** Agree to keep the metadata as tables<br />
<br />
==GSoC==<br />
<br />
<br />
==SPDX 3.0 Security Profile==<br />
* Thomas provided an overview of the proposal: https://docs.google.com/document/d/1GyUMEcv4G8ZUGbXB8T_-pkDFxYUAbP0W0Tuts2cpZiw/edit#heading=h.szfwkkflaxx2<br />
* Proposal to focus scope on Vulnerability information<br />
** Create separate proposals for Virus information and other areas of security<br />
** William and Gary agreed with proposal, no objections<br />
* Do we need a data provider identity?<br />
** Tradeoff of complexity vs additional data<br />
** having a data provider may be useful for other profiles<br />
** useful at the vulnerability level<br />
** potentially useful at the document level<br />
** need an identity object <br />
** can be a field for vulnerability<br />
** can also be used as in a relationship<br />
* Do we want to include a remediation field?<br />
** Proposal to include a “first patched version” field<br />
** Proposal to use the description field to capture the remediation suggestion<br />
** Steve suggested we stick to the facts – similar to legal profile<br />
** Consensus to not include a remediation field (other than the first patched version field which will be included)<br />
* Discussion on filtering<br />
* Do we want to include any formatting for the description (e.g. HTML)?<br />
* Identifier Aliasing<br />
** Agreed to use ExternalRef approach under the security category<br />
* What do we do with packages that don’t maintain standard version<br />
** The fields that refer to version is a string – added many possible format<br />
* Aligning with CycloneDX<br />
** Agreed that we want to have common terms etc.<br />
** Briefly reviewed differences<br />
*** ExternalRef is on area of difference<br />
*** Description vs. summary is another area<br />
**** Suggestion to change SPDX to use description for the summary and details <br />
<br />
<br />
==Next Week’s Agenda==<br />
* How do we specify the profiles in use for 3.0<br />
* Legal update – suggest this would be a joint legal/tech call<br />
<br />
[[Category:Technical|Minutes]]</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2020-03-26Legal Team/Minutes/2020-03-262020-03-29T14:34:49Z<p>Swinslow: Created page with "2020-03-26 == Attendees == * Mark Atwood * John Horan * Jilayne Lovejoy * Steve Winslow == Minutes == Reviewed and resolved remaining comments / finalized license inclusion..."</p>
<hr />
<div>2020-03-26<br />
<br />
== Attendees ==<br />
* Mark Atwood<br />
* John Horan<br />
* Jilayne Lovejoy<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Reviewed and resolved remaining comments / finalized license inclusion guidelines on PR 990. Jilayne made a few remaining changes, and after the tests pass, Steve will merge the PR.<br />
<br />
Also discussed process and roles for adding licenses to the list – consider something with more explicit roles like “reviewer”, “maintainer/committer” – and +1’s / -1’s from X reviewers as how to track what should be added. Intention would be to have more people with reviewer role than those who are required – e.g. 6 with role but only 3 required.<br />
<br />
Also discussed “projects” – e.g. goals for 2020, including e.g. inclusion guidelines – with designated leads to shepherd them through.<br />
<br />
One project idea: gather collateral re: license list, what is where (current status), where should it be<br />
<br />
Agreed for now to leave inclusion guidelines historical background section where it is for now, in the same document as the updated principles. Will revisit as part of broader cleanup of docs.<br />
<br />
Next release (3.9) pushed to end of April. Jilayne will go through and apply tags + release labels. Steve will send announcement to email list, noting the finalized license inclusion guidelines + URL, postponing release to end of April, and asking for comments on license submissions.</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2020-03-12Legal Team/Minutes/2020-03-122020-03-29T14:29:46Z<p>Swinslow: Created page with "2020-03-12 == Attendees == * Mark Atwood * VM Brasseur * John Horan * Jilayne Lovejoy * Matija Suklje * Steve Winslow == Minutes == Reviewed update to license inclusion pri..."</p>
<hr />
<div>2020-03-12<br />
<br />
== Attendees ==<br />
* Mark Atwood<br />
* VM Brasseur<br />
* John Horan<br />
* Jilayne Lovejoy<br />
* Matija Suklje<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Reviewed update to license inclusion principles in PR 985<br />
<br />
Discussed inclusion of references to “binary-only” exclusion re: software vs. media content and data; revised language to clarify meaning of exclusion, also to add language to clarify that this isn’t about the files under the license, but about the license itself.<br />
<br />
Suggest including a side FAQ doc that can evolve over time, for clarifications that don’t require fully reopening the principles. For e.g. drive-by submissions, can then point people to the docs specifically and then be able to close the issue.<br />
<br />
Discussed wording of next-to-last bullet point on “source available” licenses<br />
<br />
Discussed adding Definition of Free Cultural Works to list of baseline definitions<br />
<br />
Participants will continue commenting on open issues. Anything new coming in won’t get into 3.9, which will likely be delayed by a month to accommodate new additions under the updated inclusion principles after they go live.<br />
<br />
W3C licenses – only a few are currently on the list, but more are in real-world use. Matija will locate actually-used W3C licenses and start submitting issues to add them.</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2020-02-27Legal Team/Minutes/2020-02-272020-03-29T14:26:20Z<p>Swinslow: Created page with "2020-02-27 == Attendees == * VM Brasseur * John Horan * Jilayne Lovejoy * Paul Madick * Steve Winslow == Minutes == Agenda: # review handful of quick licenses # LGPL-3.0 qu..."</p>
<hr />
<div>2020-02-27<br />
<br />
== Attendees ==<br />
* VM Brasseur<br />
* John Horan<br />
* Jilayne Lovejoy<br />
* Paul Madick<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Agenda:<br />
# review handful of quick licenses<br />
# LGPL-3.0 question - license vs. exception<br />
# inclusion guidelines<br />
<br />
For the licenses that were discussed, comments on specific issues are contained in the particular GitHub issue threads at https://github.com/spdx/license-list-XML/issues<br />
<br />
LGPL-3.0 discussion – have tried to be sensitive to prevailing views in the community. Really try not to change identifiers – have deprecated some (re: e.g. -or-later / -only) – should be only changed if there’s a very, very strong reason to do so. Consensus on the call was that community views of the LGPL-3.0 tend to treat it as its own license, rather than as an exception.<br />
<br />
For the inclusion guidelines, discussion continued of the draft update from Jilayne at PR 985. Changes and open issues were discussed regarding the interim draft.</div>Swinslowhttps://wiki.spdx.org/view/Technical_Team/MinutesTechnical Team/Minutes2020-03-29T14:19:03Z<p>Swinslow: </p>
<hr />
<div>{{#subpages:|limit=500|format=ul|kidsonly=no|pathstyle=none|sort=desc}}<br />
<br />
[[Category:Technical|Minutes]]<br />
[[Category:Minutes]]<br />
[[Technical Team/Minutes/CollabSummitPhotos|White Boards from Collab Summit]]</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/MinutesLegal Team/Minutes2020-03-29T14:18:13Z<p>Swinslow: </p>
<hr />
<div>{{#subpages:|limit=500|format=ul|kidsonly=no|pathstyle=none|sort=desc}}<br />
<br />
[[Category:Legal|Minutes]]<br />
[[Category:Minutes]]</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2020-02-13Legal Team/Minutes/2020-02-132020-03-29T14:12:29Z<p>Swinslow: Created page with "2020-02-13 == Attendees == * Mark Atwood * VM (Vicky) Brasseur * Brad Goldring * John Horan * Van Lindberg * Jilayne Lovejoy * Paul Madick * Steve Winslow == Minutes == Com..."</p>
<hr />
<div>2020-02-13<br />
<br />
== Attendees ==<br />
* Mark Atwood<br />
* VM (Vicky) Brasseur<br />
* Brad Goldring<br />
* John Horan<br />
* Van Lindberg<br />
* Jilayne Lovejoy<br />
* Paul Madick<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Comments on specific issues are contained in the particular GitHub issue threads at https://github.com/spdx/license-list-XML/issues<br />
<br />
Much of the discussion focused on the request to add CAL-1.0, in issue 953, along with specifics of formatting / how it would be added. Particularly relevant as the license text instructions incorporate use of the SPDX identifier. Specific discussion included:<br />
* where to place license use info – at the top vs. at the bottom (cf Apache-2.0, GPL-*)<br />
* where to place the identifier, in particular the “Combined Work Exception”<br />
* lead-in describing how to apply the license<br />
* PR and XML files</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-11-14Legal Team/Minutes/2019-11-142020-03-29T14:08:35Z<p>Swinslow: Created page with "2019-11-14 == Attendees == * John Horan * Jilayne Lovejoy * Steve Winslow == Minutes == Jilayne is reviewing and gathering thoughts from prior discussions on updates to the..."</p>
<hr />
<div>2019-11-14<br />
<br />
== Attendees ==<br />
* John Horan<br />
* Jilayne Lovejoy<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Jilayne is reviewing and gathering thoughts from prior discussions on updates to the license inclusion guidelines.<br />
<br />
Discussed follow-up from joint legal/tech team call, potentially changes to names for fields + separate profiles proposed for 3.0: https://docs.google.com/document/d/1XfNrDmlVdnUzvtrPsylJZFfz1LLDoqnm_vi_PguSzy8/edit?ts=5d976d7b#<br />
<br />
Discussed request to change from CC0 as mandatory data license. Jilayne reaching out to Karen Copenhaver re: what were the things we were trying to avoid originally. Are the earlier concerns still applicable / relevant today? Separately, send a request back to tech team: what are the proposed alternatives? and/or, can they explain why they need something different?<br />
Want to spell out:<br />
# what the old concerns were<br />
# are they still relevant?<br />
# what are the concerns from the requestors now?<br />
<br />
Steve to do 3.8 issue list review and cleanup, picking up XML where possible. Steve will also send out 2020 invite update, change to Jan. 9 and thereafter; and note dates<br />
<br />
Upcoming goals include:<br />
* new license inclusion guidelines<br />
* rewrite of overview text on website in connection with that</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-10-31Legal Team/Minutes/2019-10-312020-03-29T14:05:43Z<p>Swinslow: Created page with "2019-10-31 == Attendees == * John Horan * Steve Winslow == Minutes == Discussed background on SPDX 3.0, license inclusion guidelines and updates, matching guidelines, and s..."</p>
<hr />
<div>2019-10-31<br />
<br />
== Attendees ==<br />
* John Horan<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Discussed background on SPDX 3.0, license inclusion guidelines and updates, matching guidelines, and similar topics.<br />
<br />
Discussed issue 947, John will take the lead on reviewing and preparing a PR.</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-10-17Legal Team/Minutes/2019-10-172020-03-29T14:03:32Z<p>Swinslow: Created page with "2019-10-17 == Attendees == * Alan Tse * Jilayne Lovejoy * Jim Vitrano * John Horan * Mike Dolan * Paul Madick * Steve Winslow == Minutes == Steve will run the release proce..."</p>
<hr />
<div>2019-10-17<br />
<br />
== Attendees ==<br />
* Alan Tse<br />
* Jilayne Lovejoy<br />
* Jim Vitrano<br />
* John Horan<br />
* Mike Dolan<br />
* Paul Madick<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Steve will run the release process for 3.7 to go live shortly.<br />
<br />
Most of the discussion focused on the ongoing considerations for updating the license inclusion guidelines, including discussion of the following:<br />
* must be stable text – is there an exception?<br />
* if OSI approved, it gets added to the list<br />
* if not open source-ish, at least needs to be source available – and other factors will apply more strongly<br />
* if not OSI-approved or FSF-libre, or one of the others – if the license does not, then it MUST be source-available and other factors will be weighed more heavily<br />
** philosophical reason: if OSI, FSF, etc. approved it, then they’ve already gone through a process to know who the steward is, etc.<br />
** if not OSI etc., then go back with questions such as: who is steward? do they commit to stable and versioned license texts? will they engage with the process?<br />
** drive-by submissions with no engagement, we close the issue</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-10-03Legal Team/Minutes/2019-10-032020-03-29T13:58:18Z<p>Swinslow: Created page with "2019-10-03 == Attendees == * Mark Atwood * Mark Baushke * Jilayne Lovejoy * John Horan * Paul Madick * Steve Winslow == Minutes == Comments on specific issues are contained..."</p>
<hr />
<div>2019-10-03<br />
<br />
== Attendees ==<br />
* Mark Atwood<br />
* Mark Baushke<br />
* Jilayne Lovejoy<br />
* John Horan<br />
* Paul Madick<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Comments on specific issues are contained in the particular GitHub issue threads at https://github.com/spdx/license-list-XML/issues<br />
<br />
Work continued on preparing and finalizing issues for the upcoming 3.7 release. Issues 923, 913 and 867 were discussed and comments included in thread.<br />
<br />
908 – MirOS – go to OSI? or go back to author to say it matches against OSI website? If putting in new optional text, files under the old instructions text would not be found<br />
<br />
925 – License inclusion guidelines discussion – advertise for next legal team call. Won’t be a redline rule, need to think about how we draft this so that it’s clearly a “totality of the circumstances”. Challenging part is it’s not one continuum, it’s a mix of factors</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-09-19Legal Team/Minutes/2019-09-192020-03-29T13:53:48Z<p>Swinslow: Created page with "2019-09-19 == Attendees == * Alan Tse * Bradlee Edmondson * Jilayne Lovejoy * Jim Vitrano * John Horan * Mark Baushke * Steve Winslow == Minutes == Comments on specific iss..."</p>
<hr />
<div>2019-09-19<br />
<br />
== Attendees ==<br />
* Alan Tse<br />
* Bradlee Edmondson<br />
* Jilayne Lovejoy<br />
* Jim Vitrano<br />
* John Horan<br />
* Mark Baushke<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Comments on specific issues are contained in the particular GitHub issue threads at https://github.com/spdx/license-list-XML/issues<br />
<br />
Discussion focused on prep for the upcoming 3.7 release.<br />
<br />
Discussed GPL family of licenses re: proxies / later versions. May have been previously discussed re: operator in connection with -only/-or-later issue.<br />
If need to add an operator, won’t be in the next week as it would need to be in the spec; not really a standalone license list matter.<br />
<br />
Could re-open the conversation - would be a good mailing list conversation – John will search the archives to check and email list by meeting after next (e.g. in next 4 weeks)<br />
<br />
Different languages in licenses: issue to be opened<br />
Jilayne and Kate presentation from 2017: <br />
Wiki: https://wiki.spdx.org/view/Legal_Team/non-English-licenses<br />
https://docs.google.com/presentation/d/1miQz9F7q_oVbYCibTuhSrJ_qog6eHWs0DxcXxQ-ZLuk/edit#slide=id.p4<br />
<br />
MirOS:<br />
comments are already optional – ask Gary why they aren't showing as blue optional text in the published list. Is this new version used in the wild? The noted text is already optional, but can’t rewrite the license now -- matching guidelines should be raised in the issue.<br />
<br />
May want to add to documentation re: we strongly try to avoid changing license IDs for existing entries.</div>Swinslowhttps://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2020-02-25T15:09:28Z<p>Swinslow: /* Skills Needed */</p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2020 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
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. .<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
=Proposed 2020 Projects=<br />
<br />
Mentors: please fill out the following template for any projects you wish to propose. <br />
<br />
=== Project Name ===<br />
add overview of project here<br />
====Skills Needed====<br />
what skills should the student have to do the coding exercises<br />
====Background Information====<br />
context for the project and references to be studied<br />
====Available Mentors====<br />
list individuals who are willing to mentor and provide information about the project proposal. <br />
<br />
(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] ).<br />
<br />
==SPDX Workgroup Tooling Projects== <br />
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.<br />
<br />
===Implement SPDX License Matching in Python===<br />
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.<br />
<br />
Following is a list of suggested features:<br />
* Provide an interface which will check text against a license template using the license matching guidelines<br />
* Provide an interface which will check text and return all matching SPDX listed license ID's<br />
* 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<br />
* When there is not a match, provide a return value making it possible to describe where and why the license does not match<br />
<br />
====Background Information====<br />
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines<br />
* 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<br />
* 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]<br />
* 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.<br />
<br />
====Skills Needed==== <br />
* Development skills in the Python<br />
* Skills in parsing and pattern matching<br />
* Ability to work with the community in integrating results with other projects<br />
<br />
====Available Mentors====<br />
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
=== Generate Java SPDX Model Classes from XML XSD file ===<br />
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. <br />
<br />
====Skills Needed====<br />
* Java programming skills<br />
* XML/XSD skills<br />
* Skills in code generation practices<br />
* Ability to work with the community in integrating results with other projects<br />
<br />
====Background Information====<br />
* 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.<br />
* Current Java tools can be found on [https://github.com/spdx/tools SPDX Tools github page]<br />
* 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.<br />
<br />
====Available Mentors====<br />
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
=== Validate License Cross-References ===<br />
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).<br />
<br />
====Skills Needed====<br />
* Java programming skills<br />
* XML/XSD skills<br />
* HTML parsing skills<br />
* Ability to work with the community in integrating results with other projects<br />
<br />
====Background Information====<br />
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.<br />
<br />
Over the summer, we may be adding the XML format to the supported output data formats in the license list data repo.<br />
<br />
====Available Mentors====<br />
[mailto:gary@sourceauditor.com Gary O'Neall] <br />
<br />
=== Improve SPDX Golang tooling ===<br />
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.<br />
<br />
====Skills Needed====<br />
* Go programming skills<br />
* Experience with JSON and YAML (XML a plus)<br />
* Ability to interpret and implement the SPDX specification and related community documentation<br />
* Ability to work with the community in integrating results with other projects<br />
* Willingness to learn about open source licensing and related technical matters<br />
<br />
====Background Information====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
<br />
==SPDX Specification Projects==<br />
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.<br />
<br />
=== SPDX Specification Views for legal counsels and developers ===<br />
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.<br />
====Skills Needed====<br />
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX<br />
====Background Information====<br />
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:<br />
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.<br />
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]</div>Swinslowhttps://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2020-02-25T15:08:18Z<p>Swinslow: </p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2020 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Documents in multiple formats]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
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. .<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
=Proposed 2020 Projects=<br />
<br />
Mentors: please fill out the following template for any projects you wish to propose. <br />
<br />
=== Project Name ===<br />
add overview of project here<br />
====Skills Needed====<br />
what skills should the student have to do the coding exercises<br />
====Background Information====<br />
context for the project and references to be studied<br />
====Available Mentors====<br />
list individuals who are willing to mentor and provide information about the project proposal. <br />
<br />
(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] ).<br />
<br />
==SPDX Workgroup Tooling Projects== <br />
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.<br />
<br />
===Implement SPDX License Matching in Python===<br />
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.<br />
<br />
Following is a list of suggested features:<br />
* Provide an interface which will check text against a license template using the license matching guidelines<br />
* Provide an interface which will check text and return all matching SPDX listed license ID's<br />
* 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<br />
* When there is not a match, provide a return value making it possible to describe where and why the license does not match<br />
<br />
====Background Information====<br />
* See the [https://spdx.org/spdx-license-list/matching-guidelines SPDX License Matching Guidelines] for a description of the guidelines<br />
* 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<br />
* 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]<br />
* 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.<br />
<br />
====Skills Needed==== <br />
* Development skills in the Python<br />
* Skills in parsing and pattern matching<br />
* Ability to work with the community in integrating results with other projects<br />
<br />
====Available Mentors====<br />
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
=== Generate Java SPDX Model Classes from XML XSD file ===<br />
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. <br />
<br />
====Skills Needed====<br />
* Java programming skills<br />
* XML/XSD skills<br />
* Skills in code generation practices<br />
* Ability to work with the community in integrating results with other projects<br />
<br />
====Background Information====<br />
* 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.<br />
* Current Java tools can be found on [https://github.com/spdx/tools SPDX Tools github page]<br />
* 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.<br />
<br />
====Available Mentors====<br />
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
=== Validate License Cross-References ===<br />
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).<br />
<br />
====Skills Needed====<br />
* Java programming skills<br />
* XML/XSD skills<br />
* HTML parsing skills<br />
* Ability to work with the community in integrating results with other projects<br />
<br />
====Background Information====<br />
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.<br />
<br />
Over the summer, we may be adding the XML format to the supported output data formats in the license list data repo.<br />
<br />
====Available Mentors====<br />
[mailto:gary@sourceauditor.com Gary O'Neall] <br />
<br />
=== Improve SPDX Golang tooling ===<br />
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.<br />
<br />
====Skills Needed====<br />
* Go programming skills<br />
* Experience with JSON and YAML (XML a plus)<br />
* Ability to work with the community in integrating results with other projects<br />
<br />
====Background Information====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
<br />
==SPDX Specification Projects==<br />
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.<br />
<br />
=== SPDX Specification Views for legal counsels and developers ===<br />
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.<br />
====Skills Needed====<br />
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX<br />
====Background Information====<br />
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:<br />
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.<br />
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2020-01-30Legal Team/Minutes/2020-01-302020-01-30T19:28:59Z<p>Swinslow: Created page with "2020-01-30 == Attendees == * Mark Atwood * John Horan * Paul Madick * Jim Vitrano * Steve Winslow == Minutes == The meeting focused on finalizing issues tagged for the upco..."</p>
<hr />
<div>2020-01-30<br />
<br />
== Attendees ==<br />
* Mark Atwood<br />
* John Horan<br />
* Paul Madick<br />
* Jim Vitrano<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
The meeting focused on finalizing issues tagged for the upcoming 3.8 release, and shifting to 3.9 those that are unlikely to be finished for 3.8. Comments on specific issues are contained in the particular GitHub issue threads at https://github.com/spdx/license-list-XML/issues<br />
<br />
A couple of topics were flagged as likely warranting discussion on a joint legal / tech team call:<br />
# regular expressions in license list schema files: concerns have been raised about "anything goes" (.+) matches, and would like to discuss what alternatives are or are not feasible<br />
# license option selections and potential impact on license expression syntax -- see https://github.com/spdx/license-list-XML/issues/970 for details</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2020-01-16Legal Team/Minutes/2020-01-162020-01-30T16:49:47Z<p>Swinslow: Created page with "2020-01-16 == Attendees == * Mark Atwood * Mark Baushke * Brad Edmondson * John Horan * Steve Winslow == Minutes == Much of the meeting focused on reviewing issues tagged f..."</p>
<hr />
<div>2020-01-16<br />
<br />
== Attendees ==<br />
* Mark Atwood<br />
* Mark Baushke<br />
* Brad Edmondson<br />
* John Horan<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Much of the meeting focused on reviewing issues tagged for the upcoming 3.8 release. Comments on specific issues are contained in the particular GitHub issue threads at https://github.com/spdx/license-list-XML/issues<br />
<br />
A handful of the pending requests for 3.8 are dependent on the next steps with the license inclusion guidelines. In light of Jilayne's absence and Steve not making progress on a revised draft proposal for the guidelines, they are not likely to be changed for 3.8, so the related issues were agreed to be moved to 3.9.<br />
<br />
Lengthy discussion occurred regarding various requests over the past couple years that involve licensors' ability to make multiple choices from within a certain license. E.g., where a licensor has chosen to use OFL-1.1, they can also optionally choose to specify a "Reserved Font Name"; if they do, then it has a different set of obligations than if they do not.<br />
<br />
For OFL the decision was made to go ahead and add separate entries for the different options. However, as a broader question it was discussed whether the license expression syntax should be modified to accommodate this, and to enable users to be able to better articulate selections or choices of options within a single license. The following possible approaches were discussed:<br />
<br />
# Adding separate license entries for each combination<br />
# Use the WITH syntax; change the meaning of the "exceptions" list to something different, since not all of these are "exceptions"<br />
# Create a new syntax, such as USING or SELECT; list the options in a manner separate from the "exceptions" list<br />
# Don't do anything; keep adding separate options to the license list where it seems appropriate, but otherwise let people use LicenseRef- IDs if they want to be more precise<br />
<br />
Other comments noted that selections could veer away from what is otherwise an "open source" license, and could be useful but also potentially harmful. In particular, care should be taken to avoid conflating "exceptions" with things that take away rights. The approach here should focus on articulating options within the four corners of the license, not as a mechanism to modify licenses with external texts.<br />
<br />
2020-01-30 update: Steve has submitted an issue summarizing this in greater detail at: https://github.com/spdx/license-list-XML/issues/970</div>Swinslowhttps://wiki.spdx.org/view/Technical_Team/Minutes/2019-12-03Technical Team/Minutes/2019-12-032019-12-03T19:12:52Z<p>Swinslow: /* SPDX Document License */</p>
<hr />
<div>December 3, 2019<br />
== Attendees ==<br />
* Gary O’Neall<br />
* Alexios Zavras <br />
* Kate Stewart<br />
* Jim Hutchinson<br />
* Steve Winslow<br />
* Matthew Crawford<br />
* William Bartholomew<br />
* Alan Tse<br />
* Mark Atwood<br />
* Rose Judge<br />
* Nisha Kumar<br />
* Philippe Ombredanne<br />
<br />
==3.0 Model==<br />
* Proposed update from William<br />
* Came out of feedback from OMG group<br />
* Feedback on current model:<br />
** Exclusively focused on licensing and IP<br />
** Not very approachable<br />
* Different profiles for the different usages (e.g. IP, Security)<br />
* Feedback: Change “Intellection Property” to “Licensing” for profile name<br />
* Tooling – do we need to support all profiles?<br />
** SPDX focused on syntax<br />
** Producers and consumers have policies on what profiles are supported<br />
* Discussion on Relationship – issue has already been added<br />
* Discussion on FilesAnalyzed – William will add an issue to track <br />
<br />
==SPDX Document License==<br />
* We didn’t have a quorum to discuss completely<br />
* Steve and Jilyane are researching the reasons for the mandatory DataLicense: CC0-1.0 declaration currently in use<br />
* Request that those who would like it changed to document the reasons<br />
* Philippe suggested that for some use cases where there is a contract in place between the supplier and consumer, the license for the SPDX document be in the license and not the document itself<br />
* Steve will open an issue to track<br />
<br />
[[Category:Technical|Minutes]]<br />
[[Category:Minutes]]</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-09-05Legal Team/Minutes/2019-09-052019-10-03T14:28:36Z<p>Swinslow: Created page with "2019-09-05 == Attendees == * Mark Atwood * Mark Baushke * Richard Fontana * John Horan * Jilayne Lovejoy * Paul Madick * Philippe Ombredanne * Steve Winslow == Minutes == D..."</p>
<hr />
<div>2019-09-05<br />
<br />
== Attendees ==<br />
* Mark Atwood<br />
* Mark Baushke<br />
* Richard Fontana<br />
* John Horan<br />
* Jilayne Lovejoy<br />
* Paul Madick<br />
* Philippe Ombredanne<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
Discussed workflow for PRs coming in without a corresponding issue<br />
* New licenses should always have an issue<br />
* for minor changes, e.g. markup fixes, PR only is fine<br />
* CONTRIBUTING file should be expanded to explain this, e.g.: non-substantive changes or corrections to existing licenses<br />
<br />
Polyform / License Inclusion Principles: Move Polyform to next release (3.8). <br />
# Solidify license inclusion principles as currently exists; point website to GitHub docs<br />
# Then, discuss in Github issue<br />
<br />
Comments during call:<br />
* Include source available licenses, where intended for widespread use, and written by someone “third party” go on list; by companies for their own projects, goes in their own namespace<br />
* Some interest in including source available licenses on the list, whether b/c of use case for using that license for one’s own project, or to facilitate other FOSS projects being able to avoid them<br />
* Concern about SPDX license list being used as a mechanism to promote hitherto-not-heavily-used licenses<br />
* Maybe another factor is: If a license doesn’t substantially comply, then maybe it can still be added but has to meet these other criteria: e.g. not company-specific; maintained in a versioned way; significant enough use in the wild; and/or license steward’s “constellation” of licenses has significant enough use in the wild<br />
<br />
Current issue for discussion of updates to license inclusion guidelines: https://github.com/spdx/license-list-XML/issues/925<br />
<br />
Python-2.0: Discussed whether should be split up into separate versioned licenses; earlier SPDX participant did a whole forensic analysis of Python license pieces. May not want to re-open but should at least document earlier decisions that were previously made.</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-08-08Legal Team/Minutes/2019-08-082019-10-03T14:26:16Z<p>Swinslow: </p>
<hr />
<div>2019-08-08<br />
<br />
== Attendees ==<br />
* Mark Atwood<br />
* John Horan<br />
* Paul Madick<br />
* Alan Tse<br />
* Steve Winslow<br />
* Alexios Zavras<br />
<br />
== Minutes ==<br />
<br />
Discussions and decisions for several matters were noted in the corresponding threads in the Github issues. Additional discussions are noted below.<br />
<br />
For UCL-1.0, John will draft the XML + test files with Steve's review.<br />
<br />
XML and test files for the new Polyform set of licenses were submitted as a PR: https://github.com/spdx/license-list-XML/pull/903 (Not submitted as an issue, so wasn't initially seen by the legal team.) The team continued the ongoing discussion of whether licenses like this are appropriate for inclusion on the license list, where they are source available and in a standardized / templated format for use by any licensor, but where they are clearly not within e.g. the OSI definition of open source.<br />
<br />
Discussion noted that some users and consumers of SPDX documents / license IDs want to be able to refer to source-available licenses through that process, even if not open source. It was noted that there are at least two relevant reasons for the existing license inclusion guidelines: one being purpose-focused (the "generally FOSS" nature of the list), and the other being practical (availability of time for SPDX volunteers). It was also discussed how this question intersects with the idea of "namespaced" LicenseRef- identifiers that anyone can use to refer to licenses that are not approved for inclusion on the list.<br />
<br />
General consensus was that a decision on the Polyform licenses should be related to a broader conversation about changes to the license inclusion guidelines, similar to the pending outcome on some other recent license submissions with e.g. non-commercial restrictions.<br />
<br />
An issue was raised at https://github.com/spdx/license-list-XML/issues/752 requesting that "-only" and "-or-later" modifiers be made to the EUPL family of licenses, as was done for the GNU licenses. Discussion on the call agreed that this change would only be considered upon request from the license steward, and that in most cases the existing "+" operator should suffice.</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-08-15Legal Team/Minutes/2019-08-152019-10-03T14:25:49Z<p>Swinslow: Created page with "2019-08-15 Special session for demonstration of new license submission features from 2019 Google Summer of Code project == Attending == * Umang Taneja * Mark Atwood * Shawn..."</p>
<hr />
<div>2019-08-15<br />
<br />
Special session for demonstration of new license submission features from 2019 Google Summer of Code project<br />
<br />
== Attending ==<br />
* Umang Taneja<br />
* Mark Atwood<br />
* Shawn Clark<br />
* John Horan<br />
* Rahul Kumar<br />
* Jilayne Lovejoy<br />
* Paul Madick<br />
* Tushar Mittal<br />
* Thomas Steenbergen<br />
* Steve Winslow<br />
<br />
== Minutes ==<br />
<br />
* YouTube video: https://youtu.be/1xVgZAF7rkk<br />
* Recording of demo session + discussion: https://zoom.us/recording/share/jhilyN7bg60yBRWgCJbBb_d35iVzTsxnC3z77ODSj-CwIumekTziMw<br />
* Link to repo: https://github.com/spdx/spdx-online-tools/<br />
<br />
Extra meeting – demo from Umang Taneja on GSoC 2019 License Submission Tool improvements<br />
<br />
Developing the new features included the following tasks:<br />
# Create API for license submittal feature<br />
# Create SPDX license matcher => tool to match submitted license against SPDX license list. Takes into account SPDX matching guidelines <br />
# Check if license already present on license list<br />
# Check whether license is not yet approved / is rejected – looks only at what’s been submitted through the tool<br />
# Improve XML generating algorithm and license submittal feature – added Beautify button inside tools. In process, breaks if license text itself has angle bracket tags<br />
# Check for close matches, show diff, ask user if changes are substantial. Still working on PR<br />
<br />
Suggestions:<br />
* Diff to matching – include button / link to matching guidelines; include telling submitter which license is matching<br />
* Diff against other licenses – can it be word-by-word rather than full line? Longer-term fix, would involve changing the full algorithm</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-08-08Legal Team/Minutes/2019-08-082019-10-03T14:21:30Z<p>Swinslow: Created page with "2019-08-08 == Attendees == Mark Atwood John Horan Paul Madick Alan Tse Steve Winslow Alexios Zavras == Minutes == Discussions and decisions for several matters were noted i..."</p>
<hr />
<div>2019-08-08<br />
<br />
== Attendees ==<br />
Mark Atwood<br />
John Horan<br />
Paul Madick<br />
Alan Tse<br />
Steve Winslow<br />
Alexios Zavras<br />
<br />
== Minutes ==<br />
<br />
Discussions and decisions for several matters were noted in the corresponding threads in the Github issues. Additional discussions are noted below.<br />
<br />
For UCL-1.0, John will draft the XML + test files with Steve's review.<br />
<br />
XML and test files for the new Polyform set of licenses were submitted as a PR: https://github.com/spdx/license-list-XML/pull/903 (Not submitted as an issue, so wasn't initially seen by the legal team.) The team continued the ongoing discussion of whether licenses like this are appropriate for inclusion on the license list, where they are source available and in a standardized / templated format for use by any licensor, but where they are clearly not within e.g. the OSI definition of open source.<br />
<br />
Discussion noted that some users and consumers of SPDX documents / license IDs want to be able to refer to source-available licenses through that process, even if not open source. It was noted that there are at least two relevant reasons for the existing license inclusion guidelines: one being purpose-focused (the "generally FOSS" nature of the list), and the other being practical (availability of time for SPDX volunteers). It was also discussed how this question intersects with the idea of "namespaced" LicenseRef- identifiers that anyone can use to refer to licenses that are not approved for inclusion on the list.<br />
<br />
General consensus was that a decision on the Polyform licenses should be related to a broader conversation about changes to the license inclusion guidelines, similar to the pending outcome on some other recent license submissions with e.g. non-commercial restrictions.<br />
<br />
An issue was raised at https://github.com/spdx/license-list-XML/issues/752 requesting that "-only" and "-or-later" modifiers be made to the EUPL family of licenses, as was done for the GNU licenses. Discussion on the call agreed that this change would only be considered upon request from the license steward, and that in most cases the existing "+" operator should suffice.</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-07-25Legal Team/Minutes/2019-07-252019-08-05T18:11:07Z<p>Swinslow: Created page with "2019-07-25 == Attendees == * Jilayne Lovejoy * Jim Vitrano * John Horan * Mark Atwood * Mike Dolan * Paul Madick * Steve Winslow == Agenda == 1) Follow-up conversation re:..."</p>
<hr />
<div>2019-07-25<br />
<br />
== Attendees ==<br />
* Jilayne Lovejoy<br />
* Jim Vitrano<br />
* John Horan<br />
* Mark Atwood<br />
* Mike Dolan<br />
* Paul Madick<br />
* Steve Winslow<br />
<br />
== Agenda ==<br />
<br />
1) Follow-up conversation re: “SPDX-Copyright:” or related tags – suggestion from REUSE folks and discussion in Github issue here: https://github.com/spdx/spdx-spec/issues/122<br />
* Based on SPDX legal team and tech team calls, current conversation is towards adding an appendix to the SPDX spec that recommends use of a subset of tags from the File Information section of the spec, prefixed by “SPDX-”. This would enable inclusion of various information in source file comments in a way that maps directly to existing SPDX fields.<br />
* For a file’s copyright notices, this would be: “SPDX-FileCopyrightText:”<br />
* But, this has not been formalized or adopted by SPDX, and there is not yet a draft appendix to add this to the spec. Don’t need to wait until a full new release of the spec, but would want to see a merged PR adding the appendix to the spec before making further informal recommendations.<br />
* Community participants who would like to see this added are welcome and invited to attend tech team calls as this is one of the topics under discussion, and to help with drafting an appendix.<br />
<br />
2) 3.7 planning<br />
Discussed “shepherding” an issue via being assignee. Being “assigned” doesn’t mean you’re making the decision on whether or not to add a license to the list. If >= 3 people give a +1 and no objections, then fine, easy to add. If complicated issues, then label as “discuss on legal call” in Github issue thread.<br />
Call attendees agreed to each go through the open issues and add comments before the next call.<br />
<br />
3) Specifically discussed open issues:<br />
* Commons Clause: not really either a license or an exception, but more of an additional restriction. Not clear that this is suitable to add either to the license list or to the exceptions list. Issue at: https://github.com/spdx/license-list-XML/issues/902<br />
* UCL-1.0: appears to be just a small mod to OSL-3.0 but believe it is a substantively different license, and should likely be added since it is OSI-approved. Issue at: https://github.com/spdx/license-list-XML/issues/894</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-06-27Legal Team/Minutes/2019-06-272019-07-10T15:26:44Z<p>Swinslow: Added minutes for 2019-06-27 legal team meeting</p>
<hr />
<div>== Attendees ==<br />
<br />
* John Horan<br />
* Mark Atwood<br />
* Steve Winslow<br />
* Jilayne Lovejoy<br />
* Paul Madick<br />
* Brad Edmondson<br />
* Mike Dolan<br />
<br />
== Agenda ==<br />
<br />
The meeting again focused on reviewing and triaging issues that were tagged for consideration as part of the 3.6 release milestone. Some issues were resolved as noted in the relevant GitHub issue threads. 3 issues remained open to finalize, and following those the 3.6 release will be tagged and pushed.<br />
<br />
The attendees briefly discussed the Polyform Project, specifically about the possibility of using “PF-“ prefix for Polyform licenses should certain of the combinations be predominant, and not allocating tags at this time that start with “PF-“ prefix for other licenses. May need to consider what’s reasonable in terms of exponential combination of options, as well how “substantially open source” or “source available” entries on the SPDX list should be.<br />
<br />
The attendees discussed requests to have SPDX itself categorize licenses as permissive, etc., or track obligations. The Legal Team consensus is that SPDX’s role is “just the facts” and is focused on identifying and enabling conversations about licensing, to help people talk about licenses consistently. Approaches for e.g. categorizing licenses, providing recommendations or interpretation of obligations, etc. can be useful but should be handled in separate community efforts. Those community efforts would ideally make use of SPDX short-form license identifiers.<br />
<br />
There was also a brief discussion, following from the earlier tech team call, about the possibility of adding something like PROPRIETARY / CLOSED, PUBLIC-DOMAIN, etc. as identifiers. If so, this would be as part of the spec itself, not as part of license list (since there would not be particular license texts to match on). Suggest tech / legal joint call to discuss whether this would be a helpful and appropriate use case.</div>Swinslowhttps://wiki.spdx.org/view/Legal_Team/Minutes/2019-06-13Legal Team/Minutes/2019-06-132019-06-17T19:37:18Z<p>Swinslow: Added minutes for 2019-06-17 legal team meeting</p>
<hr />
<div>== Attendees ==<br />
* John Horan<br />
* Jilayne Lovejoy<br />
* Jim Vitrano<br />
* Kyle Mitchell<br />
* Mike Dolan<br />
* Steve Winslow<br />
<br />
== Agenda ==<br />
<br />
The meeting focused on reviewing and triaging issues that were tagged for consideration as part of the 3.6 release milestone. Some issues were resolved and closed; some were moved to 3.7 release given the limited time before 3.6 release at end of month; and some remain open, pending final review of PRs / creation of new PRs in a couple of instances. Specific notes on many of the resolutions can be seen in the particular issue threads on GitHub; and those issues that currently remain open for 3.6 can be found at https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.6+release%22<br />
<br />
The team also briefly discussed recent updates to the license inclusion principles, which can be seen at https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md. Jilayne noted that the team may continue to iterate on the inclusion principles in accordance with discussions on prior legal team calls.<br />
<br />
Since the 3.6 release is coming up at the end of the month, any newly-submitted requests will be considered as part of 3.7. The next legal team call will be on Thursday, June 27, and will focus on any last-minute matters needed to get 3.6 out the door. The team will focus on several longstanding prior requests for 3.7 during the first legal team call in July.</div>Swinslowhttps://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2019-02-20T21:16:57Z<p>Swinslow: /* Update Parser Libraries for Golang */</p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2019 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Doucments in either RDF or Tag/Value format]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
Beyond working wth 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 (see resources). There is however a weekly call you could join as well. All of the daily work for the Tech team is done on this wiki.<br />
<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
<br />
=SPDX Workgroup Tooling Projects=<br />
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX and increase the accuracy of the SPDX documents.<br />
<br />
==Enhanced Workflow for Online License Request==<br />
Update the SPDX Online Tools license submit feature to support the following workflow:<br />
* License submit can be initiated directly from the UI or through an external application (e.g. the [https://github.com/spdx/spdx-license-diff SPDX License Diff browser plugin]) using a documented API<br />
* License text is compared to the currently approved license list<br />
** If matched, the SPDX ID is returned and the user is informed that the license already exists<br />
* License is compared to all submitted yet not approved licenses<br />
** If matched, the user is informed the license is already submitted and is provided a link to the [https://github.com/spdx/license-list-XML/issues License List XML issue]<br />
* License is compared to all submitted and rejected licenses<br />
** If a match is found, the user is provided a link to the [https://github.com/spdx/license-list-XML/issues License List XML issue]<br />
* License is compared to the existing license list using an algorithm which finds close matches (SPDX License Diff is an example)<br />
** If an existing license is close, a diff view will show the word differences<br />
** The user is presented with a choice of adding an issue for the nearly matching license stating that the license should match<br />
*** If the user chooses to add the issue, the license text will be added to the issue requesting a change to the license XML to allow the match<br />
*** We could also implement suggested XML markup (e.g. alt or optional text) to make the licenses match - NOTE: This may be a technically challenging feature to implement<br />
* If the user wants to submit a new license request, the information is captured and processed by the SPDX legal team through [https://github.com/spdx/license-list-XML GitHub]<br />
<br />
====Skills Needed====<br />
* Development skills in the Python language<br />
* Experience with parser development<br />
* Experience proposing spec changes<br />
* Understanding of Github API's<br />
* Experience in XML parsing<br />
<br />
====Background Information====<br />
The SPDX legal team uses an online request process for new license requests. This feature was implemented by a GSoC student in 2018. Extending the functionality to check for duplicate requests and checking for near matches would greatly improve the efficiency of the license request and approval process.<br />
<br />
This project would require significant interaction with the users of the tool (the SPDX legal team) and would have some interesting technical challenges in storing and matching text. The optional feature of suggesting XML markup for near matches could involve sophisticated matching techniques to find the appropriate text to include as optional or alternate.<br />
<br />
The current SPDX license list request process is documented in the [https://github.com/spdx/license-list-XML/blob/master/CONTRIBUTING.md License List XML contributing page].<br />
<br />
<br />
====Available Mentors====<br />
[mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
==Update Parser Libraries for Golang ==<br />
A new Golang library has recently been added to the SPDX tools, at [https://github.com/spdx/tools-golang]. This tool updated the SPDX Golang libraries to the SPDX 2.1 specification. This tool has several opportunities for improvement and adding features.<br />
====Skills Needed====<br />
* Development skills in the Golang language<br />
* Experience with parser development<br />
* Understanding of RDF and XML<br />
====Background Information====<br />
SPDX currently provides libraries supporting the reading and writing of SPDX documents. A recent new tool has been added for parsing, generating and working with SPDX documents in Golang [https://github.com/spdx/tools-golang]. Opportunities for improving and adding features to this tool include the following:<br />
* adding support for the official RDF format<br />
* experimenting with support for other formats, such as JSON, YAML and XML <br />
* enabling support for parsing and generation of documents under pre-2.1 versions of the SPDX spec<br />
<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
==Additional Format Support for the Python Libraries==<br />
Add the ability to read and write XML, JSON, and YAML formats of the SPDX documents.<br />
<br />
====Skills Needed====<br />
* Development skills in the Python language<br />
* Experience with parser development<br />
* Understanding of XML, JSON and YAML<br />
<br />
====Background Information====<br />
SPDX 2.1 specification supports reading and writing RDF/XML and a tag/value format for SPDX documents. Version 2.2 of the specification will add support for XML, JSON and YAML. The Python libraries currently support reading and writing the RDF/XML and tag/value. This project would extend the parsing and file generation capabilities of the python libraries to include XML, JSON and YAML format. <br />
<br />
The current python libraries are in the [[https://github.com/spdx/tools-python SPDX python tools git repository]]<br />
<br />
====Available Mentors====<br />
[mailto:tetechris20@gmail.com Krys Nuvadga], [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
== Port SPDX license expression library to Ruby, JavaScript and Java==<br />
The [[https://github.com/nexB/license-expression/]|licens_expressionlibrary]] provides comprehensive support license expression using a boolean engine for Python.<br />
The goal of this project is to port and/or package this library for JavaScript, Ruby and Java, considering either code conversion tools, alternative Python implementations (e.g. Jython) or calling Python from another language to bring the same features to these other languages.<br />
====Skills Needed====<br />
* Development skills in Python, Java, Ruby, JavaScript.<br />
<br />
====Background Information====<br />
See https://github.com/spdx/tools-python/issues/10 and https://github.com/nexB/license-expression/<br />
====Available Mentors====<br />
[mailto:pombredanne@nexb.com Philippe Ombredanne]<br />
<br />
=SPDX Specification Projects=<br />
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.<br />
<br />
== SPDX Specification in PDF ==<br />
Generate a version of the specification in PDF based on the markdown version in the SPDX specification repository <br />
====Skills Needed====<br />
* Understanding of documentation tooling<br />
* Familiarity with GIT and github API's<br />
<br />
====Background Information====<br />
The [https://spdx.org/specifications 2.1 SPDX specification] has been moved to markdown on at https://github.com/spdx/spdx-spec<br />
and now generates an HTML version at: https://spdx.github.io/spdx-spec<br />
<br />
We need to find an approach to generate PDF (potential approach to consider at https://github.com/tombensve/MarkdownDoc)<br />
<br />
====Available Mentors====<br />
[mailto:kstewart@linuxfoundation.org Kate Stewart]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
<br />
== SPDX Specification Views for legal counsels and developers ==<br />
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.<br />
====Skills Needed====<br />
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX<br />
====Background Information====<br />
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:<br />
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.<br />
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
<br />
== SPDX Document Generator for projects using SPDXIDs ==<br />
As more projects start to use SPDXIDs at the file level it becomes much simpler to generate SPDX docs for them from a python script. <br />
====Skills Needed ====<br />
* Ability to program in python<br />
====Background Information ====<br />
Forward thinking open source projects are adopting SPDXIDs in source files (initially U-Boot, but now much wider use like Zephyr, Linux Kernel, etc.) <br />
With these easy to find "SPDX-License-Identifier:" strings, generating an SPDX document for a project is a matter of iterating over<br />
the files in a project and extracting the information from these SPDXIDs and calculating checksums. <br />
Creating an open source tool to do this will aid these projects in generating accurate SBOM information at release time.<br />
This tool should be implemented as a command line, so it can be incorporated into builds, and options can be added. <br />
Goal is that projects that use SPDX identifiers can automatically generate a SPDX document as a Software Bill of Materials <br />
(SBOM) on demand (build, release, etc.).<br />
====Available Mentors====<br />
[mailto:kstewart@linuxfoundation.org Kate Stewart]<br />
[mailto:saiudayshankar@gmail.com Uday Shankar]</div>Swinslowhttps://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2019-01-10T19:21:13Z<p>Swinslow: /* Update Parser Libraries for Golang */</p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2019 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Doucments in either RDF or Tag/Value format]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
Beyond working wth 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 (see resources). There is however a weekly call you could join as well. All of the daily work for the Tech team is done on this wiki.<br />
<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
<br />
=SPDX Workgroup Tooling Projects=<br />
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX and increase the accuracy of the SPDX documents.<br />
<br />
==Update Parser Libraries for Golang ==<br />
Update one of the SPDX Golang libraries to the SPDX 2.1 specification. The current implementation in the [https://github.com/spdx/tools-go SPDX git repository] was built for use with version 1.2 of the SPDX specification; the current specification is now at version 2.1, and is a major upgrade from 1.2 including support for relationships between SPDX documents and SPDX elements. <br />
====Skills Needed====<br />
* Development skills in the Golang language<br />
* Experience with parser development<br />
* Understanding of RDF and XML<br />
====Background Information====<br />
SPDX currently provides libraries supporting the reading and writing of SPDX document. Currently, the Java libraries are the only official SPDX tools that support the new SPDX 2.1 specification. The Python libraries and the Golang libraries support version 1.2 of the spec. <br />
<br />
A rewrite of the Golang tools for SPDX 2.1 is in process at [https://github.com/swinslow/spdx-go github.com/swinslow/spdx-go], but does not yet support RDF. The libraries should support both RDF/XML import/export as well as tag/value import/export. The tools should also support newer formats such as JSON and YAML as the SPDX definition for those formats continues to be established.<br />
<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
==Additional Format Support for the Python Libraries==<br />
Add the ability to read and write XML, JSON, and YAML formats of the SPDX documents.<br />
<br />
====Skills Needed====<br />
* Development skills in the Python language<br />
* Experience with parser development<br />
* Understanding of XML, JSON and YAML<br />
<br />
====Background Information====<br />
SPDX 2.1 specification supports reading and writing RDF/XML and a tag/value format for SPDX documents. Version 2.2 of the specification will add support for XML, JSON and YAML. The Python libraries currently support reading and writing the RDF/XML and tag/value. This project would extend the parsing and file generation capabilities of the python libraries to include XML, JSON and YAML format. <br />
<br />
The current python libraries are in the [[https://github.com/spdx/tools-python SPDX python tools git repository]]<br />
<br />
====Available Mentors====<br />
[mailto:tetechris20@gmail.com Krys Nuvadga], [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
== Port SPDX license expression library to Ruby, JavaScript and Java==<br />
The [[https://github.com/nexB/license-expression/]|licens_expressionlibrary]] provides comprehensive support license expression using a boolean engine for Python.<br />
The goal of this project is to port and/or package this library for JavaScript, Ruby and Java, considering either code conversion tools, alternative Python implementations (e.g. Jython) or calling Python from another language to bring the same features to these other languages.<br />
====Skills Needed====<br />
* Development skills in Python, Java, Ruby, JavaScript.<br />
<br />
====Background Information====<br />
See https://github.com/spdx/tools-python/issues/10 and https://github.com/nexB/license-expression/<br />
====Available Mentors====<br />
[mailto:pombredanne@nexb.com Philippe Ombredanne]<br />
<br />
=SPDX Specification Projects=<br />
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.<br />
<br />
== SPDX Specification in MarkDown ==<br />
Migrate the specification from Google docs to GitHub+MarkDown based toolchain capable of generating HTML, PDF and EPUB<br />
====Skills Needed====<br />
* Understanding of documentation tooling<br />
* Web-development skills to style HTML version<br />
====Background Information====<br />
The [https://spdx.org/specifications 2.1 SPDX specification] PDF and HTML version have several issues.<br />
1. Navigation through both document is difficult as a index is missing<br />
2. Switching to GitHub+MarkDown will remove friction for contributors to comment/amend the specification. Common workflow within the OSS community<br />
====Available Mentors====<br />
[mailto:kstewart@linuxfoundation.org Kate Stewart]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:bkuhn@sfconservancy.org Bradley M. Kuhn]<br />
<br />
== SPDX Specification Wiki Examples of Package Managers ==<br />
SPDX specification describes on a high level how to describe package, files and snippets but lack examples how to capture the use of package managers<br />
====Skills Needed====<br />
* Understanding of package managers <br />
====Background Information====<br />
To encourage adoption of SPDX it should be clear how to encode the use of common programming language package managers within SPDX. The aim of this project is to create example per build tool/package manager so that not only as example to the community but also form the input for SPDX tech team discussions and future tooling development<br />
<br />
Initial package managers:<br />
* Bower<br />
* CocoaPods<br />
* Gradle<br />
* gem<br />
* gitmodules<br />
* Maven<br />
* npm<br />
* PyPi<br />
* sbt<br />
* NuGet<br />
<br />
====Available Mentors====<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:stewart@linux.com Kate Stewart]<br />
<br />
== SPDX Specification Views for legal counsels and developers ==<br />
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.<br />
====Skills Needed====<br />
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX<br />
====Background Information====<br />
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:<br />
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.<br />
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:ybronshteyn@blackducksoftware.com Yev Bronshteyn]</div>Swinslowhttps://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2019-01-10T19:17:18Z<p>Swinslow: /* Update Parser Libraries for Golang */</p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2019 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Doucments in either RDF or Tag/Value format]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
Beyond working wth 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 (see resources). There is however a weekly call you could join as well. All of the daily work for the Tech team is done on this wiki.<br />
<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
<br />
=SPDX Workgroup Tooling Projects=<br />
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX and increase the accuracy of the SPDX documents.<br />
<br />
==Update Parser Libraries for Golang ==<br />
Update one of the SPDX Golang libraries to the SPDX 2.1 specification. The current implementation in the [https://github.com/spdx/tools-go SPDX git repository] was built for use with version 1.2 of the SPDX specification; the current specification is now at version 2.1, and is a major upgrade from 1.2 including support for relationships between SPDX documents and SPDX elements. <br />
====Skills Needed====<br />
* Development skills in the Golang language<br />
* Experience with parser development<br />
* Understanding of RDF and XML<br />
====Background Information====<br />
SPDX currently provides libraries supporting the reading and writing of SPDX document. Currently, the Java libraries are the only official SPDX tools that support the new SPDX 2.1 specification. The Python libraries and the Golang libraries support version 1.2 of the spec. A rewrite of the Golang tools for SPDX 2.1 is in process at [https://github.com/swinslow/spdx-go github.com/swinslow/spdx-go], but does not yet support RDF. The libraries should support both RDF/XML import/export as well as tag/value import/export. <br />
<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
==Additional Format Support for the Python Libraries==<br />
Add the ability to read and write XML, JSON, and YAML formats of the SPDX documents.<br />
<br />
====Skills Needed====<br />
* Development skills in the Python language<br />
* Experience with parser development<br />
* Understanding of XML, JSON and YAML<br />
<br />
====Background Information====<br />
SPDX 2.1 specification supports reading and writing RDF/XML and a tag/value format for SPDX documents. Version 2.2 of the specification will add support for XML, JSON and YAML. The Python libraries currently support reading and writing the RDF/XML and tag/value. This project would extend the parsing and file generation capabilities of the python libraries to include XML, JSON and YAML format. <br />
<br />
The current python libraries are in the [[https://github.com/spdx/tools-python SPDX python tools git repository]]<br />
<br />
====Available Mentors====<br />
[mailto:tetechris20@gmail.com Krys Nuvadga], [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
== Port SPDX license expression library to Ruby, JavaScript and Java==<br />
The [[https://github.com/nexB/license-expression/]|licens_expressionlibrary]] provides comprehensive support license expression using a boolean engine for Python.<br />
The goal of this project is to port and/or package this library for JavaScript, Ruby and Java, considering either code conversion tools, alternative Python implementations (e.g. Jython) or calling Python from another language to bring the same features to these other languages.<br />
====Skills Needed====<br />
* Development skills in Python, Java, Ruby, JavaScript.<br />
<br />
====Background Information====<br />
See https://github.com/spdx/tools-python/issues/10 and https://github.com/nexB/license-expression/<br />
====Available Mentors====<br />
[mailto:pombredanne@nexb.com Philippe Ombredanne]<br />
<br />
=SPDX Specification Projects=<br />
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.<br />
<br />
== SPDX Specification in MarkDown ==<br />
Migrate the specification from Google docs to GitHub+MarkDown based toolchain capable of generating HTML, PDF and EPUB<br />
====Skills Needed====<br />
* Understanding of documentation tooling<br />
* Web-development skills to style HTML version<br />
====Background Information====<br />
The [https://spdx.org/specifications 2.1 SPDX specification] PDF and HTML version have several issues.<br />
1. Navigation through both document is difficult as a index is missing<br />
2. Switching to GitHub+MarkDown will remove friction for contributors to comment/amend the specification. Common workflow within the OSS community<br />
====Available Mentors====<br />
[mailto:kstewart@linuxfoundation.org Kate Stewart]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:bkuhn@sfconservancy.org Bradley M. Kuhn]<br />
<br />
== SPDX Specification Wiki Examples of Package Managers ==<br />
SPDX specification describes on a high level how to describe package, files and snippets but lack examples how to capture the use of package managers<br />
====Skills Needed====<br />
* Understanding of package managers <br />
====Background Information====<br />
To encourage adoption of SPDX it should be clear how to encode the use of common programming language package managers within SPDX. The aim of this project is to create example per build tool/package manager so that not only as example to the community but also form the input for SPDX tech team discussions and future tooling development<br />
<br />
Initial package managers:<br />
* Bower<br />
* CocoaPods<br />
* Gradle<br />
* gem<br />
* gitmodules<br />
* Maven<br />
* npm<br />
* PyPi<br />
* sbt<br />
* NuGet<br />
<br />
====Available Mentors====<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:stewart@linux.com Kate Stewart]<br />
<br />
== SPDX Specification Views for legal counsels and developers ==<br />
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.<br />
====Skills Needed====<br />
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX<br />
====Background Information====<br />
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:<br />
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.<br />
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:ybronshteyn@blackducksoftware.com Yev Bronshteyn]</div>Swinslowhttps://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2019-01-10T19:10:15Z<p>Swinslow: /* Update Parser Libraries to SPDX 2.1 for GO */</p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2019 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Doucments in either RDF or Tag/Value format]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
Beyond working wth 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 (see resources). There is however a weekly call you could join as well. All of the daily work for the Tech team is done on this wiki.<br />
<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
<br />
=SPDX Workgroup Tooling Projects=<br />
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX and increase the accuracy of the SPDX documents.<br />
<br />
==Update Parser Libraries to SPDX 2.1 for Golang ==<br />
Update one of the SPDX Golang libraries to the SPDX 2.1 specification. The SPDX 2.1 specification is a major upgrade from SPDX 1.2 supporting relationships between SPDX documents and SPDX elements.<br />
====Skills Needed====<br />
* Development skills in the Golang language<br />
* Experience with parser development<br />
* Understanding of RDF and XML<br />
====Background Information====<br />
SPDX currently provides libraries supporting the reading and writing of SPDX document. Currently, only Java libraries support the new SPDX 2.1 specification. The Python libraries and the Golang libraries support version 1.2 of the spec. The libraries must support both RDF/XML import/export as well as tag/value import/export. The [[https://github.com/spdx/tools-go SPDX git repository]] SPDX Tools project contains the source code for the libraries. <br />
<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
==Additional Format Support for the Python Libraries==<br />
Add the ability to read and write XML, JSON, and YAML formats of the SPDX documents.<br />
<br />
====Skills Needed====<br />
* Development skills in the Python language<br />
* Experience with parser development<br />
* Understanding of XML, JSON and YAML<br />
<br />
====Background Information====<br />
SPDX 2.1 specification supports reading and writing RDF/XML and a tag/value format for SPDX documents. Version 2.2 of the specification will add support for XML, JSON and YAML. The Python libraries currently support reading and writing the RDF/XML and tag/value. This project would extend the parsing and file generation capabilities of the python libraries to include XML, JSON and YAML format. <br />
<br />
The current python libraries are in the [[https://github.com/spdx/tools-python SPDX python tools git repository]]<br />
<br />
====Available Mentors====<br />
[mailto:tetechris20@gmail.com Krys Nuvadga], [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
== Port SPDX license expression library to Ruby, JavaScript and Java==<br />
The [[https://github.com/nexB/license-expression/]|licens_expressionlibrary]] provides comprehensive support license expression using a boolean engine for Python.<br />
The goal of this project is to port and/or package this library for JavaScript, Ruby and Java, considering either code conversion tools, alternative Python implementations (e.g. Jython) or calling Python from another language to bring the same features to these other languages.<br />
====Skills Needed====<br />
* Development skills in Python, Java, Ruby, JavaScript.<br />
<br />
====Background Information====<br />
See https://github.com/spdx/tools-python/issues/10 and https://github.com/nexB/license-expression/<br />
====Available Mentors====<br />
[mailto:pombredanne@nexb.com Philippe Ombredanne]<br />
<br />
=SPDX Specification Projects=<br />
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.<br />
<br />
== SPDX Specification in MarkDown ==<br />
Migrate the specification from Google docs to GitHub+MarkDown based toolchain capable of generating HTML, PDF and EPUB<br />
====Skills Needed====<br />
* Understanding of documentation tooling<br />
* Web-development skills to style HTML version<br />
====Background Information====<br />
The [https://spdx.org/specifications 2.1 SPDX specification] PDF and HTML version have several issues.<br />
1. Navigation through both document is difficult as a index is missing<br />
2. Switching to GitHub+MarkDown will remove friction for contributors to comment/amend the specification. Common workflow within the OSS community<br />
====Available Mentors====<br />
[mailto:kstewart@linuxfoundation.org Kate Stewart]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:bkuhn@sfconservancy.org Bradley M. Kuhn]<br />
<br />
== SPDX Specification Wiki Examples of Package Managers ==<br />
SPDX specification describes on a high level how to describe package, files and snippets but lack examples how to capture the use of package managers<br />
====Skills Needed====<br />
* Understanding of package managers <br />
====Background Information====<br />
To encourage adoption of SPDX it should be clear how to encode the use of common programming language package managers within SPDX. The aim of this project is to create example per build tool/package manager so that not only as example to the community but also form the input for SPDX tech team discussions and future tooling development<br />
<br />
Initial package managers:<br />
* Bower<br />
* CocoaPods<br />
* Gradle<br />
* gem<br />
* gitmodules<br />
* Maven<br />
* npm<br />
* PyPi<br />
* sbt<br />
* NuGet<br />
<br />
====Available Mentors====<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:stewart@linux.com Kate Stewart]<br />
<br />
== SPDX Specification Views for legal counsels and developers ==<br />
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.<br />
====Skills Needed====<br />
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX<br />
====Background Information====<br />
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:<br />
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.<br />
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:ybronshteyn@blackducksoftware.com Yev Bronshteyn]</div>Swinslowhttps://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeasGSOC/GSOC ProjectIdeas2019-01-10T19:06:34Z<p>Swinslow: /* Available Mentors */</p>
<hr />
<div><br /><br />
<br />
<span style="font-size:150%">'''Welcome to the 2019 SPDX Google Summer of Code Project Page'''</span><br />
<br />
See the [https://rtgdk.github.io/spdx-gsoc-proposal.html proposal template] if you are interested in submitting a Google Summer of Code proposal.<br />
<br />
Should you have questions please do not hesitate to contact one of the mentors directly.<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
<br /><br />
<br />
== What is SPDX ? ==<br />
<br />
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.<br />
<br />
As part of this effort we have developed a set of collateral that can be used:<br />
<br />
* [https://spdx.org/using-spdx License List and Short Identifiers]<br />
* [https://spdx.org/using-spdx SPDX Specification for generating SPDX Doucments in either RDF or Tag/Value format]<br />
* [https://spdx.org/tools A set of basic tools for working with SPDX Documents]<br />
* [https://spdx.org/using-spdx License Identifiers in source]<br />
<br />
== Why choose an SPDX Project? ==<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Getting Involved =<br />
<br />
Beyond working wth 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 (see resources). There is however a weekly call you could join as well. All of the daily work for the Tech team is done on this wiki.<br />
<br />
<br />
== Resources ==<br />
<br />
* [http://spdx.org SPDX website]<br />
* [https://spdx.org/specifications SPDX Specification]<br />
* [https://spdx.org/tools SPDX Workgroup Tools webpage]<br />
* [https://lists.spdx.org/mailman/listinfo/spdx-tech SPDX tech mailing list]<br />
<br />
<br />
=SPDX Workgroup Tooling Projects=<br />
These projects are aimed at contributing to the SPDX tools to help reduce the effort to create SPDX and increase the accuracy of the SPDX documents.<br />
<br />
==Update Parser Libraries to SPDX 2.1 for GO==<br />
Update one of the SPDX GO libraries to the SPDX 2.1 specification. The SPDX 2.1 specification is a major upgrade from SPDX 1.2 supporting relationships between SPDX documents and SPDX elements.<br />
====Skills Needed====<br />
* Development skills in the GO language<br />
* Experience with parser development<br />
* Understanding of RDF and XML<br />
====Background Information====<br />
SPDX currently provides libraries supporting the reading and writing of SPDX document. Currently, only Java libraries support the new SPDX 2.1 specification. The Python libraries and the GO libraries support version 1.2 of the spec. The libraries must support both RDF/XML import/export as well as tag/value import/export. The [[https://github.com/spdx/tools-go SPDX git repository]] SPDX Tools project contains the source code for the libraries.<br />
<br />
====Available Mentors====<br />
[mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
==Additional Format Support for the Python Libraries==<br />
Add the ability to read and write XML, JSON, and YAML formats of the SPDX documents.<br />
<br />
====Skills Needed====<br />
* Development skills in the Python language<br />
* Experience with parser development<br />
* Understanding of XML, JSON and YAML<br />
<br />
====Background Information====<br />
SPDX 2.1 specification supports reading and writing RDF/XML and a tag/value format for SPDX documents. Version 2.2 of the specification will add support for XML, JSON and YAML. The Python libraries currently support reading and writing the RDF/XML and tag/value. This project would extend the parsing and file generation capabilities of the python libraries to include XML, JSON and YAML format. <br />
<br />
The current python libraries are in the [[https://github.com/spdx/tools-python SPDX python tools git repository]]<br />
<br />
====Available Mentors====<br />
[mailto:tetechris20@gmail.com Krys Nuvadga], [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
== Port SPDX license expression library to Ruby, JavaScript and Java==<br />
The [[https://github.com/nexB/license-expression/]|licens_expressionlibrary]] provides comprehensive support license expression using a boolean engine for Python.<br />
The goal of this project is to port and/or package this library for JavaScript, Ruby and Java, considering either code conversion tools, alternative Python implementations (e.g. Jython) or calling Python from another language to bring the same features to these other languages.<br />
====Skills Needed====<br />
* Development skills in Python, Java, Ruby, JavaScript.<br />
<br />
====Background Information====<br />
See https://github.com/spdx/tools-python/issues/10 and https://github.com/nexB/license-expression/<br />
====Available Mentors====<br />
[mailto:pombredanne@nexb.com Philippe Ombredanne]<br />
<br />
=SPDX Specification Projects=<br />
The following projects contribute directly to the creation or validation of the SPDX 2.1 specification.<br />
<br />
== SPDX Specification in MarkDown ==<br />
Migrate the specification from Google docs to GitHub+MarkDown based toolchain capable of generating HTML, PDF and EPUB<br />
====Skills Needed====<br />
* Understanding of documentation tooling<br />
* Web-development skills to style HTML version<br />
====Background Information====<br />
The [https://spdx.org/specifications 2.1 SPDX specification] PDF and HTML version have several issues.<br />
1. Navigation through both document is difficult as a index is missing<br />
2. Switching to GitHub+MarkDown will remove friction for contributors to comment/amend the specification. Common workflow within the OSS community<br />
====Available Mentors====<br />
[mailto:kstewart@linuxfoundation.org Kate Stewart]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:bkuhn@sfconservancy.org Bradley M. Kuhn]<br />
<br />
== SPDX Specification Wiki Examples of Package Managers ==<br />
SPDX specification describes on a high level how to describe package, files and snippets but lack examples how to capture the use of package managers<br />
====Skills Needed====<br />
* Understanding of package managers <br />
====Background Information====<br />
To encourage adoption of SPDX it should be clear how to encode the use of common programming language package managers within SPDX. The aim of this project is to create example per build tool/package manager so that not only as example to the community but also form the input for SPDX tech team discussions and future tooling development<br />
<br />
Initial package managers:<br />
* Bower<br />
* CocoaPods<br />
* Gradle<br />
* gem<br />
* gitmodules<br />
* Maven<br />
* npm<br />
* PyPi<br />
* sbt<br />
* NuGet<br />
<br />
====Available Mentors====<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:stewart@linux.com Kate Stewart]<br />
<br />
== SPDX Specification Views for legal counsels and developers ==<br />
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.<br />
====Skills Needed====<br />
* Understanding of compliance needs of legal counsels and developers so we can remove friction to adopt SPDX<br />
====Background Information====<br />
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:<br />
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.<br />
2. Provide legal counsels with a "package and limited file view" to enable legal conclusions<br />
====Available Mentors====<br />
[mailto:swinslow@linuxfoundation.org Steve Winslow]<br />
[mailto:thomas.steenbergen@here.com Thomas Steenbergen]<br />
[mailto:ybronshteyn@blackducksoftware.com Yev Bronshteyn]</div>Swinslowhttps://wiki.spdx.org/view/General_Meeting/Minutes/2018-11-01General Meeting/Minutes/2018-11-012018-11-01T16:02:14Z<p>Swinslow: fixed references to SEVA and license list v3.3</p>
<hr />
<div>* Attendance: 6<br />
* Lead by Phil Odence<br />
* Minutes of Oct meeting approved <br />
<br />
<br />
== Tech Team Report - Kate/Gary ==<br />
<br />
* Spec<br />
** SEVA discussions<br />
*** Looking at fields that we might incorporate<br />
**** Security<br />
**** Evidence<br />
*** Idea is to bring in as a separate section<br />
*** Good Progress<br />
**Some discussions with NTIA Group as well<br />
*** SWID<br />
** May start using the security mailing list soon<br />
* Tooling<br />
** Multiple formats<br />
*** Challenges solves<br />
*** XML, JSON, YAML, Tag value, RDF<br />
** Attention back to updating tooling with spec<br />
** Some concern about file sizes with certain packages/formats<br />
*** May simply be an issue of LOTS of files<br />
** Generating License List <br />
*** Didn’t work perfectly<br />
*** Giving another run<br />
** Updating tooling for license submittal/editing<br />
*** A few bugs need to be worked around<br />
<br />
<br />
== Legal Team Report - Jilayne ==<br />
<br />
* There’s a fair backlog of issues to work through<br />
** Ongoing process<br />
* 3.3 Is out<br />
** Started new practice of release notes<br />
* Tooling and new request system has to be nailed down<br />
** People are going through multiple paths/processes<br />
** Need to standardize<br />
** Tooling is close<br />
*** Need a few more text fields<br />
*** All submissions seem to come from Gary<br />
* License inclusion guidelines<br />
** Inbound request regarding open hardware languages<br />
** Already included open data license<br />
** May need to revisit inclusion guidelines<br />
* OSI discussion about naming issues with SPDX<br />
** Need to find opportunity for better collaboration <br />
<br />
<br />
== Outreach Team Report - All ==<br />
<br />
* Seems to be a lot more use of SPDX in the wild than we are aware of<br />
** How do we run down and catalog?<br />
** Wonder if it’s time for another poll<br />
*** Last poll results: https://spdx.org/sites/cpstandard/files/pages/files/spdx_survey_results_may_2013.zip <br />
<br />
<br />
== Attendees ==<br />
<br />
* Phil Odence, Black Duck/Synopsys<br />
* Kate Stewart, Linux Foundation<br />
* Gary O’Neall, SourceAuditor<br />
* Andrew Katz, Orcro<br />
* Jilayne Lovejoy<br />
* Steve Winslow, LF<br />
<br />
<br />
[[Category:General|Minutes]]<br />
[[Category:Minutes]]</div>Swinslow