Hi all!
Sorry if it is a little bit offtopic. As I posted before the company I am
working for would like me to write a linux driver. It's wunderful. But as the
other companies it wouldn't like to publish the source code and wants to
distribute it only in binary format.
Of course I prefer the GPL. How can I change the company's mind about it?
I planned the driver as the following:
The DRIVER itself (handles interrupt, pci resources, memory access etc)
A LIB, used by applications. In real life it implements the functions of the
card.
First question: Is it possible to write the driver in GPL and then develop a
binary only LIB? (I think yes because the LIB is in user space)
The company may accept the GPL-d driver, but not the GPL-d (or LGPL-d) LIB.
What are the advantages when the driver is GPL? How can I change the company's
mind to publish the driver in GPL? (or if someone has got idea about the LGPL
LIB too...)
Now the driver doesn't use any GPL-only symbols...
THX
Gabor
> First question: Is it possible to write the driver in GPL and then develop a
> binary only LIB? (I think yes because the LIB is in user space)
Thats a legal question about derivative works again. Its a lawyer question.
Don't ask lawyers how to program, don't ask programmers how the law works 8)
In business terms a binary only driver means that it won't be considered for
the mainstream kernel and you will need to rebuild it for every exact kernel
version your customers want. Irrespective of the GPL/lib question it may be
helpful to provide your customers source code to the kernel part of the
driver if only so you don't have to keep recompiling it. VMware follows very
much this model - their kernel bits are source code, vmware itself is most
definitely proprietary and per copy licensed.
Alan
Hi!
> The company may accept the GPL-d driver, but not the GPL-d (or LGPL-d) LIB.
That's okay. You can have GPLed driver and proprietary library using
it.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
On Wed, 17 Apr 2002, Alan Cox wrote:
| > First question: Is it possible to write the driver in GPL and then develop a
| > binary only LIB? (I think yes because the LIB is in user space)
|
| Thats a legal question about derivative works again. Its a lawyer question.
| Don't ask lawyers how to program, don't ask programmers how the law works 8)
|
| In business terms a binary only driver means that it won't be considered for
| the mainstream kernel and you will need to rebuild it for every exact kernel
| version your customers want. Irrespective of the GPL/lib question it may be
| helpful to provide your customers source code to the kernel part of the
| driver if only so you don't have to keep recompiling it. VMware follows very
| much this model - their kernel bits are source code, vmware itself is most
| definitely proprietary and per copy licensed.
Hi-
If this isn't clear to you, consider all of the processor-type
possibilities, CONFIG possibilities, etc., that you could need to
build for...not that anyone does all of this, but you could have
customers who want all of these variations.[1]
Furthermore, with open source code, you get lots of debugging
help and often get help porting the driver to newer kernel
versions (there's always something needed for the next kernel
version).
Another argument, if your company is concerned about exposing IP,
is that you expose IP that is not exactly the latest and greatest.
So what? Maybe some other company will try to copy it.
If they do, they will be working on a design that is a generation
behind your company's new/latest design!
[1] from 2.4.18:
alpha/ cris/ ia64/ mips/ parisc/ s390/ sh/ sparc64/
arm/ i386/ m68k/ mips64/ ppc/ s390x/ sparc/
CONFIG_SMP=y or n requires a different kernel build.
CONFIG_HIGHMEM=z requires a different kernel build.
Not to mention CONFIG_module support, processor tuning...
(probably missed a few CONFIG options here...)
Now how many target kernel binaries do you want to build for
each kernel version?
15 processor_types * 2 * 2 = 60 kernel binaries per kernel version
(but obviously worst case since you won't support all of
those processor types)
--
~Randy