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
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
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:[email protected]]
Sent: Thursday, October 11, 2007 11:16 AM
To: Crane, Matthew
Cc: [email protected]
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
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
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:[email protected]]
Sent: Thursday, October 11, 2007 12:22 PM
To: Crane, Matthew
Cc: Adrian Bunk; [email protected]
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
> 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
On Thu, 11 Oct 2007 12:06:14 -0400
"Crane, Matthew" <[email protected]> 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
Adrian Bunk wrote:
> even for dynamically linking including non-GPL code is not white but
> already dark grey.
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
On Thu, Oct 11, 2007 at 01:49:03PM -0700, David Schwartz wrote:
> Adrian Bunk wrote:
>
> > even for dynamically linking including non-GPL code is not white but
> > already dark grey.
>
> 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.
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