14

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 :-)

  • After reading this question and its answers I think there is still plenty about which to be confused. For instance, I have a repo with a ".LICENSE" file, which is apparently not automatically interpreted by Github as being a license since it isn't titled "license.txt" or "license.md". I have also included the same license text at the head of every source file, and at the end of the README.md. Presumably this should cover all the bases, but without talking to an actual lawyer and/or knowing a lot about the legal precedents surrounding the issue it's nigh impossible to know if it's covered. – Darren Sep 16 '17 at 17:54
  • PS I remember a few months ago a large stir in the online community about changes to Github's policies, with many arguing that the new terms meant traditional licences were no longer compatible with Github's site terms and uploading code to Github may automatically violate the GPL because the site reserves the right to cut/paste sections for independent display for the business purposes of the website at their sole discretion. – Darren Sep 16 '17 at 17:55
9

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.

  • Nice answer, but still I'm eager to know what the actual best practices are: item one, item two... You know, the full list) – Pavel K Sep 27 '16 at 12:23
  • 1
    So would I, but I don't know of any such list (otherwise I'd link to them). My answer exists to explain why people don't follow "best practices" that the questioner mentioned: adding a LICENSE and Contributing file, requiring CLAs, and tracking changes (though Git can handle that part). – Tariq Ali Sep 27 '16 at 23:15
  • 2
    +1 for much info. I think it's DMCA though. – IsaacS Nov 30 '17 at 1:49
0

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.

  • This seems like a general answer to a specific question - I don't really see the various points being explicitly covered. – Zizouz212 Feb 21 '16 at 23:26
-2

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.

  • I don't understand how does this answer the question. – svick Feb 27 '16 at 12:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.