I’ll describe the most common open-source software licenses for libraries or software you can find in the internet. If you’re ever planning to release your application to public, it’s important to know some basics about licenses, as costs of violating those are very high if you’d get sued. I’m also attaching my recommendations for usage of those licenses. Please not that I’m not a lawyer, I do not guarantee that statements in this post are correct.

Notable licenses

So, here are notable licenses, from the least to the most restrictive ones (for usage in commercial applications):

  • Public Domain – you can do whatever you want with the code or its binaries published on this license, there are no limitations and you don’t even need to mention authors. That’s a good license for educational materials like tutorials or code snippets.
  • MIT – no real limitations, you only need to include copy of its copyright notice with your software that states mostly about lack of warranty. This is a good license if you want to be credited for creating your software, but release it for free to everyone – both to commercial and open-source developers.
  • BSD – there are few versions of it, but its usage is the same as MIT license. Only that some versions treat about not using authors to promote derived products (3-clause BSD/new BSD) or about forcing to include notice about authors in advertisments (4-clause BSD/old BSD). Usage of this license is very similar to MIT license, only that it imposes few more restrictions.
  • LGPL (Lesser General Public License) – open-source license used mainly for libraries that allows you to link dynamically with its unmodified version without impact on licensing your software. In case of static linking, direct usage of library’s sources or modifications to the library, your software (or only the modifications made to the library) must be also released under LGPL (or optionally GPL) license. That’s called the copyleft virus – this license makes sure that the library will stay LGPL and nobody (except copyright holders) can make it closed-source in the future. Another restriction is that you must make code of this LGPL software available to everyone you distribute binaries to. This license is good for libraries that you want to be developed by open-source community, making sure that no company will take it over and starts releasing new proprietary versions of it (perhaps killing the original open-source development). This license has few downsides though – there are quite a lot of applications in which you can’t link libraries dynamically, for example in applications developed for iOS that go to Apple’s App Store.
  • GPL (General Public License) – open-source license with the copyleft virus in its full form. Linking to or using source of GPL software in any way forces your own software to be GPL too. Also, like in case of LGPL, you have to provide sources of GPL software when distributing binaries. This license is primarily meant for applications, but some libraries also use it. It’s good for open-source application projects that are meant to be developed by open-source community. In case of applications, GPL doesn’t do much harm for commercial usages, but using it for libraries is entirely different. It effectively shuts off most of commercial usages, as commercial developers will usually have to just use another non-GPL library with similar functionality or write they own one.

Note: there is a GPL linking exception clause that some libraries use to maintain their code open-source (GPL), but at the same time allow linking (static or dynamic) them to your software under license of your choice. This works like LGPL, but is less restrictive in terms of allowing any kind of linking.

GPL vs non-GPL

There are many arguments for and versus GPL and I think this preference is mostly connected with how close are you to writing commercial applications.

Taking into consideration that open-source developers won’t maintain their software forever and that money is the thing that opens opportunities for big and quality software projects, I suggest going with MIT license if you want your small/medium (non-commercial) library project ever to be used. Or GPL with linking exception if you have open source community that would like to develop it.

As for (non-commercial) applications, MIT is always a good option. Choosing GPL here could be a good idea if you really have open-source community that would be interested in developing it and you want to keep it open-source.

Mixed GPL/LGPL/commercial

There are many libraries out there that offer you a choice:

  • GPL or commercial – some companies offer their libraries either on GPL license (for open-source projects) or on commercial license. I guess that’s a good way to make your software known better (in order to sell commercial versions later) and it should work for small or medium libraries. Example: Ext JS.
  • GPL or LGPL or commercial – there are libraries out there where you can choose either of those 3 licenses. However offering LGPL means that other companies can use that library for free. This approach could be successful for large projects that can get to be widely used (thanks to LGPL + high quality content) and could also bring money from support, warranties and additional features in commercial licenses. Example: Qt.

“Bypassing” GPL licenses

First LGPL. Don’t try to effectively include LGPL library in your executable (as if statically) by just linking dynamically and then putting it in resources or something. License doesn’t really treat about “-shared” gcc option, but describes that LGPL is effectively GPL with exception of using very small parts of the code (such as headers) to communicate with the library.

Second is GPL (or LGPL). All software derived from another GPL software must be GPL. This won’t change, but that doesn’t mean that a software that’s just using GPL software not as its core can’t be non-GPL or even commercial. This is all about the definition of derived work here. So if you’ll use external GPL application to do some operation for your application – say compile (using GPL gcc) or unzip (LGPL using 7zip), you should be fine, especially if this is just an optional part of your application or you allow user to configure your software to use other replacements. For example Qt Creator does just that by letting you select your compilers (like gcc) in its IDE. You have to make sure your work isn’t effectively derived as in case of, say, writing an executable wrapping all GPL library functions into command-line and then using resulting application through some weird protocol just as you would use the original library. Remember that it’s always treading on thin ice, since this is all about “how much” derived your work is.

Qt comes with QtTest library, which lets you write your own test suites for internal and GUI components. However, its usage together with your application in an easy to maintain way is not so obvious. In this tutorial I’ll focus more on framework and ease of usage and less on how to write contents of tests themselves. There is already a tutorial on how to write QtTest unit tests. I’m using Qt 4.8 for this tutorial, but those methods and concepts can be used in Qt 5 too.

Some code to test

I created an example project, which is a simple math expressions parser with GUI. I’m sharing it under Public Domain license on bitbucket, so use is as you please. There are three non-GUI classes there:

  • Token – class representing a single entity in math expressions – a number or an operator (+, -, *, /),
  • MathTokenier – class used to split a string into tokens while validating input,
  • MathParser – class used to parse and compute expression consisting of sequence of tokens.

Writing test suites

Having some decent chunk of code, we can now move on to testing it. Tests are grouped into test suites. Test suite is represented by a normal QObject class with test functions being her slots. There’s a special naming convention used here:

  • Tests have “test” prefix of their method name,
  • initTestCase() and cleanupTestCase() are methods called before and after execution of the whole test suite,
  • init() and cleanup() are methods called before and after execution of each test in the suite.

Structure is as below:

#include <QtTest>

class TestSomething : public QObject {

private slots:
    // functions executed by QtTest before and after test suite
    void initTestCase();
    void cleanupTestCase();

    // functions executed by QtTest before and after each test
    void init();
    void cleanup();

    // test functions - all functions prefixed with "test" will be ran as tests
    void testSomething();

Any function not conforming to those name conventions will be just ignored and not ran as test. So we can safely create helper functions. I’d like to note that this whole mechanism work well thanks to QObject’s meta properties which lets you list and access all your slots dynamically (and much more).

Lets create such a test suite in test/ folder (or some other location). It’s a good idea to write some stubs at the beginning to see if everything works well. So lets do this:

void TestTriangleIntegral::testStubPass() {

void TestTriangleIntegral::testStubFail() {

After setting everything up well, two messages should pop out after running those tests:

PASS   : TestSomething::testStubPass()
FAIL!  : TestSomething::testStubFail() 'false' returned FALSE.

Running test suites

QtTest library is used by making a separate executable that runs your tests. If you’d do this by creating another project, you’d have to maintain two lists of source files, libraries, flags etc. I’ll describe the approach I’ve taken to avoid that.

The default way is to use QTEST_MAIN macro, but that lets you use just one test suite per executable. Lets use another approach by creating a main() function for tests in test/main.cpp in the following fashion:

#include <QtTest>
#include "testsuite1.h"
#include "testsuite2.h"

int main(int argc, char** argv) {
    QApplication app(argc, argv);

    TestSuite1 testSuite1;
    TestSuite2 testSuite2;
    // multiple test suites can be ran like this
    return QTest::qExec(&testSuite1, argc, argv) |
            QTest::qExec(&testSuite2, argc, argv);

Note usage of “|” instead of “||”. This is in order to run all tests, even if one of test suites failed.

That’d be enough to run a test suite if it was a standalone application. But since we don’t want to maintain two applications, we’ll share the build between them.

Lets create a new Build Configuration to produce unit tests executable while also including to the build all code used in original application. Go to Projects > Build Settings and duplicate your debug configuration naming the new one “Test”. Then go to Build Steps, select qmake step and add additional argument “CONFIG+=test”. “Additional arguments” is a place in which you can define some additional parameters for your build. We’ll be using this together with conditionals in Qt project file (.pro) to create test build.
Note: this step has to be repeated for each checkout of your project, as those settings are stored in “.pro.user” file (which shouldn’t be checked in as it contains machine-specific build information).

QtTest application differs from our application only by using different main function and having additional test suite classes. If you didn’t put much code into your main function (which should have been the case), you should be fine with just removing it from test build. You can use the “test” configuration argument defined earlier to incorporate that. Lets create the test build by:

  • adding QtTest library,
  • renaming our target executable to one with test name (optional),
  • removing original main.cpp file (in order to avoid conflicts),
  • adding sources of our test suites.

Assuming main.cpp contains your original main function, test/main.cpp contains main function for tests and test/testSuite* contain test suites, you can use following code:

test {
    message(Test build)
    QT += testlib
    TARGET = UnitTests

    SOURCES -= main.cpp

    HEADERS += test/testSuite1.h \

    SOURCES += test/main.cpp \
        test/testSuite1.cpp \
} else {
    message(Normal build)

In case of normal build it only displays message. But in case of test (CONFIG+=test) build, it also does changes mentioned above.

Writing test methods

Content of those tests is just like normal test cases – initialize some data, run tested code and check if everything is okay. I won’t go into details – QtTest tutorial elaborates enough on them. Just remember to browse through available macros and use QVERIFY/QVERIFY2 and QCOMPARE instead of Q_ASSERTs. See test/testMathTokenizer.cpp in my example project for examples of test methods themselves. If you want to write more exhaustive tests, have a look at Qt’s data-driven tests. There are also GUI tests, but those work well mainly on widgets, as your main window usually has private access to UI elements.

This setup allows for development in which you often write tests and run them, but is not quite as convenient as to hit some key combination to run your tests and display red/green. Also switching between builds (Debug/Test) is required if you want to alternate between running tests and application. So test-driven development is possible, although requires more work than in other libraries/languages.