https://wiki.spdx.org/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=20&offset=&namespace=0&username=&tagfilter=SPDX Wiki - New pages [en]2024-03-29T12:40:39ZFrom SPDX WikiMediaWiki 1.23.13https://wiki.spdx.org/view/Canonicalisation_CommitteeCanonicalisation Committee2022-04-06T14:19:09Z<p>Seabass: Add page for the Canonicalisation Committee</p>
<hr />
<div>The Canonicalisation Committee is a group within SPDX dedicated to creating a canonical serialisation format for the upcoming SPDX 3.0 specification, enabling SPDX data to be shared and combined whilst ensuring data integrity.<br />
<br />
There are several key opportunities for SPDX 3.0: the ability to verify the integrity of individual Elements independent of a containing document, multiple equivalent serialisation formats<br />
capable of round-trip conversion, and a clearly demarcated split between SPDX's information model and data models.<br />
<br />
All of these opportunities hinge on having a canonical serialisation format: a representation of SPDX data that is never ambiguous and is unaffected by stylistic or platform-specific concerns.<br />
As such, the SPDX Canonicalisation Committee will be dedicated to:<br />
<br />
* Writing a specification for a canonical serialisation format for SPDX 3.0 data.<br />
<br />
* Determining processes for Element-level integrity and signing.<br />
<br />
* Making recommendations to the [[Technical_Team | SPDX Tech Team]] about potential ambiguities found in the information model that might inhibit canonicalisation.<br />
<br />
The Canonicalisation Committee's discussions are currently held on the [https://lists.spdx.org/g/Spdx-tech SPDX Tech Team mailing list] (send an email to <code>spdx-tech+subscribe@lists.spdx.org</code> to subscribe).</div>Seabasshttps://wiki.spdx.org/view/GSOC/PastProjectIdeasGSOC/PastProjectIdeas2022-02-07T14:36:12Z<p>Zvr: Created page with "Past year Project Ideas for GSoC projects = 2021 = ==SPDX Workgroup Tooling Projects== These projects are aimed at contributing to the SPDX tools to help reduce the effort..."</p>
<hr />
<div>Past year Project Ideas for GSoC projects<br />
<br />
= 2021 =<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 />
=== Migrate SPDX Online Tools to DJango3 ===<br />
Migrate the SPDX online tools to later versions of Django and upgrade dependencies (such as Django Social Auth) to later version to support better / more secure authentication to Github. In addition to migrating to DJango 3, additional issues can be taken on to create a full GSoC project (see the list below).<br />
<br />
====Skills Needed====<br />
* Experience with Python3 programming<br />
* Familiar with Django framework<br />
<br />
====Background Information====<br />
The SPDX Online Tools are currently being migrated to Python3. Several libraries can now be upgraded to more supportable versions including DJango. There are some known issues with the current version of Django Social Auth which would be resolved by upgrading the versions. There may be additional libraries which can be upgraded. There is also an opportunity to improve the structure and unit tests for the online tools if time allows. See the [https://github.com/spdx/spdx-online-tools/tree/rtgdk_python3 Python3 Branch] of the SPDX online tools for the current state of the Python3 migration.<br />
<br />
Additional tasks and issues can can be included in a project (in priority order):<br />
* Migrate project to python3 and Django3 [https://github.com/spdx/spdx-online-tools/issues/58 issue 50] and [https://github.com/spdx/spdx-online-tools/issues/24 issue 24]<br />
* [https://github.com/spdx/spdx-online-tools/issues/287 Merge app and api code]<br />
* Fix and improve test [https://github.com/spdx/spdx-online-tools/issues/201 issue 201] [https://github.com/spdx/spdx-online-tools/issues/282 issue 282], [https://github.com/spdx/spdx-online-tools/issues/202 issue 202] + others<br />
* [https://github.com/spdx/spdx-online-tools/issues/299 Add a submit via mail functionality to license submittal]<br />
* [https://github.com/spdx/spdx-online-tools/issues/218 Store license diff screenshot in database instead of uploading to github]<br />
* [https://github.com/spdx/spdx-online-tools/issues/157 Improve error message when error received from the Java code]<br />
* [https://github.com/spdx/spdx-online-tools/issues/186 Add a License Diff section to the SPDX Online Tool]<br />
* [https://github.com/spdx/spdx-online-tools/issues/91 API documentation tool]<br />
* API for license namespace <br />
* [https://github.com/spdx/spdx-online-tools/issues/204 Move to Github Apps and improvement for production]<br />
<br />
====Available Mentors====<br />
[mailto:rohit.lodhartg@gmail.com Rohit Lodha] [mailto:anshuldutt21@gmail.com Anshul Dutt Sharma] [mailto:gary@sourceauditor.com Gary O'Neall]<br />
<br />
=== Migrate Python Tools to Python 3 ===<br />
Migrate the [https://github.com/spdx/tools-python SPDX Python Tools] to Python 3 including all unit testing. In addition, additional known issues raised on GitHub may be tackled.<br />
<br />
====Skills Needed====<br />
* Experience with Python3 programming<br />
* Knowledge of parsing algorithms<br />
<br />
====Background Information====<br />
The Python tools are command-line tools and a library that implement reading and writing of SPDX files in different formats, as well as converting and validating SPDX files.<br />
The current implementation uses Python 2, which is no longer supported.<br />
In addition to migration, some additional tasks may be taken on to improve the supportability of the library. In particular, restructuring the code to separate out the different serialization formats (see [https://github.com/spdx/tools-python/issues/147 issue 147]).<br />
<br />
====Available Mentors====<br />
[mailto:santiago@nyu.edu Santiago Torres Arias] [mailto:alexios.zavras@intel.com Alexios Zavras] [mailto:anshuldutt21@gmail.com Anshul Dutt Sharma]<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 />
=== YAML Support for Golang libraries ===<br />
YAML is one of the supported formats for SPDX. This project is to add support for reading and writing YAML to the Golang libraries.<br />
<br />
====Skills Needed====<br />
* Knowledge of YAML<br />
* Skills in YAML 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 />
=== 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 specification.<br />
<br />
=== Generate a JSON Representation of the Specification from Structured Markdown ===<br />
Convert a consistently structured Markdown file into a JSON structure following a well defined schema. Changes to an existing Markdown file should update the JSON files. The Markdown will have a well defined structure to allow for translation of the text in Markdown to the properties of the JSON file. The conversion will also validate that the Markdown follows the required specification. The conversion would be run as part of a Github action for the SPDX specification.<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 Markdown and JSON 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. The conversion will be in 2 stages:<br />
* Convert from Markdown to an intermediate JSON format<br />
* Convert from the JSON format to RDF/OWL<br />
<br />
The specific schema for the JSON format is under development and planned to be available before the start of GSoC.<br />
<br />
Below are some additional resources for this project:<br />
* [https://github.github.com/gfm/ GitHub flavored Markdown]<br />
* [https://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]<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://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)<br />
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)<br />
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)<br />
<br />
====Available Mentors====<br />
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]<br />
<br />
=== Generate RDF/OWL from from JSON specification format ===<br />
Convert a set of JSON files into a Web Ontology Language XML document. The JSON file will map to the elements and attributes of the RDF/OWL XML file. The JSON schema will be defined prior to the project start and will be consistent with the "Generate a JSON Representation of the Specification from Structured Markdown" project described above.<br />
<br />
====Skills Needed====<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 JSON parsers<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. The conversion will be in 2 stages:<br />
* Convert from Markdown to an intermediate JSON format<br />
* Convert from the JSON format to RDF/OWL<br />
<br />
The specific schema for the JSON format is under development and planned to be available before the start of GSoC.<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://json-schema.org/ JSON Schema] information site and its [https://tools.ietf.org/html/draft-bhutton-json-schema-00 current draft]<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://docs.google.com/document/d/1LN5CepVVOu38w4pXeLpw_3BDNn2CKAWUyTVdlh8C2WM/edit?usp=sharing Template for Spec Markdown] (work in progress)<br />
* [https://docs.google.com/document/d/1J6P3q6wcP0c1xquTIfMfIBJCa8S1xtkhDs6dD1hSf4Y/edit?usp=sharing Example spec JSON file] (work in progress)<br />
* [https://docs.google.com/document/d/1OF_EqfU4tLPF-oGheEZ1aCzsnGIJHyRptzQ_U7AA-wY/edit?usp=sharing Draft JSON schema] (work in progress)<br />
<br />
====Available Mentors====<br />
[mailto:gary@sourceauditor.com Gary O'Neall] [mailto:alexios.zavras@intel.com Alexios Zavras]<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]<br />
<br />
= 2019 =<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].</div>Zvrhttps://wiki.spdx.org/view/General_Meeting/Minutes/2021-12-02General Meeting/Minutes/2021-12-022021-12-07T15:25:03Z<p>Podence: </p>
<hr />
<div>* Attendance: 33<br />
* Lead by Phil Odence<br />
* Minutes from last approved<br />
<br />
* Phil will company membership announcement before end of week<br />
* We will be move General Meeting minutes to GitHub and crowdsource during meetings.<br />
<br />
== Microsoft and SPDX - Adrian/Steve ==<br />
<br />
* Microsoft standardizing on SPDX [Adrian Giglio]<br />
** Why SPDX?<br />
*** On ISO standard path<br />
*** Already participating<br />
*** Great group<br />
** Why build their own tool?<br />
*** Already had tooling<br />
*** Easy to move to SPDX<br />
*** Needed certainty to meet NTiA standards<br />
*** Utilize MS Detection<br />
*** Needed a great range of environments<br />
*** Support for very large, complex build systems; layered builds<br />
** The Tool<br />
*** Built on .Net and available for Windows/Linux/Mac<br />
*** Available as build step in Azure<br />
*** Plan is to open source<br />
*** Pulls OSS data from a variety of build system formats<br />
** Future<br />
*** Proving by early March, then rolling out across Microsoft<br />
*** Exploring different methods of SBOM distribution including web portal<br />
*** Exploring signing with others in the industry<br />
<br />
* MCR Distributing SPDX SBoMs for Microsoft content [Steve Lasker]<br />
** How to distribute secured supply chain components? Specifically SBOMs<br />
** Supply chain artifact challenges:<br />
*** artifacts get promoted across environments, including production assets getting pulled from the Internet into restricted networks<br />
*** private virtual networks within cloud infrastructure<br />
** Solution: Validation artifacts need to travel together with the supply chain objects<br />
*** by default, SBOM might get blocked from being accessed due to "airgapped" / VNet setup<br />
*** instead, create a private registry within each vnet; with shared internal registry hosting all artifacts + SBOMs, then promoted into each vnet<br />
** ORAS: need signatures to be separable, verifiable, able to be validated, prior to bringing artifact / binary into the environment<br />
*** Microsoft built this for Azure Container Registry, but customers share with other registries and other infrastructure; registries should be a broader standard => OCI Artifacts, ORAS Artifacts<br />
*** Signatures and SPDX SBOMs get attached to the graph<br />
*** ACR support for ORAS Artifacts today => customers can store SPDX SBOMs today: https://aka.ms/acr/supply-chain-artifacts<br />
** Opportunity: having SPDX document travel alongside the target artifact; CLI that can natively push / pull / validate SPDX SBOMs to Registries<br />
** What does the SPDX community want to see in an SBOM?<br />
*** recording EULA text?<br />
*** something validated at the time the content is used? => needs to be accessible along with the artifact itself<br />
<br />
* Questions/Comments<br />
** Dick: what about having vulnerability disclosures together as a part of the distributed info?<br />
*** Appreciate that the SPDX structure enables describing all the pieces of what went into a software build in the first place => static information at a point in time<br />
*** Scan results are things that you learn about over time => e.g. might learn later about a problem that was discovered after it was shipped<br />
*** Scan results will continue to be additive, whereas the SBOM itself doesn't change<br />
*** Dick: some vendors are running scans and producing NVD reports together with vendor's findings; making that info available together with the SBOM. During customer risk assessments, they can see beforehand if a CVE is reported => if shows up in the disclosure, that helps address the risk.<br />
*** Scan results, etc., could be attached to the other documents that are included in the registry<br />
*** Eventually, looking to have a web-browsable portal to easily access these documents. But, the automation is the interesting part.<br />
** Just this morning, this was announced to be becoming part of an OCI working group; previously getting proven within the ORAS project<br />
** Sebastian: Ostree (Fedora): https://fedoraproject.org/wiki/Changes/OstreeNativeContainer<br />
** Signature format: shipped in Notary v2, but working on expanding via conversations with the broader community. Needs to be able to be validated broadly.<br />
** Dick: NIST workshop that took place this week: ability to distribute SDLC evidence and policy data. Will that be part of this?<br />
*** Viewing this as plumbing / core infrastructure, in a generic way; new types will emerge for what types of artifacts are used to be deployed / promoted on this infrastructure<br />
*** Because it's generic / abstracted, any new type can be hosted on this infrastructure<br />
<br />
<br />
== Tech Team Report – Kate/Gary/Others ==<br />
* Tools<br />
** New release of SPDX Java Tools available at https://github.com/spdx/tools-java/releases/tag/v1.0.3<br />
* Specification<br />
** Focused on the Core modeling<br />
** Made progress on collections, packages, and document definitions and relationships<br />
** Significant testing of the model with different use cases and serialization considerations<br />
<br />
<br />
== Legal Team Report - Jilayne/Pau/Steve ==<br />
* License List version 3.15 was released and published to https://spdx.org/licenses on Nov. 14<br />
* Shortened month for meetings due to Thanksgiving holiday in US<br />
* Warner Losh presented to the team about FreeBSD's use of SPDX short-form license identifiers: https://docs.google.com/presentation/d/1mRWj7DCiicK57BqD4XzUMSZs51TpUUIYIgI-UcB8XDw/edit#slide=id.p<br />
<br />
== Outreach Team Report - ==<br />
* No update, but Sebastian sent an email to the General Meeting list with notes on behalf of the team.<br />
<br />
<br />
== Attendees ==<br />
<br />
* Phil Odence, Black Duck/Synopsys<br />
* Adrian Digli, Microsoft<br />
* Steve Lasker, Microsoft<br />
* Sebastian Crane<br />
* Steve Winslow, Boston Technology Law<br />
* Dick Brooks, REA<br />
* Rich Steenwyk, GE Healthcare<br />
* Annie <br />
* Brad Goldring, GTC<br />
* Jeff Schutt, Cisco<br />
* David Edelsohn, IBM<br />
* Jilayne Lovejoy, Red Hat<br />
* Aveek Basu, NextMark Printers<br />
* Marc Gisi, Windriver<br />
* Gary O’Neall, SourceAuditor<br />
* Philippe Ombrédanne- nexB<br />
* Dick Brooks<br />
* Alex Rybek<br />
* Brend Smits, Philips<br />
* Christopher Lusk, Lenovo<br />
* Christopher Phillips<br />
* Fellow Jitser<br />
* Jilayne Lovejoy, Red Hat<br />
* Mashid<br />
* Kendra Morton<br />
* Marco<br />
* Majira<br />
* Michael Herzog- nexB<br />
* Mike Nemmers<br />
* Molly Menoni<br />
* Paul Madick, Jenzabar<br />
* Rose Judge, VMWare<br />
* Vicky Brasseur, Wipro<br />
<br />
<br />
[[Category:General|Minutes]]<br />
[[Category:Minutes]]</div>Podencehttps://wiki.spdx.org/view/General_Meeting/Minutes/2021-11-04General Meeting/Minutes/2021-11-042021-11-11T20:57:59Z<p>Podence: Created page with "* Attendance: 25 * Lead by Phil Odence * Minutes from last approved * Company membership mechanics will be rolled out within a couple weeks. == GSOC - Ujjwal == * JSON Su..."</p>
<hr />
<div>* Attendance: 25<br />
* Lead by Phil Odence<br />
* Minutes from last approved<br />
<br />
* Company membership mechanics will be rolled out within a couple weeks.<br />
<br />
<br />
== GSOC - Ujjwal ==<br />
<br />
* JSON Support for Golang libraries<br />
<br />
== Tech Team Report - Kate/Gary/Others ==<br />
<br />
* Tools <br />
** no update<br />
* Specification<br />
** Spec version compatible with ISO, now available<br />
* Version 3<br />
<br />
* Most of the work is focused on the core model. We’re making progress but still have a ways to go to settle on a good code the other profiles will be built on.<br />
* A new repo has been setup for the SPDX 3.0 spec since it will have a different way of generating the examples and spec and will also be under the new license as part of the new governance we put in place<br />
* We expect more activities on the profiles next month, especially security<br />
* Interest in the spec and tools continues to increase – we’re seeing some good signs of adoption from companies, other open source projects, and individuals (if you need more detail – SW360 is engaged in some issues conversations on the tools, the SPDX 2.1 spec issues has some new contributor)<br />
<br />
== Legal team update - Jilayne/Pau/Steve ==<br />
* FreeBSD will be adopting SPDX tags<br />
* Fedora is exploring as well<br />
* Conversations about adding better instructions on using Git to contribute to license repo<br />
<br />
== Outreach team - Sebastian ==<br />
* Processes<br />
** Transitioned to monthly meeting<br />
** Different ways of working in between under discussion<br />
* Wikipedia page updates<br />
** Adding history<br />
* Adding logos of companies and projects that are using<br />
<br />
<br />
== Attendees ==<br />
<br />
* Phil Odence, Black Duck/Synopsys<br />
* Ujjwall Agarwal<br />
* Alexios Zavras, Intel<br />
* Eric Billingsley, Calculi<br />
* Jeff Schutt, Cisco<br />
* Sebastian Crane<br />
* Bob Martin, Mitre<br />
* Steve Winslow, Boston Technology Law<br />
* Christopher Lusk, Lenovo<br />
* David Edelsohn, IBM<br />
* Jilayne Lovejoy, Red Hat<br />
* Tony Aiuto<br />
* Karan Marjara, AWS<br />
* Joshua Marpet, RM-ISAO<br />
* Paul Madick, Jenzabar<br />
* Adrian Diglio, Microsoft<br />
* Alfredo Espinosa<br />
* Brad Goldring<br />
* Edgar<br />
* Joe<br />
* Vicky Brasseur, Wipro<br />
* Warner Losh, FreeBSD<br />
* Fellow Jitser<br />
* Aasim, Microsoft<br />
<br />
<br />
[[Category:General|Minutes]]<br />
[[Category:Minutes]]</div>Podence