Why do licenses exist at all?

Computer programs and code can be protected by copyright law. In Germany this protection cannot be removed. The German Copyright (German: Urheberrecht) grants all right to whoever created the work. Following only this general rule, only the developer could use, modify, share the code he wrote.

This patent right (German: Verwertungsrecht), which the creator of a work holds automatically with creation, can be transferred to other persons as a whole or partially, for example a developer might transfer his patent right to his employer. Therefore the creator of a work and the holder of the patent right can be different persons.

The German Copyright has a quite strict understanding of who has and has not the right to use, modify and share the work. To transfer these rights, normally an individual contract was needed. Some people desired code to be free and modifiable by everyone, without the need to individually transfer the rights to the code. Quite like you could buy a bike and then also inspect and modify it, without having to ask the manufacturer first.

Because in German Copyright one can not simply decide to not have the patent right for the work one has created, people used the tool of the copyright, namely licenses, to offer the right to the work to everyone (Free Software). To use the right to share and modify, first the code had to be published: open sourcing the code is the answer.

Free and Open Source Software

Open source literally only means to make the code available to the public. This does not necessarily have to be done with a version control tool, though this is quite popular, even providing the code on individual request can be understood as open source. If the code is publicly available, many eyes with knowledge of many different fields check on it, vulnerabilities and need for general improvement are noticed quickly.

While information about need for improvement on proprietary code by external persons often lead to legal consequences against those who speak out, evidently interfering with finding and closing of vulnerabilities, open sourcing can lead to an improvement of the code, both security-wise and usability-wise.

Open Source also encourages the permission to everyone to modify the code, unlike code-available programs. It is self-evident though, that the original open sourced code may not be tempered with, unless permission individually granted. If someone wants to make a modification, he may fork the original code and then, on his own fork, apply the modification.

Free Software on the other side strongly emphasizes the freedom of the user, which, more as a side effect, is only possible if the code is generally accessible. A developer of Free Software does not primarily open source his programs due to the technical and economical advantages, but wants to actively shape the society towards a higher standard of freedom of the individual. For the resulting program there is hardly any difference though.

In a nutshell you can roughly put it, that Open Source is a description of software, namely that the source code is accessible and modifiable, and Free Software is the ethical framework of freedom, which may or may not be the reason for open sourcing. To have an unifying term, FOSS can be used, which stands for Free and Open Source Software, or FLOSS, which adds Libre. For the user of FOSS-programs, the distinctions in the definitions don't result in any real difference.

For a FOSS-license to be effective, it has to be issued by the holder of the patent right. A program, which is open sourced by breaching its proprietary license, is not a FOSS program and is therefore not legally usable by the public, and a "license" attached by the illegally releasing person is not binding in the way, that the program would somehow be free to use. Just like a proprietary license remains effective even after illegal release of the code, a FOSS license remains effective even when e.g. maintenance is suspended. An amendment to the license or change of license is possible, but the former legal use of the software does not retroactively breach the new license terms. An amendment to the license only becomes effective from the day of the amendment onwards.

Embedded Linux

Embedded Linux is an Embedded Operating System, which is based on the Linux kernel. There are in general three layers of the system:

• the hardware
• the kernel and the basic operating system
• the individual applications

The Linux kernel is Open Source (GPL-v2) and therefore accessible, modifiable, shareable. FOSS embedded systems have the advantage of being flexible and can therefore be tailored to the exact needs, may therefore be lighter and faster, and involve a multitude of intellectual resources worldwide. With regular updates an Open Source System in generally more secure than a comparable proprietary system.

Especially in the commercial environment it may be noted, that with open source software there exists no vendor-lock-in and with time and practice even a complete in-house support and maintenance is possible. Nevertheless, open source systems may still be vulnerable infrastructure, so support and maintenance by a specialized service provider is recommended. Just like everybody could build or modify a bike, but only skilled professionals know, which component is useful for what usecase and how to assemble it, so that the bike is suitable or the intended usecases.

License management

With accessible sourcecode there is another characteristic to open source software: several licenses, which conditions need to be met. While proprietary software includes licenses as well, it normally is already cleared during acquisition that the software may be used in the intended way and only afterwards one gets to check on the program.

It is different for Open Source Software though, as everything lies open from the start and could be, hypothetically speaking, used by everyone. If one is allowed to use a program though, that's a different story - the license. For open source software there often is no vendor to contact and ask, if the software may be used in the intended way. Instead, openly accessible licenses are included in the software for the potential user to read.

There are a handful of widely spread licenses out there, of which the license terms become well known to every considerate user just by using FOSS-programs. One could for example name the GPL-v2 and GPL-v3, the LGPL, the BSD-License, and some more. But the patent right holder is not bound to these licenses, of course he can just as fine invent an own license. That is why one can always encounter code, which is not licensed under some well- known license, but some quite unique conditions. Just like with widespread licenses one has also to comply with rather exotic licenses, if one wants to use the program which is licensed under it.

The most common ways to include a license in a program is either a license-file (also called copying-file), or a license-header in every file of the program. It is vital to check on the license conditions for every program one wants to use and, at least for licenses one is not familiar with, check for compatibility with the intended use and also with modifications one maybe wants to add the the existing code. A breach of license conditions is a violation of the patent right, as in order to use the program one has to first consent to the license terms. Therefore the consent to the license terms is implied by use. If the efforts to a good license management are evident, the reactions to minor inaccuracies are in general rather clement. License management should, as always when working with IT, be well documented. This not only sheds light on what parts still need more care, but also makes work for a successor or newcomer in the compliance team easier.

Out there are many individuals as well as companies, who have decades of know-how in license management and who developed some good tools to make the life of the compliance team easier. For users of PTXdist there is among others the command ptxdist make license-report which gives out pdf-file of the licenses, including license text if traceable, of all programs used in the BSP.

Generating the license report helps with license management, as it is a quick (and readable by lawyer) overview, from which one has a good start. If a license is only stated with its name or if questions regarding compatibility remain, SPDX (Software Package Data Exchange) is helpful, as all common licenses are listed there with their respective conditions.

Many developers use scripts to compare license texts, therefore it is strongly recommended to use the same wording for the same matter. As there already are many licenses out there, there is for almost every need an existing license. Try for example choosealicense. Whenever possible, one should choose a pre-existing license. If absolutely required to have an individual license, writing an own license text should at least not be the time to shine with originality regarding the wording.

so what are the consequences?

FOSS programs and all of their advantages are strictly tied to the compliance of their respective licenses. This is simply the state of our legal system, in which all creative work belongs to the creator. It falls to the creator of the work, to allow individuals or the general public to use it. If a creative work does not state a license, the creator holds all the rights to it - it is not usable by anyone else.

On the other side there are also some licenses which go even further by setting additional conditions. Quite common is the condition that binds the derivative work to the same (or pre-defined similar) terms that the original work is licensed under. I'd like to point out the so-called Copyleft licenses, which demand that a derivative work of a copylefted original work shall be copylefted as well. This means, that the derivative work needs to be open sourced according to the respective terms and must include a Copyleft notice, so that derivative work of the derivative work shall also be licensed under a Copyleft license. If it excludes commercial use or not is subject to the respective Copyleft license. This is called Copyleft Effect.

It is like the Copyleft is playing a trick to Copyright: using the tools of the Copyright, which were originally meant to exclude to public from using the work, to instead make it publicly accessible. Just as we think of hacking as creative handling of technology, Copyleft is to some extent creative handling of law: one digs deep into the possibilities of the Copyright and absolutely perfectly uses them to achieve a goal not intended by legislature, which nevertheless is without doubt legal.

The advantage of this kind of license is the continuous spread of Open Source Software, so that the society may profit from the growing number of programs. The apparent disadvantage is, that developers of proprietary code don't get to profit from that. The Copyleft effect is to be respected when using copyleft FOSS programs.

The above listed licenses are to be seen as an incomplete example.

Creative Commons licenses could be used for software, or a software license for other creative work. But because these are pre-defined licenses, there might exist problems which are not typical for the intended usecase of the license.

Copylefted programs are not necessarily a problem when developing proprietary software, as only derivative works are governed by the license of the original code. A creative work is considered derivative according to German Copyright, when the original work gets mixed up with some new work. For programs this means, that when creating a joint process, the emerging new program is a derivative work - the Copyleft of the original program applies. But when two programs run independently of each other, even on the same system, they both are considered original works of their own - the Copyleft of one of the programs does not govern over the other program. The same applies to incompatible licenses in general. For embedded-systems using FOSS components it is therefore very important, that proprietary software runs on the highest layer, which is left out when releasing, and that the system runs fine even without that part. Both PTXdist and Yocto contain this layering option. Developers should ensure that the layering is correctly done. In no case should the release of the open source components and their derivative work be withheld to protect the proprietary components. This would be a breach of license and moreover can be easily avoided.

While licenses are very prominent in the FOSS universe, they are no singularity of Free and Open Source Software. Licenses and the consequential license management are always inevitable, to be permitted to profit from external code at all, be it proprietary or open sourced code. License management and Compliance must therefore ensure the compatibility of the license terms of the programs used, regarding both the compatibility of the used programs to each other and towards the final product. But in the end, and maybe with a little help of some already existing tools, that's not rocket science at all.