From: Crane, Matthew <mcrane03@...>
Subject: Aggregation in embedded context, is kernel GPL2 prejudice against embedded systems?
Date: Oct 11, 10:33 am 2007

Hi,


From the GPL FAQ:
===
What is the difference between "mere aggregation" and "combining two
modules into one program"? 
	Mere aggregation of two programs means putting them side by side
on the same CD-ROM or hard disk. We use this term in the case where they
are separate programs, not parts of a single program. In this case, if
one of the programs is covered by the GPL, it has no effect on the other
program. 
	Combining two modules means connecting them together so that
they form a single larger program. If either part is covered by the GPL,
the whole combination must also be released under the GPL--if you can't,
or won't, do that, you may not combine them.
	What constitutes combining two parts into one program? This is a
legal question, which ultimately judges will decide. We believe that a
proper criterion depends both on the mechanism of communication (exec,
pipes, rpc, function calls within a shared address space, etc.) and the
semantics of the communication (what kinds of information are
interchanged).
	If the modules are included in the same executable file, they
are definitely combined in one program. If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program.
	By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate programs. So
when they are used for communication, the modules normally are separate
programs. But if the semantics of the communication are intimate enough,
exchanging complex internal data structures, that too could be a basis
to consider the two parts as combined into a larger program. 
=== 

The typical mechanisms of aggregation in desktop systems are much
different then embedded systems.   Embedded systems often do not have
room for pipes, sockets, and loadable modules.   Static linking may be
the only practical means of building a kernel image in such systems.   A
good example of this would be the extensive use of busybox, where many
programs have been aggregated into a single binary.  The same utilities
are normally separate on desktop systems.  It is also typical of
embedded devel to link the a low-level app directly to the OS where
drivers are normally modules in desktops.

If that is what is normal for embedded systems, wouldn't the expectation
of what is reasonable for "mere aggregation" be similarly different?
I've read much FUD about how anything linked statically is instantly a
derived work.   I do not think it is so black and white.  To me this
seems to pre-suppose that the option to load modules dynamically always
exists.   I do believe that if it does exist, it should be taken, and
that the interface boundaries always need to be respected regardless, to
the point of not using kernel headers and limiting the number of calls
to EXPORT_SYMBOL functions to the absolute minimum.

So would the persons responsible for defending the kernel GPL make
allowance for the minimal options for separation in a system so resource
constrained that it makes sense only to link statically?  I am trying to
make a case that this is ok because that is what systems similar in hw
specs generally due to save resources, and that many examples of an
"embedded" style of aggregation exist.

I'm also wondering if current Linksys WRT54G packaging may be used as a
model for building embedded Linux systems with some closed source.
According to wikipedia "The WRT54G is notable for being the first
consumer-level network device that had its firmware source code released
to satisfy the obligations of the GNU GPL".  I notice they still have
multiple binary objects that link to the kernel in a final image. 

Thanks for any feedback, cheers,


Matt
-


From: Adrian Bunk <bunk@...>
Subject: Re: Aggregation in embedded context, is kernel GPL2 prejudice against embedded systems?
Date: Oct 11, 11:15 am 2007

On Thu, Oct 11, 2007 at 10:33:28AM -0400, Crane, Matthew wrote:
> Hi,

Hi Matthew,

>... 
> If that is what is normal for embedded systems, wouldn't the expectation
> of what is reasonable for "mere aggregation" be similarly different?
> I've read much FUD about how anything linked statically is instantly a
> derived work.   I do not think it is so black and white.  To me this
> seems to pre-suppose that the option to load modules dynamically always
> exists.   I do believe that if it does exist, it should be taken, and
> that the interface boundaries always need to be respected regardless, to
> the point of not using kernel headers and limiting the number of calls
> to EXPORT_SYMBOL functions to the absolute minimum.

even for dynamically linking including non-GPL code is not white but 
already dark grey.

> So would the persons responsible for defending the kernel GPL make
> allowance for the minimal options for separation in a system so resource
> constrained that it makes sense only to link statically?  I am trying to
> make a case that this is ok because that is what systems similar in hw
> specs generally due to save resources, and that many examples of an
> "embedded" style of aggregation exist.
>...

There are no "persons responsible for defending the kernel GPL", there 
are just a few hundreds or thousands copyright holders of the kernel,
and each of them has the right to sue you if he thinks you distribute 
something that violates his copyright. Jurisdiction and applicable 
copyright law depends on things like where the copyright holder lives 
and where you distribute it.

> Matt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-


From: Crane, Matthew <mcrane03@...>
Subject: RE: Aggregation in embedded context, is kernel GPL2 prejudiceagainst embedded systems?
Date: Oct 11, 12:06 pm 2007

Hi, 

I wasn't sure how to describe what the people and groups with the
mandate to defend open source software.  There are people and groups
with such a mandate.

I'm asking if in a legal sense the grayness is affected by the
constraints of the hw the kernel is being run on, and some attempt to
quantify how the grayness is affected.  Of course it is not black and
white and ultimately up to a judge. 

I realize similar questions have been asked for more then a decade.
What is generally practiced and accepted does change, and any judge
weighing a case wrt these issues would consider that.

Matt



-----Original Message-----
From: Adrian Bunk [mailto:bunk@kernel.org] 
Sent: Thursday, October 11, 2007 11:16 AM
To: Crane, Matthew
Cc: linux-kernel@vger.kernel.org
Subject: Re: Aggregation in embedded context, is kernel GPL2
prejudiceagainst embedded systems?

On Thu, Oct 11, 2007 at 10:33:28AM -0400, Crane, Matthew wrote:
> Hi,

Hi Matthew,

>... 
> If that is what is normal for embedded systems, wouldn't the
expectation
> of what is reasonable for "mere aggregation" be similarly different?
> I've read much FUD about how anything linked statically is instantly a
> derived work.   I do not think it is so black and white.  To me this
> seems to pre-suppose that the option to load modules dynamically
always
> exists.   I do believe that if it does exist, it should be taken, and
> that the interface boundaries always need to be respected regardless,
to
> the point of not using kernel headers and limiting the number of calls
> to EXPORT_SYMBOL functions to the absolute minimum.

even for dynamically linking including non-GPL code is not white but 
already dark grey.

> So would the persons responsible for defending the kernel GPL make
> allowance for the minimal options for separation in a system so
resource
> constrained that it makes sense only to link statically?  I am trying
to
> make a case that this is ok because that is what systems similar in hw
> specs generally due to save resources, and that many examples of an
> "embedded" style of aggregation exist.
>...

There are no "persons responsible for defending the kernel GPL", there 
are just a few hundreds or thousands copyright holders of the kernel,
and each of them has the right to sue you if he thinks you distribute 
something that violates his copyright. Jurisdiction and applicable 
copyright law depends on things like where the copyright holder lives 
and where you distribute it.

> Matt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-


From: Alan Cox <alan@...>
Subject: Re: Aggregation in embedded context, is kernel GPL2 prejudiceagainst embedded systems?
Date: Oct 11, 3:54 pm 2007

On Thu, 11 Oct 2007 12:06:14 -0400
"Crane, Matthew" <mcrane03@harris.com> wrote:

> Hi, 
> 
> I wasn't sure how to describe what the people and groups with the
> mandate to defend open source software.  There are people and groups
> with such a mandate.

The same as any other work generally: "The authors", "the rights holder",
and sometimes "the state". In the case of something like the GPL possibly
the recipient of a binary only version, although that is much less
certain.

Alan
-


From: Theodore Tso <tytso@...>
Subject: Re: Aggregation in embedded context, is kernel GPL2 prejudiceagainst embedded systems?
Date: Oct 11, 12:22 pm 2007

On Thu, Oct 11, 2007 at 12:06:14PM -0400, Crane, Matthew wrote:
> I wasn't sure how to describe what the people and groups with the
> mandate to defend open source software.  There are people and groups
> with such a mandate.

There is no such thing as "mandate".  If you are a copyright owner,
and you elect to be a hard*ss about enforcing the GPL, you can choose
to do so.  If you are not a copyright owner, all you can do is
pontificate with FAQ's about GPL....

> I'm asking if in a legal sense the grayness is affected by the
> constraints of the hw the kernel is being run on, and some attempt to
> quantify how the grayness is affected.  Of course it is not black and
> white and ultimately up to a judge. 

At the end of the day it all boils down to what is a derived work.  If
an object file which is designed to link into a kernel is a derived
work, then the GPL claims that it will infect across to that derived
work.  Whether or not it this is a case is a matter of much debate,
and as far as I know, no court has ever ruled on point regarding the
question of object files, dynamical linking, and whether or not that
would be a derived work or not.  It seems likely that the answer may
vary from one legal jurisdiction to another.  Hence, the only answer
that we can give which is useful is, "Take this off of LKML, and go
ask a lawyer."

Best regards,

						- Ted
-


From: Crane, Matthew <mcrane03@...>
Subject: RE: Aggregation in embedded context, is kernel GPL2prejudiceagainst embedded systems?
Date: Oct 11, 12:49 pm 2007

Hi, 

So really, the only way for a company to know if they are ok would be to
sue themselves in a test case and force the issue.  This would at least
set some precedent and help remove some of the FUD around the issue.  I
have no idea about the details, but it seems that those groups who have
pursued GPL cases may have avoided setting precedents lest it reduce the
grayness.  I can easily imagine constructing a generic system that can
be used as a solid test and provide technical and legal reference for
others, once it has been ruled on in one or more courts.

Matt


-----Original Message-----
From: Theodore Tso [mailto:tytso@mit.edu] 
Sent: Thursday, October 11, 2007 12:22 PM
To: Crane, Matthew
Cc: Adrian Bunk; linux-kernel@vger.kernel.org
Subject: Re: Aggregation in embedded context, is kernel
GPL2prejudiceagainst embedded systems?

On Thu, Oct 11, 2007 at 12:06:14PM -0400, Crane, Matthew wrote:
> I wasn't sure how to describe what the people and groups with the
> mandate to defend open source software.  There are people and groups
> with such a mandate.

There is no such thing as "mandate".  If you are a copyright owner,
and you elect to be a hard*ss about enforcing the GPL, you can choose
to do so.  If you are not a copyright owner, all you can do is
pontificate with FAQ's about GPL....

> I'm asking if in a legal sense the grayness is affected by the
> constraints of the hw the kernel is being run on, and some attempt to
> quantify how the grayness is affected.  Of course it is not black and
> white and ultimately up to a judge. 

At the end of the day it all boils down to what is a derived work.  If
an object file which is designed to link into a kernel is a derived
work, then the GPL claims that it will infect across to that derived
work.  Whether or not it this is a case is a matter of much debate,
and as far as I know, no court has ever ruled on point regarding the
question of object files, dynamical linking, and whether or not that
would be a derived work or not.  It seems likely that the answer may
vary from one legal jurisdiction to another.  Hence, the only answer
that we can give which is useful is, "Take this off of LKML, and go
ask a lawyer."

Best regards,

						- Ted
-


From: Alan Cox <alan@...>
Subject: Re: Aggregation in embedded context, is kernel GPL2prejudiceagainst embedded systems?
Date: Oct 11, 3:51 pm 2007

> have no idea about the details, but it seems that those groups who have
> pursued GPL cases may have avoided setting precedents lest it reduce the
> grayness.  

I think its more that the cases pursued have been about wholesale abuse
of the GPL not about precise fine points. When you have someone
committing outright blatant breaches of the licence its quite different
to a philosophical dispute about a cornercase.

If you talk to a copyright lawyer you will find they can provide a lot of
guidance based upon prior caselaw in other areas (combining works in
books, setting works to music etc) where a great deal of caselaw has been
produced and many consider can be mapped reasonably onto arguments about
other areas.

That is however a discussion to have with someone qualified to practice
that area of law.

Alan
-