Legal: Copyright notice

[pellared]

Most of OTel repositories are using dependencies with licenses (e.g. MIT, Apache-2.0) that AFAIK require a copywrite notice. I am not sure if any OTel repository has any copywrite notice file.

Should the repositories contain a NOTICE file (which is even mentioned in the Apache-2.0 license text)?

Reference: https://infra.apache.org/licensing-howto.html

Side question: Do we have any requirements regarding OTel repositories?

PS. I am not a lawyer 😉

[pellared]

Scott K Peterson (a member of the Red Hat legal team) writes here that:

As to copyright notices, it is difficult to justify investing in maintaining copyright notice details. But some people may expect notices to be present. As to the "origin of the software," perhaps it would be more useful and more accurate to simply refer to the project, rather than attempt to capture something more fine-grained.

I think that this issue is good to close, but I just want to make sure we have a common agreement among OTel repositories.

PTAL @open-telemetry/governance-committee

[dyladan]

We may be able to autogenerate these in many cases. For example we should be able to generate a NOTICE file from the lockfiles in node.

[yurishkuro]

I'd expect the orgs that care about supply chain to use automated tools that scan dependencies, which would be way more comprehensive than any manually-written NOTICE file. Curiously, Apache policy 1 says "_ if _ the Work includes a "NOTICE" text file as part of its distribution...", i.e. doesn't say that it must include it.

[pellared]

I'd expect the orgs that care about supply chain to use automated tools that scan dependencies, which would be way more comprehensive than any manually-written NOTICE file. Curiously, Apache policy 1 says "_ if _ the Work includes a "NOTICE" text file as part of its distribution...", i.e. doesn't say that it must include it.

But the dependency (aka "Work") may have it

[trask]

hey @pellared!

Most of OTel repositories are using dependencies

I think there's an important distinction between usage and redistribution, here's a couple of examples from the OTel Java world that may help:

Usage example: The OTel Java OTLP JSON Logging Exporter uses the 3rd party JSON library com.fasterxml.jackson.core:jackson-core, but does not embed/redistribute it. End users must download the 3rd party JSON library themselves (typically via their package manager). And so in this example we don't need to pass along the 3rd party's LICENSE or NOTICE files.

Redistribution example: The OTel Java agent embeds all of its dependencies, and so it does redistribute com.fasterxml.jackson.core:jackson-core, and so we do need to pass along its LICENSE and NOTICE files.

[pellared]

@trask Thanks. Yes, you are right and the examples are correct 👍

I had a conversation with Splunk's legal team. Below is the summary.

1. Regarding @yurishkuro comment

The fact that a downstream user should scan the code DOES NOT remove the obligation to provide copyright/license notifications required by many OSS licenses. Apache 2.0, in the clause right before the clause that I cited here states:

You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Work".

Providing the copyright attribution and license notice is NOT optional if you want to distribute/contribute the code.

2. What requires notices

Any 3rd party code that is included in a submission to OTel should be given attribution per the terms of the corresponding license. This includes 3rdy party code that is:

A) copied into the repository;

B) distributed (embedded) in object/compiled form.

Many of the OTel components are distributed as packages or binaries (which are object/compiled forms of distribution).

3. NOTICE file

The use of the NOTICE file to provide notice is just one option.

CC @open-telemetry/governance-committee

[yurishkuro]

Sometimes stupid reasons produce stupid solutions. Here's one stupid solution:

NOTICE file

(1) The dependencies for this project are listed in pom.xml 
(2) All copyright, patent, trademark, and attribution notices from these dependencies are hereby incorporated.

(1) - attribution
(2) - notices included

(not a lawyer)

[trask]

I had a conversation with Splunk's legal team

just as an fyi, the CNCF service desk also provides legal services. the @open-telemetry/governance-committee members are able to open CNCF service desk tickets on behalf of the OpenTelemetry community.

[dyladan]

2. What requires notices

Any 3rd party code that is included in a submission to OTel should be given attribution per the terms of the corresponding license. This includes 3rdy party code that is:

A) copied into the repository;

B) distributed (embedded) in object/compiled form.

Many of the OTel components are distributed as packages or binaries (which are object/compiled forms of distribution).

Does this include distributions like JS, ruby, python, and others which don't actually include their dependencies in the distributed package, but instead a manifest (package.json in case of node.js) which instructs the package manager where to go to get the dependency? In this case we're not actually distributing the dependency right?

edit: am I also correct in assuming this would not apply to any development-only dependencies like the test suite, linters, and related tooling which is not needed to run OTel on end-user production systems?

[pellared]

Does this include distributions like JS, ruby, python, and others which don't actually include their dependencies in the distributed package, but instead a manifest (package.json in case of node.js) which instructs the package manager where to go to get the dependency? In this case we're not actually distributing the dependency right?

AFAIK it does not include it as the dependencies are not embedded. Meaning, these distributions do not contain "compiled" code of those dependencies.

EDIT: Without deep analysis I think it affects the "releases" of the following repositories:

• https://github.com/open-telemetry/opentelemetry-collector
• https://github.com/open-telemetry/opentelemetry-collector-contrib
• https://github.com/open-telemetry/opentelemetry-java-instrumentation
• https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation
• https://github.com/open-telemetry/opentelemetry-go-instrumentation

edit: am I also correct in assuming this would not apply to any development-only dependencies like the test suite, linters, and related tooling which is not needed to run OTel on end-user production systems?

Correct.

[trask]

@pellared do you think this issue is sufficiently answered/discussed and can be closed? thx!

[pellared]

I do not think so. Personally, I think that the releases from these repositories should include copywrite and license notices. I let the @open-telemetry/governance-committee to figure it out how to address the issue.

[trask]

https://github.com/open-telemetry/opentelemetry-java-instrumentation releases already include license and notice files from 3rd party dependencies that are redistributed.

@open-telemetry/collector-maintainers @open-telemetry/collector-contrib-maintainer @open-telemetry/dotnet-instrumentation-maintainers @open-telemetry/go-instrumentaiton-maintainers can you review this issue and comment how you are managing license and notice files for 3rd party dependencies which you are redistributing (if any)? thx!

[pellared]

Regarding https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation I have created open-telemetry/opentelemetry-dotnet-instrumentation#1706 which was planned for 1.0.0-rc milestone during SIG meeting.

[pellared]

Addressed for .NET Automatic Instrumentation: open-telemetry/opentelemetry-dotnet-instrumentation#2134

[jpkrohling]

I have opened a ticket with the CNCF to clarify our legal requirements (CNCFSD-1647).

[TylerHelmuth]

It is possible that the operator and its images need to be considered in this issue.

[jpkrohling]

There hasn't been an update to the ticket yet, probably because folks are focused on KubeCon, but I pinged them and will post an update here as soon as I have it.

[TylerHelmuth]

It is also possible that the opentelemetry-demo images need to be considered.

[jpkrohling]

I pinged the CNCF helpdesk again, still waiting.

[pellared]

@jpkrohling Still no update?

[jpkrohling]

I still didn't get an official answer from Legal (the ticket is still open), but I did hear back from @caniszczyk. Excerpt:

in short, the answer is generally yes, you need to include the NOTICE file in distributed binaries per Apache license

I would work with the assumption that we should provide attribution and that including the NOTICE file is the preferred way to go.

[trask]

I would work with the assumption that we should provide attribution and that including the NOTICE file is the preferred way to go.

@pellared does this answer your question/concern?

[pellared]

@trask This is confirming that we can follow https://infra.apache.org/licensing-howto.html when distributing binaries. Do you think that we need to describe it e.g. under CONTRIBUTING.md as part of this issue? If not then I think that this issue can be closed.

I also created open-telemetry/opentelemetry-collector-releases#364. In my opinion all other repositories are already compliant with the licensing and copywrite requirements.

[trask]

I'm not sure if we should specifically recommend https://infra.apache.org/licensing-howto.html, since that page is about requirements for Apache Software Foundation projects, which are stricter in some cases than the requirements of the Apache License itself.

Though I do really like that page's sections on bundling.

I can try sending a PR to https://github.com/cncf/foundation introducing a new page bundling-third-party-dependencies.md, based on the ASF bundling sections, if that sounds like a good resolution?

[jpkrohling]

It would be great to have that information available publicly, @trask. I think it's a good idea.

[pellared]

@trask @jpkrohling I agree. I am closing this issue.