[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPL 2(b) HUH?

From: David Kastrup
Subject: Re: GPL 2(b) HUH?
Date: Wed, 17 Sep 2008 23:04:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Rjack <> writes:

> It is interesting to note that compiling the source code of standard
> program packages of independently authored c code (and assembler) like
> the Linux kernel does not create a derivative work. Some people think
> that compiling module1.c, module2.c, . . . into "-o prgm" translates
> the source code into a derivative work.
> e.g.: gcc -o prgm module1.c module2.c . . .
> There is absolutely *no* spark of originality added as gcc assembles
> the source code into an executable -- something thousands of people do
> every day. Gcc assembles the c code modules into a collective whole
> (the executable) according to fixed, predetermined rules with no
> assistance from the author.

Sure.  gcc is operating on behalf of the caller and assembles prgm from
various modules.  prgm clearly is a derivative work of all the various

Now gcc is just a tool, so who is _responsible_ for creating this
derivative?  Is the user calling gcc on his own volition, or is he
acting as an agent of the person who sold him module1.c?  This depends
on whether other possible reasons to buy module1.c exist, so that the
decision to call gcc can be considered reasonably independent from
buying module1.c.

If that is the case, creation of the derivative binary is clearly not
tied to the sale of module1.c.

Where this is not the case, things are quite less clearcut.
"contributory infringement" is a relevant buzzphrase in this context,
and trying your favorite search engine will show you that there is much
talk and very little hard evidence in one direction or the other.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]