-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Legal: Copyright notice #1280
Comments
Scott K Peterson (a member of the Red Hat legal team) writes here that:
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 |
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. |
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 |
This comment was marked as outdated.
This comment was marked as outdated.
hey @pellared!
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 Redistribution example: The OTel Java agent embeds all of its dependencies, and so it does redistribute |
@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 commentThe 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:
Providing the copyright attribution and license notice is NOT optional if you want to distribute/contribute the code. 2. What requires noticesAny 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 fileThe use of the NOTICE file to provide notice is just one option. CC @open-telemetry/governance-committee |
Sometimes stupid reasons produce stupid solutions. Here's one stupid solution:
(1) - attribution (not a lawyer) |
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. |
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? |
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:
Correct. |
@pellared do you think this issue is sufficiently answered/discussed and can be closed? thx! |
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. |
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! |
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. |
Addressed for .NET Automatic Instrumentation: open-telemetry/opentelemetry-dotnet-instrumentation#2134 |
I have opened a ticket with the CNCF to clarify our legal requirements (CNCFSD-1647). |
It is possible that the operator and its images need to be considered in this issue. |
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. |
It is also possible that the opentelemetry-demo images need to be considered. |
I pinged the CNCF helpdesk again, still waiting. |
@jpkrohling Still no update? |
I still didn't get an official answer from Legal (the ticket is still open), but I did hear back from @caniszczyk. Excerpt:
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? |
@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. |
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 |
It would be great to have that information available publicly, @trask. I think it's a good idea. |
@trask @jpkrohling I agree. I am closing this issue. |
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 😉
The text was updated successfully, but these errors were encountered: