lkml.org 
[lkml]   [1999]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: embedded linux products && GPL && non-GPL'ed stuff
On Mon, 20 Sep 1999, Steve Dodd wrote:
[SNIPPED]

>
> This is interesting. First of all, the applications: this is relatively
> straightforward. So long as the apps don't link against any GPLd libraries,
> or include any GPLd code, there's no problem (libc, for example, is LGPLd,
> so that's OK). Linus' note at the top of linux/COPYING states that he does not
> consider a program which communicates with the kernel via syscalls to be a
> 'derived work'.
>
> Kernel modules, whether loadable or compiled in, are a different matter (but
> I'm Really Not A Lawyer). My understanding is that if you link (statically or
> dynamically) against a GPLd library, your code is a derived work. As kernel
> modules are linked to the kernel, I'd imagine that they are, therefore,
> derived works. Regardless of the linking issue, 99% of modules are going to
> use the kernel headers, which are AFAIK also GPLd.
>
> Having said all this, it's up to the copyright holder(s) to set and enforce
> the license(s). I guess Linus holds the copyright on a lot of the core stuff
> (i.e. the bits a driver would actually be linking against), but grep'ing for
> "Copyright" in, say, linux/fs produces some files which don't claim to be
> copyright Linus, or (more interestingly) which have multiple copyright
> messages.
>
> So Linus, for example, could say that he doesn't consider modules to be
> derived works. But others who have contributed code, and therefore hold the
> copyright on those bits, might disagree, which could get nasty.
>
> Perhaps this should be clarified with another note at the top of
> linux/COPYING, so people contributing code know where they stand.
>
> Did anyone ever set up that linux-legal list, so we can move this there? I
> don't want to piss off the regulars <g>
>

What I am doing is providing (giving) the source-code for the module
necessary to communicate with our proprietary hardware away. We WANT
customers to write other applications and the module (driver) is the API
to the hardware. The API could simply be written without a module, since
the hardware is memory-mapped. However, you'd lose the ability to
poll for completion (interrupts).

The other stuff (a network server that communicates with the API) will
probably be given away also.

Basically, my embeded system communicates as a server via GPIB, RS-232C,
and a TCP/IP socket. A monitor allows one to set the IP address, etc.,
and the port number as well as the GPIB address and the RS-232C baud-
rate. This is pretty simple stuff.

The most complicated stuff is booting from NVRAM, with a BIOS module that
replaces a boot-drive on startup. This is complicated because the NVRAM
chosen by the hardware engineers can only be read sequentially so the
virtual heads/sectors/cylinders have to be 'munged'. The NVRAM is
read as a sequential stream of bits (not even bytes) -- gawd they
make this difficult. Basically, I have 1 bit of assessible NVRAM.
It sits at the `game-port` address.


Cheers,
Dick Johnson
**** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2011 Jasper Spaans