Jump to content

Ict@innovation: Free your IT Business in Africa/1-4

From Wikibooks, open books for an open world

Module 1.4 FOSS Licensing Models

[edit | edit source]

Duration

[edit | edit source]

1:00hrs

Delivery method

[edit | edit source]

For instructional purpose, it is advised that trainers/lectures use a combination of lectures and discussion sessions as a major means of delivering this module.

Introduction

[edit | edit source]

There is a wide range of licensing models, in proprietary or free and open source environment. The information in this section is focused on free and open source model licensing, on three types of licenses and the difference between them.

General description of common licenses

[edit | edit source]

Since this applies to all other authors of software as well, it means that any piece of software is originally proprietary, meaning that no one but the original author (or, if the author has sold the rights of use and distribution to someone else, the copyright holder) has legal control over how it is used and distributed.

This also means that the users of those programs do not enjoy any freedom in relation to the software. Without the express permission of the copyright holder, they may not redistribute the program, or change it and adapt it to their needs.

Yet the power to change an existing program and adapt it to one's own needs is the keystone of the ideas behind FOSS. Richard Stallman, founder of the GNU project and the Free Software Foundation, has defined four basic freedoms that a program must provide users with if it is to be called “free”:

  1. The freedom to run the program, for any purpose (freedom 0).
  2. The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
  3. The freedom to redistribute copies so you can help your neighbor (freedom 2).
  4. The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

As the rapid global growth of FOSS has shown, these freedoms are clearly desirable. So how does one move a piece of software from its original, proprietary state into FOSS?

This is accomplished with a license. Wikipedia summarily describes a license as follows:

The verb license or grant license means to give permission. The noun license (license in British spelling) refers to that permission as well as to the document memorializing that permission. License may be granted by a party ("licensor") to another party ("licensee") as an element of an agreement between those parties. A shorthand definition of a license is "a promise (by the licensor) not to sue (the licensee)."

A license is thus a document which the copyright holder issues to the user, and which determines what the user is allowed to do with the software program in question.

In the world of proprietary software, this license is usually called an “End User License Agreement” (EULA), and often carries far-ranging restrictions on the use of the program, which exist in addition to those imposed by copyright law.

Licenses as the key to FOSS

[edit | edit source]

FOSS uses licenses differently. Here, they are a means to free the user of the program from the restrictions not only of an End User License Agreement, but also from those which copyright law imposes by default.

The basic process for releasing a program as FOSS is as follows:

  • You write a piece of software. This automatically makes you the copyright holder, giving you far-ranging powers to decide how that piece of software can be distributed.
  • You assert your copyright by adding a copyright notice to the software, showing the copyright symbol, your name and the year of creation or publication (“© John Miller 2009”).
  • With your power to decide about the distribution of the program, you decide that you want to distribute it as FOSS. This means that your program will give all its users the four freedoms listed above.
  • You select a FOSS license that suits your needs, and integrate it into the source files of your program, as well as adding a file with the license text (usually called license.txt).
  • You distribute your program, either gratis or for a fee.

From this process, it becomes clear that FOSS uses the license as a trick to get around the restrictions which copyright law normally imposes on the user. After asserting your copyright on the program, you use this right to decide that your software should give the user certain freedoms beyond those afforded by copyright law. You also abstain from imposing an intrusive EULA on your users.

The license gives the users of your program legal certainty that they enjoy those freedoms, and that you will not take legal steps to deprive them of those freedoms.

Whether a program is FOSS or not is determined by the license under which it is distributed. If that license provides users with the four freedoms listed above, then the program is FOSS. If not, it is non-free (or proprietary).

Note that releasing a piece of software as FOSS does not mean that you relinquish all your rights over it. There is a growing number of court cases in which the copyright holder of a FOSS program has sued a company for copyright infringement, after that company had built the FOSS program into products without complying with the license, e.g. by not providing source code to the buyers of the product.

Basic types of FOSS licenses

[edit | edit source]

All free software licenses must grant people all the freedoms discussed above. However, unless the applications' licenses are compatible, combining programs by mixing source code or directly linking binaries is problematic, because of license technicalities. Programs indirectly connected together may avoid this problem.

FOSS licenses can be categorised as belonging to one of the following types:

  • Public domain software - the copyright has expired, the work was not copyrighted or the author has abandoned the copyright. Since public-domain software lacks copyright protection, it may be freely incorporated into any work, whether proprietary or free.
  • Permissive licenses, also called BSD-style because they are applied to much of the software distributed with the BSD operating systems. The author retains copyright solely to disclaim warranty and require proper attribution of modified works, but permits redistribution and modification in any work, even proprietary ones.
  • Copyleft licenses, the GNU General Public License being the most prominent. The author retains copyright and permits redistribution and modification provided all such redistribution is licensed under the same license. Additions and modifications by others must also be licensed under the same 'copyleft' license whenever they are distributed with part of the original licensed product. The Open Source Initiative (OSI) , http://www.opensource.org/licenses, which acts as an FOSS advocating body for the FOSS community also maintains and updated different types of FOSS licenses, listed by by name and category.

Dual License

[edit | edit source]

Dual licenses can both mitigate license interoperability issues (such as GPLv2 vs. GPLv3), while also providing the foundation for FOSS business models where commercial use of the code generates revenue.

In such dual-licensing scenarios, different terms are granted based on how the resulting code will be distributed. For new code which will be distributed under GPL or open source licenses, a corresponding GPL or open source license is granted. But for commercial vendors who distribute the licensed code with their proprietary products, and do not license and distribute their own source code under the GPL, a commercial license is granted, and usually associated with licensing fees or other revenue sharing. The MySQL database platform has a good example of dual licensing on their license page athttp://www.mysql.com/about/legal/licensing/.

While best practices for FOSS licensing are hard to generalize, the following assertions are safe to make:

  • The GPL still represents the highest ideals of FOSS licensing, and should be considered in any licensing decisions. However factors including dependent code licenses, partnering agreements, target markets, business models and institutional constraints may prevent GPL from being the best choice. On the other hand, GPL licensing provides a “moral high ground” in FOSS distribution, and saves projects from having to explain and defend why they opted for “less free” licensing.
  • Dual or multiple license approaches should also be considered when looking to increase uptake and adoption of FOSS projects. While such licensing models have the effect of “watering down” pure GPL offerings, they provide flexibility to those who otherwise might not be able to incorporate the available code. FOSS License Exceptions such as those mentioned above also alleviate code interoperability blockages.

In any case, creating a new FOSS license should only be considered as a very last resort. While unique institutional and legal requirements such as those associated with the OpenMRS project can mandate a specialized license, new licenses only clutter the landscape. All efforts should be made to not only use an existing license, but to use one which is in broad distribution, so as to maximize the re usability of the licensed code.

Resources for FOSS licenses

[edit | edit source]

Module 1.4: ASSESSMENT

[edit | edit source]
  • Exercise 1: Debate and answer the following questions
  • What is a software license?
  • What are the differences between the licenses for proprietary software and free and open source software?
  • Which are the free software licenses in this module?
  • Beside the licenses in this module search and list two more FOSS licenses
  • What do you understand with dual license?
  • Find and discuss at least 1 (one) example of a dual-licensed FOSS solution.


Previous Chapter | Next Chapter