Add FOSSology as a (remote) license scanner

[sschuberth]

In order to compare scan results with other scanners, and to be able to continue any existing workflows within FOSSology, it would be nice to use FOSSology's REST API to "upload packages and trigger their scanning".

Note that this might have some overlap with #967 if FOSSology already uses Atarashi internally. In that case it maybe only makes sense to implement either issue.

[sschuberth]

Also see https://github.com/fossology/fossology/wiki/FOSSology-scanners-in-CI.

[sschuberth]

There's a GSoC 2021 project to integrate ORT into FOSSology. The task is a bit fuzzy WRT how exactly the integration should work; it sounds a bit like they're planning to import an ORT analyzer result. But I believe an ORT remote scanner implementation that leverages FOSSology's REST API still would be the technically better solution.

[sameer1046]

fossology/fossology#2140 (comment)

[dgutson]

Hi, any update on this?

[sschuberth]

AFAIK no one from ORT is working on this. I guess some one needs to reach out to the Fossology guys to find out whether something has happened from their side (see above GSoC links).

[dgutson]

@sschuberth if you still think that "an ORT remote scanner implementation that leverages [FOSSology's REST API] still would be the technically better solution" is still relevant, please assign this to @qequ and we will manage this internally and prioritize it.
(regardless of the opposite direction of the integration as proposed in the gsoc)

[sschuberth]

I believe which approach to take depends on the use-case, @dgutson.

In their original project description the FOSSOLOGY people aim "to render the project dependencies created by ort and display those in the fossology-UI".

On the other hand, what I had in mind was to get FOSSOLOGY scan results in ORT.

From ORT perspective, the second is more appealing as ORT can already display dependencies and it would allow to easily compare e.g. ScanCode and FOSSOLOGY scan results, which is something that I know would help at least Bosch's workflow.

Which use case are you interested in @dgutson / @qequ?

[dgutson]

@sschuberth second one, the one you had in mind

[sschuberth]

In probably mid September @mnonnenmacher plans to make the currently experimental new scanner API the default. That's probably a good point to start writing a new (remote) scanner wrapper against the FOSSOLOGY API.

[dgutson]

Ok! Let us know pls. Let's address this then.

[dgutson]

@sschuberth any update on when to address this?

[sschuberth]

I recently learned that FOSSology by now supports ScanCode as a (the default?) scanner. Which means ORT would not get anything back (in terms of scan results) from FOSSology that ORT doesn't already know by running ScanCode itself.

So I'm asking myself again what the purpose of such an integration would be. It's now probably more about pushing information about dependencies to get scanned to FOSSology (in order to continue the workflow in FOSSology) rather than getting scan results from FOSSology back to ORT.

Would you agree, @dgutson? If so, I guess now is as good a time as any to start working on this.

[dgutson]

Sorry @sschuberth I'm not sure I'm following you. So what benefit can ORT get by sending it to fossology if in the end both run the same scanner?

[dgutson]

Unless you are suggesting this to use fossology, which is not my use case.
If this doesn't bring any benefit for ORT-only users, I think we can close this issue.

[sschuberth]

Indeed, I do not see a general benefit for ORT users that don't already use FOSSology. My subordinate idea was to help people who already use FOSSology in their process, and who want to get ORT's data into FOSSology. That, however, is a different use-case than the original "use FOSSology as a license scanner" topic. So I'm closing this given that there's probably no scanner in FOSSology that's better than what ORT is already able to use.