How to apply MIT license in the GitHub repo for fully free project?

Question

I have a public repository for an open source project on GitHub. It's main goal is to

1. make this code available to anybody (including myself) who may what to use it, for free, for all the time, with no future possibility of suing them (or me) for anything
2. make the process of contribution to this code as easy as possible, while maintaining the first requirement

In two words - I'd like to give away all the copyright for it (not sure if public domain is the correct word here, I'm not a layer, but that's what comes to my mind) and force any other contributors to do the same with less efforts.

UPDATE: as others correctly mentioned, these "two words" were incorrect, they didn't correspond to my goal, because giving away copyright does not give the protection from being sued. So lets just stick to the goal - make software free, and easy to contribute to with disclaimer in mind.

So I've chosen the MIT license as the most suitable and added a LICENCSE file with it inside to the root folder of the project. Also I've added a link to it to the README file (according to this answer). But the following questions arise when I try to set up everything correctly:

1. Copyright info part in the main LICENCSE file. There is no company or any other name for the group of people that are contributing to this project. And I hope more and more will join, so it looks like a pain to maintain the list of contributors. Is there a way to just drop this line or to call them, say MyProjectName developers not to update it later on?

2. Contributor License Agreement. Ideal case will be when the fact that file belongs to the project source immediately mean that it is under MIT license and copyright is no more important. Is it possible or valid from jurisdiction point of view? I'm using CLA Hub to verify that every contributor has signed corresponding CLA. Is that enough?

3. License header per source file in this project. Is it really necessary to include some kind of link to the LICENSE file to each source file? According to answer to this question - yes. But is there any exception for exact MIT license? Can I just say something like This license apply to each file of this project at the end of the LICENSE file?

4. Copyright info in the header per source file in this project. This is similar to the first question - is it ok not to add it or add some general name for copyright owners like MyProjectName developers. Otherwise maintaining this up to date is even more pain - I have to track every file in every commit and pull request. I've read this question, but it mostly says that it is necessary to apply copyright later (either in form of re-license or in any other). But I want to make it not relevant (see item 2.)

5. Are there any other things I may be missing?

6. Is there any easier way to achieve this goal? This question was asked for some best practice and in this part it is very similar to mine, but it was not properly answered.

Answer 1

That's not true that a public domain dedication won't protect you, for instance the Unlicense is a public domain dedication but still includes a limitation of warranty. In GitHub's choosealicense.com list of suggested licenses, this is the only license that is more permissive than MIT. The only difference with MIT is that no attribution is required (people can effectively use your code without saying where it comes from).

EDIT: the Unlicense is not officially open source because it is not listed by the OSI, although it respects the definition of open source IMHO. It is free software because it is approved by the FSF but they recommend to use CC-0 instead. I think that the choice of GitHub to recommend the Unlicense over CC-0 is because the latter was not written specifically for software.

You can have a look at this answer which defends the point of view of the OSI. I do not agree with it. Using "public domain" would be a bit dangerous because it is not defined in every jurisdiction but the Unlicense is technically a license (very similar to MIT but with no conditions) which contains a public domain dedication (third paragraph). The second paragraph explains already pretty clearly the rights of the licensee before saying anything about public domain. The problem of moral rights is not specific to public domain dedications. It can also interfere with the right to modify the software which is granted by every FLOSS license.

Now, let's answer your specific questions:

1. Copyright part of the license

If you choose to use the Unlicense, there is no copyright part of the license so you don't need to worry. If you rather choose to use MIT, you could use <Your name and contributors>. It is quite common to see. You could also maintain a separate list of contributors (also quite common). But in any case the absence of such notice or its imprecision does not void the copyright of each contributor so it is not very important.

2. Contributor license agreement

A contributor license agreement is a really good idea to prevent future lawsuit as much as possible because you can typically ask for a patent grant in it, for all the users of your software. It is something that is not included already in very permissive licenses such as MIT or the Unlicense.

I quite like Github's CLA https://cla.github.com/agreement and they give reasons to justify it as well https://cla.github.com/.

Of course, you need to be aware that asking people to sign a CLA will make contributing a tiny bit more difficult but given your concerns, I would still encourage you to use one.

EDIT: I am not a legal expert but I believe that digitally signed documents are valid contracts in most jurisdictions, in particular the United States. I can't guarantee anything about CLA Hub however, because they do not give much guarantee themselves.

3. License header

No a license header is not necessary, at least for MIT and the Unlicense. Some other licenses encourage you to add such a header but that is not the case of these two.

The list of licenses I was mentioning earlier includes instructions on how to apply each license. For MIT and the Unlicense, it is just to copy the text of the license in a LICENSE file at the root of your repository.

4. Copyright header

A list of each copyright owner in each file is not necessary as well, and even projects which do maintain such headers generally forget to update them at every change. Fortunately a version tracker such as git is much more efficient to know precisely who added what to the software and even if it does not mean that they are the author (as they could have included a dependency), it means (if you use the same CLA as Github) that they are responsible of knowing the source and the licensing implications of the code.

5&6. Missing stuff and best practices

If you want to make contributing to your project as easy as possible, I would encourage you to include a CONTRIBUTING file which explains the process for that (how you handle issues, pull requests, the fact that contributors will need to sign a CLA, presenting the code, the dependencies). Also include details instructions on how to compile the code. None of this is legal recommendation, just technical recommendation to make contributing as easy as possible.

If you project grows, another good thing to have is a CODE OF CONDUCT to make everyone welcome. Have a look at examples of such codes here: https://github.com/search?q=code+of+conduct

Finally, even if contributors are supposed to do that, always check that new dependencies are properly licensed and not incompatible with your own license (typically, not GPL). If you need to include the dependency in your repository, try to put it in a specific subfolder with its own original license notice and list the dependencies somewhere in your README. If possible, do not even include the dependencies in your repository if they can be installed with some standard package manager.

Answer 2

There is no license or copyright status that will do exactly what you want to do. These things are incompatible:

• give away copyright
• force makers of derivatives to do likewise
• avoid lawsuits

Giving away your copyright is, as you guessed, dedicating your work to the public domain. You retain no copyright in the work; anyone is free to do as they wish with the work. The catch with this is that you have no more rights than anyone else does; you can't force future modifiers to also dedicate their work to the public domain, nor can you forbid commercial or proprietary uses.

To avoid lawsuits, you need to use a license that includes a disclaimer of responsibility and warranty. The MIT license includes this: it's the big all-caps block that essentially says "I'm not responsible and you can't sue me if everything goes terribly wrong." A public domain dedication does not include this.

To force future contributors to also open-source their work, you need a copyleft license, such as the GPL. That ensures that (a) your work and all future modifications to it will always be open, and (b) you're free of lawsuits (the GPL also includes the necessary disclaimer), but you're not giving people as many rights as you possibly can.

So, what's more important to you?

• If it's giving away copyright no matter what the consequences, go ahead and dedicate your work to the public domain. The world will thank you.
• If it's avoiding lawsuits, but giving people lots of rights, use the MIT or Apache 2.0 licenses (the major difference is that Apache includes a patent clause; if you don't have any patent rights to the software, use the MIT license).
• If it's avoiding lawsuits, but making sure that future derivatives are also open, use the GPL.