Latest blog entries
The Art of Writing a Blogpost
Mar 09 2017 : Matias Vera
Feb 14 2017 : Felipe Ripoll
Do you need a blazing fast reverse geocoder? Enter offline-geocoder!
Jan 18 2017 : Roberto Romero
MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.
Dec 13 2016 : Sergio Abraham
20 Questions, or Maybe a Few More
Nov 16 2016 : Stephanie Goldner
Because conferences and meetups are not just about the technical stuff.
Nov 01 2016 : Pablo Villar
Sharing some light on how it is to partner with us.
Oct 27 2016 : Inaka
How to easily play a sound in Android
Oct 25 2016 : Giaquinta Emiliano
We're publishing our work guidelines for the world to see.
Oct 13 2016 : Brujo Benavides
Using niffy to simplify working with NIFs on Erlang
Oct 05 2016 : Hernan Rivas Acosta
How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.
Sep 16 2016 : Pablo Villar
How to automatically trigger rails tests with a Jenkins job
Sep 14 2016 : Demian Sciessere
A description of our usual stack for building REST servers in Erlang
Sep 06 2016 : Brujo Benavides
Using Erlang's External Term Format
Aug 17 2016 : Hernan Rivas Acosta
Integrating our Android linter with Github's pull requests
Aug 04 2016 : Fernando Ramirez and Euen Lopez
Introducing how to implement passwordless login with phoenix framework
Jul 27 2016 : Thiago Borges
Our newest game to test your Beam Skills
Jul 14 2016 : Brujo Benavides
Three Open Source Projects, one App
Jun 28 2016 : Andrés Gerace
Running credo checks for elixir code on your github pull requests
Jun 16 2016 : Alejandro Mataloni
Thoughts on rebar3
Jun 08 2016 : Hernán Rivas Acosta
Navigating Open Source Licensing
Why is Choosing a License Important?
First of all, let’s clear something up. In choosing an open source license, you aren’t giving away your rights. You’re simply releasing certain permissions to allow others to use your work.
The lack of a license implies a copyright, as you haven’t informed others how they can use, change, and distribute your code. Many developers won’t touch an implicitly copyrighted code; they have no legal claim to it and could be required to stop using it at any time.
If you are releasing your code to the public, you likely want people to share and use it, so you'll want to avoid implicitly copyrighted code by including a license. By declaring a license, you declare your rules. Otherwise, why would you release the code at all, right?
But now that you've realized you need a license, you still have to decide which suits you best. So let’s get to choosing!
How Do I Choose a License?
Well, there are a lot of options. Maybe too many, in fact. People have different uses, needs, and expectations for licenses, so sometimes new licenses are written to fill that demand – but this just means there’s more to sift through for everyone else. At the moment, there are over fifty open source licenses alone.
To keep this post relatively simple, we’ll focus on the more commonly used open source licenses.
Useful Questions to Ask Yourself
Before getting into specifics, take a second to figure out what’s important to you. (This list of questions is adapted from a post by Ed Burnette.)
Do you want to give up all control? If yes, then consider a very liberal license like either the BSD or MIT. Better yet, consider the DBAD license or the notorious WTFPL, all of which are covered below.
Do you want people to use your code exclusively in open source programs? If yes, then consider the GPL. GPL'd code can only be re-released under the GPL, which means that if you are using GPL'd code in a new project, your project needs to be GPL'd, too. (Or, to release it under a different license, you would need to remove all GPL'd code from your project.) This viral aspect of the GPL probably has something to do with its popularity, but it’s a good license and is covered below.
Do you want a share of any profits that are made using your code in other projects? If yes, then you can do one of two things. One: don’t release the code at all, and keep it closed. Anyone who wants to use it will have to come to you first to work something out. Two: opt for a dual license. In this case, you choose two licenses: one which applies to personal use of the code, and the other to any commercial projects.
Do you want to receive any and all improvements to the code, like if another person were to fix a bug or add a feature? If yes, then consider using a reciprocal license like Eclipse (EPL), Solaris (CDDL), or Firefox (MPL). We’ll discuss the MPL below.
Common Open Source Licenses
What constitutes an open source license? Every open-source license must comply with some common components: free distribution, included source code, derivative works, no discrimination, techonology-neutral and not software-restrictive, among a few others. For more on this, check out the Open Source Definition at the Open Source Initiative.
Now – finally – let’s discuss the licenses themselves, a few broad strokes apiece. Again, we’ll just be covering a few of the more widely known open source licenses. For a conmprehensive list, check the tools at the end of this article.
Work moves to the public domain when rights have expired, have been forfeited, or are inapplicable. For our purposes here, declaring your code to be in the public domain is basically forfeiting. You hold your hands up in indifference and say, "Have at it!"
To be clear, though, your code won’t go to the public domain automatically. You must explicitly declare it. Simply giving the public access to your work does not imply public domain licensing.
As Ed Burnette explains it, "This isn't really a license at all, but rather a renouncing of any rights you might have under copyright law. The idea is simple to understand but gets a little hairy legally… After reading about it some more, my advice is to punt and and use a BSD/MIT license instead."
After releasing code under the GPL, you cannot revoke it, and those who have already received the code will still have rights to it. You can, however, choose to stop distributing the code and then release it under a different license. It’s also important to note that you can charge for software distribution but you cannot charge a fee for using the software itself.
BSD, likewise, is a pretty permissive free software license. It is less restrictive than the GPL, though both versions are compatible with the GPL.
Essentially, as long as copyright notices and disclaimers of warranty are maintained, you’re good to go. You may not use the names of contributors in derivations of the original project without their permission, however.
This is very, very basic. Essentially, it just includes a liability disclaimer. As long as a copy of the MIT license terms is included, code can be used in proprietary software.
It is also compatible with the GPL.
The Apache License is very open and permissive, allowing any and all reuse and distribution without a concern for royalties. The copyright notice and disclaimer must remain intact.
Creative Commons retains copyright while still permitting others to copy, distribute, and use the work. It is designed with three layers: the legal code, plus human- and machine-readable versions of the same permissions.
If you’re confused about which Creative Commons variation suits your needs best, this flowchart may help.
The MPL, on the other hand, is a world-wide, royalty-free, non-exclusive license allowing liberal mixing with proprietary software.
Alternatively, you have some other options, a few of which poo-poo at the idea of licensing all together. Here they are with brief explanations, but I strongly suggest checking out the official licenses on their respective sites – either because they're useful to you or you want a good laugh.
As reads the WTFPL site, "There is a long ongoing battle between GPL zealots and BSD fanatics…[but] in fact, both license types have unacceptable obnoxious clauses…that severely restrain our freedoms."
With the WFTPL, however, anything goes. And I mean anything.
The DBAD is similar to the WTFPL, but a better option if you want to keep your hold on the reins just a bit.
Then there’s Unlicense, built on the idea of "life’s too short, let’s get back to coding." There are too many instances of not using a code because its open source license didn’t quite mesh with your own, it argues, and Unlicense is the solution.
The Unlicense is actually a safe way to release your code to the public domain.
They recommend putting the "license" in a file named unlicensed in lieu of license as a means to further distance yourself from the idea of having a license at all.
Coding Horror also has a useful text chart comparing a concentrated range of open source licenses, if you are so inclined.
For an exhaustive and detailed list, see the Open Source Initiative.