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

-

[ message continues ]

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

-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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


-

[ message continues ]

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
-

[ message continues ]