Aggregation in embedded context, is kernel GPL2 prejudice against embedded systems?

["Crane, Matthew" <mcrane03@harris.com>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/