invalidate_mmap_range() again

Posted Feb 26, 2004 9:02 UTC (Thu) by simlo (subscriber, #10866) [Link]

To me it seems the GPL zealots are using the same arguments against this kind of module as SCO is towards RCU: If it was developped for Linux it is a derivative of Linux and must thus be distributed under GPL. Since RCU was developed for Unix it is a derivative work of Unix and must be treated according to the contract between the Unix licensee and SCO.

I don't know what the lawyers say, but I can't see that a function not contanining any direct code from Linux or Unix can be a derivative work. Only the combination between the function and Linux or Unix can be a derivative work.

Posted Feb 26, 2004 14:20 UTC (Thu) by Duncan (guest, #6647) [Link]

As I posted last week, I think this discussion is missing one item that needs
considered. Last week the article mentioned that the person requesting the
change to EXPORT from GPL_EXPORT was none other than the person
that originally proposed the patch. Therefore, it obviously has his permission
and that isn't in question. Also, his code is GPLed as part of the kernel and
naturally gets access to the rest of the kernel as such. He's free to
dual-license it elsewise to whoever, including proprietary-ware folks as it's his
code. However, what of the code HE calls? How much of a say should
THOSE authors get? What about code THEY call? How far do such things
permission questions need to revert?

At that time, I hadn't taken a look at the request or the patch. I now have.
I'm no kernel hacker by far, but the patch seems reasonably self-coherent.
Other than the header and export definitions, naturally in their respective
files, everything applies as a single linear patch to a single file, so he's not
piece-mealing anything. I'm not qualified to determine how many kernel
functions he calls and how deep in the kernel THEY are, but its obvious this
patch wasn't extremely invasive, more additive, and that it's as self coherent
as it can be. Therefore, the ones that maintain the file the function is added
to and any functions it calls should be easily determinable, as should their
status both within the kernel and in the patch. The opinions of owners and
maintainers of at least the direct callees should be taken into account, IMO.
If none of them object, there shouldn't be a problem. If one or more of them
do, then it becomes more of a judgement call.

As well, the request mentions that the IBM GPFS folks were instrumental in
testing the patch. I also noted that the original patch proposal included a
straight EXPORT, not the GPL_EXPORT that is the current situation. I
don't know the history of that, whether general kernel policy changed since
then, whether it was introduced with GPL_EXPORT by policy or
deliberately changed on introduction, or what, but it does seem obvious that
the original intention was that it be generally exported as evidenced by the
unrestricted EXPORT in the original patch proposal.

As the article points out, the request is a generally valid request in that it's a
legitimate function that filesystems of the general genre could certainly use.
Thus, the policy debate shouldn't be restricted to this particular case, either.
As Morton seemed to be getting at, the question then becomes one of is this a
function that we want to export to make available to non-GPL callers or not?
If the answer is yes, then certainly IBM being the friendly force they are
shouldn't change that. If they answer is no, then just because IBM is friendly,
shouldn't change it either.

Then we have the question of GPFS itself. The article is forthcoming enough
with the information that it's IBMs, and that it originated in AIX and remains
currently proprietary, and with the BSD license info on the "glue" module.
However, there's still a vital piece of info missing. Presumably IBM is only
asking for this having considered and rejected the possibility of making the
entire fs open source, as they have with a lot of other code. Unfortunately,
no mention of why this may be is made. Is this something that indeed DOES
have NON-IBM intellectual property belonging to others in it and therefore
CANNOT be open sourced without their go-ahead? (Of course, SCO is
claiming this to be the case with all sorts of previous IBM donated code,
which it appears to think it can restrict in entirety even without owning a bit
of it, simply because it touched AIX, a UNIX licensee. I'm asking about a
more reasonable claim of third party IP.) If that isn't claimed to be the case,
then it's simply IBM saying it doesn't want to release this particular code just
yet, for whatever reason, probably competitive. That's certainly within its
rights as it owns the code in question, but it's certainly within the rights of the
Linux folks to fail to be cooperative with their code as well, then, in this
instance, despite past cooperation. What is the current distribution and usage
of the filesystem and how would that conceivably expand if it were GPLed?
IOW, what are the practical implications for IBM choosing not to open
source the FS at this point, and is it likely to do so in the future? How might
the decision of the kernel folks now impact such a future decision?

Yes, I just got thru a couple paragraphs up saying GPFS in specific shouldn't
make a big difference to the case, since it's already acked that the function in
question is a legitimate call for such file systems, which means it's ultimately
a larger policy question. However, until another such proprietary file system
asks, it's just the one, and the question could always be put off until later,
keeping it GPL_EXPORT for the present. Thus, the questions above about
this /particular/ case certainly matter to the degree that timing is an issue,
even if they don't matter to the eventual policy debate. Unfortunately, tho
the issue has been covered two weeks in a row by LWN, both articles
overlooked this seemingly quite apropos question.

Personally, as I mentioned last week, I'm all for letting them hang. The
authors of proprietary-ware by the very fact that it IS proprietary are
demonstrating an unwillingness to operate in what most open source
developers have chosen to believe in to the point of making a commitment to
at VERY MINIMUM invest a significant amount of personal time in. That
goes double for kernel developers, who've obviously invested a VERY
significant amount of time to open source. For a propriatery-ware developer
to ask such a favor while refusing to open his own work is in some ways akin
to a slap in the face! I firmly believe that every bit of code turned open
source makes this world a better place, and thus, believe that every effort to
encourage that should be made, and the converse also, that little if any time
should be given to abiding the requests of those continuing to support
proprietary-ware. None-the-less, I'm pragmatic enough to realize that
proprietary-ware will not only exist for some time, and that we must co-exist
with it, but that sometimes yielding a bit may produce the greater gain,
ultimately, for libre-ware, and thus, for what I believe to be a better world,
Unfortunately, there are still a few pieces missing from the coverage here for
me to hold a fully informed opinion as to the merits of this particular case
and how the current decision may advance or inhibit the software libre cause.

Duncan