RE: Possible GPL infringement in Broadcom-based routers

[Adam J. Richter]

David Schwartz wrote:
>> 	I think you're missing the idea that that such drivers are
>> _contributory_ infringement to the direct infringement that occurs when
>> the user loads the module.

>	Except that loading the module is not infringement. The GPL does not
>restrict use of GPL'd code in any way.

>> In other words, even for a driver that has
>> not a byte of code derived from the kernel, if all its uses involve it
>> being loaded into a GPL'ed kernel to form an infringing derivative
>> work in RAM by the user committing direct copyright infringement against
>> numerous GPL'ed kernel components, then it fails the test of having
>> a substantial non-infringing use, as established in the Betamax decision,
>> and distributing it is contributory infringement of those GPL'ed
>> components of the kernel.

>	In order for there to be an "infringing derivative work", some clause of
>the GPL would have to be infringed. There exists no clause in the GPL that
>restricts the *creation* of derivative works that are not distributed.

	The GPL is a grant of permission.  So, if you have an activity
that is restricted by copyright, you have to find something in the GPL
that gives you permission.  It's not just me saying that.  A representative
from the FSF explained that to room of ~50 lawyers and ~50 lay people
at a seminar that I went to on it.

>	If your argument were correct, then no non-GPL'd software could *ever* be
>distributed for Linux. You see, loading that software would create an
>"infringing derivative work" in the memory of the computer running it,
>combining the Linux kernel with the software.

	The FSF has addressed the question of interpretation of the
GPL with respect to how running a program in RAM may not by itself
make it a derivative work of other programs in RAM while dynamically
loading a module into a program (including a kernel) does in their
FAQ at http://www.gnu.org/licenses/gpl-faq.html:

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

                    __     ______________
Adam J. Richter        \ /
adam@xxxxxxxxxxxxx      | g g d r a s i l
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/