Re: [ECOS] Clean room module loader + GPL module + Application

[Bart Veer <bartv@ecoscentric.com>]

>>>>> " " == Retallack, Mark (Siemens) <mark.retallack@siemens.com> writes:

     > I know eCos mod-GPL have been discussed several times. I also
     > understand that eCos is not GPL compatible

Incorrect. The old RHEPL license was incompatible with the GPL. The
current GPL+exception license is compatible.

     >  --- Using GPL code in eCos kernel will force the license of
     > eCos application GPL.

The reference to the eCos kernel is irrelevant. Using GPL code means
that you have to comply with the terms of that license. If your
application makes use of two other bits of code released under
different licenses then it must comply with the terms of both
licenses. You cannot ignore the license of one just because the other
happens to be released on more liberal terms.

For an analogy, suppose your application makes use of a proprietary OS
and a proprietary device driver supplied by a different software
company. You would expect to pay two license fees, one to the OS
company and one to the company providing the driver. You cannot avoid
paying the OS license fee because you are paying somebody else for
different software.

     <snip>

     > Considering only legal issues (just ignore any technical or
     > code size issue),

You cannot get a definitive answer to legal questions on this mailing
list. Instead you need to consult a copyright lawyer who understands
these issues, including legal variations between all the countries
where you expect to do business.

     > If an eCos system is implemented like this:
     > (a) eCos kerenl (mod-GPL)
     > (b) Clean room module loader  (closed license)
     > (c) A GPL module registers itself as "/dev/storage" (GPL)
     > (d) Clean room application, mount "/dev/storage" and use eCos
     > POSIX layer (via FAT filesystem) to access the device (closed
     > license).

     > Does the GPL "special exception" apply to this situation? Is it
     > legal If the provider do not release the source code of (b) and
     > (d)?

My understanding is that (b) is fine. Such a module loader would be
equivalent to application code and hence can be kept proprietary.

However (d) is not fine. The application depends on the GPL'd code. My
understanding is that legally this makes it a derived work and hence
subject to the terms of the GPL. You cannot just bypass the GPL by
adding a few indirections, copyright law does not work like that.
Similarly under Linux you cannot just take GPL'd code like the gcc
code generator, turn it into a shared library, and then link your
proprietary application with the shared library.

And before people start quoting the Linux kernel as a counter example,
it has an explicit exemption allowing application code to use kernel
services by the normal Linux system calls. See the top level COPYING
file in the kernel sources. No such exemption applies in your
scenario.

I am not a lawyer and this is not official legal advice. If in doubt
then you need to consult somebody suitably qualified to answer these
questions.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss