Change license from Apache-2.0 to MIT or BSD

[rochdev]

Is your feature request related to a problem? Please describe.

The Apache-2.0 license is basically non-existent in the Node and JavaScript communities. Most projects use MIT and some commercial vendors prefer to use the slightly more strict BSD family of licenses. There are almost no JS projects using Apache-2.0. This could result in issues since most of the community won't know the implications, which could result in confusion at best and in scaring people off at worst.

Describe the solution you'd like

We should go with a more permissive and less invasive license. Basically the most permissive possible given any restrictions from CNCF. I personally propose using MIT which is used by probably over 99% of community-driven Node and JavaScript projects.

Describe alternatives you've considered

Additional context

I don't know why Apache-2.0 was used and maybe there is a good reason. If that's the case, it should be well explained why the choice was to use such a restrictive license.

[SergeyKanzhelev]

@caniszczyk can you please help with this? Is there some write up in CNCF already regarding the licenses?

[draffensperger]

What are the restrictions that Apache-2.0 has that MIT would not? (I confess to not being as familiar with the nuances of these licenses as I probably should be)

[rochdev]

I'm no expert either, but the one that comes to mind is to have to add the copyright to every file in the project, and in any other projects who want to use those files. This is unnecessary noise and would generally be used to protect copyright for a vendor. Since this work is community-driven and attribution cannot be given to any single vendor, it renders such attribution mostly useless.

As I also mentioned above, it's also really non-standard in the Node community, which tends to be more open than some other languages. This fact is even listed on https://choosealicense.com/community/.

In general, I would use MIT if there is not a strong reason to do otherwise. If there is such a reason, it needs to be documented appropriately. "CNCF says to use Apache" is not a valid reason either.

[SergeyKanzhelev]

"CNCF says to use Apache" is not a valid reason either.

It kind of is as CNCF helps us make intellectual property vendor neutral and protect it. As well as protecting users of this project.

I'm not against MIT as it is recommended license for Microsoft OSS. I think MS will be happier if it's MIT, but perfectly fine with Apache. I know Google is opposite and they like Apache license more. And there might be reasons why CNCF recommends Apache.

As for code attribution - why is it a bad thing? Even with MIT I see people do attribution of code to make it easier for whoever reads code. See this for example:

https://github.com/dotnet/corefx/blob/2e6661d4cceeff2549b0299ec54e9f3b34c09b20/src/Common/src/CoreLib/Internal/IO/File.Unix.cs#L1-L3

[caniszczyk]

Yes, see: https://www.cncf.io/blog/2017/02/01/cncf-recommends-aslv2/

The CNCF IP Policy is clear, Apache-2.0:
https://github.com/cncf/foundation/blob/master/charter.md#11-ip-policy

There are no implications since Apache-2.0 and MIT/BSD are permissive in spirit and there are no issues really combining them.

[danielkhan]

AFAIK, the attribution is not a must criterion but best practice.
Besides that, Apache-2 has some wording on patents but the general opinion by lawyers is, that the same is true for MIT implicitly.

[SergeyKanzhelev]

@rochdev do you have more questions or feedback? Is there any implications to DataDog w.r.t. contributions or your customers with the current license that CNCF can help resolve?

If not - I'd suggest to close the issue. I will post the license link to Community readme page.

[rochdev]

There are no implications for Datadog. This is a personal observation that the Node community is much more comfortable with MIT/ISC/BSD. My point is that there should be a reason for using a specific license and no valid reason was provided so far. This is especially true when there is an implication on a per-file basis.

In general, I feel the CLA requirement will already discourage many contributors, especially for small fixes, but adding an unknown license to the mix will just make things worse by upping the barrier to entry.

Do we have a strategy to ensure that the license is automatically added to every file? My understanding is that pre-commit hooks cannot be committed.

[draffensperger]

I think it would be cool for the npm run test command to check for the right license preambles similar to lint checks and for npm run fix to not only properly format code (Prettier via gts, fix TSLint, etc.) but also to add the necessary license boilerplate. That could be explained in the contributing guide and could be part of the CI build with a nice explanation for the contributor to just run npm run fix on their branch.

Maybe we could use https://www.npmjs.com/package/license-check-and-add or adapt it in some way?

[rochdev]

Is there a way to actually fail linting if license headers are not present? I think it would be even better if this can simply be handled by the linter. I know it's possible to write extensions for ESLint, but I don't know if TSLint has similar functionality.

It also sounds like the license header could be a lot smaller.

My preference still goes to not needing this in the first place.

[draffensperger]

Per that linked convo, it seems like the header may be required? I found it annoying and also wished we didn't need it - but if it can at least be a 1-liner that would be great.

We may be in luck on the TSLint side, see https://palantir.github.io/tslint/rules/file-header/

[rochdev]

That's great news! A one liner and this rule would definitely be a lot less painful. I think for a first iteration this works.

[rochdev]

Are there any organization contributing to OpenTelemetry who actually prefer Apache-2.0 and can give some more context why?

[danielkhan]

I think we should stick to apache 2 because

1. the header is a may and not a must
2. CNCF recommends it
3. The CLA also reflects very much of the Apache 2 license (like patents) - so if someone is fine with the CLA they will also be fine with the license
4. Many developers have to add some header to their code and there are lots of tools for each IDE
5. This has only to be done once for every new file
6. The rest oft OpenTelemetry will likely stick to Apache 2 as well
7. Many larger projects like k8s use it as well and it's fine for them

As Dynatrace, we recommend Apache 2.0 for our own projects but we don't mind for contributions.

[rochdev]

Please note that I'm answering the above for completeness only. If we can automate the license with the linter and reduce the header to a one liner or remove it completely I'm fine with closing this issue.

1. the header is a may and not a must

We should confirm this, but it seems to be the case according to open-telemetry/community#113 (comment)

2. CNCF recommends it

We should not blindly follow recommendations from CNCF especially if they conflict with the community and actual requirements (which no one seems to be able to describe)

3. The CLA also reflects very much of the Apache 2 license (like patents) - so if someone is fine with the CLA they will also be fine with the license

I agree with this. The CLA is definitely much more painful than the license in any case.

4. Many developers have to add some header to their code and there are lots of tools for each IDE

This is not something that is setup for Node/JavaScript engineers since this type of license is non-existent in the community. It would however be mitigated by having this automation as part of the linter.

5. This has only to be done once for every new file

Which is exactly the point I'm making.

6. The rest oft OpenTelemetry will likely stick to Apache 2 as well

I don't know what are the standard licenses in other languages. I think this is only correct because CNCF enforces Apache which probably shouldn't be the case. If you look at the history of OpenTracing, almost only Java was Apache until someone enforced a change to all the repositories.

7. Many larger projects like k8s use it as well and it's fine for them

This is on a completely different scale, and also not in JavaScript.

As Dynatrace, we recommend Apache 2.0 for our own projects but we don't mind for contributions.

Unless you use mostly Node internally, Dynatrace is not representative of the Node community.

[rochdev]

One interesting thing I've noticed in the article above is the mention that Apache-2.0 is roughly equivalent to BSD+CLA. Does this mean we could remove the CLA?

I'm really just trying to reduce the barrier to entry since it may happen that at some point our users will need to contribute to OpenTelemetry.

[caniszczyk]

@rochdev The CNCF IP Policy requires Apache-2.0, it's baked in the charter and everyone agrees to and understands: https://github.com/cncf/foundation/blob/master/charter.md#11-ip-policy

Please tell me how this "conflict with the community" ? - where does it say that all JS projects must use MIT/BSD?

[danielkhan]

Please note that I'm answering the above for completeness only. If we can automate the license with the linter and reduce the header to a one liner or remove it completely I'm fine with closing this issue.

1. the header is a may and not a must

We should confirm this, but it seems to be the case according to open-telemetry/community#113 (comment)

To apply the ALv2 to a new software distribution, include one copy of the license text by 
copying the file:

http://www.apache.org/licenses/LICENSE-2.0.txt

into a file called LICENSE in the top directory of your distribution. 
If the distribution is a jar or tar file, try to add the LICENSE file 
first in order to place it at the top of the archive. 
This covers the collective licensing for the distribution.

In addition, a correct NOTICE file MUST be included in the same 
directory as the LICENSE file.

Each original source document (code and documentation, 
but excluding the LICENSE and NOTICE files) ***SHOULD*** include a 
short license header at the top. If the distribution contains documents 
not covered by CLA, CCLA or Software Grant (such as third-party libraries) 
then see the policy guide.

Source: http://www.apache.org/dev/apply-license.html
There is nothing to confirm - it's part of the license.

1. CNCF recommends it

We should not blindly follow recommendations from CNCF especially if they conflict with the community and actual requirements (which no one seems to be able to describe)

How exactly does it conflict with the community?
Can you make a case about any part of the license that you doubt would work with the community?

1. Many developers have to add some header to their code and there are lots of tools for each IDE

This is not something that is setup for Node/JavaScript engineers since this type of license is non-existent in the community. It would however be mitigated by having this automation as part of the linter.

This is really a minor ask and how many contributors really add a new file compared to editing an existing one going forward?

1. The rest oft OpenTelemetry will likely stick to Apache 2 as well

I don't know what are the standard licenses in other languages. I think this is only correct because CNCF enforces Apache which probably shouldn't be the case. If you look at the history of OpenTracing, almost only Java was Apache until someone enforced a change to all the repositories.

And all of OpenCensus is Apache 2.0. Plus it's a CNCF standard.

1. Many larger projects like k8s use it as well and it's fine for them

This is on a completely different scale, and also not in JavaScript.

I don't understand this argument.

As Dynatrace, we recommend Apache 2.0 for our own projects but we don't mind for contributions.
Unless you use mostly Node internally, Dynatrace is not representative of the Node community.

I was saying that we don't mind. So I was actually not objecting against your point from a Dynatrace perspective.

[rochdev]

There is nothing to confirm - it's part of the license.

Missed that, thanks for clarifying.

How exactly does it conflict with the community? Can you make a case about any part of the license that you doubt would work with the community?

All I'm saying is this is not a license that is usually used for JavaScript projects, which may be confusing to contributors if they don't know the implications. Please note that this was based on the assumption that the header is mandatory, which it's not. By automatically adding the header, this concern is also invalidated.

This is really a minor ask and how many contributors really add a new file compared to editing an existing one going forward?

Very valid point. Once the API has stabilized, there will probably be a lot more improvements compared to any new files.

And all of OpenCensus is Apache 2.0. Plus it's a CNCF standard.

Other than the fact they enforce it, this is irrelevant. Taking a sample from only a few foundations doesn't represent the JavaScript landscape. Even Node itself is MIT.

I don't understand this argument.

You are taking as an example a project that is under CNCF (so it's forced to be Apache), in a different language, and on a completely different scale (over 50,000 stars and 2,000 contributors).

Please tell me how this "conflict with the community" ? - where does it say that all JS projects must use MIT/BSD?

It's a de facto standard but is not enforced.

As a said above, if we have proper mitigations in place I'm fine with using Apache-2.0. I'm just not a fan of using something just because it's enforced, especially when it's different than the de facto standard that everyone else is used to. I would love to be convinced otherwise with a real world argument of what benefits this license is actually bringing to the project.

In any case, let's stop arguing and talk about action items:

• Can we reduce the header size? If so let's open an issue to do it. In its current state it's too much noise. A header should not take more place than the code in a file.
• It looks like we can automate the header with TSLint which is perfect. Let's open an issue to do that.

Then let's put this issue to rest since it looks like an issue I should probably bring to the CNCF instead.

[rochdev]

We discussed this a bit at today's SIG meeting and basically we can leave this issue open with 2 action items:

• Add TSLint rule to enforce Apache headers in every file. (Add TSLint rule to enforce Apache headers in every file #43)
• Discuss with CNCF to make licensing more flexible. This will probably take a lot of time.

If anyone has any explicit requirements for Apache-2.0 at their company and can provide the reasoning why they need it, please share and the issue can then be closed.

[SergeyKanzhelev]

@rochdev I suggest to go from opposite and find more justifications not to require Apache-2.0. Single license across projects makes life of vendors and big end users easier. Less legal work to do.

I'm not sure what kind of "blocking argument" you are seeking for. And I'm not sure any company legal team will completely block any other license or openly comment on all the implications they "perceive" as dangerous for company portfolio with other licenses.

Just my couple cents. It is good to seek for clarity and more reasoning you can find and share - the better for the project.

[mayurkale22]

Closing this as per https://github.com/open-telemetry/community#license, feel free to open again if you disagree.