Scribd
Upload
52 views4 pages

Appendix B - GPL

General Public License

Uploaded by

Luis Jácome
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
52 views4 pages

Appendix B - GPL

General Public License

Uploaded by

Luis Jácome
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

AU0586_book.

fm Page 387 Wednesday, November 9, 2005 12:25 PM

Appendix B

GPL and Embedded Linux


Linux and most of the open source applications, libraries, drivers, and so on
are distributed under GNU GPL. In earlier days companies were reluctant to
move to embedded Linux because of its GPL licensing. They feared that
moving to Linux might force them to make their intellectual property public.
As time passed companies gained more insight into GPL and they realized
that proprietary software can always be kept safe with embedded Linux.
In your design you may decide to use some open source applications in
the product. You should not assume that all the open source software comes
under GPL. Apart from GPL there are other licenses such as Mozilla Public
License (MPL), Lesser GPL (LGPL), Apache License, BSD License, and so on.1
We highly recommend that you contact an open source legal advisor and
clarify 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 on
Linux.
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 services
of 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

387

AU0586_book.fm Page 388 Wednesday, November 9, 2005 12:25 PM

388

Embedded Linux System Design and Development

Downloaded by [Universidade Estadual de Campinas - UNICAMP (CRUESP)] at 09:12 07 July 2015

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 your
application.
 You must not link your application with any GPL library either statically
or dynamically. You can link your application with LGPL libraries. Most
of the key libraries in Linux such as libc, pthreads, and so on are released
under LGPL. You can link LGPL libraries in your program with no obligation
to release the applications source code.

Its 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 application
and 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 a
product. You can use any GPL programs, drivers, and so on in any manner
you want as long as its for internal use and not for distribution. For example,
you can use open source debuggers and profilers for debugging your proprietary programs. You can also make modifications to them without releasing
any 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 standard
exported 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 kernel
mailing 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 kernel
modules 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.

2006 by Taylor & Francis Group, LLC

AU0586_book.fm Page 389 Wednesday, November 9, 2005 12:25 PM

GPL and Embedded Linux

389

Downloaded by [Universidade Estadual de Campinas - UNICAMP (CRUESP)] at 09:12 07 July 2015

Points to Remember
 As a manager of a project you should make sure that the developers
understand GPL and other licenses involved in the project.
 During development, the developers should take care when using a piece
of software (in the form of a library or some source code) available on
the Net for their project. They should not accidentally violate any licenses
involved. As rightly said, prevention is better than cure.
 One point where you must take care is software patent violation. It is
possible that you are using some off-the-shelf source code that is violating
some software patent. These violations are very difficult to catch and you
should be extremely careful.

Listing B.1
Modules

Linus Torvalds Mail Regarding GPL and Binary Kernel

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 any
gray 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.

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 Linux
in 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 that
some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behavior.
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 core
code, you're derived, no question about it.

2006 by Taylor & Francis Group, LLC

AU0586_book.fm Page 390 Wednesday, November 9, 2005 12:25 PM

390

Embedded Linux System Design and Development

Downloaded by [Universidade Estadual de Campinas - UNICAMP (CRUESP)] at 09:12 07 July 2015

Historically, there's been things like the original Andrew filesystem


module: a standard filesystem that really wasn't written for Linux in the
first place, and just implements a UNIX filesystem. Is that derived just
because it got ported to Linux that had a reasonably similar VFS interface
to 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 a
gray area.
Personally, I think that case wasn't a derived work, and I was willing
to 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 nonmodules 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 works
just 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 just
one sign that _maybe_ it might have other arguments for why it isn't
derived.

Notes
1. 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.

2006 by Taylor & Francis Group, LLC

You might also like