How to add license to github repository

Open source license in GitHub| How to add license to a GitHub repository?

What you need to know about open source software license with relevant to GitHub. To add license to an existing and new (while creating a repo) GitHub repository.

What is public repository on GitHub?

Whenever we surf about any resources, relevant code or open source software on GitHub, some of the repositories are listed and we can access them by forking it. Simply, any one can find a repository and fork it in order to use the files as desired.

Public repositories are accessible (able to fork) to everyone on the internet but Private repositories are not accessed, (not able to fork) by everyone, only who created that repositories and people who has the access privilege provided by the creator of the private repository.

What is licensing a repository?

Open source software need to be licensed (to provide rights to modify, distribute other than creator) so the repository in which the software dwells should include the license file. So, other (who forked the repository) can edit, distribute the software in repository. We know open source software helps not to re-invent the wheel.

Is license recommended for private repository?

Nope. If the software in the private repository, never published which is considered not as open source. So providing license is meaningless. It is better to create a repository in private or public during the creation of repo itself.

Software license.

Types: Public domain, Permissive, Copyleft, Proprietary. In this article we cover only permissive and copyleft which is highly preferred in GitHub repos.

Permissive License

This type of license grants the user but with minimum condition

Less Restriction Permissive License

1. MIT License— This license allow the person to obtain a copy of the software and associated files with the rights to use, modify, merge, distribute, publish, sublicense, and sell copies of the software. MIT means Massachusetts Institute of Technology.

Condition: copyright notice in all copies.

2. Apache— Similar to MIT but license include clear definition about the grant of license, copyrights, redistribution, contribution and limitations to use this license. It grants for patent use (definition number 3 in below).

Condition: Termination of license if the user sues anyone over patent infringement related.

3. ISC— Internet Systems Consortium has simple description about the license. Condition: copyright notice in all copies.

4. BSD— Berkeley Software Distribution has 3 versions of licenses which are termed as 2-clause(similar to MIT license), 3-clause and 4-clause.

3-clause and 4-clause does not allow to endorse or promote the products from software in the name of copyright holder/ contributors or organization.

The Unlicense- Permissive license with no condition. It is a public domain type of software license. Public domain means resources can be modified, re-distributed and even sell the resources without any legal or authorization from the author.

Copyright vs Copyleft

Copyright comes to the major point when we need a re-use of any resources. 3 kinds of re-use resources are public domain (re-use), creative commons (limited re-use), copyright (no re-use). So, copyright need legal authorization of the author to re-use by others. For example, most of the writeups includes relevant images taken from internet with credits to the author.

Copyleft License

If there is a condition to distribute the software in extended versions but it is termed as illegal then everyone moves to free software. So, it won’t be the right choice for all the developers. Apple is the

Firstly, the software are copyrighted then distribution terms are generated. Now, everyone has the rights to use, modify and even re-distribute, derived from it only if the distribution terms are unchanged. Even if the software contains any proprietary code then it become open source. This is because you modified the code so its up to you and it won’t wholly consider inherited from existing or proprietary.

More Restriction License/ Strong Copyleft

GPL— GNU’s General Public License is the most preferred license by developers for commercial products. Basically, Richard Stallman wrote this license to prevent GNU software to become proprietary software.

AGPL v3- Affero General Public License most restrictive license used for the software hosted on the server. The purpose of this license is to prevent a problem that affects developers of free programs that are often used on servers. MongoDB uses AGPL- License text

Weak License (Weak Copyleft)

LGPL v3- Lesser General Public License. Initially L represents library but later changed to lesser. Library which are under LGPL permits to use in proprietary software which doesn’t supported by GNU GPL. Also, another case if you want the library under LGPL to be used in free software then go for GNU GPL.

Mozilla Public License- MPL 2.0 developed and maintaining by Mozilla Foundation. Code licensed under MPL are allowed to integrated with proprietary software.

Note: LGPL is library based and MPL is code based license.

What license should I choose if it’s not a software?

Non-software license— if it is a open resources like media, documentation, hardware design and even data can be licensed under Creative commons.

Note: If a software/resources published in a public repository on GitHub, according to the Terms of Service, others (any GitHub users)have the right to view and fork it.

Also, your non-licensed project may contain README file to add copyright notice or contribution agreement to accept other contribution to your project. Publish your repo under The Unlicensed(public domain) instead of non-licensed.

How to add license to your GitHub repository?

To license an existing repository

Open your GitHub repository in which you need to add the license.

Type LICENSE or LICENSE.md or LICENSE.txt in the text box then automatically Choose a license template button is displayed next to Cancel changes button. Tap on Choose a license template button.

Based on the selection, license information are displayed.

If you have tapped on Review and Submit then the license text has been written on the file and ready for the commit. So commit the changes and it will be published on your repo.

To add license to new repository

Tap on New repository.

Type your repository name and description if needed. Check on Choose a license and shows a list box contains all license name. Tap on your desired license and tap on Create repository.

By doing the above, a repository will be created with License file and tap on Add files to add your project related folders, files and even README file.

Can I change the license of a project in GitHub?

Yes, you can change by simply following the above steps(add license to an existing repository). It’s not a good practice to change the license when you have licensed a project and commit in the GitHub and changing to another license. You can commit the derivative work or new release of the existing licensed project to be in another license by commit on separate repo.

Adding a license to a repository

In this article

You can include an open source license in your repository to make it easier for other people to contribute.

If you include a detectable license in your repository, people who visit your repository will see it at the top of the repository page. To read the entire license file, click the license name.

Open source licenses enable others to freely use, change, and distribute the project in your repository. For more information on repository licenses, see «Licensing a repository.»

Including an open source license in your repository

On GitHub.com, navigate to the main page of the repository.

Above the list of files, using the Add file drop-down, click Create new file.

In the file name field, type LICENSE or LICENSE.md (with all caps).

To the right of the file name field, click Choose a license template.

On the left side of the page, under «Add a license to your project,» review the available licenses, then select a license from the list.

Click Review and submit.

At the bottom of the page, type a short, meaningful commit message that describes the change you made to the file. You can attribute the commit to more than one author in the commit message. For more information, see «Creating a commit with multiple co-authors.»

Below the commit message fields, decide whether to add your commit to the current branch or to a new branch. If your current branch is the default branch, you should choose to create a new branch for your commit and then create a pull request. For more information, see «Creating a new pull request.»

If you have more than one email address associated with your account on GitHub.com, click the email address drop-down menu and select the email address to use as the Git author email address. Only verified email addresses appear in this drop-down menu. If you enabled email address privacy, then @users.noreply.github.com is the default commit author email address. For more information, see «Setting your commit email address.»

Click Commit new file.

A dev’s guide to open source software licensing

A crash course in licensing.

Gina Häußge // Creator & Maintainer, OctoPrint

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

If you’ve ever created a repository on GitHub, you will have seen this repository creation dialog.

Right at the end there it says «Choose your license». That sounds important, it’s right there in the repository creation dialog after all. But what is a license and why do you need to choose one?

We’ve all heard the term Open Source, and many of us will also have come across the term Open Source License, but what these things actually mean, how they come together and why you as an OSS dev should even care is still a mystery to many. This post hopes to help clarify this subject a bit more.

What is Open Source?

Many people think that Open Source simply means availability of the source code of a project, but that does only tell part of the whole story.

The Open Source Initiative (OSI) provides a commonly accepted definition of what constitutes Open Source. To summarize that, in order to be constituted Open Source,

a work has to allow free redistribution,

the source code needs to be made available,

it must be possible to create further works based on it,

there must be no limitations of who may use the work or for what purpose (so something like «no commercial use» or «no military use» won’t fly with Open Source),

the work must not require an additional license on top of the one it comes with,

and finally, the license must not depend on a specific distribution format, technology or presence of other works.

So, you see, it goes way beyond «the source code is available», in fact, a whole lot more requirements are stated that must be fulfilled in order for a work to really be considered Open Source.

Note however that it doesn’t say «must be free of charge» anywhere there. A common misconception is that OSS must not cost anything, or that you are not allowed to earn money making it. That is wrong, and the term Free Software often encountered alongside Open Source usually gets further specified as «free as in speech, not as in beer» to make this distinction clear. Commercial services built around OSS are fine, and so is selling OSS, as long as the licenses are adhered to and the sources are made available alongside.

What is a license and why would I need one?

Any work that you create by default makes you the copyright holder of it. That means only you are allowed to distribute whatever you created. If you want to transfer this right to other people as well, you can do that via a so-called license. Consider it a set of rules that define how others may use, distribute, modify and otherwise interact with the work you created, and under what terms.

Let’s say you have written a software tool and you want to host its source code repository on GitHub. Without a license attached, people will be able to look at it, and fork it (because both of that is allowed via GitHub’s own Terms of Service), but they may not use it in their own projects, modify it or otherwise do anything else with it. You alone have the exclusive copyright.

So, long story short, a license allows you to define additional rights and obligations regarding your work that go beyond the copyright you own, and it can protect yourself.

What options are there?

Thankfully you do not have to write your own license (and frankly, neither should you, there be dragons). There are a multitude of existing licenses for you to choose from already, and I’m going to introduce you to some of the most common ones.

Please note that I’m going to focus on Open Source software licenses here, so licenses that fulfill the Open Source Definition by the OSI, as those are also what I’d recommend to restrict yourself to when choosing a license for a new OSS project. However, I will also briefly outline Creative Commons licenses, as they are often encountered on hardware projects, and Public Domain, as it is often encountered in the wild.

«Copyleft» licenses: GPL, AGPL, LGPL

Remember when I said that you could require anyone who modifies your work to share its source as well? Having to adhere to similar terms is commonly referred to as being viral and the most popular member of the family of viral Open Source licenses are the so called copyleft (in contrast to «copyright») licenses GPL, AGPL and LGPL.

The GPL, or GNU Public License, is viral (so derivatives must be distributed under compatible terms), rules out any claims of warranty (so you cannot be sued), and states that any kind of attribution («written by J. Random Hacker») must be kept in place. The license and its siblings are OSI approved and thus commercial use is no problem.

The AGPL, or Affero GNU Public License, expands on the virality clause such that even if derivatives are only accessed through a network connection, their sources must be made available under compatible terms.

The LGPL, or Lesser GNU Public License, on the other hand, dials back the virality a bit, stating that derivatives only linking against the work don’t have to share under the same license terms. What considers linking has been a subject of quite some debate, but in general the idea here is that as long as your work is only used like a library and not directly build upon, the virality clause doesn’t trigger.

If the copyleft philosophy isn’t your thing for any reason, there is a family of quite permissive Open Source Licenses that are not viral but still offer attribution and protection against liability.

Creative Commons

BY: requires the author to be stated

As you can see, Creative Commons can mean trouble when it comes to Open Source compatibility. As long as you stay away from the «NC» and «ND» modules, your work should still be Open Source by definition, but since the license is not itself OSI approved, you might run into compatibility problems with anything you depend on, or make your work difficult to build upon.

It might happen that you also come across software that has been released into the Public Domain, meaning that all copyright claims have been forfeit. This concept seems to be quite attractive to people who really just want to set their code free and don’t care at all what happens to it.

It should be noted that even though this might seem a quite charming concept at first, there is a huge downside to it: no warranty waiver. You really do not want to make yourself vulnerable to legal threats simply for having written some code that caused someone issues due to a bug, so if you want to go this route my recommendation is to at the very least consider something like the Unlicense because it at least contains the warranty waiver and thus protects you from liability.

So how do I license my Open Source project?

Depending on whether your project is stand-alone or building on the work of others, there are different things to consider.

If you are creating a standalone project, you can freely decide on a license. Take a look at other projects in your development community, or similar projects, and what they have chosen. Make sure you understand the license you plan to use, and that you are comfortable with it. If the thought that someone might take your code, build something new on it and not share the source of that sickens you, a permissive license might not be the best choice and a viral copyleft license like GPL might be more your cup of tea. If on the other hand you just want people to be able to whatever with your code, as long as your name stays in it and you won’t get sued over it, you probably want to take a look at a permissive license like MIT instead. Take a look at choosealicense.com if you need a helping hand.

If you are building on other works however, things get a bit more complicated. You need to check and understand their licenses, and also understand that you will be restricted to something compatible in your own choice. If you are building on something licensed under GPL, keep the virality in mind. If you are building on something under a Creative Commons license, be very careful, you might not even be allowed to build on it, depending on the flavor. For the GPL specifically, there is a helpful compatibility list you may want to consult.

You’ve done all of that? Congratulations, you have licensed your project!

Unless you put a license on your source code, your exclusive copyright applies and no one can really utilize your code. There is a huge number of available licenses to choose from, and before you decide on one you should make sure you understand it, are comfortable with it and also don’t run into any kinds of incompatibilities with things you depend on. Best stick to established, well-known and proven licenses instead of the more obscure ones, and never try to roll your own.

Further reading

OSS Watch License Differentiator: Filter OSS licenses by certain criteria to help you finding possible candidates

How open source licenses work and how to add them to your projects

How open source licenses work and how to add them to your projects

Recently, there was some exciting news for developers around the world. Facebook changed the license of multiple libraries they develop. They switched from BSD-3+patents to a MIT.

That seems good, but what does it mean? What are the implications of different open source licenses?

This article will give you a quick understanding of the popular licenses. It will also teach you how to apply them to your open source projects on GitHub.

The Authority

The most popular open source licenses have an important aspect in common. The Open Source Initiative (OSI) has approved them.

OSI formed in 1998 with the goal of promoting open source software. It has created the Open Source Definition (OSD) to define what an open source software means.

This is how they describe themselves:

The Open Source Initiative (OSI) is a non-profit corporation with global scope formed to educate about and advocate for the benefits of open source and to build bridges among different constituencies in the open source community.

The Licenses

Most open source licenses include the following statements:

We will go through the most popular licenses, in order from the most restrictive to the most permissive (from a user’s perspective).

GNU General Public License, version 3 (GPLv3)

GPLv3 is one of the most restrictive licenses. It offers high protection for the author of the software.

GPLv2 is also very popular. The main difference from GPLv3 is the clause on patent grants.

That clause was added in version 3 to prevent companies from charging users for the use of their patents.

Ezequiel Foncubierta pointed something important for GPL licenses:

The license of your source code must be compatible with the license of the open source code you are linking to. For instance, if your code is proprietary, you won’t be allowed to use a library under the GPL license. This is where people tends to make more mistakes.

Apache License 2.0

Apache License 2.0 offers more flexibility to the users.

Berkeley Software Distribution (BSD)

BSD has two main versions: 2-clause and 3-clause. They both offer more flexibility to the users than the Apache License 2.0.

MIT License

MIT is one of the most permissive licenses. It is also the most popular one. It offers very low protection for the author of the software.

Facebook’s React.js had a BSD-3+patents license up until September 25th. It combined the BSD-3 license with an extra clause on patents usage.

In a nutshell, if you sue Facebook or any of its subsidiaries, you lose the right to use React (or any other software under the same license).

React is now MIT licensed. You are now able to sue Facebook and still use React. What a relief!

Applying a license to your open source projects

GitHub makes it even easier:

In summary…

Check out my explanation of how I used Python to find interesting people to follow on Medium!

Licensing a repository

In this article

Public repositories on GitHub are often used to share open source software. For your repository to truly be open source, you’ll need to license it so that others are free to use, change, and distribute the software.

Choosing the right license

We created choosealicense.com, to help you understand how to license your code. A software license tells others what they can and can’t do with your source code, so it’s important to make an informed decision.

You’re under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you’re creating an open source project, we strongly encourage you to include an open source license. The Open Source Guide provides additional guidance on choosing the correct license for your project.

Note: If you publish your source code in a public repository on GitHub, according to the Terms of Service, other users of GitHub.com have the right to view and fork your repository. If you have already created a repository and no longer want users to have access to the repository, you can make the repository private. When you change the visibility of a repository to private, existing forks or local copies created by other users will still exist. For more information, see «Setting repository visibility.»

Determining the location of your license

Most people place their license text in a file named LICENSE.txt (or LICENSE.md or LICENSE.rst ) in the root of the repository; here’s an example from Hubot.

Some projects include information about their license in their README. For example, a project’s README may include a note saying «This project is licensed under the terms of the MIT license.»

As a best practice, we encourage you to include the license file with your project.

Searching GitHub by license type

You can filter repositories based on their license or license family using the license qualifier and the exact license keyword:

Detecting a license

The open source Ruby gem Licensee compares the repository’s LICENSE file to a short list of known licenses. Licensee also provides the Licenses API and gives us insight into how repositories on GitHub are licensed. If your repository is using a license that isn’t listed on the Choose a License website, you can request including the license.

If your repository is using a license that is listed on the Choose a License website and it’s not displaying clearly at the top of the repository page, it may contain multiple licenses or other complexity. To have your license detected, simplify your LICENSE file and note the complexity somewhere else, such as your repository’s README file.

Applying a license to a repository with an existing license

The license picker is only available when you create a new project on GitHub. You can manually add a license using the browser. For more information on adding a license to a repository, see «Adding a license to a repository.»

The goal of GitHub’s open source licensing efforts is to provide a starting point to help you make an informed choice. GitHub displays license information to help users get information about open source licenses and the projects that use them. We hope it helps, but please keep in mind that we’re not lawyers and that we make mistakes like everyone else. For that reason, GitHub provides the information on an «as-is» basis and makes no warranties regarding any information or licenses provided on or through it, and disclaims liability for damages resulting from using the license information. If you have any questions regarding the right license for your code or any other legal issues relating to it, it’s always best to consult with a professional.