Common practice on GitHub and license/copyright

Question

I have been searching the web for quite some time now, but the plethora of opinions/comments/articles about licensing questions make it difficult to verify how trustworthy the various sources are. Also, they often contradict common practice. All of which left me beyond confused. I'm trying to collect what I've found here for cross-checking, adding references, controversy, and discussing common practice.

1. If you create a public GitHub repository with a single file file1, add no license file as well as no license and copyright line to file1, this file is automatically copyrighted by you, the GitHub user. As such, it's all rights reserved, with the following additional rights determined by GitHub's ToS:

   We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

2. It seems common practice to add one file, LICENSE, to a repository that should (hopefully) cover all of the repository's code. I have found very different opinions as to how this is actually true.

3. The common practice on GitHub is to fork a repository, fix bugs, add features, or modify the code in any other way and then sent a pull request to incorporate the changes in the upstream repository. If the repo contained a license file, then so did the fork, so I guess all changes published in the fork fall under the same license file and (if it was one of the GPL, MIT, BSD, Apache licenses) this allows easy acceptance of the pull request without any license or copyright problems.

   e.g. That's the case for the Linux repository; it has the GPL license file, people fork, and their changes might eventually propagate back to be incorporated in the kernel repo.

4. Somehow GitHub tracks who submitted what part of the code anyway, and the changes that were made -- so the copyright for each part of the project should be clear anyway, no? So it's more about the licensing?

I'm just generally confused how even the big projects (as mentioned here as examples for the respective licenses) seem to follow a common practice that contradicts some of the articles I've read about copyright/licensing -- there is no CLA, they merge pull requests that don't explicitly permit them to do so, they don't track all changes in the header comment of each BSD-licensed file (isn't this really just done by GitHub anyway?), they often don't have a contributing file, etc pp. So I wonder how in everyday life, people go about all the common workflow on GitHub, with a decent pragmatism but still following the rules.

I mean, if I commit some code to a friend's repo that only has a license file with his name, what happens to the modifications I added? (It is unlikely to ever be a problem in these cases, but what would be the proper way of dealing with it?)

I haven't found easy and comprehensive best practices, let's say for the most widespread license models, GPLv3, BSD, MIT and the workflow on GitHub -- and even such big projects like Linux seem to not follow some of the legal advice I've found online (e.g. each file should contain the full GPL, etc pp).

Surely, such a document that outlines this legal stuff with close consideration of the already-established working principles on GitHub should be a highly desired information collection for any open-sourcer hanging out on GitHub :-)

Answer 1

Licenses only matter if there is a conflict between programmers. If programmers don't get in any conflict or dispute, then you can be as informal as you want and everything will go fine. According to The Federalist, "If men were angels, no government would be necessary."

But men aren't angels, and that's why licenses exist (to serve as the "law" that guides the use of the code). When programmers do get in a dispute over code, that's when we start parsing the license agreement to find out what the correct course of action is. If the dispute becomes heated, we may even start bringing out the lawyers to help us resolve the dispute.

Sometimes, the dispute can be resolved peacefully ("Eh, this coder wants attribution? We'll throw his name in a README file.") But this may not happen, and the dispute has to be escalated. In the case where a person is in blatant violation of a license (say, by stealing someone's code and claiming it as their own), then the original writer of that code may file a DCMA request with GitHub to remove that code. This has happened with the oh-my-fish project, since that code was found to be in violation of the MIT License.

The experiences of oh-my-fish is also a warning against the unprofessional practices of not caring about copyright/licensing. The original founders of that project were friends, and only later had a falling-out, which led one of the programmers to make the DCMA request based on violations of the MIT License. A more professional attitude towards licensing compliance (such as requiring CLAs to be signed and tracking changes) would certainly have prevented this legal issue heads-on (although it would have added more initial up-front costs and may be rather annoying).

It's up to you to decide whether you want to follow the easy path of doing what you want and hoping men will keep being angels, or to follow 'best practices' and end up doing way more work than is necessary (especially if your project is not "important enough" to justify all the legal compliance steps). Just know that "common practice" and "best practice" are never the same.

Answer 2

Be careful. You got the original (clone) under the stated LICENCE (if available). If said license doesn't allow you to create derivatives, you can't change it. The license may specify that derivatives belong to the original author (would probably need some sort of agreement by you), that derivatives are yours to do as you please (e.g. MIT license), that if you share some derivative you must also share full source (e.g. GPL), some licenses request to contribute changes back, others (e.g. TeX's) allow redistribution under the condition it isn't named the same. As always, as long as everybody gets along happily, legalese doesn't matter. It gets critical when somebody is playing dirty or there is a falling out.

If you are allowed to create derivatives, you are their owner. Under GPL the derivative must be distributed under GPL, but if it is e.g. MIT you are free to dictate your own terms for your changes (make them private, GPL-only, whatever). So I could subvert your MIT project into GPL by sneaking in enough GPLed changes that getting rid of them is impractical...

Presumably the upstream project should state that contributions will only be accepted under the condition that they are acceptable, i.e., add a contributor agreement of some sort. Check out the OSI FAQ too. Just like stating the license explicitly, most don't bother (we are all a big friendly family, right?) until it is too late.

Answer 3

I may be off here, but I used http://choosealicense.com/ to help me decide I needed to pursue inclusion of MIT license in the github repositories we are working to publish.

The decision for our project was fairly simple as we wanted to legally support AND encourage developers to create derivatives of tools/samples/examples using our existing API constructs.

Not sure the site is detailed enough for your needs.