Different licenses

[pavolloffay]

What license should be used for OpenTracing? Apache 2.0/MIT?

• https://github.com/opentracing/specification/blob/master/LICENSE Apache 2.0
• https://github.com/opentracing/opentracing-ruby/blob/master/LICENSE Apache 2.0
• https://github.com/opentracing/opentracing-java/blob/master/LICENSE Apache 2.0
• https://github.com/opentracing/opentracing-python/blob/master/LICENSE MIT Uber
• https://github.com/opentracing/opentracing-javascript/blob/master/LICENSE MIT
• https://github.com/opentracing/opentracing-go/blob/master/LICENSE MIT OT
• https://github.com/opentracing/opentracing-objc/blob/master/LICENSE MIT OT
• https://github.com/opentracing/opentracing-cpp/blob/master/LICENSE MIT OT
• https://github.com/opentracing/opentracing-csharp/blob/master/LICENSE MIT OT

[wu-sheng]

Look like Apache VS MIT. ：） Definitely, both are good enough for me. Maybe Apache is a little bit better. After all, it is up to @bhs and @yurishkuro

[bhs]

In general I think it makes sense to use the license that will minimize risk/friction for the given language's community. As a default, I like ASF2.0 because it is the most industry-friendly.

In my primitive understanding, MIT license brings slightly more indemnity/IP risk, though in recent high-profile cases (Oracle vs Google) I think it's been shown that a pure API is not protected IP, at least in the US.

PS: this is definitely not strictly up to @bhs and @yurishkuro! We should have a voice, but so should everyone.

[wu-sheng]

IMO, the spec repo stays in Apache 2.0, that is good enough for me. The language's community should have more freedom. The I am not familiar with the IP risk about MIT license.

Don't know enough details about Oracle vs Google in Java APIs, I assume. @bhs maybe, you can give me some background stories?

[bhs]

@wu-sheng the Oracle vs Google thing is not really very relevant, I was just thinking out loud about how IP is not really a concern for pure APIs. Here's more detail if you're curious: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.

(TL;DR: the conventional wisdom is that the Android team created Dalvik when Sun owned Java, and Sun was fine with it. Oracle then devoured Sun and thought it would be a nice opportunity to be characteristically evil and try to extract billions of dollars from Google. Honestly a preposterous lawsuit, but so it goes.)

PS: this video is a :100: rant about Oracle if anyone wants some light entertainment :)

[pavolloffay]

In general I think it makes sense to use the license that will minimize risk/friction for the given language's community.

This is a reasonable answer. First, I'm not an expert in this area... I thought that as it is one project it should use the same license. Maybe what is little bit odd is that python's license mentios Uber there.

[yurishkuro]

Uber header is an artifact of the python implementation being originally written as Uber project (https://github.com/uber-archive/opentracing-python), where I was required to include it. Now that it has moved to OT org, it would be appropriate to add another header on top saying OT Authors, like the rest of the repos. I am not even sure it's necessary to keep Uber header since the API is quite different.

[bhs]

Yeah, I would like to add OpenTracing to the authors. If it's kosher to remove Uber entirely, let's do that, too, since it's misleading at this point. Yuri, do you know what the "rules" are around those sorts of changes/removals?

[pavolloffay]

+1 JS does not mention OT either.

[yurishkuro]

@bhs I'm fairly sure we can add The OT Authors at the top. I don't know if we can remove the Uber header, I am following up with our legal.

[cwe1ss]

This was mentioned in yesterday's OTSC call and according to that, all projects should use the Apache license. Is this already final? Can I just change the license in opentracing-csharp (by copying the license file from Java) or do I have to do anything special?

Also, does this really require the license info at the top of all files?

/cc @tedsuo

[bhs]

@cwe1ss he license headers are not necessary (as I understand it) though are a best practice in some cases.

I think the procedure is roughly as follows:

1. Create a PR that changes the LICENSE file to be ASF
2. Explicitly cc every GH user who has made changes in the past and give a 7d warning
3. Assuming there are no objections, merge the PR after 7d

I'm (almost) sure nobody will mind. The only thing I can imagine people getting upset about is moving from GPL to something non-GPL... but MIT->ASF is no biggie for this sort of project (at least as I understand it).

[wu-sheng]

License headers are not necessary, but it is a traditional. Prefer to change all file headers if already exist headers about MIT.

[cwe1ss]

Here's the PR for the license change in opentracing-csharp: https://github.com/opentracing/opentracing-csharp/pull/65

[eirinikos]

Hi all, @bhs and I have been discussing the issue of updating the licensing for all of OpenTracing's projects. (I will take a cue from Christian's (@cwe1ss) opentracing-csharp update and update each README). Here's the process I'm planning to undertake:

For each project:

• delete LICENSE file and replace it with LICENSE-APACHE and LICENSE-MIT files (these will be sourced from rust-postgres-macros)
• update the README file
• identify every GitHub user who has previously made changes to the repo
• CC these users to notify them of new licensing, giving them a 7-day window to air any objections
• [have an admin] merge the PR after 7 days if there are no objections

This is how I'll prioritize the projects:

• opentracing-go
• all other OpenTracer APIs (11 total)
• BasicTracer projects (4 total)
• remaining repos: specification, documentation, opentracing.io
• I see that contrib points to the opentracing-contrib meta repo; @bhs do we want or need to update the licensing for these opentracing-contrib repos?

I'm going to get started shortly. In the meantime, let me know if you have any feedback or suggestions - thanks!

[yurishkuro]

Sounds good, except for

delete LICENSE file and replace it with LICENSE-APACHE and LICENSE-MIT files

The convention is to have a single LICENSE file per repository, GitHub even recognizes it and puts an icon in the top right corner. I suggest simply updating the content of the LICENSE file with Apache version, in a PR that tags other contributors to the repo (although the latter can be done via an issue first).

Note that in addition to the license file, the headers in the source files should also be replaced. Here's an example of this in Jaeger: https://github.com/jaegertracing/jaeger/pull/391

these will be sourced from rust-postgres-macros

not sure I follow - the official Apache license is http://www.apache.org/licenses/LICENSE-2.0, and the simplest way to get the official plain text version is to create a new GitHub repo and select Apache-2 as the license, the file will be created automatically.

[eirinikos]

The convention is to have a single LICENSE file per repository, GitHub even recognizes it and puts an icon in the top right corner.

Right! I've just learned this myself. I forgot to mention that the overall plan is to dual-license all OpenTracing repos. (CCing @bhs @dankohn to clarify/rectify, if needed).

Note that in addition to the license file, the headers in the source files should also be replaced. Here's an example of this in Jaeger: jaegertracing/jaeger#391

I haven't yet checked every OT repo, but so far it appears that at least some repos do not have license headers in any of the source files. I figured I'd follow suit with @cwe1ss 's example PR: https://github.com/opentracing/opentracing-csharp/pull/65

If I encounter a repo that does contain source files with license headers, I'll make sure to address them. 👍

not sure I follow - the official Apache license is http://www.apache.org/licenses/LICENSE-2.0, and the simplest way to get the official plain text version is to create a new GitHub repo and select Apache-2 as the license, the file will be created automatically.

Thanks! That's good to know. In regards to sourcing the license texts from rust-postgres-macros, I think this is an arbitrary decision, not set in stone. That project probably just came up in discussion as an example of dual-licensing with Apache 2.0 and MIT.

[dankohn]

I believe we got ahead of ourselves a little. I was under the impression that the OpenTracing community wanted to dual license as Apache 2.0 OR MIT.

https://github.com/opentracing/specification/issues/61#issuecomment-364682071 indicates that you're OK with just Apache 2.0. If so, that would be CNCF's preference, because all other CNCF projects are Apache 2.0 and a single license is clearer. It also enables GitHub to display the license on the status bar of the repo.

So, @eirinikos can wait to do any PRs until the license is decided.

[bhs]

@dankohn @eirinikos

I was under the impression that the OpenTracing community wanted to dual license as Apache 2.0 OR MIT.

Somewhere along the line that was suggested as a way to make the relicensing trivial. I really don't think anyone in the OT community objects to the Apache 2.0 license (or, if those people exist I haven't heard about them)... the question for me was just what can be done, legally, and nothing more. If it is indeed possible to swap in Apache 2.0 for MIT, personally I would prefer that just for its simplicity.

@yurishkuro, it sounds like you all did this in Jaeger... let's use that as a guide, then.

[yurishkuro]

When we converted to Apache, we ran it by Uber's legal, and they said as long as we give a public notice and nobody objects, there was no issue in switching. So we opened an issue (https://github.com/jaegertracing/jaeger/issues/252) stating the intent to convert, tagged all contributors, and then after about a month proceeded with the conversion.

[dankohn]

@bhs I got feedback from the LF's counsel that dual licensing Apache OR MIT doesn't make a lot of sense since the MIT option doesn't seem to preserve anything and just adds complexity. They recommend relicensing as Apache.

[bhs]

Okay, great. Thanks @dankohn and @yurishkuro. @eirinikos please proceed with the Apache2 relicensing in OT-Go... once that PR is alive and well we can move on to other repos.

Thanks again.

[eirinikos]

Roger that, @bhs. Thanks to everyone for the feedback.

I've opened the OT-Go PR: https://github.com/opentracing/opentracing-go/pull/181

@bhs I have a couple questions (noted in that PR) regarding copyright year and file headers. Once those questions are addressed, should I go ahead and move on to other repos?

[bhs]

@eirinikos let's wait like ~24h just to make sure there aren't any immediate objections to the basic approach. If not, let's proceed with the opentracing-* repos that are not already Apache2.0. Thanks again.

[eirinikos]

Thanks @bhs. I'll wait a couple more hours before I proceed with the other opentracing-* repos. ☺️

Would you like to be CCed on all other PRs by default?

[eirinikos]

Touching base - I've submitted PRs for the Python, PHP, C++, Obj-C, and Ruby repos (as you can see above).

IIRC, these repos are already licensed with Apache 2.0, but could probably use some file clean-up in some way or another. I'll revisit tomorrow:

• opentracing-c
• opentracing-csharp
• opentracing-java-v030
• opentracing-javascript
• opentracing-java
• opentracing-rust