Re: CISCO Aironet 350

From: Ray (
Date: 2002-07-04 21:01:04 UTC

On Thu, Jul 04, 2002 at 03:02:39PM -0500, Jim Thompson wrote:
> > They only need to give the source code to whatever GPLd binaries they are
> > distributing to those that they have distributed to, not everyone. I don't
> > know if they are doing this or not but I certainly hope so. Of course, any
> > modules that they've created themselves they do NOT have to provide source
> > for.
> Not quite. Read on.

Yes quite, the GPL is actually quite understandable.

> David Sifry writes:
> > Of course, Tony doesn't need to license the code he wrote (AP drivers, etc)
> > under the GPL. He's the author, and he can create non-GPL'd binary modules
> > if he chooses, amongst other options.
> This isn't true. I've been engaging with Eben Modgen, rms and Linus
> over exactly this issue since last November on a wireless driver. While
> I can't discuss the details, I can say one thing for sure: You are (currently)
> quite wrong, though this is a commonly-held (but still incorrect) belief..

The problem seems to be that you are mixing several different issues together and making a simple issue murky.

> If Tony's kernel module code uses no Linux code, then he might have a case,
> but its doubtfull. In general, if your code runs in user-space, only links
> against LGPLed libraries, and contains no GPLed code, then you don't have to
> distribute the source. You should, of course, but that is a different subject.

Back up a second, both David and I were talking about code WRITTEN BY Tony. Yes, if he's using modified GPL code or linking against GPLed libraries then that changes things but I don't think anyone was talking about that. Just writing a program and including it on the same CD as a GPLed program does NOT make the result a derivative work for the purposes of the GPL. In the case of modules, I see no reason why he would need to modify or link to any GPLed code. He may not (and shouldn't) get it included in the kernel and he won't get much sympathy if his modules break with newer kernels but that's about it. Whatever he uses for a front end might have issues but I'm just talking about the drivers here.

> What is absolutely true is that Tony distributes FreeBSD now, which
> isn't GPLed. However, if any of his code is based on, or contains,
> or links to code covered by the GPL, then he has to make the source
> available. Period.


> By his own admission, Tony allows that there is probably GPL code in
> his product:
> Our product has Linux roots, which, along with the GPL is on our manual, but
> our Wireless drivers are not based on any GPL code, and are developed
> in-house by yours truly.

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


This archive was generated by hypermail 2.1.4.