Foreword: This guest whitepaper offers suggestions on creating Linux stacks that are fully compatible with proprietary software. It was written by three Access employees, and at times uses the Access Linux Platform (ALP) as an example of such a stack.

---

Open Source Best Practice

by Yann Cheri, Anna Schaller, Greg Wilson

Note: The use of the word “free” throughout this document should be interpreted as a reference to freedom rather than gratuity.

Overview

Linux and more generally open source software are often associated in end-users' minds with free software. For others, such as software and hardware companies that have to deal with the open source landscape, Linux is generally associated with source code redistribution and code license contamination, as well as with intellectual property rights. It is these three points that generate the biggest fears in discussions about embracing the open source software world. The purpose of this document is to debunk myths about open source software and licenses.

Open source software licenses

The Open Source Initiative (OSI) is a nonprofit organization that manages and promotes open source software. It determines whether or not a software license is in line with the OSI's Open Source Definition (OSD), which is based on 10 criteria.

In particular, to be approved by OSI, a license to software must require the free (unrestricted) redistribution of that software, both the binary version and its complete source code. The license terms must also allow modifications and creation of derivative works that must be distributed under the same license terms as the original software.

According to these criteria, the OSI has approved 58 different license schemes so far. The most well known ones are the GNU General Public License (GPL) and the Lesser General Public License (LGPL), both of which are distributed by the Free Software Foundation (FSF).

The terms of the GPL grants users the freedom to use, study, copy, change and redistribute software programs under the condition that the modified source code for those software programs accompany any distribution of the binary files. Entitled Copyleft, this concept advocates free software and subsequent improvements to be given back to the community, such as the GNU system and the Linux Kernel. To enforce these principles, GPL specifies that any software that embeds a GPL licensed program, or a portion of it, automatically inherits the GPL and thus must make its source code available for redistribution. This also applies to software that would either link dynamically or statically with a GPL licensed program. For this particular reason, one talks about license contamination.

The LGPL is just like the GPL but it is less restrictive in the sense that it allows the creation of proprietary software. Indeed, a software program that combines or links software, itself containing a LGPL library or a portion of it, does not inherit from the LGPL. One additional license, the Mozilla Public License (MPL) is interesting to consider. As with the licenses described above, this license specifies that MPL'd source code that is copied or changed must remain under the MPL. However, code under the MPL can be combined in a software program with proprietary files without contaminating them. In other words, this license allows you to take advantage of the benefits of MPL'd source code while creating proprietary software.

The exposure to other components' licenses is an intrinsic factor around open source. Therefore it is necessary for developers to take into account the different license constraints at all phases of development. These constraints are summarized in Table 1.

Table 1: License constraints

Table notes: IP added in such licensed code becomes open source Code that includes such licensed code becomes open source

Now that clarifications have been given regarding constraints associated with GPL and LGPL, it is important to understand where these licenses can be found in a Linux based operating system.

Licenses throughout the platform

Each Linux platform is typically split into two parts that, besides any technical differences, may be subject to different license terms.

The first part, the kernel space, is where Linux itself resides. It contains device drivers, one or more file systems, a scheduler, and optionally networking components and other operating-system dependant code. All of the components that are included in the kernel space, or that are dynamically or statically linked with it, are required to be licensed under the GPL by virtue of the viral nature of the GPL.

Nevertheless, this GPL contamination stops at the edge of the kernel space. Applications that are executed outside of this space and communicate with the kernel solely through system calls (a hardware architecture-dependent mechanism that cedes program control to the kernel), can be licensed under any terms desired by the application owner.

These applications need not be licensed under the GPL, as long as the applications themselves were not developed separately using GPL-licensed code.

Figure 1: License areas in Linux
The second part of the platform, which is exempted from the kernel GPL contamination so long as it contains no GPL components, is the user space. This is the place where typical middleware components and applications with different license types can coexist.

Middleware is defined as code that enables or provides services to user applications. Types of middleware can include databases, interpretive language run-time code (like a Java Virtual Machine), user space network stacks, multimedia software, and so forth.

About intellectual property

Even if the definition of open source advocates source code redistribution for the sake of the community, there are several cases where this cannot be done or may not be desirable due to competitive or otherwise sensitive information. Companies simply don't want to expose what is the heart of their competitive advantage: in a word, their IP.

The only way to protect intellectual property when dealing with open source software is to follow a rigorous process during the development of proprietary code in order to isolate sensitive components from others that are less sensitive, and from others that may infect the whole product. Here is what such a process should include:

• Identify which components constitute the essence of the IP that you most want to keep as proprietary (the “crown jewels”).
• Forbid the improper use of “GPLed” or viral software, and the use of any other open source software that is subject to any other license terms that could require unrestricted delivery or disclosure of the source code for the IP you want to protect.
• Isolate as much as possible the open source components used in the development phase (e.g. keep proprietary components in a common location in the source tree, and open source components in another common location in the source tree).

Several companies, such as Blackduck Software, offer solutions to help determine if source code includes parts of existing open source projects. Such solutions represent an additional way to ensure that IP will not suffer from a contamination.

Developing Software on Linux

User Space Freedom

Most of the software developed on a Linux-based platform targets an execution in the user space.

Therefore, to avoid GPL contamination, the following rules must be observed:

• Do not include GPL code
• Do not include code that derives from preexisting “GPLed” programs
• Do not link to GPL libraries or other GPL program code

However, as stated earlier, simply invoking system routines (making system calls) will not itself result in contamination.

Kernel modules (GPL)

Development that must be done in the kernel space (e.g., device drivers) must take into account the following: Linux offers the option of loading extensions into the kernel after boot-time. This post-boot time loading of extensions will cause such extensions to be contaminated by the GPL.

Any time code is embedded in a dynamically loaded module, it must link with the kernel's libraries and will not access them via ordinary system calls.

Nevertheless, some hardware companies, such as video card manufacturers, already have distributed binary-only versions of their drivers by either:

• Infringing the GPL license by loading their driver at boot time
• Creating a GPL component in charge of dynamically loading its own proprietary code

These methods are not in line with the definition of open source software and have raised several stormy discussions, recently tempered by Linus Torvalds.

Source code redistribution

In the case where your software inherits from GPL or LGPL (falls under the scope of the GPL or LGPL terms), here are the three options for distributing the source code:

• Direct supply with the binary distribution
• Offer to supply upon request
• In limited circumstances, point the user back to the party where the binaries came from

Ensuring the protection of intellectual property is a core concern of ACCESS. This concern is evident in the design of ACCESS Linux Platform, which provides an environment of:

• Trust, as particular attention has been paid to avoid unanticipated exposure to third party intellectual property dependencies.
• Choice, as the platform allows users to create either open source or proprietary software on top of the platform, as they desire.

Example: An application framework

With the above principles in mind, ACCESS designed the ACCESS Linux Platform to address developer and licensee needs.

Figure 2: ACCESS Linux Platform and licenses
To support this ecosystem ACCESS used the Mozilla Public License to create an application framework, called Hiker Application Framework, that allows proprietary code to run on top of the platform. In addition, the middleware frameworks, running in the user space, provide the choice of creating either open source or proprietary software on top of the platform. Figure 2 shows how the different ACCESS Linux Platform areas are exposed to the OSI licenses.

Taking into account the license constraints listed previously, and knowing that it is composed of proprietary, “MPLed”, “LGPLed” and “GPLed” components, the ACCESS Linux Platform provides a concrete solution for protecting IP and developing business at all levels, from end user applications down to the mobile handset hardware.

Copyright (c) 2007, ACCESS Co. Ltd. All rights reserved. Reproduced with permission by LinuxDevices.com.

---

About the authors: Yann Cheri, Anna Schaller, Greg Wilson work for ACCESS Co. Ltd., a global provider of technology, software products, and platforms for Web browsing, mobile phones, wireless handhelds, and other networked devices. Cheri serves as Product Marketing Manager, Application Framework and Open-Source; Anna Schaller is Project Manager, Platform Services; and Greg Wilson works as a Senior Software Engineer.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.