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

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

[Retallack, Mark (Siemens)]

I am sure others will be able to answer this in a better way, but: 

First off, eCos is (now) GPL compatible. It has an exception for static
linking against a closed source application.

If any GPL source is introduced into the eCos+Applicaion mix, and it
does not have a similar exception, then the whole
eCos+Application+OtherApp mix will become GPL. The only way to prevent
this is to not statically link the OtherApp. This would require runtime
dynamic linking and a very careful development process.   

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of C.J.
Sent: 24 May 2005 18:47
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Clean room module loader + GPL module + Application


Hi,
I know eCos mod-GPL have been discussed several times.
I also understand that eCos is not GPL compatible --- 
Using GPL code in eCos kernel will force the license 
of eCos application GPL.

GNU GPL (http://www.gnu.org/copyleft/gpl.html) states:
   The source code for a work means the preferred form of the work for
making modifications to it. 
   For an executable work, complete source code means all the source
code for all modules it contains, 
   plus any associated interface definition files, plus the scripts used
to control compilation and 
   installation of the executable. 
   However, as a special exception, the source code distributed need 
   not include anything that is normally distributed (in either source
or binary form) with the major 
   components (compiler, kernel, and so on) of the operating system on
which the executable runs, 
   unless that component itself accompanies the executable. 

Considering only legal issues (just ignore any technical or code size
issue), 
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)?

Best Regards,
C.J.




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

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

[Bart Veer]

>>>>> " " == 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

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

[Retallack, Mark (Siemens)]

Opps. Mised not the important bit.

If the Clean room module loader, is realy fully clean room (including
headers etc..), and the GPL module is loaded at runtime. And there are
no GPL sources in the eCos kernel and application, then this should be
ok. But then the question is: Where will the GPL module be stored before
loading? I don't think it could be staticly linked with the
eCos+application binary (like an image used in the HTTP server). It
would need to be stored on the filesystem. 

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of C.J.
Sent: 24 May 2005 18:47
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Clean room module loader + GPL module + Application


Hi,
I know eCos mod-GPL have been discussed several times.
I also understand that eCos is not GPL compatible --- 
Using GPL code in eCos kernel will force the license 
of eCos application GPL.

GNU GPL (http://www.gnu.org/copyleft/gpl.html) states:
   The source code for a work means the preferred form of the work for
making modifications to it. 
   For an executable work, complete source code means all the source
code for all modules it contains, 
   plus any associated interface definition files, plus the scripts used
to control compilation and 
   installation of the executable. 
   However, as a special exception, the source code distributed need 
   not include anything that is normally distributed (in either source
or binary form) with the major 
   components (compiler, kernel, and so on) of the operating system on
which the executable runs, 
   unless that component itself accompanies the executable. 

Considering only legal issues (just ignore any technical or code size
issue), 
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)?

Best Regards,
C.J.




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

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

[C.J.]

Hi,
I know eCos mod-GPL have been discussed several times.
I also understand that eCos is not GPL compatible --- 
Using GPL code in eCos kernel will force the license 
of eCos application GPL.

GNU GPL (http://www.gnu.org/copyleft/gpl.html) states:
   The source code for a work means the preferred form of the work for making modifications to it. 
   For an executable work, complete source code means all the source code for all modules it contains, 
   plus any associated interface definition files, plus the scripts used to control compilation and 
   installation of the executable. 
   However, as a special exception, the source code distributed need 
   not include anything that is normally distributed (in either source or binary form) with the major 
   components (compiler, kernel, and so on) of the operating system on which the executable runs, 
   unless that component itself accompanies the executable. 

Considering only legal issues (just ignore any technical or code size issue), 
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)?

Best Regards,
C.J.