Hi all,
I have the following question. Suppose that some proprietary driver
(otherwise completely clean, based only on non-GPL symbols)
requires a large buffer of physically contiguous memory.
A GPL-ed driver could get this memory by having some boot-time
code compiled into the kernel which calls bootmem_alloc during
kernel initialization. This function would stash the address of the
memory into some global variable which is exported for the
module to use.
How do you solve this problem in a proprietary driver? It seems
like the above solution taints the kernel, because the kernel
provides a symbol which exists only for the sake of supporting
a proprietary driver.
Would it be okay to have a mechanism like this:
Suppose that on the kernel command line, you could
request a boot-time memory allocation and give it a name.
For instance, the parameter:
boot_alloc=foo,8192K
would create an 8192 kilobyte allocation, and associate it
with the string "foo". A non-GPL function would be provided to
find the address of this memory, using the string "foo"
as the key. The proprietary driver would document the
requirement that it needs a memory region of at least
8192K, under the name "foo".
Help! :)
On Tue, 2008-10-14 at 14:56 -0700, Kaz Kylheku wrote:
> Hi all,
>
> I have the following question. Suppose that some proprietary driver
> (otherwise completely clean, based only on non-GPL symbols)
> requires a large buffer of physically contiguous memory.
>
> A GPL-ed driver could get this memory by having some boot-time
> code compiled into the kernel which calls bootmem_alloc during
> kernel initialization. This function would stash the address of the
> memory into some global variable which is exported for the
> module to use.
>
> How do you solve this problem in a proprietary driver? It seems
> like the above solution taints the kernel, because the kernel
> provides a symbol which exists only for the sake of supporting
> a proprietary driver.
>
> Would it be okay to have a mechanism like this:
> Suppose that on the kernel command line, you could
> request a boot-time memory allocation and give it a name.
> For instance, the parameter:
>
> boot_alloc=foo,8192K
>
> would create an 8192 kilobyte allocation, and associate it
> with the string "foo". A non-GPL function would be provided to
> find the address of this memory, using the string "foo"
> as the key. The proprietary driver would document the
> requirement that it needs a memory region of at least
> 8192K, under the name "foo".
Any GPL driver doing that deserves to be taken out and shot just as bad
as anyone else ;-)
That said, I don't think you'll find much sympathy here for non-GPL
kernel modules.
On Tue, Oct 14, 2008 at 02:56:40PM -0700, Kaz Kylheku wrote:
> I have the following question. Suppose that some proprietary driver
> (otherwise completely clean, based only on non-GPL symbols)
You have strange notion of "clean".
> requires a large buffer of physically contiguous memory.
>
> A GPL-ed driver could get this memory by having some boot-time
> code compiled into the kernel which calls bootmem_alloc during
> kernel initialization. This function would stash the address of the
> memory into some global variable which is exported for the
> module to use.
>
> How do you solve this problem in a proprietary driver?
:-)
> It seems
> like the above solution taints the kernel, because the kernel
> provides a symbol which exists only for the sake of supporting
> a proprietary driver.
>
> Would it be okay to have a mechanism like this:
> Suppose that on the kernel command line, you could
> request a boot-time memory allocation and give it a name.
> For instance, the parameter:
>
> boot_alloc=foo,8192K
>
> would create an 8192 kilobyte allocation, and associate it
> with the string "foo". A non-GPL function would be provided to
> find the address of this memory, using the string "foo"
> as the key. The proprietary driver would document the
> requirement that it needs a memory region of at least
> 8192K, under the name "foo".
>
> Help! :)
Since the code to reserve memory and code to find by name won't be
accepted, the question is rather pointless.
Kaz Kylheku wrote:
> I have the following question. Suppose that some proprietary driver
> (otherwise completely clean, based only on non-GPL symbols)
The fact that it's not using GPL symbols does not actually mean that the
driver is not a derivative work of the kernel (and thus subject to the GPL).
> Would it be okay to have a mechanism like this:
<snip>
You should probably talk to a lawyer specializing in IP law.
Chris
On Tue, Oct 14, 2008 at 3:10 PM, Alexey Dobriyan <[email protected]> wrote:
> On Tue, Oct 14, 2008 at 02:56:40PM -0700, Kaz Kylheku wrote:
>> Would it be okay to have a mechanism like this:
>> Suppose that on the kernel command line, you could
>> request a boot-time memory allocation and give it a name.
>> For instance, the parameter:
>>
>> boot_alloc=foo,8192K
>>
>> would create an 8192 kilobyte allocation, and associate it
>> with the string "foo". A non-GPL function would be provided to
>> find the address of this memory, using the string "foo"
>> as the key. The proprietary driver would document the
>> requirement that it needs a memory region of at least
>> 8192K, under the name "foo".
>>
>> Help! :)
>
> Since the code to reserve memory and code to find by name won't be
> accepted, the question is rather pointless.
Suppose that this problem is being solved by people who maintain
their own OS distribution, based around a customized Linux kernel,
targetting a very specific piece of hardware, manufactured by
them.
So there is no situation in which users of a mainstream
distribution would be asked to patched their kernels to
be able to use this driver. Their kernels would already
come that way from this distribution.
The driver in question is specific to the hardware, and uses code
licensed from the vendor of some chips that are used on the
embedded system, so the developers don't have the option of
open-sourcing it, however attractive that might be.
On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen <[email protected]> wrote:
> Kaz Kylheku wrote:
>
>> I have the following question. Suppose that some proprietary driver
>> (otherwise completely clean, based only on non-GPL symbols)
>
> The fact that it's not using GPL symbols does not actually mean that the
> driver is not a derivative work of the kernel (and thus subject to the GPL).
But thanks to the gracious tolerance of the kernel development
community, such drivers are permitted to exist. That is the question:
setting aside GPL chapter and verse, could that tolerance extend
to allow such a driver to get a piece of boot-time memory, and if so,
what mechanism would be tolerated?
On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen <[email protected]> wrote:
> Kaz Kylheku wrote:
>
>> I have the following question. Suppose that some proprietary driver
>> (otherwise completely clean, based only on non-GPL symbols)
>
> The fact that it's not using GPL symbols does not actually mean that the
> driver is not a derivative work of the kernel (and thus subject to the GPL).
One more thing. Here is another question.
Suppose that this proprietary driver can be moved entirely into user
space. It still needs the contiguous buffer, but it can
map it using mmap, given the address.
Can this proprietary user-space application read the address
of this buffer from a custom /proc entry?
Or does this dependency make it a derived work of the kernel?
Kaz Kylheku wrote:
> On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen <[email protected]>
> wrote:
>
>> Kaz Kylheku wrote:
>>
>>
>>> I have the following question. Suppose that some proprietary
>>> driver (otherwise completely clean, based only on non-GPL
>>> symbols)
>>
>> The fact that it's not using GPL symbols does not actually mean
>> that the driver is not a derivative work of the kernel (and thus
>> subject to the GPL).
>
>
> But thanks to the gracious tolerance of the kernel development
> community, such drivers are permitted to exist.
If you're thinking of something like the Nvidia driver, the binary
portion of that driver is cross-platform and is not a derivative work of
the kernel.
If you sit down and write a new driver for linux, is is arguable that it
is in fact a derivative work of the kernel and is thus subject to the GPL.
This may of course vary based on location, but I strongly suggest that
you consult suitable legal advice before proceeding.
Chris
Chris Friesen wrote:
> If you sit down and write a new driver for linux, is is arguable that
> it is in fact a derivative work of the kernel and is thus subject to
> the GPL.
This is essentially the argument that SCO used when they sued IBM over
IBM's printing technology.
On Tue, Oct 14, 2008 at 04:23:37PM -0700, Kaz Kylheku wrote:
> On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen <[email protected]> wrote:
> > Kaz Kylheku wrote:
> >
> >> I have the following question. Suppose that some proprietary driver
> >> (otherwise completely clean, based only on non-GPL symbols)
> >
> > The fact that it's not using GPL symbols does not actually mean that the
> > driver is not a derivative work of the kernel (and thus subject to the GPL).
>
> But thanks to the gracious tolerance of the kernel development
> community, such drivers are permitted to exist.
>...
"tolerance" = "it has not yet been brought to court"
There is no explicit permission of any kind for doing this, and it can
be might to court in any country based on the local copyright law at
any time.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> But thanks to the gracious tolerance of the kernel development
> community, such drivers are permitted to exist. That is the question:
Thats an interesting interpretation and not one I'd want to rely upon.
> setting aside GPL chapter and verse, could that tolerance extend
> to allow such a driver to get a piece of boot-time memory, and if so,
> what mechanism would be tolerated?
You should discuss such matters with your lawyer. What you are trying to
ask I think is a question about what constitutes an independant work, and
that is a legal not a technical question.
Alan
On Wednesday 15 October 2008 10:39, Kaz Kylheku wrote:
> On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen <[email protected]> wrote:
> > Kaz Kylheku wrote:
> >> I have the following question. Suppose that some proprietary driver
> >> (otherwise completely clean, based only on non-GPL symbols)
> >
> > The fact that it's not using GPL symbols does not actually mean that the
> > driver is not a derivative work of the kernel (and thus subject to the
> > GPL).
>
> One more thing. Here is another question.
I don't know if there are any lawyers on this list, and definitely you
shouldn't take this kind of advice from answers here.
> Suppose that this proprietary driver can be moved entirely into user
> space. It still needs the contiguous buffer, but it can
> map it using mmap, given the address.
The kernel carries a license that states:
'NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".'
Which could be relevant.
> Can this proprietary user-space application read the address
> of this buffer from a custom /proc entry?
>
> Or does this dependency make it a derived work of the kernel?
I would be careful if you were to explicitly modify the kernel you
distribute with the driver in order to allow your driver to live
in userspace. No idea whether that is safe.
However, we do have this pagemap proc API existing in the kernel
which is a kernel service that can be used with a normal system
call. It returns the page frame number that a given virtual address
is mapped to. (God knows WTF that is supposed to be a remotely good
idea for the kernel to export, but there you have it.)
Whether that helps you or allows you to comply with your obligations,
I don't know.
Or, as an alternative, why not instead run the gauntlet with your
other licensor and tell them their license isn't acceptable because
your product contains code with incompatible restrictions?!
>>>>> "Kaz" == Kaz Kylheku <[email protected]> writes:
Kaz> On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen <[email protected]> wrote:
>> Kaz Kylheku wrote:
>>
>>> I have the following question. Suppose that some proprietary driver
>>> (otherwise completely clean, based only on non-GPL symbols)
>>
>> The fact that it's not using GPL symbols does not actually mean that the
>> driver is not a derivative work of the kernel (and thus subject to the GPL).
Kaz> But thanks to the gracious tolerance of the kernel development
Kaz> community, such drivers are permitted to exist. That is the question:
Kaz> setting aside GPL chapter and verse, could that tolerance extend
Kaz> to allow such a driver to get a piece of boot-time memory, and if so,
Kaz> what mechanism would be tolerated?
Why doesn't your hardware support Scatter Gather Lists instead? Then
you could setup virtual contiguous memory regions to use, but the
underlying physical RAM could be fragmented and you wouldn't care.
Seems like the more sensible solution. Also, more people would be
*happy* to help you in that case, as opposed to the "I need a large
block of contiguous RAM" request which pops up a couple of times a
year on this list and pretty much always gets shot down.
John
Kaz Kylheku wrote:
> Hi all,
>
> I have the following question. Suppose that some proprietary driver
> (otherwise completely clean, based only on non-GPL symbols)
> requires a large buffer of physically contiguous memory.
>
> A GPL-ed driver could get this memory by having some boot-time
> code compiled into the kernel which calls bootmem_alloc during
> kernel initialization. This function would stash the address of the
> memory into some global variable which is exported for the
> module to use.
>
> How do you solve this problem in a proprietary driver? It seems
> like the above solution taints the kernel, because the kernel
> provides a symbol which exists only for the sake of supporting
> a proprietary driver.
>
> Would it be okay to have a mechanism like this:
> Suppose that on the kernel command line, you could
> request a boot-time memory allocation and give it a name.
> For instance, the parameter:
>
> boot_alloc=foo,8192K
>
> would create an 8192 kilobyte allocation, and associate it
> with the string "foo". A non-GPL function would be provided to
> find the address of this memory, using the string "foo"
> as the key. The proprietary driver would document the
> requirement that it needs a memory region of at least
> 8192K, under the name "foo".
>
> Help! :)
Hardware with scatter/gatcher capabilites would be best. But short
of that, you could just use the bigphysarea patch. GOOGLE for it and you'll
find a version suitable for most kernel versions. I've been using it for years with
a GPL driver but even if the driver wasn't GPL I would still be using it.
I sure wish it could be included in the kernel??
There really aren't many good reasons not to GPL your driver BTW.
Mark