appendix b - gpl

7/18/2019 Appendix B - GPL

http://slidepdf.com/reader/full/appendix-b-gpl 1/4387

Appendix B

GPL and Embedded Linux

Linux and most of the open source applications, libraries, drivers, and so onare distributed under GNU GPL. In earlier days companies were reluctant tomove to embedded Linux because of its GPL licensing. They feared thatmoving to Linux might force them to make their intellectual property public. As time passed companies gained more insight into GPL and they realizedthat proprietary software can always be kept safe with embedded Linux.

In your design you may decide to use some open source applications inthe product. You should not assume that all the open source software comesunder GPL. Apart from GPL there are other licenses such as Mozilla PublicLicense (MPL), Lesser GPL (LGPL), Apache License, BSD License, and so on.1

We highly recommend that you contact an open source legal advisor andclarify that you are not violating any of the licenses.

In this appendix we discuss how proprietary software can be kept safe with Linux. First we discuss the user-space applications and then the kernel.

User-Space Applications

Linus Torvalds made a clarification regarding user-space programs that run onLinux.

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." 2

It means that you can write a code from a fresh code base and use servicesof Linux and keep your code proprietary. It does not come under GPL and you need not release the source code either. But you must make sure that

© 2006 by Taylor & Francis Group, LLC



388 Embedded Linux System Design and Development

you are not using any GPL software accidentally in your user-space programs.The following points should be taken care of.

You must not use source code of any program under GPL in yourapplication.

You must not link your application with any GPL library either statically or dynamically. You can link your application with LGPL libraries. Mostof the key libraries in Linux such as libc, pthreads, and so on are releasedunder LGPL. You can link LGPL libraries in your program with no obligationto release the application’s source code.

It’s allowed to use IPC mechanisms between GPL and non-GPL programs.For example, you can download the DHCP server released under GPL and write your own DHCP client. You are not obliged to release your DHCP client

under GPL. However, any modifications done by you to any GPL applicationand that use the IPC mechanisms to work around GPL are very dangerous. You must take advice from an attorney in such cases.

Note that GPL only applies when it comes to distributing a program or aproduct. You can use any GPL programs, drivers, and so on in any manner you want as long as it’s for internal use and not for distribution. For example, you can use open source debuggers and profilers for debugging your propri-etary programs. You can also make modifications to them without releasingany code as long as they are for internal use.

Thus, user applications can always be kept proprietary in Linux. You only need to take some precautions while developing applications.

Kernel

There is a general opinion that loadable kernel modules using standardexported kernel interfaces can be kept safe and need not come under GPL.For example, you can have proprietary device drivers implemented as a Linux

kernel module and need not release the source code of the driver provided you use standard interfaces exported by the kernel. However, this is one of the gray areas and you should consult your attorney.

Listing B.1 shows an excerpt from mail from Linus Torvalds to the kernelmailing list regarding his view on loadable kernel modules and GPL.

Thus the following points should be taken care of.

Consult your attorney to find out whether you can use loadable kernelmodules to protect your proprietary software.

Any modifications done to the Linux kernel come under GPL. In the kernel do not export any nonexported kernel interface to support

your loadable module. Any changes done to the kernel in the form of a kernel patch come under

GPL.


D o w n l o a d e d b y [ U n i v e r s i d a d e E s t a d u a l d e C a m p i n a s - U N I C A M P ( C R U E S P ) ] a t 0 9 : 1 2 0 7 J u l y 2 0 1 5



GPL and Embedded Linux 389

Points to Remember

As a manager of a project you should make sure that the developersunderstand GPL and other licenses involved in the project.

During development, the developers should take care when using a pieceof software (in the form of a library or some source code) available onthe Net for their project. They should not accidentally violate any licensesinvolved. As rightly said, prevention is better than cure.

One point where you must take care is software patent violation. It ispossible that you are using some off-the-shelf source code that is violatingsome software patent. These violations are very difficult to catch and youshould be extremely careful.

But one gray area in particular is something like a driver that was originally written for another operating system (i.e. clearly not a derived work of Linuxin origin). At exactly what point does it become a derived work of the kernel(and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe thatsome modules may be considered to not be derived works simply becausethey weren't designed for Linux and don't depend on any special Linuxbehavior.

Basically:

Anything that was written with Linux in mind (whether it then _also_

works on other operating systems or not) is clearly partially a derived work. Anything that has knowledge of and plays with fundamental internal Linux

behavior is clearly a derived work. If you need to muck around with corecode, you're derived, no question about it.

Listing B.1 Linus Torvalds’ Mail Regarding GPL and Binary KernelModules

From: Linus Torvalds

Subject: Re: Linux GPL and binary module exception clause?

Date: 2003-12-03 16:10:18 PST

….

And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel_is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived

work has to be GPL'd. It's that simple.

Now, the "derived work“ issue in copyright law is the only thing that leads to anygray areas. There are areas that are not gray at all: user space is clearly not a derived

work, while kernel patches clearly _are_ derived works.





390 Embedded Linux System Design and Development

Historically, there's been things like the original Andrew filesystemmodule: a standard filesystem that really wasn't written for Linux in thefirst place, and just implements a UNIX filesystem. Is that derived justbecause it got ported to Linux that had a reasonably similar VFS interfaceto what other UNIXes did? Personally, I didn't feel that I could make

that judgment call. Maybe it was, maybe it wasn't, but it clearly is agray area.

Personally, I think that case wasn't a derived work, and I was willingto tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work? NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kernel

that you can't load them as a module, they are clearly derived worksjust by virtue of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's justone sign that _maybe_ it might have other arguments for why it isn'tderived.

Notes1. http://www.gnu.org/philosophy/license-list.html has the complete list. GPL license

can be downloaded from http://www.fsf.org/licensing.

2. See the COPYING file in kernel sources.



http://www.gnu.org/

http://www.gnu.org/

http://www.fsf.org/

http://www.gnu.org/

http://www.fsf.org/

http://www.fsf.org/

http://www.gnu.org/

appendix b - gpl

Documents