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...
[ message continues ]

even for dynamically linking including non-GPL code is not white but 
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 
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
-

IANAL, but personally, I think it's perfectly black and white.
No mechanical combination (that means compressing, linking, tarring, compiling, or whatever) can create a work for copyright purposes. It can only convert the original work into a new form or aggregate works.
There are a few exceptions to this by statute. For example, translation (by explicit law) can create a derivative work. Presumably this was because nobody ever imagined an automated process that could translate a work. It was assumed such a process must always be creative.
To create a 'derivative work', you must create a new *work*, and a compiler and linker can't do that. Under copyright law, the creation of a work requires creative input. Compilers and linkers are not creative.
If you link two works together, the result is an aggregate of those two works (and possibly the linker). This must be the case because there is no creative combination, and without creativity, a new work (for copyright purposes) cannot be formed.
No amount of mechanical automated combination of works can create a new work for copyright purposes. If you feed A and B into a linker, all you can get out is A, B, and perhaps the linker.
This doesn't mean that the result isn't a derivative work of one of the inputs. But this can only happen if one of the input works was a derivative to begin with.
"Mere aggregation" must mean as opposed to creative combination. Think about a tar/gzip. Bits of each work are mixed into the other as the subsequent work has elements in common to the previous work compressed out. This is just as much mixing as a linker does, perhaps arguably more. The key is that no creativity is used, and thus no *new* work (and a derivative work is a new work) is created.
DS
-

This may (or may not) be true in the US.  But whether or not it is

true in another legal jurisdiction, or whether there is code in the

form of inline functions in header files getting dragged in at

compilation time (and thus forming part of the driver object file),

are all reasons why the only valid answer is TALK TO A LAWYER, NOT

LKML.
						- Ted

-

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?
even for dynamically linking including non-GPL code is not white but 
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 
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
-

On Thu, 11 Oct 2007 12:06:14 -0400
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

-

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

-

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?
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
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

-

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

-