New source code license Sep 1, 2016

Personal note: I’m not a native English speaker, this post might contain mistakes, typos, etc. I’ve written it as fast as possible.

From Aseprite v1.1.8 the program source code license has changed from the GPLv2 to a new EULA that still gives you the possibility to compile and modify the program for your own purposes, but it doesn’t allow you to redistribute Aseprite.

For most users and customers this doesn’t affect them at all, but for several other users (mainly for people using Aseprite from Linux distributions) this is a big red flag. On Linux terminology: Aseprite is non-free software from now on. What does this mean? Linux distributions cannot package and distribute Aseprite freely anymore.

First we have to ask why the license didn’t change before?

This post is separated in several sections. It is a whole travel through my mind in these years developing Aseprite. So here we go.

Selling free software

From the very beginning (1998~2001), I started developing Aseprite for free in my spare time as an innocent activity. I don’t know exactly when I’ve decided to create “a product,” but maybe after Aseprite v0.9.6-beta1, or when I turned 30 years old, or after reading Xah Lee ideas about Emacs. Then Aseprite v1.0.0 came out in 2014 and it was the first commercial version. Selling GPL software was a reality. (Note: I remember that a lot of people hated this decision.)

Selling free software sounds great: You can live doing what you like (programming), give support to users (fixing bugs, new features, emails, etc.), people can contribute patches, and the program is still “free.”

But the reality is quite different: When you decide to start living from your own software (in my case, from March 2015), and your software is not a service, there is a feeling inside your head that makes you tremble: all your code is out there available for free.

My decision back then was (and I still think the same): The code is not as important as the design, the decisions and choices I’ve made, and the vision of what product I want to make. Modifying code doesn’t matter as much as how well you handle complexity and transform that complexity into a product, with a reduced number of bugs and a proper user experience (UX).

A lot of open source projects have a complete lack of vision, “good taste” (whatever that means), or a minimal thinking about the UX. If you want to help an open source project, you can: 1) learn how to handle complexity, 2) listen the user complains, 3) try to improve the UX from there.

Contributions and patches

It sounds nice that people can contribute patches, but the reality is that it requires a lot of time. You need to stop doing what you were working on, change the priority of things in the roadmap (because the patch might be something that you was expecting to implement in a non-near future), review the code, test in all platforms, think about a nice UX, maybe propose more changes to the pull request, repeat the process, and merge the change.

Despite all this, I’ve always thought that keeping the source code of Aseprite available was a good idea. (And I still think the same, so Aseprite source code is still available for contributions.)

Open Source vs. Piracy

If someone doesn’t want to (or just cannot) pay for your work, she/he is not a customer. And in that case he/she will try to find other ways to get the program. You just have to give up. Personally I think that sharing source code is like declaring that explicitly: “If you cannot afford it, you might try to compile the program and use it anyway until you can pay for it or feel that worth it.”

I recommend this reading: “Piracy is a Thing - Give Up”, and “I Don’t Sell Games; I Sell Self-Satisfaction”.

Linux Distributions vs. Developers

From long time ago, Linux distributions (I think Debian was the first one) have packaged and distributed Aseprite. I welcomed this, even after I started selling Aseprite. (Also I’ve to thanks to Tobias Hansen for this, a Debian package maintainer, which also contributed with some patches.)

But in these months I started seeing a recurrent pattern: some people think that Aseprite is available in Ubuntu or other distributions because it is “just there” in the software center. It looks like Aseprite is free just because the distribution made it free (and not because the developer’s decision, the developer is basically inexistent).

And that was the trigger of several issues that I have with Linux distributions from long time ago:

1. Almost none Linux distribution assert that they “are not associated in any way with the developer of the application.”
2. They do not show who is the real developer of the application in a clear way. Sometimes misleading or confusing people that the developer (who fix bugs and add new features) is the (package) “maintainer.” Sometimes they include a link to the program website, but theres is no “official support contact email.”
3. They do not show buttons/links/a simple way to contribute to the real developer of the program. In my specific case, there is a way to buy the official version or donate just in case you want to contribute to the development.
4. In an alternative world, open source programs that are being sold, could have a charge, and a % could be for the distribution, other % for the package maintainer, and other % for the developer.
5. I’m not sure how is the review system for applications on Ubuntu or other Linux distributions, but I think they don’t have a way to contact the developer before the user makes the review, the review is just based on what was packaged.

I could also talk about the packaging mess that all distribution made for application development, or the lack of interfaces to interact with the desktop. But those are other Linux Distributions vs. Developers rants.

The worst Linux issue are crash reports. I think that Linux distributions should have an automatic mechanism to save/show crash reports (a la OS X), or share those crash reports automatically with the application developer. (In this case I think Ubuntu Apport and whoopsie are making the best effort.)

From my point of view it’s happening a complete inverse process: Windows memory dumps and OS X crash reports are useful to detect bugs that then will benefit Linux users.

This is one example of an OS X crash report. A pretty nice example that a bug detected on OS X benefits all platforms. So the question here is why should I distribute software on Linux if the benefit to other platforms is almost null?

Advices for Linux distributions

1. Show clear information in your Linux distribution website and software center about 1) who is the developer, 2) that you are not associated with the developer, 3) an official support email address, and 3) be friendly with the developer distribution mechanism (e.g. donation link, charge for software, etc.).
2. Make an automatic mechanism a la OS X to show/send/copy-and-paste/print-screen/etc. crash reports.

From my point of view, it looks like Linux distributions want to just distribute software, but they don’t work on ways to help developers to integrate software with the distribution. E.g. better ways to find bugs on that software, better ways to interact with the desktop, etc.

So why not GPL?

I don’t think anymore that distribution of software is a good thing just because it can be freely distributed without any cost. (Even from an ecological point of view.) So these comments don’t apply to the GPL only.

Software is a tool, but also is about making the tool, improving it. Each user should help in certain way to the development of that tool (e.g. paying for it, compiling it, reporting bugs, etc.). If one user get a crash, we should have an opportunity to fix the bug from that crash and benefit all other users (from all platforms).

GPL is about “giving everything to the user” and asking for nothing. That kind of mentality might contribute to the destruction of the software (or destruction of people). Users have a responsibility, they should be encouraged to contribute as much information as possible to fix bugs, and we have the responsibility to facilitate this process as much as possible.

I remember an extreme case of this kind of mentality: The Heartbleed Bug (and OpenSSL is released under a Apache-like license).

Future contributions to the open source community

Several parts of Aseprite are released under the MIT license and we will continue releasing more code with this permissive license in benefit of other projects. We have two long term objectives:

1. Create a MIT licensed library to develop desktop applications. This should include a way to handle crash reports on each platform.
2. Create a MIT licensed Aseprite-CLI to be integrate easily in all kind assets pipelines and third party tools.