inaka

Latest blog entries

/
The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

/
SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

/
Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

/
Using Jayme to connect to the new MongooseIM REST services

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

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

/
The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

/
Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

/
Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

/
Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

/
Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

/
Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

/
Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

/
Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

/
Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

/
Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

/
Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

/
Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
Thoughts on rebar3

Thoughts on rebar3

Jun 08 2016 : Hernán Rivas Acosta

/
See all Inaka's blog posts >>

/
Navigating Open Source Licensing

Inaka Blog wrote this on October 17, 2013 under bsd, cc, dbad, gpl, inaka, license, mit, open, source, unlicense, wtfpl .

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.

Public Domain

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."

General Public License / GNU

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.

Berkley Software Distribution / BSD

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.

MIT License

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.

Apache License

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 / CC

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.

Mozilla Public License / MPL

The MPL, on the other hand, is a world-wide, royalty-free, non-exclusive license allowing liberal mixing with proprietary software.

Alternative Licenses

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.

Do What the F*** You Want Public License / WTFPL

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.

Don’t be a D*** Public License / DBAD

The DBAD is similar to the WTFPL, but a better option if you want to keep your hold on the reins just a bit.

Unlicense

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.

Other Tools

If you’d like to compare two licenses directly, tools like tl;drLegal will help you keep the what’s-whats straight. And – as with most things – it doesn’t hurt to check Wikipedia, either.

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.