Community: How to handle MIT licence

[bogdandrutu]

Hi GC members, we are blocked by an issue related to attributions and MIT license. Can you give us feedback about how to handle this? See https://github.com/open-telemetry/opentelemetry-collector/pull/1622

[SergeyKanzhelev]

this is the direct link to the conversation:

https://github.com/open-telemetry/opentelemetry-collector/pull/1622#discussion_r483713783

@bogdandrutu do we need to have a reference to this code (external dependency), copy of the code (like vendoring), copy and modification?

@caniszczyk should we file a support ticket in attlassian or just mentioning you here is enough =)?

[tigrannajaryan]

I think we had a similar issue in the past: https://github.com/open-telemetry/community/issues/305 and the guidance was that there should not be vendor-specific authoring comments (if I understand correctly).

[SergeyKanzhelev]

@tigrannajaryan it would be helpful if you can give more details on what needs to happen specifically. Yes, our position was to strip the copyright if this is the question about contributing code from another repository. The only qq would be how it will play with CLA - ideally the author of code needs to do it. In any case, more details on what needs to happen would be useful

[tigrannajaryan]

@SergeyKanzhelev let me have a look and post what I find here.

[maxgolov]

We have the same question in C++ SDK. There is a contribution that we may integrate from MSFT (HTTP client implementation for C++). But the code is MIT-licensed. Just strip the copyright - won't work.

[tigrannajaryan]

Disclaimer: I am not a lawyer.

Here is my understanding of the situation.

A contributor wants to submit a PR with a code which includes a copy of this https://github.com/uber-go/automaxprocs/blob/master/internal/cgroups/cgroup.go code that is MIT licensed and is copyright of Uber.

To comply with the requirements of MIT license the contributor needs to retain the copyright notice in the copy. They correctly did that by keeping the notice as-is in this file that is part of the PR.

The contributor in this case is not the author of the original code so they cannot delete the notice and choose to relicense the source code. The copyright notice must remain. (this makes it different from the previous case which I linked above and where the contributor was the original author and was free to relicense the source code as they wish).

Again, my understanding is that in this case the copyright notice cannot be deleted.

However, in _addition_ to the original copyright and notice we can include our own copyright and notice. Here is an answer for the exact same situation when MIT work is used in an Apache licensed work: https://opensource.stackexchange.com/a/7391

Relevant portions:

Always keep any existing copyright and license notices intact.
If you made non-trivial changes, you may add your own copyright and license notices.

It is customary to order notices in reverse chronological order so that the newest information is at the top.

When the project is under both the MIT and Apache license, then it is sufficient to call your project Apache 2 licensed: the terms of the Apache license are a superset of the MIT license terms. However, you still have to keep any existing MIT license notices intact.

Based on this I believe what we can do is have the regular OpenTelemetry copyright notice at the top of cgroup.go file, followed by MIT copyright notice, followed by the source code.

However, before moving forward we at OpenTelemetry need to decide if it is acceptable for us to have a contribution that contains such notice. My understanding is that it is legal to for the contributor to make such contribution and it is legal for us to accept it. I do not know whether it is _desirable_ for us and whether it complies with the _spirit_ of vendor neutrality that OpenTelemetry aims for. It also possibly opens up a can of worms when people can include their own names (or their company names) in every file they add just because they are (rightfully) the original author of the code.

If we decide that it is acceptable to keep original copyright notice I would suggest to only allow it when the code copy being contributed is a third-party code and when the contributor is not the author and hence has no power to relicense it (which is true in this particular case). We should not allow contributors who are original authors of the code to include their names in copyright notices to avoid proliferation of copyright notices solely for the purpose of promoting a person's or a corporation's name.

[jpkrohling]

I do not know whether it is desirable for us and whether it complies with the spirit of vendor neutrality that OpenTelemetry aims for. It also possibly opens up a can of worms when people can include their own names (or their company names) in every file they add just because they are (rightfully) the original author of the code.

Completely agree with @tigrannajaryan in general. However, and perhaps because I'm someone directly affected by this, I think we could have a few exceptions in place: code with the copyright assigned to another open source project, and under the same license, should be allowed to still have the copyright assigned to the original project (and perhaps, with dual copyright, if we have modifications).

[tigrannajaryan]

Let's have a decision on this. We have several issues now blocked on this.

I posted my recommendation that unblocks and allows to move forward. Does @open-telemetry/governance-committee believe that this needs to be vetted additionally, possibly with a lawyer?

[bhs]

Going back to @SergeyKanzhelev's comment:

@caniszczyk should we file a support ticket in attlassian or just mentioning you here is enough =)?

... we haven't heard from Chris, so I think we ought to file a CNCF Legal support ticket about this. I share @tigrannajaryan's desire for a decision. I haven't personally weighed in because "I'm not a lawyer" and am continually surprised by the nuances of how software licenses work and do-not-work, so don't feel qualified to make a decision (or even really have much of an opinion, aside from the fact that I want to see this resolved soon, too).

I filed a request just now: https://cncfservicedesk.atlassian.net/servicedesk/customer/portal/1/CNCFSD-529

Unfortunately it's not publicly-visible, but this is what it says:

[tigrannajaryan]

Looking at CNCF recommendation here: https://github.com/cncf/foundation/blob/master/copyright-notices.md#what-about-third-party-code I believe my recommendation matches it.

They say:

If a file only contains code that originates from a third party source who didn't contribute it themselves, then you would not want to add the notices above. (In a similar vein, you wouldn't add a notice identifying you as the copyright holder either, if you didn't own it.) Just preserve the existing copyright and license notices as they are.

This means if the new file is a literal copy of a third-party code then you keep the third-party code as-is with its own copyright notice. There is not need to also include the OpenTelemetry's copyright notice.

If, however, you add copyrightable content to a pre-existing file from another project, then at that point you could add a copyright notice similar to the one above.

This means if you make any modifications to the the third-party code you _prepend_ the file with OpenTelemetry's copyright notice.

You should not change or remove someone else's copyright notice unless they have expressly permitted you to do so. This includes third parties' notices in pre-existing code.

This means we should not delete the MIT license copyright notice.

[caniszczyk]

sorry github notifications is useless for me, servicedesk is better, we document things here:

https://github.com/cncf/foundation/blob/master/copyright-notices.md#dont-change-someone-elses-notice-without-their-permission

[caniszczyk]

In short, preserve copyright notices

[bhs]

Okay. So: if there are non-trivial changes, prepend the OTel copyright notice and preserve the prev one. If there are no changes, just keep the old one.

I consider that decided unless someone objects in the next 24h – the guidance in the cited file above is clear, I just hadn't seen it. 🙈

PS: Chris, no worries about GH notifications! I can only imagine...

[tigrannajaryan]

This adds the relevant link to our contribution guidelines: https://github.com/open-telemetry/community/pull/479

[tigrannajaryan]

There is one more important section in the CNCF link:

What if I want my copyright notice included?
Please note that it is not wrong, and it is acceptable, if a contributor wishes to keep their own copyright notices on their contributions. The above is a recommended format for ease of use, but is not mandated by CNCF.

My concern above was that this may not be fully aligned with our vendor-neutrality stance, but I believe CNCF has a significant experience running projects like ours, so I am happy to accept this recommendation.

[SergeyKanzhelev]

There is one more important section in the CNCF link:

What if I want my copyright notice included?
Please note that it is not wrong, and it is acceptable, if a contributor wishes to keep their own copyright notices on their contributions. The above is a recommended format for ease of use, but is not mandated by CNCF.

My concern above was that this may not be fully aligned with our vendor-neutrality stance, but I believe CNCF has a significant experience running projects like ours, so I am happy to accept this recommendation.

When vendors contribute code they typically own it to re-license. So let's put recommendation to re-license when possible. I agree that keeping copyrights may lead to concerns.

[jpkrohling]

My concern above was that this may not be fully aligned with our vendor-neutrality stance, but I believe CNCF has a significant experience running projects like ours, so I am happy to accept this recommendation.

I don't think I would have a problem in seeing a source code with (c) Lightstep and OpenTelemetry Authors and another one with (c) Splunk and OpenTelemetry Authors or (c) Jaeger and OpenTelemetry Authors. I really don't think it alone means that a code is tied to a vendor in any way. In fact, I would probably think the project is in a healthy state, with multiple vendors collaborating towards a common goal.

[SergeyKanzhelev]

@jpkrohling what do you think about this PR: https://github.com/open-telemetry/community/pull/479 It has reference on reasoning to use a single copyright when possible. I all boils down to extra burden with a little benefit.

For example, this thing "Adding many different copyright notices may increase the burden on downstream distributors, if their license compliance processes involve reproducing notices" resonates with some big vendors and there were feedback about it in the past.

If the way it formulated here https://github.com/open-telemetry/community/pull/479 is ok, let's keep it as a recommendation.

[jpkrohling]

For example, this thing "Adding many different copyright notices may increase the burden on downstream distributors, if their license compliance processes involve reproducing notices" resonates with some big vendors and there were feedback about it in the past.

I believe that the linked PR is certainly OK. Imagine that we have a code for was originally written for a project that we have no representatives, say, Apache SkyWalking, which is licensed under Apache 2.0. It's wrong on many levels to remove them from the copyright notices...

An example closer to home is tracegen (open-telemetry/opentelemetry-collector-contrib#956): it was developed originally by someone (not me, probably @yurishkuro) for the Jaeger Project. Even though I'm a maintainer on the Jaeger project, I have no rights to remove the copyright notices from that code when building a similar tool for OpenTelemetry. My options are to either start a tracegen from scratch (certainly influenced by its design) and don't credit it at all, or fork it and give credit where credit is due ;-)

Note how I used only open source projects in my examples, which is to stress that having external influences while developing open source code isn't a bad thing: if you have code originally coming from Microsoft, Lightstep or Splunk, it's better to show this influence than to hide it. What is bad is to have code that was written with only one vendor in mind, or worse, code that works with only one vendor (commercial or not).

[SergeyKanzhelev]

@bogdandrutu I believe the PR that just got merged helps with the guidance on initial question. Closing, please re-open if you still have questions.