Open Source and License Keys - A Contradiction?

We get lots of questions about Structr’s open source licensing model and our license keys system. This article will answer the most frequently asked questions.

Since we introduced a license key system with our release 2.1 of the Structr platform (https://structr.org/download), we get lots of questions like “Structr is Open Source but requires License Keys. Isn’t that a contradiction?”

It is not, but apparently, there’s still a lot of confusion about the concept of Open Source/Free Software and commercial usage.

Open Source

Open Source software (in its broadest definition) is software that is made available to the public in form of source code that can be compiled to an executable program, distributed with or without a compiled, runnable version.

Typically, an Open Source Software (OSS) package is distributed under an Open Source License. It does not necessarily imply that the software is free (of costs, often used in the expression “free as in beer”, in contrast to “free as in speech”), although still many people seem to think that exactly this always is the case. To know precisely what is allowed with the source code of a specific OSS program or package, it’s essential to look at the license it comes with.

As this blog post is not intended to discuss the specifics of open source licenses, please refer to https://opensource.org/licenses to get a good overview of the most popular OSS licenses. Summarized, there are basically two kinds of OSS licenses: Permissive (BSD or MIT-style) and non-permissive (e.g. GPL/AGPL, also called copyleft).

Both basically guarantee that their users have the freedom to use, modify and redistribute the code, but only permissive licenses permit proprietary derivative works. A derivative work is a new, separate creation (here: a software) that uses major elements of an original work (called the underlying work), so copyleft licenses ensure that any derivative work will remain freely available.

Monetizing Open Source Software

Regardless whether they are backed by a large community or a company: Most open source projects provide a large value to their users and are of good quality. Furthermore, they are mostly well documented, secure and easy to use and to integrate into own projects. Many people think that, in total, open source projects or products are better than their proprietary counterparts.

And yet, many people think that open source software has to be free (as in beer) and wonder about people or companies calling a price in exchange of the right to use their software. One reason for this could be the trend that big companies like Google or Facebook are contributing to or even creating a lot of free software published under permissive licenses such as Apache, MIT or BSD. It’s no surprise because they earn their money by advertising or providing paid services, so software development itself is not meant to generate profit at all but rather creating closed ecosystems to attract and bind developers.

Dual-Licensing

Many OSS projects of great value are published under the GPLv3 and/or AGPLv3. GPL (and its variant AGPL for hosted software or services) are both copyleft, non-permissive licenses. That means that anyone can take any part of the OSS project and use it to create their own, new software or services, and even to use it commercially. The only thing the GPL/AGPL licenses will make sure is that the derivative work (the new software or service) has to be published under the same license (GPL or AGPL).

If a person or company doesn’t want to publish their own software or service based on or using copyleft-licensed components, they can choose to buy a commercial license from the maintainers or distributors of the OSS package they want to incorporate into their own solution. We at Structr offer a commercial license which releases any paying customer from the restrictions of the GPL/AGPL.

In short: With dual-licensing, people have the choice of contributing to the project either in the form of their code, or buy a license. Both ways, they help supporting a project, be it backed by a community of volunteers or a company.

Structr’s License Model

As you might know, the Structr project is not funded by a big company or VC investors. Everything we built over the past couple of years was only possible because the small company behind the Structr project, Structr GmbH, was able to earn some money by doing custom development and project work.

Since the release 1.0 in 2015, we’re asking commercial customers for a license fee because we think it’s fair to get something back in exchange for a software we put many thousands of hours of serious work into. But to be frank - it didn’t work very well during the first two years.

A typical pattern back in 2015 and 2016 was that companies and even more individual people were quite interested in our software and frequently asked for support (to be fair: Documentation and usability weren’t as good as today). With Structr being an open source project, people were able to download and compile the software, and most of them were expecting to get support, bug fixes etc. for free because it’s apparently what they expected from Open Source.

Providing support to people evaluating a software takes time, especially if the software is young and developing fast. And it can be frustrating to see that people are not willing to spend even smallest amounts of money in exchange for many hours of writing e-mails, support tickets or even phone calls with individual help, even touching completely unrelated topics like JavaScript coding or helping to configure their operating system properly. At this point, it should be noted that not everyone was acting like this, so a big thanks goes out to the small but very helpful group of people and companies that supported us with money and even paid some license fees. Without you, the Structr project wouldn’t be possible, and even more wouldn’t make any sense.

License Keys as a Secret of Success

In 2017, our frustration about countless hours spent on supporting people not contributing at all to the project grew. Then we made an important decision and introduced license keys, and this required us to group functionality into free (as in beer) vs. paid editions/modules. To be clear: Everything in the Structr project is still Open Source and Free Software (as in speech), and everything is published on GitHub. But despite being open source, we have built security mechanisms into Structr on two different levels:

Restricted Compiliation

Compiling the published source code into a runnable program can only be done by us because the software ships with a certificate we exclusively own the private key for. This is to make sure our customers run official copies only, as we can only guarantee (in terms of liability) for official versions of our product.

You might ask “but it’s open source and so is the certificate - we could create our own certificate/private key and compile it”. Yes, that’s on purpose, and that’s why our software is still eligible to be called Open Source and Free Software, because you can modify the source code and build and use your own version. But by modifying the certificate, you create a derivative work which has to be published under the same license (GPL in this case).

Restricted Runtime

The second building block of our licensing policy is that you can run a Structr instance without any license key on the functionaliy level of the Community Edition. To enable more advanced functions, our users have to obtain a license key for the add-on modules they require.

The reason behind this is that we have to cover our support and development efforts for the more complex features which deliver a higher value, require a certain level of explanation and are more expensive to maintain.

We think that the packaging options with a free Community version and fee-based add-on modules are a good compromise and reflect the fairness we expect from our users.

Resumee

Since introducing the new licensing system, we experienced a strong growth in license revenue and number of customers. We think that this is caused by two effects:

First and foremost, we could spent more time enhancing the software and its documentation so more people and companies are attracted to the more recent versions.

Secondly, we think that the target audience is somewhat filtered in the way that we get a higher percentage of requests from people or companies that are seriously interested, see the value in our software and can even think about paying a license fee in exchange for a good software and great services rendered by its creators.