Why Add a License to your Open Source Project?

Most people don’t add a license to their code projects. In 2013 for example, only ~15% of projects on GitHub had one.

There are a few explanations for this. Some suggest developers are pushing back against what they see as a “permission culture”, others blame platforms like GitHub for initially not taking licensing seriously enough (it was 5 years before they added a license picker for example). But I think James Governor perhaps gets closest to the truth in this tweet:

Whatever the reason, it creates a real problem which actually could stop your code from being used by others. Probably, the exact opposite of what you intended!

Just sharing your code publicly on GitHub, Glitch or elsewhere doesn’t mean it can be used. Actually, any code that doesn’t specifically have a license should be considered “all rights reserved” by its author. The author could assert their copyright at any time, and demand you stop using it. So not knowing whether your shared code is meant to be used due to lack of a license could be why your projects don’t have more stars, forks or remixes. As Jeff Atwood puts it “a proper software license is a necessary evil for any code you plan to release to the public.”

**But picking a license is hard?! I hear your cry. **And you’re right, in the past licensing was tricky. There are lots of them, and they included legalese that made them difficult to understand.

But thankfully, there’s been a push in recent years to make licensing more accessible with sites like the Open Source Guide and Choose A License (both GitHub initiatives) making understanding them and choosing one a lot easier.

Which to choose typically comes down to how comfortable you are with other people:

• Using your code
• Copying it
• Modifying it
• Redistributing it
• Selling it to others
• Making decisions about what others can do with it But a number of de facto standards have emerged for different use-cases. Like if you want your project to be used as a dependency in other projects then it’s probably best to use the most popular license in that community. For Node projects for example, MIT is the most frequently used license for npm libraries. If you want your project to appeal to large businesses, then they’ll probably want an express patent license like Apache 2.0. If you want your project to appeal to those who don’t want their contributions to be used in closed source software then GPLv3 and AGPLv3 are good candidates. And if you’re contributing to an existing project, it’s often expected that you’ll release your modified versions under the same license as the original work.

As a result of these common scenarios, the vast majority of software now use either a permissive license, like an MIT, BSD, or Apache license, or a strong copyleft one such as GPL v2 or GPL v3. Sticking with one of these standardized licenses makes it easier for others to know what they can and can’t do with your code. But if you’re releasing an open-source project for work, then it’s always good to check in with your legal team.

If good fences make good neighbors, then a good license certainly makes for a good project. It backs up the appearance of permission you've given folks in sharing your project publicly by expressly giving it in a way you’re happy with. That way, everyone knows where they stand.

It’s such an important aspect, we've made the ability to add a license (and a Code of Conduct) to your project a one-click thing in Glitch. For us, having more Glitch projects explicitly declare their licenses increases the odds that people will be able to easily work together and share their creations. So we've added licenses to all our sample projects too.

So the next time you’re creating a project on Glitch, be a good neighbor and add a license to it.