invalidate_page_range() for non-GPL modules
Paul McKenney has requested that this function be exported to all modules. It seems that IBM's GPFS filesystem needs it, and that filesystem is not free software. The claim is that the filesystem is an entirely independent development, and is thus not derived from the kernel; it should not have to be licensed under the GPL to be loadable into the kernel.
Andrew Morton says he is not opposed to the patch. One might think it would not be too controversial, especially since that function was first created and submitted by...Paul McKenney. There are developers, however, who believe that any module which is digging that deeply into the virtual memory subsystem cannot help but be derived, in some fashion, from the Linux kernel. There is also, perhaps, a certain desire to demonstrate that even IBM can't obtain arbitrary access to the kernel for proprietary modules.
In general, the kernel hackers are more interested in seeing their work be
useful and used, instead of fighting over licensing battles.
So one might expect to
see this patch eventually get incorporated. In more recent times, however,
some developers have been adopting a firmer position with regard to
proprietary modules. This patch may still get in, but it's likely to have
a harder time than would have once been the case.
| Index entries for this article | |
|---|---|
| Kernel | Modules/Licensing |
Posted Feb 19, 2004 23:37 UTC (Thu)
by larryr (guest, #4030)
[Link]
Andrew Morton later said
I agree 100%. I think any (viz non-GPL) filesystem implementation should be able notify the kernel that the underlying store has changed.
Larry
Posted Feb 20, 2004 4:40 UTC (Fri)
by Duncan (guest, #6647)
[Link]
digging that deeply
Needing access to invalidate_mmap_range() is surely not an indication of a
derived work. It is an indication of a need for a reliable way to achieve
inter-node cache consistency.
> One might think it would not be too controversial, invalidate_page_range() for non-GPL modules
> especially since that function was first created
> and submitted by...Paul McKenney.
It would seem to me, however, that the above is only one chapter of the story.
His submission could be added to the kernel, and indeed use the REST of the
kernel, because it WAS GPLed. What of the idea of "standing on the
shoulders of giants"?
Who wrote the code that HIS patch called, or the code it was inserted in the
middle of and thus depends on? Who wrote the code that THAT code
called? Etc..
It seems to me that all the callees get veto power over this as well, at least in
theory. At minimum, it would seem that the writer of the code directly called
by the patch or that the patch or segments of were introduced in the middle
of, have veto power. How far beyond that we want to take it could be
debated, as could be what the default policy, should the author of supporting
code no longer be available or refuse to take a position. but it seems to me
that at minimum, should those authors express an opinion one way or the
other, it should be honored.
(Personally, my position is that, would any of my work ever be involved..
purely for argument's sake, since I'm not likely to ever do anything more than
trivial re the kernel.. I'd be inclined to say NO, since I wouldn't have
bothered switching from a decade on proprietary-ware if I didn't believe it
was the wrong solution, and I have strong feelings about ANYTHING I do
being supportive of proprietary-ware, PERIOD. That's why tho I use
Mandrake, itself fairly strongly libre-ware supportive, I'm not a member of
Mdk Club -- a small portion of the dues of which must go to support in
SOME way the "freebie" proprietary-ware the club offers access to as one of
its benefits. I don't want ANY support of mine going to proprietary-ware.
However, as my code is NOT part of the dependency tree, here, it's not up to
me to decide whether GPL exceptions should be granted or not.)
Duncan