To make onboarding easier there should be documentation which describes the trail coming from user stories (what do I want/need to do) to capabilities of the different functional building blocks of the big picture (e.g. License & copyright scanner) and to a concrete instances of tools which implement the capabilities (this will also be a good base to identify needed glue code and/or APIs to be implemented in the concrete tools)

It would be great to have in the FAQ (or even README.md) how this differs from other similar programmes, like e.g.:

• OpenChain
• Open Compliance Program
• Copyleft.org

The entire repo shall be organzised in a way that new members can be onboarded very quickly and they find easily "what is this all about", "what is there", "what is currently in work", "what is next".

The data model shall be extended to cope with not yet evaluated licenses aka. unknown licensess

rework the statement in regard to FOSSology the project is not dedicated to FOSSology.
It should be more a goal to collect a Database of all known licenses :-)

The existing repo shall be restructed in a way that it focuses on the tooling aspect. This means that the directories "Good-Practices", "OSS-Package-Analysis-Files", "OSS-license-compliance-resources" and the file FAQ shall be removed from the repo andshall be placed in another Repo of the Open-Source-Compliance group (this repo has to be set up with a nice name.
@mcjaeger ; @sgustafsson ; @shanecoughlan ; @misappi ; @blaumeiser-at-bosch ; @heliocastro ; @HansMKern ; @zvr

please comment

Even on a screen 1080p high, the list of tools in the menu of this page is too long. On my screen, "OSS Discovery by OpenLogic" is the last item I can fully see.

I am not sure how this can be achieved, but ideally the menu should be scrollable as well or be organised in two columns.

Data types which are most probably company specific shall be separated from the model and be modeled in a way that companies can easily implement their own policies.
Examples of comapny policy data types are:
Risk level := Enumeration { 1,2,3,4,5 }
criticality := Enumeration {0,1,2,3,4,5}

better wording one way to go instead of solution

We need to define clear rules, which specify under which conditions our logo can be used.
@zvr @misappi @blaumeiser-at-bosch @mcjaeger and others please comment and provide input

Process contributions
we want to provide a platform
we do not provide support tools
Clear hint that everybody is invited to contribute

A nice webpage shall be created, so that internet surfers can find the page and learn what aim this project has and perhapy motivate the visitors to contribute to the project.
In order to do that the content at least of the Readme.md has to be changed in the first step. Others will follow

it would be great if the picture
https://github.com/Open-Source-Compliance/Sharing-creates-value/blob/master/Tooling-Landscape/Unanimous-Understanding/OSS_Tooling_Landscape_UML_Comp.vsdx
is converted to a format that can be read / write by publicly available free of charge tools.
Please comment @misappi , @mcjaeger

As recently discussed in Brussels, I would like to suggest to add REUSE to the (by the way great!) tooling landscape graphic.

I think the project is a solution for some of the described areas. For example:

• Inbound: REUSE compliant software greatly improves the reuasbility of its code.
• Compliance checker
• Component Analysis Service
• CI/CD
• FOSS Compliance Artefact Generator (reuse spdx for a BoM)
• License & Copyright Scanner (searching for license identifiers and copyright statements)
• Outbound: if the resulting shared/published code is REUSE compliant, the inbound for another party is also much easier to understand with regard to licensing and copyright

The package provides Commands for Manipulating POSIX Access Control Lists.
The project homepage is http://savannah.nongnu.org/projects/acl

Hi,
I did a comparison between the glossary of the tooling landscape (TL) and the terminology around tooling of the OpenChain project (OC). I propose the following changes in the glossary (I can to the changes, but first I would like to discuss that in the community):

• "Component Analysis Service" -> "Component Scanner".
  This tool scan software (source code or binaries) to identify the contained (open source) components. OC distinguishes between binary scanners and source code scanners. IMO, we do not need to make this distinction in the TL. In the TL we should IMO distinguish between the identification of contained components and the identification of the corresponding licenses (OC does this, TL didn't do it so far).

For documentation purposes I list additional differences between the TL and OC terminology below. I do not think that we should keep the TL terminology in these cases but want to document this decision:

Thanks,
Michael

[Meta Level]
This issue is used as example for potential collaboration in our regular meeting.
Steps:

• go to the file
• go to the code
• go to the line
• click on the 3 dots and
• click "Reference in new issue"
• add your issue comment

[Content Level]
I would appreciate to have a collection of examples in the description. That would help to get familiar with the capabilities.
In this special case I would list at least

• the OSS Review Toolkit Analyzer (https://github.com/oss-review-toolkit/ort#analyzer)
  Hint: also with other tools, the naming of the overall tool would potentially be too vague so that the detailed sub-feature/component would need to be referred to, to have the correct capability mapping. A naming convention like [Overall Tool Name]/[Sub Component/Function] may be helpful

Dear Tooling Community,

at SAP we are working on an Open Source strategy, incorporating enhancements to the established Open Source Vulnerability Management. We aim to achieve qualities assurance (security and maintenance) and proactive prevention of vulnerabilities by supporting tools:

• Automated risk rating for developers indicating the “well-being” of a community and its artifacts
• Hardening of a component based on the usage in the application
• Monitoring external threat landscape for an increasing risk of public CVE advisories
• Regular update notifications to the developers

We would like to share and exchange with the security community. I see that Tooling Group primarily focus on license but picks up some security-related tool guidance. ClearlySecure community may be an alternative but a) their focus seems to be on particular projects and b) the project seems to be in a very early state.
Would Tooling Group be the right place to bring up the discussion?

Michael