[ECOS] License restrictions

Bart Veer bartv@redhat.com
Thu Mar 22 07:45:00 GMT 2001


>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

    >> When it comes to Linux there are serious licensing problems. A
    >> typical existing Linux device driver will be licensed under the
    >> GPL. With eCos application code is linked directly to the
    >> kernel and hence to the device drivers, rather than being
    >> separated via a system call interface. Therefore all of the
    >> code in the system, including all of your application, needs to
    >> be under a license that is compatible with the GPL. Typically
    >> this means that you would have to release all of the
    >> application source code under an open source license. For most
    >> eCos developers that would be unacceptable.

    Andrew> This is probably a hard question to answer....

    Andrew> From what i understand, You can develop code for Linux and
    Andrew> not have to distribute the sources because libc is not
    Andrew> GPL, it uses some other licence. The application does not
    Andrew> directly call the GPL kernel.

Actually, applications can access the kernel directly without going
via glibc. For example the eCos synthetic target makes system calls
directly, not via glibc, but does not need to worry about GPL. See
below.

    Andrew> Now with eCos something similar is true. My application
    Andrew> code calls the eCos KAPI. This is covered by the eCos
    Andrew> licence. My application code does not directly call into
    Andrew> the device driver which could contain GPL code.

    Andrew> So, in terms of the licencing conditions, whats the
    Andrew> difference between a Linux system call interface and the
    Andrew> eCos function call interface?

Linking any application with GPL'd code creates a derived work under
the terms of the GPL. Therefore you must satisfy clause 2b of the GPL:

    "b) You must cause any work that you distribute or publish, that
    in whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License."

However, Linus Torvalds has added a special exemption to the GPL as it
applies to the Linux sources, see /usr/src/linux/COPYING:

   "NOTE! 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". Also note that the GPL below is copyrighted by the
    Free Software Foundation, but the instance of code that it refers
    to (the Linux kernel) is copyrighted by me and others who actually
    wrote it.
			Linus Torvalds"

This means that application code can use Linux system calls without
having to worry about the GPL. The key issue is that Linux has a very
clearly defined set of system calls, i.e. the traps, so the above
exemption is unambiguous. For eCos this is not true: everything ends
up linked together in a single executable. Your application will not
just use the interface defined in <cyg/kernel/kapi.h>, it will
typically also use the C library package, the TCP/IP stack, etc. In
some cases it may in fact access device drivers directly, for example
if you develop a USB-based application for the SA1110 then your
application will need to reference variables specific to the device
driver such as usbs_sa11x0_ep0 during initialization.

I suppose that theoretically it is possible to claim that the eCos
kernel services are the sum of everything in the exported header
files, and hence are covered by the Linus Torvalds exemption. However
IMHO that is playing word games, and I do not think it matches either
the spirit or the legal letter of the GPL. I am afraid that you would
find little or no support for such a claim from anybody involved in
Linux kernel development, let alone from the FSF.

Bart



More information about the Ecos-discuss mailing list