Clarify distribution of dependency license texts

[florianl]

With https://github.com/open-telemetry/opentelemetry-ebpf-profiler/pull/137 a discussion started on how to best follow the license requirements and distribution for 3rd party licenses.

Should every Open Telemetry repository store and provide all the licence texts for its respective dependencies?

At the moment, the majority for OTel repository does not store and provide the licence texts for its dependencies (e.g. https://github.com/open-telemetry/opentelemetry-collector, https://github.com/open-telemetry/opentelemetry-java, https://github.com/open-telemetry/opentelemetry-go, https://github.com/open-telemetry/opentelemetry-operator and others), while some OTel repositories host the license texts for their dependencies (e.g. https://github.com/open-telemetry/opentelemetry-go-instrumentation/).

Related:

• https://github.com/open-telemetry/opentelemetry-collector/pull/2604
• https://github.com/open-telemetry/opentelemetry-collector-releases/issues/364

[trask]

hey @florianl, does https://github.com/cncf/foundation/blob/main/recommendations-for-attribution.md#scope-and-nature-of-dependencies answer your question?

[austinlparker]

The GC looked at the linked PR and found the document that @trask linked -- we are not lawyers, but it does seem like the use case here would be a Type 3 situation. Hopefully the guidance there is helpful, although please let us know if our interpretation is incorrect.

[florianl]

Thanks for your answer. I did come along https://github.com/cncf/foundation/blob/main/recommendations-for-attribution.md#scope-and-nature-of-dependencies and Use case 3: Build-time dependency as well, before opening this issue.

For this use case it is said:

In this case, it is necessary that the redistributed version of the built artifacts also comply with the
attribution requirements contained in the licenses for those redistributed dependencies.

In some cases, the language or packaging ecosystem may automatically result in the built artifacts
containing the complete source code of those dependencies, including copyright notices and license
texts. For these situations, the license attribution requirements may automatically be handled where
that source code and relevant notices are included as a part of the built artifacts.

Taking https://github.com/open-telemetry/opentelemetry-collector as an example: This project has some build-time dependencies. The license text of these dependencies is not part of the artifact provided with https://github.com/open-telemetry/opentelemetry-collector/releases/tag/v0.108.1 nor are the licenses of build-time dependencies part of the artifacts distributed with https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/v0.108.0 - specifically checked https://github.com/open-telemetry/opentelemetry-collector-releases/archive/refs/tags/v0.108.0.zip and https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.108.0/otelcol_0.108.0_linux_amd64.tar.gz.

Is https://github.com/open-telemetry/opentelemetry-collector (and maybe others) not compliant with CNCF?

Overall, I'm looking for guidance for https://github.com/open-telemetry/opentelemetry-ebpf-profiler/pull/137: Do license texts of build-time dependencies need to be part of the repository or is it fine to bundle them in some kind of artifact, if there is a release of the project?

[trask]

Is https://github.com/open-telemetry/opentelemetry-collector (and maybe others) not compliant with CNCF?

cc @open-telemetry/collector-approvers

[jpkrohling]

We've discussed this in the past, here: https://github.com/open-telemetry/opentelemetry-collector/issues/7371

In short: yes, we should be including it, but we never got around actually doing it, especially as attribution can be done in other ways. We do have SBOMs, which could be used for this, but apparently, the license is not being detected correctly for most of the dependencies (cc @cpanato).