Support Maven(?) scopes

[jerrinot]

It's OK to have a certain license as a build-time only dependency.

Think of a benchmark harness under a GPL license: We only use it during a build/testing time and we never distribute it / our product does not depend on it. So as long as it stays as a build-time only dependency only it's OK and it should not have been reported.

However I am reluctant to whitelist/ignore this dependency/license because if someone accidentally change the scope of this dependency then it won't be reported at all and this would lead to a compliance issue.

[4rokis]

@jerrinot That's for this issue.

You are correct. We should not include "dev" issues in the results.

[4rokis]

@jankoritak Removing Web App label. This is core issue

[4rokis]

:heavy_check_mark: NPM :heavy_check_mark: YARN :heavy_multiplication_x: PIPENV :heavy_multiplication_x: MAVEN

[4rokis]

Pipenv issue has separate issue as there might be another issue #187

[jankoritak]

I see, so the problem is exclusive to Pip and Maven. Let's focus the Maven part within this thread, in order to address @jerrinot's issue.

We can deal with Pip separately.

[4rokis]

If i understand it correctly from https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

You can have 6 scopes (compile, provided, runtime, test, system, import). Only test scope is not included in the product itself. So test scope should not be included in the license dependency tree.

@jerrinot Can you please confirm that this is correct?

[jerrinot]

@S4n60w3n It depends. Usually you do not want to include libraries in a test test scope in compliance checks. but this depends on a license.

It's probably fine for GPL as you typically don't distribute test code. but imagine a testing library with a license which says: "Everything this testing library touches belongs to me. Deal with it. :trollface:"

Then you do not want to use this library even in a test scope and you want a compliance check to fail when it encounters this library under any scope.

The other scopes are similar. The provided scope is probably fine for many vendors - as it's typically not the vendor who distributes these libraries. but in some cases you want to run compliance checks even for these scopes.

[4rokis]

@jerrinot Thanks for clarification. Ill update it so for now we have is consistent with npm and yarn. And ill create new issues with the

It's probably fine for GPL as you typically don't distribute test code. but imagine a testing library with a license which says: "Everything this testing library touches belongs to me. Deal with it. "

As it requires more input

[4rokis]

Proper support for dependency scopes #189