The following routers (and they might be other models, too) :
- Us Robotics 9105 (without wireless) and 9106 (with wireless)
- Siemens SE515
- Dynalink RTA230
- Buffalo WMR-G54
- Inventel DBW-200
... are all based on the same Broadcom chipset (96345 board). They
integrate a 4-ports Ethernet switch, a 802.11g wireless access point,
and a DSL modem (and doing routing and/or bridging between those
interfaces). The CPU runs the MIPS32 instruction set. It runs a 2.4.17
linux-mips kernel with additional patches, and is loaded with a lot of
free software (busybox, uclibc, zebra...)
The vendors (probably Broadcom, in fact) had to patch the kernel to
support the DSL modem, the wireless interface (which is a PCMCIA-hosted
BCM4306 ; which already was subject of heated debates earlier), and also
some generic stuff like the flash memory and the front leds.
Miscellaneous vendors provide so-called "GPL sources", which are
generally mutilated kernels, lacking all the "interesting" parts
(wireless and DSL drivers for instance).
Can Broadcom and the vendors "escape" the obligations of the GPL by
shipping those proprietary drivers as modules, or are they violating the
GPL plain and simple by removing the related source code (and showing
irrelevant code to show "proof of good will") ?
Broadcom has been contacted about this matter but hasn't answered so
far, nor did US Robotics (I tried to contact USR since I own a USR router).
Any suggestions about the legal (or if it's a lost cause, technical!)
ways to get support for this platform will be very welcome.
More information can be found here :
http://skaya.enix.org/wiki/GplInfringement (some extra details)
http://skaya.enix.org/wiki/BroadCom96345 (technical info that I gathered
about the router, firmware and kernel formats, etc.)
http://sourceforge.net/projects/brcm6345-linux/ (sourceforge project)
Best regards,
J?r?me Petazzoni <jp at enix dot org>
PS: please be kind and cc me, as my lkml awareness is limited to KT ...
> Can Broadcom and the vendors "escape" the obligations of the GPL by
> shipping those proprietary drivers as modules, or are they violating the
> GPL plain and simple by removing the related source code (and showing
> irrelevant code to show "proof of good will") ?
That is a contentious issue that has been debated on this group far too
much. In the United States, at least, the answer comes down to the complex
legal question of whether the module is a "derived work" of the Linux kernel
and whether the kernel as shipped with those modules is a "mere
aggregation".
You can google those terms to form your own opinions. IMO, discussing and
debating these type of borderline GPL violations on the LKML is not a good
idea. Save bringing up GPL violations on the LKML for cases where the
violation is really obvious and all measures short of public shaming have
already been tried.
DS
On Nov 04, 2004, at 18:57, David Schwartz wrote:
>
>> Can Broadcom and the vendors "escape" the obligations of the GPL by
>> shipping those proprietary drivers as modules, or are they violating
>> the
>> GPL plain and simple by removing the related source code (and showing
>> irrelevant code to show "proof of good will") ?
>
> That is a contentious issue that has been debated on this group far
> too
> much. In the United States, at least, the answer comes down to the
> complex
> legal question of whether the module is a "derived work" of the Linux
> kernel
> and whether the kernel as shipped with those modules is a "mere
> aggregation".
Well, from what I can see of the makefiles and sources they distribute,
they
_don't_ distribute it as kernel+modules, they compile their drivers
directly
into their kernel:
./arch/mips/brcm-boards/bcm96345/Makefile:EXTRA_CFLAGS +=
-I$(TOPDIR)/../../targets
./drivers/char/bcm96345/board/Makefile:EXTRA_CFLAGS += -I.
-I$(HPATH)/asm/bcm96345 -I$(TOPDIR)/../../targets -fno-exceptions
./Makefile:SUBDIRS +=modulesrc/drivers ../../targets
./Makefile:DRIVERS-y += modulesrc/drivers/kermods.o ../../targets/bp.o
They may call the directory "modulesrc", but it does _NOT_ appear to be
linked as a kernel module, but directly into the kernel. I think that
in this
case their build process is too tightly integrated with the kernel to
_not_
be a derivative work.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
I work for lawyers. Let me know if you would like a referral.
Regards,
Scott Lockwood
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of J?r?me
Petazzoni
Sent: Thursday, November 04, 2004 5:34 PM
To: [email protected]
Subject: Possible GPL infringement in Broadcom-based routers
The following routers (and they might be other models, too) :
- Us Robotics 9105 (without wireless) and 9106 (with wireless)
- Siemens SE515
- Dynalink RTA230
- Buffalo WMR-G54
- Inventel DBW-200
... are all based on the same Broadcom chipset (96345 board). They
integrate a 4-ports Ethernet switch, a 802.11g wireless access point,
and a DSL modem (and doing routing and/or bridging between those
interfaces). The CPU runs the MIPS32 instruction set. It runs a 2.4.17
linux-mips kernel with additional patches, and is loaded with a lot of
free software (busybox, uclibc, zebra...)
The vendors (probably Broadcom, in fact) had to patch the kernel to
support the DSL modem, the wireless interface (which is a PCMCIA-hosted
BCM4306 ; which already was subject of heated debates earlier), and also
some generic stuff like the flash memory and the front leds.
Miscellaneous vendors provide so-called "GPL sources", which are
generally mutilated kernels, lacking all the "interesting" parts
(wireless and DSL drivers for instance).
Can Broadcom and the vendors "escape" the obligations of the GPL by
shipping those proprietary drivers as modules, or are they violating the
GPL plain and simple by removing the related source code (and showing
irrelevant code to show "proof of good will") ?
Broadcom has been contacted about this matter but hasn't answered so
far, nor did US Robotics (I tried to contact USR since I own a USR
router).
Any suggestions about the legal (or if it's a lost cause, technical!)
ways to get support for this platform will be very welcome.
More information can be found here :
http://skaya.enix.org/wiki/GplInfringement (some extra details)
http://skaya.enix.org/wiki/BroadCom96345 (technical info that I gathered
about the router, firmware and kernel formats, etc.)
http://sourceforge.net/projects/brcm6345-linux/ (sourceforge project)
Best regards,
J?r?me Petazzoni <jp at enix dot org>
PS: please be kind and cc me, as my lkml awareness is limited to KT ...
On Thu, 2004-11-04 at 15:57 -0800, David Schwartz wrote:
> > Can Broadcom and the vendors "escape" the obligations of the GPL by
> > shipping those proprietary drivers as modules, or are they violating the
> > GPL plain and simple by removing the related source code (and showing
> > irrelevant code to show "proof of good will") ?
>
> That is a contentious issue that has been debated on this group far too
> much. In the United States, at least, the answer comes down to the complex
> legal question of whether the module is a "derived work" of the Linux kernel
> and whether the kernel as shipped with those modules is a "mere
> aggregation".
Not quite.
It comes down to a question of whether their firmware as a whole is a
'collective work' based in part on the Linux kernel, or whether the
whole thing can be considered 'mere aggregation' despite the fundamental
interdependency between the kernel and their drivers, without either of
which the entire device would be useless.
"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and
separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as
separate works."
This is the bit you seem to be thinking of -- when it's not actually a
derived work. But the GPL goes on and explicitly talks about your
obligations with respect even to non-derived works, if distributed as
part of a larger whole:
"But when you distribute the same sections as
part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License,
whose permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who wrote
it.
"Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of
derivative or collective works based on the Program."
--
dwmw2
> == David Schwartz
>> == Jerome Petozzoni
>> Can Broadcom and the vendors "escape" the obligations of the GPL by
>> shipping those proprietary drivers as modules, or are they violating the
>> GPL plain and simple by removing the related source code (and showing
>> irrelevant code to show "proof of good will") ?
>
> That is a contentious issue that has been debated on this group far too
>much. In the United States, at least, the answer comes down to the complex
>legal question of whether the module is a "derived work" of the Linux kernel
>and whether the kernel as shipped with those modules is a "mere
>aggregation".
I am not a lawyer, so please do not use this as legal advice.
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. 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.
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l
Adam J. Richter writes:
> 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. 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.
Combining GPLed works with GPL-incompatible works violates the GPL if
you distribute the result; the GPL allows one to make that kind of
combination for one's own use. Go read the GPL more closely.
Michael Poole
(IANAL)
User's can't violate the GPL. Only distributers can. (If said user is
shipping around copies of the integrated kernel+module - ram images,
in this case - they become a distributer.)
Just to reiterate, since this comes up a lot....
You can do WHATEVER you want on your box, with GPL code. You can (as I
recall) even run paid services (web services, for example) on modified
GPL code without releasing any sources. The GPL only covers
-DISTRIBUTION-. As soon as the modified BINARY gets distributed, the
GPL comes into play. Until that happens, there is NO RESTRICTION.
As far as Broadcom (and Tivo, and Linksys, and Sharp, and....) the
only questions are whether the driver is shipped as a module, and
whether or not the majority of the driver existed in a similar,
non-Linux form before integration. (If its not a module, they are
distributing a modified kernel. If it was written specifically for
Linux, the derived-work question comes in to play.)
On Sat, 6 Nov 2004 02:40:35 -0800, Adam J. Richter <[email protected]> wrote:
> > == David Schwartz
> >> == Jerome Petozzoni
> >> Can Broadcom and the vendors "escape" the obligations of the GPL by
> >> shipping those proprietary drivers as modules, or are they violating the
> >> GPL plain and simple by removing the related source code (and showing
> >> irrelevant code to show "proof of good will") ?
> >
> > That is a contentious issue that has been debated on this group far too
> >much. In the United States, at least, the answer comes down to the complex
> >legal question of whether the module is a "derived work" of the Linux kernel
> >and whether the kernel as shipped with those modules is a "mere
> >aggregation".
> 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. 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.
--
Disconnect <[email protected]>
http://www.gotontheinter.net/
> 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.
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.
DS
"Adam J. Richter" <[email protected]> said:
[...]
> 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. 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.
This is nonsense: If so, I'd be commiting a crime each time I fire up emacs
on Solaris (linking (GPLed) emacs to (propietary) libc in RAM). [Yes, just
an example; haven't done so for the best part of 5 years now...]
Besides, Linus has _explicitly_ said that binary (closed source) modules
are OK (under certain conditions). And AFAIU there was legitimate
discussion wether this particular excemption was required at al.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Michael Poole writes:
>Adam J. Richter writes:
>> 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. 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.
>Combining GPLed works with GPL-incompatible works violates the GPL if
>you distribute the result; the GPL allows one to make that kind of
>combination for one's own use. Go read the GPL more closely.
There are US court cases that have established that copying
into RAM is copying for the purposes of copyright. Also, I'd have
to say that loading a module into a kernel is modification.
My understanding is that the FSF was able to get Next Computer
to release its Objective C modules for gcc, over just this sort of
"user does the link" issue.
Also, as was pointed out by Bradley Kuhn at FSF's two
day GPL seminar at Standard Law School, where we picked apart
the GPL and LGPL for about twelve hours, the GPL is a grant
of permission. People "plead the GPL to us" as Bradley put it.
If you want to argue that the GPL does not cover some action, I don't
think that's the same as saying that the GPL gave you permission to
do it. You would still have to argue that that action is not
restrictable by copyright. Fortunately, I don't think the argument
comes to that, because of what I said in the first two paragraphs,
but it's something you might want to think about before raising that
argument in the future.
Again, I am not a lawyer, so please don't take this as legal
advice.
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l
Salut,
Could this kind of debating be taken once and for all
to gpl-violations.org? We're doing kernel development,
not law enforcement.
Tonnerre
Horst H. von Brand wrote:
>"Adam J. Richter" <[email protected]> said:
>[...]
>> 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. 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.
>This is nonsense: If so, I'd be commiting a crime each time I fire up emacs
>on Solaris (linking (GPLed) emacs to (propietary) libc in RAM). [Yes, just
>an example; haven't done so for the best part of 5 years now...]
It is based precisely on the idea that that is enforceable
that the FSF created an LGPL distinct from the GPL and also why it makes
a special exception for your type of use toward the end of section 3:
| However, as a
| special exception, the source code distributed need not include
| anything that is normally distributed (in either source or binary
| form) with the major components (compiler, kernel, and so on) of the
| operating system on which the executable runs, unless that component
| itself accompanies the executable.
>Besides, Linus has _explicitly_ said that binary (closed source) modules
>are OK (under certain conditions). And AFAIU there was legitimate
>discussion wether this particular excemption was required at al.
I've seen messages that say quite the opposite. Besides,
Linus is not the only copyright holder. It only takes one copyright
for someone to be infringing.
Again, I'm not a lawyer, so please don't take this as legal
advice.
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l
On Fri, 5 Nov 2004, 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.
>
> 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.
>
> DS
>
As I understand it, anything that executes in the user-mode
environment provided by the kernel, using the kernel-provided
API(s), either through a runtime library or direct, using the
kernel interface(s), is not a derivative work of the kernel.
Anything that runs inside the kernel is a derivative work.
There used to be a "gray area" which has now been obliterated
with the new module-loading software. There is now no question
about the derivative works of a module because a module is now
data used by the kernel's built-in loading mechanism. It cannot
anymore be confused with a "program".
So, if the Broadcom router uses a linux kernel with its
built-in network routing capability, that's fair use.
If it has a user-interface program for configuring it,
that user-interface program can be considered proprietary
and its code can be private intellectual property.
If the kernel is unmodified, its source doesn't have to
be provided with the box. If there are special modules or
special modifications, then these have to be made available
if requested by any individual. The company can charge normal
distribution fees for this software source-code.
In the meantime, you can do anything you want with any
portion of linux as long as you do it in the privacy of
your own bedroom ;^;)
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
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 \ /
[email protected] | g g d r a s i l
On Fri, 2004-11-05 at 16:06 -0300, Horst von Brand wrote:
> Besides, Linus has _explicitly_ said that binary (closed source) modules
> are OK (under certain conditions). And AFAIU there was legitimate
> discussion wether this particular excemption was required at al.
this sounds like a misunderstanding; and linus isn't the only copyright
holder.
See http://people.redhat.com/arjanv/COPYING.modules for the discussion
you aim at...
--
Adam J. Richter writes:
> Michael Poole writes:
>
> >Combining GPLed works with GPL-incompatible works violates the GPL if
> >you distribute the result; the GPL allows one to make that kind of
> >combination for one's own use. Go read the GPL more closely.
>
> There are US court cases that have established that copying
> into RAM is copying for the purposes of copyright. Also, I'd have
> to say that loading a module into a kernel is modification.
Whether those actions constitute protected copying or modification is
irrelevant[1]. Section 2 of the GPL is quite clear that it only
requires GPL licensing of works that one distributes. It allows me to
copy, modify and otherwise create derivative works; the requirement to
license those works under the GPL applies when I distribute them.
(Because Broadcom does distribute those derivative works contrary to
the GPL, I suspect they are directly infringing. My main point is
that your argument about users infringing the GPL is wrong, and
therefore so is the argument about contributory infringement.)
[1]- If you mean cases I think you do, they were the inspiration for
Title III of the DMCA, which added the repair and maintenance
exceptions in 17 USC 117(c) and (d).
> My understanding is that the FSF was able to get Next Computer
> to release its Objective C modules for gcc, over just this sort of
> "user does the link" issue.
My understanding is that the Objective C front-end was a derivative of
the gcc back-end for reasons unrelated to who did the linking, and
that was what convinced NeXT.
Michael Poole
> 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 that were true, I could poem up on a billboard and sue anyone who read
it. The FSF is, of course, free to take any position it wants to. As I
understand the law, if you want to restrict use, you must restrict access.
Give free access, you give free use.
DS
On Nov 05, 2004, at 14:06, Horst von Brand wrote:
> This is nonsense: If so, I'd be commiting a crime each time I fire up
> emacs
> on Solaris (linking (GPLed) emacs to (propietary) libc in RAM). [Yes,
> just
> an example; haven't done so for the best part of 5 years now...]
What you do with the GPL _on_your_computer_ is not relevant. libc is a
standard interface, which is used by many programs, much the same way
that a keyboard is a standard interface to a computer. You don't see
companies with copyright to _all_ keyboards, do you? ;-D
> Besides, Linus has _explicitly_ said that binary (closed source)
> modules
> are OK (under certain conditions). And AFAIU there was legitimate
> discussion wether this particular excemption was required at al.
This, of course, would assume that said code is compiled as a module. I
posted earlier some available makefile snippets from the code that they
_do_ distribute that shows they do _not_ link it as a module, but
directly
into the kernel. Last I saw, NVidia couldn't distribute kernels with
their
modules compiled directly into the binary.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
On Fri, 2004-11-05 at 11:59 -0800, David Schwartz wrote:
> If that were true, I could poem up on a billboard and sue anyone who read it.
Your analogy is flawed. Consider instead the case where you want to sue
not someone who _read_ it, but someone who copied it down into their
notebook, went home and then published an anthology of poems including
yours.
> The FSF is, of course, free to take any position it wants to. As I
> understand the law, if you want to restrict use, you must restrict access.
> Give free access, you give free use.
Adam said 'an activity that is restricted by copyright', and in the
context it's blindingly obvious that he means _copying_ and
_distribution_, not just use. Yet you persist in your misdirection.
Anyone copying and distributing the Linux kernel must comply with the
copyright licence which _conditionally_ grants them permission to do so.
In particular, the permissions granted by the GPL on the Linux kernel
are conditional on your agreement that when you distribute a collective
work which is based in part on the Linux kernel, you also release all
other parts of that whole, EVEN THOSE WHICH ARE NOT DERIVED WORKS OF THE
KERNEL, under the terms of the GPL.
The GPL does not claim any fundamental 'rights' to those parts which are
your own work, just as commercial copyright licences don't claim any
fundamental 'right' to your money. It's just a trade you are offered;
that is what is asked of you, in return for permission to distribute the
GPL'd work.
You have the right to refrain from entering that agreement; to refrain
from distributing the GPL'd work. You do not have the right to
distribute the GPL'd work _without_ complying with the terms of its
licence. That would be a criminal offence.
Anyone distributing a work which is a whole based on the Linux kernel
and other non-GPL'd works, other than 'mere aggregation on a volume of a
storage or distribution medium', is quite clearly violating the terms of
the GPL. (Bearing in mind the specific exception for userspace).
It's very clear, given that the firmware for these routers is completely
useless without either the kernel or the network driver modules, that
it's more than 'mere aggregation' -- the parts form a coherent whole.
Thus, even when the modules are NOT a 'derived work', they _MUST_ be
distributed under the terms of the GPL in order for permission to
distribute the _kernel_ to be granted.
--
dwmw2
"Adam J. Richter" <[email protected]> said:
[...]
> 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:
That's just the FSF's interpretation. Unless a court says it is actually
the right interpretation, it is up in the air (sure, the FSF interpreting
it this way will have some weight in court, but it is by no means
definitive).
For the kernel, Linus has clarified the license of the kernel (it is _not_
vanilla GPL), see COPYING. And one would assume that if somebody
contributes voluntarily, they are agreeing to the licence...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
> For the kernel, Linus has clarified the license of the kernel (it is _not_
> vanilla GPL), see COPYING. And one would assume that if somebody
> contributes voluntarily, they are agreeing to the licence...
the kernel is under the vanilla GPL, not only did Linus say so
repeatedly, also it contains code that IS under the vanilla GPL.
(eg taken from other projects etc etc).
This is exactly the argument I hoped would *not* arise on the LKML. I'll
try not to reply further unelss someone posts something fundmanetally new.
> Anyone copying and distributing the Linux kernel must comply with the
> copyright licence which _conditionally_ grants them permission to do so.
*sigh* We're not talking about anyone copying or distributing *the* Linux
kernel. We're talking about someone copying or distributing another work
that is derivative of the Linux kernel (which is also *a* Linux kernel, just
not *the* Linux kernel). This is true whether they distribute the module
separately or linked with the Linux kernel. In either case, they are not
distributing the actual work placed under the GPL but a distinct, yet
derivative, work.
The GPL can only conditionally grant permission to distribute a derivative
work if that is a right normally reserved to the author of a work. Yet
nobody has yet presented any law that reserves to a copyright holder the
right to restrict the distribution of derivative works.
> In particular, the permissions granted by the GPL on the Linux kernel
> are conditional on your agreement that when you distribute a collective
> work which is based in part on the Linux kernel, you also release all
> other parts of that whole, EVEN THOSE WHICH ARE NOT DERIVED WORKS OF THE
> KERNEL, under the terms of the GPL.
This is the GPL trying to set the scope of its own authority. Nothing in
the GPL matters unless you try to do something that you could only get the
right to do from the GPL itself. Otherwise, you are free to refuse to accept
the GPL.
> The GPL does not claim any fundamental 'rights' to those parts which are
> your own work, just as commercial copyright licences don't claim any
> fundamental 'right' to your money. It's just a trade you are offered;
> that is what is asked of you, in return for permission to distribute the
> GPL'd work.
Except you're not distributing the GPL'd work! You are totally putting the
cart before the horse here. You are assuming that the compiled object that
they are distributing is a GPL'd work to show that it must be covered by the
GPL because it's distributed.
> You have the right to refrain from entering that agreement; to refrain
> from distributing the GPL'd work. You do not have the right to
> distribute the GPL'd work _without_ complying with the terms of its
> licence. That would be a criminal offence.
Here again you put the cart before the horse. You say that I'm
"distributing the GPL'd work". Why is it GPL'd? Because the GPL says it
covers collective works. But since I refused the GPL, why does it matter
what the GPL says?!
> Anyone distributing a work which is a whole based on the Linux kernel
> and other non-GPL'd works, other than 'mere aggregation on a volume of a
> storage or distribution medium', is quite clearly violating the terms of
> the GPL. (Bearing in mind the specific exception for userspace).
Again, you are quoting the GPL to decide the scope of its own authority in
the case where a person refuses to accept the GPL.
> It's very clear, given that the firmware for these routers is completely
> useless without either the kernel or the network driver modules, that
> it's more than 'mere aggregation' -- the parts form a coherent whole.
It is quite useful without *the* kernel. It is quite useful as a single
work, *a* kernel but not *the* kernel. A distinct (yet derivative) work.
> Thus, even when the modules are NOT a 'derived work', they _MUST_ be
> distributed under the terms of the GPL in order for permission to
> distribute the _kernel_ to be granted.
For the love of god, you're not distributing *the* kernel, you're
distributing *a* kernel. A distinct work, albeit a derivative work. How hard
is that to understand?
DS
On Sat, 2004-11-06 at 12:09, David Schwartz wrote:
> .... But since I refused the GPL, why does it matter
> what the GPL says?!
>
It matters, because in a dispute the copyright holder(s) will file a
civil case alleging copyright violation(s) on your part. When you
receive this, you will have no defense to this charge unless you claim
that you received a license from the copyright holder(s). The copyright
holder(s) will at that point ask "What license would that be?". You will
answer "the GPL of course!" .
After you have acknowledged the GPL as part of your defense -- Then and
only then would the debate move to whether or not you are within the
four corners of the license. However if you don't acknowledge the GPL
then you are making a summary judgment against you quite likely -- as
the court will find it as a fact not in material dispute that you had no
permission to do anything with the copyrighted work(s) at all.
So I guess you are completely right; if you refuse to use the GPL as a
defense, then it doesn't matter what it does or doesn't say -- you're
going to fry by default.
--
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677
On Sat, 2004-11-06 at 12:09 -0800, David Schwartz wrote:
> This is exactly the argument I hoped would *not* arise on the LKML. I'll
> try not to reply further unelss someone posts something fundmanetally new.
>
> > Anyone copying and distributing the Linux kernel must comply with the
> > copyright licence which _conditionally_ grants them permission to do so.
>
> *sigh* We're not talking about anyone copying or distributing *the* Linux
> kernel. We're talking about someone copying or distributing another work
> that is derivative of the Linux kernel (which is also *a* Linux kernel, just
> not *the* Linux kernel). This is true whether they distribute the module
> separately or linked with the Linux kernel. In either case, they are not
> distributing the actual work placed under the GPL but a distinct, yet
> derivative, work.
Ah, OK. So as long as they change one line of code in the kernel, it's a
derivative work and they're no longer required to comply with the GPL?
They don't even need to use binary-only modules; they can put their own
proprietary code into their kernel, and distribute it how they like?
An interesting opinion.
--
dwmw2
On Sat, Nov 06, 2004 at 04:49:17PM +0100, Arjan van de Ven wrote:
>
> > For the kernel, Linus has clarified the license of the kernel (it is _not_
> > vanilla GPL), see COPYING. And one would assume that if somebody
> > contributes voluntarily, they are agreeing to the licence...
>
> the kernel is under the vanilla GPL, not only did Linus say so
> repeatedly, also it contains code that IS under the vanilla GPL.
> (eg taken from other projects etc etc).
Well, that's not *quite* accurate.
Vanilla GPL tends to be "version 2 or any later version", whereas Linux
is distributed *only* under version 2.
(Yes, rather nitpicky, and I'm not disagreeing with you in any
meaningful way - just trying to make sure archive searches find the correct
statements over and over again.)
--
Ryan Anderson
sometimes Pug Majere