How to license your software properly

(Disclaimer: I am not a lawyer, everything in this post is probably wrong)

Too many times I’ve stumbled across a really useful library or framework that is ridiculously prohibitively licensed. The thing is that most people are simply oblivious to what the license entails and just slap on a GPLv3 (because everyone is using GPLv2, and of course you want the latest version.. right?).

The problem with GPL is that it includes a copyleft. This means that any distributed work that uses anything licensed under GPL is required to be released under a GPL license as well. The reason for this is to force organizations that are developing proprietary software to release their improvements back into the wild.

This is a really good thing in most cases. The Linux kernel use this license to make sure that any company using their code is required to release any bug fixes or features free for everyone. The thing with GPLv2 is that this only applies to your entire project if you include GPLv2 licensed code in your project code base. If you use a third party library or module which is distinct from your code you’re fine and are free to ignore the limitations of the license.

However, this was recognized by GNU and GPLv3 was soon released to fix this “problem”.

So when you license your new awesome library under GPLv3 you are essentially forcing everyone else that use your library to also license their code under the same license. And now nobody can use your code for anything without releasing all of their own code for free.

If you want to prevent people from profiting on (and using) your code you should go ahead with a GPL license. Otherwise pick something else, I explain some of the most common licenses below. Sorted from least to most complex.


This is “(Do) What The Fuck (You Want To) Public License” which is effectively the same as releasing your software under the public domain (which is useful in countries where that’s not a thing). By releasing your code under WTFPL you allow people to do anything they want with it.


The MIT license was developed at MIT (duh!) and is almost the same as WTFPL except that it includes two important points. The first is that the copyright notice must remain intact, i.e. they are not allowed to remove your license from your code. Note that this is not the same as giving any notable recognition for using your code in a released product.

The second point which is far more important is that it removes any liability from using your code. If your code accidentally deletes important files or causes a company financial losses they can’t claim any damages from you.

If you don’t know what license to pick. Pick this one.


Since MIT had their own license it was only a question of time before Berkeley created one of their own as well. The BSD license is almost identical to the MIT license except for one additional point.

This license explicitly prohibits the use of your name or your organization in endorsement of the end product. Anyone using your code is not allowed to claim that you are endorsing their product by letting them use your code.

A rather important thing about the BSD license is that there are two versions. One with four clauses and one with three. The three-clause version is the BSD license and the one you should use if you choose to use this license.

Apache License

This is the most complex license and I admit that I don’t entirely understand what all of it means. Note that the Apache license is different from Apache (which is a web server) and Apache software foundation (that are maintaining the web server and this license, among other things).

What makes Apache different from the other licenses (apart from it’s far more complex legalese) is that it grants anyone using your code a patent license for any patents that cover your source code. Because copyright and patents are entirely different animals this protects the licensee from patent infringement which makes your code safer to use.

I hope that this gives some clarity in the jungle that is licensing and copyright.

What deployment tools can do for you

I restarted work on one of my older hobby projects. Though I’m not really sure what my end goal is yet I got a vague idea of what I want to build and it’s nice to have something of my own to code on.

While setting this project up I took some extra time to make sure I got deployments automated from the start. Proper configuration and use of tools saves a lot of time but it also takes several hours to a day or two to set up, depending on the project of course.

There is a ton of guides on the web on how to do this so I won’t reiterate too much here. The project is version controlled with git which allows me to set up a repository directly on the server. In the post-receive hook I am able to add any commands necessary to properly manage the project.

As an added bonus I have fully integrated dependency management with Composer, automated asset optimization with Assetic and database migrations (that write themselves!) with Doctrine. The result is that I write some code, run a command to generate migrations if the code touches the database, and commit before pushing to live.

And that’s it.

I don’t have to SSH into the server to manually do a pull. There’s no need to optimize and minify CSS and JavaScript on my dev machine. I don’t have to worry about out of date dependencies. Heck, I don’t even have to write any SQL. It just works.

How I set up Pelican for blogging pt. 2

So the whole point of running a static website (besides that it’s cool) is the performance aspect. And I personally think that if you’re doing something for performance you might as well go all the way. So here’s how I optimized my static website.

First downloading the plugins and themes I would require to the folder for my configuration files.
git clone ~/Projects/Pelican/plugins
git clone ~/Projects/Pelican/themes

And then adding them to the main configuration file by adding these lines to the bottom.

# Plugins
PLUGIN_PATHS = ['/home/rasmus/Projects/Pelican/plugins']
PLUGINS = ['assets', 'gzip_cache']

# Theme
THEME = '/home/rasmus/Projects/Pelican/themes/monospace'

I picked “monospace” for the theme since it was fairly lightweight and only required one small CSS-file, normally I would write a theme myself but for now I just wanted everything up and running. The two plugins added in the configuration are for asset management (assets) and for generating a static compressed version of the website (gzip).

The assets plugin requires additional dependencies for Python which I had to install through pip sudo pip install webassets cssmin. To get the asset management working properly I had to do some modifications to the theme source code. By changing the CSS links to this (below) in the theme and also removing the @import in the CSS file I am able to minimize both CSS files into the same stylesheet and send both over the same request, minimizing requests to the server.

{% assets filters="cssmin", output="css/style.min.css", "css/main.css", "css/pygment.css" %}
{% endassets %}

My Apache-server automatically started serving the gzip compressed files, so I didn’t have to add anything else for the compression to work. Normally I would have to configure Apache to compress the files as they are being requested, but by having the files compressed beforehand allows for some additional milliseconds to be scaled of the wait time from the server.

And then to cheat a little bit I set up static caching with expires headers and disabled ETags. This means that the website will first be downloaded once in 10-20 milliseconds depending on network connection speeds, but after that all resources will be loaded from the local cache and I can reduce the rendering time to 3 milliseconds. I do this by first setting up modules with a2enmod headers expires and then adding this to the vhost directive (I have .htaccess disabled for even better performance).

Header unset ETag
FileETag None
ExpiresActive On
ExpiresDefault A300
ExpiresByType text/css A526000
ExpiresByType image/gif A526000
ExpiresByType image/png A526000
ExpiresByType image/jpeg A526000

All in all the site is rather fast now, I’ll keep this blog posted if I discover anything else to improve.

How I set up Pelican for blogging pt. 1

No, this blog still uses WordPress because of its convenvience and ease of use. But I needed a way to document my personal server that I use for Mumble, IRC and my small projects and I decided to test out static blog generators for that.

Normally people use Octopress (based on Jekyll) which labels itself as “A blogging framework for hackers” which is cool and all but I really don’t like Ruby and I had heard a lot of good stuff about Pelican so I went with that.

This post merely describes what’s different in my own approach and isn’t very detailed in itself, for a better tutorial in setting things up I recommend the documentation pages on how to get started. Continue reading

The Heartbleed Bug or “Why you shouldn’t reuse passwords”

The Heartbleed Bug was discovered last week, which is a vulnerability in OpenSSL which powers the HTTPS services of most major websites today. The bug can be quite adequately explained by this XKCD comic.

This brings to light the importance of not reusing passwords. Even if your password is fairly impossible to guess and mathematically improbable to crack it’s still useless if you use it for multiple websites. Because it only takes one website to leak your password through a vulnerability like this to compromise all of your accounts where you reused the same password. So don’t, or at least enable two-factor authentication.