You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The important part is that, if the end-user references OpenTelemetry.Instrumentation.Hangfire it automatically brings packages licensed by LGPL/Commercial. This dependency seems to be mandatory to make the instrumentation working correctly.
What is the recommendation in such cases? Can we host/maintains such library? If it is not possible, what is the recommendation for the already published artifacts.
hi @Kielek! in Java, the instrumentation libraries use a "compileOnly" dependency on the instrumented libraries, which avoids this:
if the end-user references OpenTelemetry.Instrumentation.Hangfire it automatically brings packages licensed by LGPL/Commercial
and seems reasonable from a usability perspective since users will only use the instrumentation library if they are already using the instrumented library
in addition to helping us avoid licensing issues, it also helps us avoid CVE issues (since we're not transitively passing those dependencies on to our consumers)
@trask, it will be unusual. I can rise this on .NET SIG. Before we can consider, we should verify what is perspective of CNCF on similar, non-production dependency. See #2558.
OpenTelemetry .NET contrib repository is hosting source code for OpenTelemetry.Instrumentation.Hangfire nuget package.
One of the dependency is Hangfire.Core licensed by double license LGPL v3 License or Commercial License.
The important part is that, if the end-user references OpenTelemetry.Instrumentation.Hangfire it automatically brings packages licensed by LGPL/Commercial. This dependency seems to be mandatory to make the instrumentation working correctly.
What is the recommendation in such cases? Can we host/maintains such library? If it is not possible, what is the recommendation for the already published artifacts.
Detected by the FOSSA scans created by #2574
The text was updated successfully, but these errors were encountered: