Wind River's worries

In a recent article in Integrated Communications Design, Mike Downing interviews Curt Schacker, vice president of corporate marketing for Wind River Systems. In the interview, Schacker expresses his “fear” that legal ambiguity surrounding the GPL “is impeding development in the embedded open-source arena.”

In Schacker's hypothetical scenario, a company making Ethernet switches uses Linux for the platform and chooses not to release their code under the GPL, because it represents the bulk of their product's core technology. Shacker fears that because the GPL has not been tested in court, this company's project may be in jeopardy. He says, “Can you imagine a court case some day that determines that all of the software you've developed falls under the GPL, and is now in the public domain?”

FUD? or a legitimate concern?

While some have jumped to the conclusion that Schacker is cynically spreading FUD (“Fear, Uncertainty, and Doubt”) about a technology (Linux) and development model (open source) that poses a threat to his company, I prefer to think that he is genuinely concerned about the welfare of users of Linux in embedded applications.

Thus, I will do my best to allay his fears.

First, it is worth noting that if Wind River is afraid of the GPL, this fear has only recently developed. Over the years they have marketed a number of GPL-licensed software packages.

I recall using — and paying a fair amount of money for — their GDB-derived debugger in the mid '90s. Earlier than many other software vendors, Wind River seemed to have discovered the benefits of using, modifying, and selling software licensed under the GPL.

If Wind River is really worried about the legal status of the GPL, why have they devoted substantial resources to modifying and marketing GDB as a product? We can only assume that others besides Schacker believe that the GPL protects Wind River's right to market this derived product — that it had at least some legal plausibility.

The benefits of pure GPL

It should also be noted that to the extent restrictions exist, they apply only to non-GPL software. If you release your code under the GPL, the situation becomes quite simple and easy — you can modify and release just about anything. This is by design. Linux was started by, and remains the product of, those who believe in open source software. It should come as no surprise, that having contributed so much of their work to an open source project, they now prefer that those who use their work also contribute.

Linux derives much of its success from its ability to gradually accumulate functionality and maturity through the combined contributions of its users. Releasing your code removes any restrictions on how Linux is used; and, as we shall see, has important practical benefits. So it is certainly not true that the GPL is “impeding development in the embedded open-source arena.” To the extent that there are impediments, they are to closed-source software.

But to more directly put Schacker's fears to rest, a review of the GPL and its application to Linux is in order.

The relationship of Linux to GPL

Linux might be considered to have three main licenses, as follows . . .

• The GPL. This is a remarkably clear and well-written document that I recommend you read yourself, but it is not hard to summarize its contents. The GPL allows you to modify, copy, and distribute software licensed under it, provided you also license the derived work under the GPL, and make available the source code. The deal seems clear enough: you get to use GPL-licensed code as a basis for your new, modified software package; but you cannot restrict others from getting the same deal you got, using your software as their basis. Also important to note is that you can use and modify GPL-licensed code for your own internal use without asking anyone's permission or notifying anyone — it is only when you distribute it that the rules take effect.

  The only sticky point is how to define a “derived work”; i.e., when am I modifying code, and when am I creating an entirely new work? If I edit, say, the emacs source code, add yet another feature to it, and call the result “myemacs” it seems clear that I have created a derived work. But what if I am an application service provider, and run it over a network? Or control it through some interprocess communication scheme like CORBA? A number of difficult cases have arisen since the second version of the GPL was released, and these are what the Free Software Foundation is attempting to address with GPL Version 3. But these cases are still fairly rare, and for most purposes a derived work is one that is a direct modification of, or linked with, the original work. If, at execution time, your work is linked with a GPL work, it is a derived work. Note that it does not matter whether the linking is static or dynamic, so making use of a GPL-licensed shared library creates a work derived from the library.

• The LGPL. This is the “lesser”, or “library”, GPL. Works licensed under the LGPL are usually built as a library and can be linked with proprietary software packages. The LGPL is important for Linux because the GNU C Library (Glibc) is licensed under it. Glibc, a shared library provided with most Linux systems, provides the interface between almost all Linux-based application programs and the kernel. Glibc is usually implemented as a shared library, meaning that an application is linked to it when the app is loaded. Applications call Glibc functions, which then execute system calls to the Linux kernel. Since user-space applications are linked only with Glibc, and not directly with the kernel, they do not fall under the Linux license.

• The GPL as clarified by Linus. The Linux kernel is licensed under the GPL, but with this clarification:
  This copyright does *not* cover user programs that use kernel services by normal system calls — this is merely considered normal use of the kernel, and does *not* fall under the heading of 'derived work.'
  This statement clarifies that user-space programs are not considered to be derived from Linux. It also is sometimes interpreted as allowing proprietary kernel modules.

Five classes of software

Based on the above, we may identify five classes of software in a Linux context and attempt to specify what type of licensing is necessary for each . . .

1. User-space applications running under Linux
   
2. Loadable device drivers using the normal kernel interfaces
   
3. Loadable modules using non-standard kernel interfaces
   
4. Standalone kernel modules
   
5. Modifications to Linux itself

Let's now consider each of these . . .

• User-space applications running under Linux — The status of the first class is quite clear. Basically any user-space application can be proprietary, provided the application is itself not derived from a GPL-licensed product. This explains why so many large software companies, such as Oracle, have released Linux versions of their proprietary products. Virtually no one contends that merely running a program under Linux obligates you to release your software under the GPL. And this conclusion is reinforced by Linus' GPL clarification.

• Modifications to Linux itself — Similarly, it is clear that modifications in the fifth class fall under the GPL. If you take the Linux source code, modify it, and compile it to form a new kernel, you have a work derived from Linux, and your work is also under the GPL.

• Loadable device drivers using the normal kernel interfaces — The status of loadable device drivers is less clear cut. Loading a module is essentially a form of dynamic linking — when loaded, the module is linked to the kernel — and files linked to GPL code must also be GPL. So it can be argued that kernel modules, including drivers, must be GPL. But Linus has stated that proprietary device drivers that use the normal driver/kernel interfaces are OK. And the kernel developers have consistently supported this interpretation by tolerating, albeit reluctantly, the presence of proprietary hardware drivers. This tolerance of proprietary drivers has held for a very long time, and numerous hardware manufacturers are currently depending on it. But some kernel developers have questioned Linus' authority to issue this GPL exception. It is fair to say that virtually none of the Linux copyright holders likes binary-only drivers much — so you should take this step only after careful consideration.

• Loadable modules using non-standard kernel interfaces — The third class, loadable modules that do not use the standard kernel interfaces, is the most problematic for closed-source code. Once loaded, a module essentially becomes part of the kernel. In principle, it is possible to modify Linux to create a special interface to a module, release that modified Linux under the GPL as required, and then write a proprietary loadable module that uses the kernel interface that you created. The result would essentially be a proprietary Linux, something quite contrary to the spirit of the GPL — and falling well outside of Linus' driver exception.

• Standalone kernel modules — Kernel modules are quite flexible, and have a wide range of uses. They are sometimes used for purposes quite independent of kernel functionality. RTLinux applications are one example — they don't modify the kernel in any way, but are simply applications running in kernel space. This defines the fourth class of Linux applications — those that do not use kernel functionality at all. These would presumably be categorized the same as standard-interface drivers since a module that does not interface with the kernel cannot be said to have non-standard interfaces.

Using your head

Despite Schacker's fears, developing for Linux is really not that complicated, from a licensing point of view. Believe it or not, in most cases common sense works just fine. For example, don't use kernel modules as a way to “get around” the Linux copyright. If what you are implementing is essentially a modification to Linux, release it under the GPL.

History suggests that if you stay within the spirit of the GPL, you are quite unlikely to run into trouble with the Linux copyright holders. If you want to worry about legal issues, worry about the minefield of software patents out there, which gets worse every year. Mind you, the Linux copyright holders reportedly do have in place the means to address abuses of their copyright. But you are much more likely to be sued by some litigious royalty-seeking patent holder than by, say, Linus.

Well structured programming helps

In any case, proper software design usually renders moot whatever ambiguity is present. Use of kernel modules should be reserved for low-level hardware manipulation, with higher-level functionality implemented in user-space programs. Sensitive intellectual property is seldom revealed in low-level code — if your value added lies in software, the software usually has a degree of sophistication that should be implemented in user space anyway.

Don't forget: the role of an operating system is to provide generalized services to all applications — application-specific code does not belong there. And if your application needs general OS functionality that Linux does not currently have, why not add it to the kernel and contribute it to the open source code base?

“But what about embedded apps?”

None of this changes when you talk about embedded applications.

Schacker asserts, “That type of software is much more closely linked with the operating-system kernel than a more classical application.”

No, the rules of modular software design still apply. If you wish to have understandable and maintainable software, you leave the kernel alone, put low-level hardware manipulation code in drivers, and put your application functionality in user-space programs.

The trouble with proprietary drivers

Another problem with using proprietary drivers involves maintenance. The binary interface between the kernel and device drivers often changes between kernel versions. In most cases the changes do not break the source code, so only a recompilation is necessary to use an old driver with a new kernel.

If, on the other hand, you are using some third-party hardware with a proprietary binary-only driver, the driver is likely to break with kernel upgrades, requiring the hardware manufacturer to provide a new binary driver for each version of the kernel.

Periodically, hardware manufacturers who do not provide source code for their drivers complain to the kernel developers about kernel changes that break their binary drivers. Rest assured that these pleas elicit no sympathy from the kernel developers — their response is, invariably, “Provide source code, or go away.”

The key point is this: avoid third-party binary-only drivers. And, if you sell hardware, provide source code to your drivers. This is a practical matter that has nothing to do with licensing. This point also applies to embedded system developers, although perhaps less so since in embedded systems there tends to be greater control over what kernel is used and more stability over the life of the system.

Conclusion

To summarize, the GPL licensing of Linux is seldom a problem for embedded applications. In most cases, your core technology is either in the hardware or in the application-level software — both of which can safely be kept proprietary.

On the other hand, there may be a few situations where developers wish to keep driver-level code proprietary. In this case, the developers (or their companies) will need to convince themselves that dynamically linked binary drivers can, indeed, be non-GPL — for this falls within a somewhat gray zone in the Linux GPL license.

However, before addressing that issue, I suggest you reconsider — is it really necessary to put proprietary functionality in a kernel module or in a modification to the kernel itself? If so, will it really hurt your company to contribute that new functionality to the community? In most cases, the answer is that it could safely benefit both your company and the community.

---

An embedded developer's GPL FAQ

The following questions and answers are intended to anticipate likely questions from developers, not all of whom are experienced Linux programmers, regarding some of the key issues raised in this article . . .

Q. I often hear the terms “module” and “driver” used more or less interchangeably. Can you clarify these terms?

A. A module is any code that can be loaded into the kernel with “insmod” or other utilities. Loading a module is essentially the same as dynamically linking it to the kernel — it becomes part of the kernel at that point. A driver is a module that uses a specific interface that allows applications to perform read, write, and other file-oriented operations. However, some drivers are not modules — see the next question.

Q. I've heard the terms dynamic and static used to describe Linux drivers and modules, and that there is a distinction in whether they must be GPL or not in the case of Linux. First, could you define these two terms?

A. In Linux, it is possible to have drivers compiled directly into the kernel. These are compiled at the same time as the kernel, linked with it, and loaded at the same time the kernel is booted. You would tend to use this model for devices you know will always be used; for example, a network interface card driver on a desktop computer you know will always be networked. So, in this case the driver is always present in the kernel. You might call these drivers static, because they are statically linked with the kernel. And because they are statically linked with Linux, they must be GPL.

Linux also supports dynamic drivers which can be loaded whenever desired (for example, with an “insmod” command). Once loaded, there's really no difference between these and the static drivers — they behave exactly the same, and have the same capabilities. Some drivers can be used either way; for example, when you configure your kernel, you can specify that your CDROM driver is to be always present (static driver) or that it is to only be loaded when needed (dynamic driver). Dynamic drivers can save memory, since they're only loaded when needed.

Some Linux copyright holders say that, since there's no real theoretical difference between static and dynamic drivers, both types should be GPL. But Linus has applied an exception, which applies only to dynamic drivers.

Q. It's my understanding that Linus has stated explicitly that it is permissable to use proprietary (non-GPL) dynamically loadable modules (including drivers and other independent code) with Linux, even though the GPL normally requires GPL-only code, for either static or dynamic drivers/modules. Is this correct?

A. This has been commonly reported — but it needs some clarification. The COPYING file in Linux contains the text of the GNU General Public License (GNU), but it begins with a “NOTE!” which contains the sentence (quoted in the article) that allows the use of non-GPL “user programs that use kernel services by normal system calls.” It is not clear, however, that this phrase can be applied to kernel modules — it seems to clarify only the status of programs in user space. As far as I can tell, Linus' non-GPL module exception has mainly been communicated by other means than the Linux copyright — he has, for example, repeatedly stated his allowance of proprietary (i.e. non-GPL) modules on the kernel mailing list.

Q. So, can you give me a simple answer to the question of whether I can use a proprietary (i.e. non-GPL) module with Linux?

A. No, I can't. I think a conservative approach is warranted. By a strict interpretation of the GPL, you can't release any proprietary kernel modules, including drivers. And some Linux copyright holders think it should be interpreted strictly. Although I don't think anyone will ever be sued for releasing proprietary Linux drivers, you shouldn't assume that it can't happen. I suspect that the copyright holders prefer to leave the situation somewhat ambiguous, since that has the effect of discouraging the proliferation of binary-only (non-GPL) modules.

---

Author's bio: Jerry Epplin has written embedded software for the past fifteen years, primarily for medical devices. He can be reached at [email protected]

---

 
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.