1.3 Lesson 1

First of all, “free” in the context of free software has nothing to do with “free of charge”, or as the founder of the Free Software Foundation (FSF), Richard Stallman, succinctly puts it:

Regardless of whether you have to pay for the software or not, there are four criteria which constitute free software. Richard Stallman describes these criteria as “the four essential freedoms”, the counting of which he starts from zero:

The emphasis on the idea of freedom is also consistent insofar as every freedom movement is directed against something, namely an opponent who suppresses the postulated freedoms, who regards software as property and wants to keep it under lock and key. In contrast to free software, such software is called proprietary.

For many, free software and open source software are synonyms. The frequently used abbreviation FOSS for Free and Open Source Software emphasizes this commonality. FLOSS for Free/Libre and Open Source Software is another popular term, which unmistakably emphasizes the idea of freedom also for other languages other than English. However, if one considers the origin and development of both terms, a differentiation is worthwhile.

The term free software with the definition of the described four freedoms goes back to Richard Stallman and the GNU project founded by him in 1985 — almost 10 years before the emergence of Linux. The name “GNU is not Unix” describes the intention with a wink of the eye: GNU started as an initiative to develop a technically convincing solution — namely the operating system Unix — from scratch, to make it available to the general public and to improve it continuously with the general public. The openness of the source code was merely a technical and organizational necessity for this, but in its self-image the free software movement is still a social and political — some also say ideological — movement.

With the success of Linux, the collaborative possibilities of the Internet, and the thousands of projects and companies that emerged in this new software cosmos, the social aspect increasingly receded into the background. The openness of the source code itself changed from a technical requirement to a defining feature: as soon as the source code was visible, the software was considered “open source”. The social motives gave way to a more pragmatic approach to software development.

Free software and open source software work on the same thing, with the same methods and in a worldwide community of individuals, projects and companies. But since they have come together from different directions — one social and one pragmatic-technical — there are sometimes conflicts. These conflicts arise when the results of the joint work do not correspond to the original goals of both movements. This happens especially when software reveals its sources but does not respect the four freedoms of free software at the same time, for example when there are restrictions on disclosure, change, or connections with other software components.

The license under which the software is available determines which conditions a software is subject to with regard to use, distribution and modification. And because requirements and motives can be very different, countless different licenses have been created in the FOSS area. Due to the much more fundamental approach of the free software movement, it is not surprising that it does not recognize many open source licenses as “free” and therefore rejects them. Conversely, this is hardly the case due to the much more pragmatic open source approach.

Let’s take a brief look at the actually very complex area of licenses below.

The already mentioned Free Software Foundation (FSF) has formulated the GNU General Public License (GPL) as one of the most important licenses for free software, which is used by many projects, e.g. the Linux kernel. In addition, it has released licenses with case-specific customizations, such as the GNU Lesser General Public License (LGPL), which governs the combination of free software with modifications made to code where the source code for the modifications do not have to be released to the public, the GNU Affero General Public License (AGPL), which covers selling access to hosted software, or the GNU Free Documentation License (FDL), which extends freedom principles to software documentation. In addition, the FSF makes recommendations for or against third-party licenses, and affiliated projects such as GPL-Violations.org investigate suspected violations of free licenses.

The FSF calls the principle according to which a free license also applies to modified variants of the software copyleft — in contrast to the principle of restrictive copyright which it rejects. The idea, therefore, is to transfer the liberal principles of a software license as unrestrictedly as possible to future variants of the software in order to prevent subsequent restrictions.

What sounds obvious and simple, however, leads to considerable complications in practice, which is why critics often call the copyleft principle “viral”, since it is transmitted to subsequent versions.

From what has been said it follows, for example, that two software components that are licensed under different copyleft licenses might not be combinable with each other, since both licenses cannot be transferred to the subsequent product at the same time. This can even apply to different versions of the same license!

For this reason, newer licenses or license versions often no longer grasp the copyleft so rigorously. Already the mentioned GNU Lesser General Public License (LGPL) is in this sense a concession to be able to connect free software with “non-free” components, as it is frequently done with so-called libraries. Libraries contain subroutines or routines, which in turn are used by various other programs. This leads to the common situation where proprietary software calls such a subroutine from a free library.

Another way to avoid license conflicts is dual licensing, where one software is licensed under different licenses, e.g. a free license and a proprietary license. A typical use case is a free version of a software which might only be used when respecting the copyleft restrictions and the alternative offering to obtain the software under a different license which frees the licensee from certain restriction in return for a fee which could be used to fund the development of the software.

It should therefore become clear that the choice of license for software projects should be made with much caution, since the cooperation with other projects, the combinability with other components and also the future design of the own product depend on it. The copyleft presents developers with special challenges in this respect.

On the open source side, it is the Open Source Initiative (OSI), founded in 1998 by Eric S. Raymond and Bruce Perens, which is mainly concerned with licensing issues. It has also developed a standardized procedure for checking software licenses for compliance with its Open Source Definition. More than 80 recognized open source licenses can currently be found on the OSI website.

Here they also list licenses as “OSI-approved” that explicitly contradict the copyleft principle, especially the BSD licenses group. The Berkeley Software Distribution (BSD) is a variant of the Unix operating system originally developed at the University of Berkeley, which later gave rise to free projects such as NetBSD, FreeBSD and OpenBSD. The licenses underlying these projects are often referred to as permissive. In contrast to copyleft licenses, they do not have the aim of establishing the terms of use of modified variants. Rather, the maximum freedom should help the software to be as widely distributed as possible by leaving the editors of the software alone to decide how to proceed with the edits — whether, for example, they also release them or treat them as closed source and distribute them commercially.

The 2-Clause BSD License, also called Simplified BSD License or FreeBSD License, proves how reduced such a permissive license can be. In addition to the standardized liability clause, which protects developers from liability claims arising from damage caused by the software, the license consists of only the following two rules:

The successful development concept of FLOSS and the associated technological progress led to attempts to transfer the open source principle to other, non-technical areas. The preparation and provision of knowledge, as well as the creative cooperation in solving complex tasks, are now regarded as evidence of the extended, content-related open source principle.

This led to the need to create reliable foundations in these areas as well, according to which work results can be shared and processed. Since the available software licenses were hardly suitable for this, there were numerous attempts to convert the specific requirements from scientific work to digitized works of art “in the spirit of open source” into similarly handy licenses.

By far the most important initiative of this kind today is Creative Commons (CC), which summarizes its concerns as follows:

With Creative Commons, the focus of rights assignment goes back from the distributor to the author. An example: In traditional publishing, an author usually transfers all publishing rights (printing, translation, etc.) to a publisher, who in turn ensures the best possible distribution of the work. The significantly changed distribution channels of the Internet now put the author in a position to exercise many of these publishing rights herself and to decide for herself how her work may be used. Creative Commons gives the opportunity to determine this simply and legally reliably, but Creative Commons wants more: authors are encouraged to make their works available as a contribution to a general process of exchange and cooperation. Unlike traditional copyright, which gives the author all the rights that they can transfer to others as needed, the Creative Commons approach takes the opposite approach: the author makes her work available to the community, but can choose from a set of features those that need to be considered when using the work — the more features she chooses, the more restrictive the license.

And so the “Choose a License” principle of CC asks an author step by step for the individual properties and generates the recommended license, which the author can last assign to the work as text and icon.

For a better understanding, here is an overview of the six possible combinations and licenses offered by CC: