Consider adding a contributing.md file

[mrennie]

To help avoid IP and code provenance issues you should consider adding in a contributor agreement / CLA. This will also help consumers of Tern that have more rigid IP policies for consuming third-party libraries - like the Eclipse foundation for example.

it could be as simple as adding the contributing.md file in the root of the repo with the following content:

A CLA is a document that specifies how a project is allowed to use your code. We want a CLA that is simple and as clear as possible so that it doesn't disrupt contributions to Tern.
When you make a contribution to the Tern project, you agree:

1. The code you wrote is your original work (you own the copyright) or you otherwise have the right to submit the work.
2. You grant the Tern project a nonexclusive, irrevocable license to use your submitted code in any way.
3. You are capable of granting these rights for the contribution.

By submitting a fix to Tern you agree to the above statements.

Or you could get as fancy as ESLint: http://eslint.org/cla/

[marijnh]

I consider the project's license to already imply all we need. Notably, by contributing code to an MIT-licensed project, you are licensing that code under an MIT license, and thus don't need to grant the project a license to use your code -- it is already allowed to do so. Submitting code that you don't actually own the rights to is something only done by the type of people who aren't going to read such a file anyway. Which points to another issue -- the existence of such a file is no guarantee that contributors are actually reading it and agreeing to it, neither legally not practically.

So I don't think such a file adds enough value to justify cluttering up the repository.

[jarthorn]

You are excluding a fairly significant community of contributors and adopters by not taking this simple step. I realize that sounds crazy, but this minimal CLA approach has been adopted by many open source communities as a simple non-disruptive way of documenting the consequences of contributing. The Linux Kernel has used roughly this approach for over 10 years. This is not an onerous step to take, and while I understand that you and many other developers believe it is not necessary or practical, it is a compromise that has been reached between the legal and developer communities that both sides seem able to live with.

Also, a contributing.md file has other practical uses. When someone makes a GitHub pull requests a prominent link is shown to the file, which is a good place to document your technical requirements like coding conventions, running tests, etc. So you could put that useful technical stuff at the top and bury the necessary evil of CLA blurb at the bottom and make a lot of contributors and adopters happy!

[vogella]

+1 for adding a contributing.md. @mrennie and @jarthorn are working on the Orion project as well as my friends from Redhat on Eclipse tooling for JavaScript. AFAIK such a file would simplify the adaption of tern for these projects.

[marijnh]

@jarthorn @vogella Could you tell me a bit more about the (legal) logic your companies rely on to make such a file a significant factor?

[vogella]

@marijnh I'm an Eclipse developer for the fun of doing Open Source development, so I have no company interest.

The Eclipse Foundation which is the legal entity behind the Eclipse project (most notable the Eclipse IDE). I personally try to ignore legal issues as much as possible (because they are boring) but I know that the Eclipse Foundation put in a lot of effort to ensure that the code used by Eclipse project is free of rights from others.

@jarthorn is with the Eclipse project since its beginning (working for IBM), so if John says this make the adaption for the Foundation easier, I trust them. From personal experience I can only say that IP reviews at the Foundation are time consuming and boring (for the Eclipse developer) and if such a file can prevent IP reviews at the foundation, you would help our projects a lot in adapting tern.

Hope this explanation helps.

[jarthorn]

I'm not a lawyer, but I shield developers from them on a regular basis, so I'll make an attempt to answer it... Lawyers want to answer two main questions about the origins of a piece of code their organization is using (fancy lawyer word is "provenance"):

1. Who wrote the code
2. Did the contributors understand the legal implications of contributing to the code base.

Over the years we've managed to convince the legal community that 1) is reasonably satisfied by Git commit history, given that author metadata is cryptographically hashed alongside the content of every change. So everyone using Git is happy on this one.

This leaves 2). If you ask a lawyer, their preferred answer to this would be a 5 page contract, in triplicate, signed in blood (I'm exaggerating of course... sometimes they are only 4 pages). Through years of push back from the developer/tech community we have settled on the CLA concept as the minimum acceptable mechanism to satisfy the legal world on this aspect of code provenance.

While I happen to work at IBM myself, this particular case is about the Eclipse Foundation's process. However all the major open source organizations (Linux, Apache, etc) use similar mechanisms, and a large number of companies require this as a minimum safeguard when consuming open source code. You have written a fantastic JavaScript tooling library, and we are trying to get this goodness into the hands of hundreds of thousands of JavaScript developers (via Eclipse and Orion developer tools in this instance). I believe it will also help increase the flow of high quality contributions to Tern and be good for the technology involved in the long term.

[mrennie]

In case you change your mind and do decide to provide a CLA, I have one ready to go here: https://github.com/mrennie/tern/blob/issue526/CONTRIBUTING.md

that I would be more than happy to open a pull request for.

[marijnh]

Patch e0e302d adds a basic contributing.md file. Let me know how it looks to you.

[vogella]

@marijnh thanks for helping the Eclipse project to adapt your tooling.

Looks good to my "untrained legal" eyes. I'm sure @mrennie or @jarthorn will be able to spot any issue it might have.

[mrennie]

@marijnh That will work nicely. I ran it past our IP folks at the Eclipse foundation and they agreed it was good.

[jarthorn]

Looks great! Thanks Marijn.