Re: Non-GPL export of invalidate_mmap_range

Lars Marowsky-Bree
2004-02-19T18:32:10Z

On 2004-02-19T01:11:29,
"Paul E. McKenney" <paulmck@us.ibm.com> said:

> > And pokes deep into internal structures that it shouldn't.
> Again, the point of the patch is to get rid of such poking.

I think this fiddling about this particular exported symbol is hiding
the real issue.

It seems that Christoph believes that _inherently_, any filesystem
kernel module on Linux must be a derived work, because it is intimately
tied into the kernel core / VFS. I can certainly see the reasoning
here, and it is a valid point of view.

Do we want to allow non-OSS filesystems in kernel space at all? That's
the entire question.

Personally, I would go with "No" and support the consequences of this,
because I believe in Open Source; and that the value proposition of
Linux is /not/ in binary-only modules, and I would /not/ sacrifice the
OSS principles of the literal core of the Linux project for a short term
pay-off.

(But I'm personally trying to solve that by making them superfluous and
putting them out of business by getting an OSS CFS, which seems to be
more amiable ;-)

Only if we can settle this, we can answer this export question. If we
want to allow them, the export is a perfectly reasonable thing to ask
for. If not, we probably need to add a few more _GPL barriers.

A rule of thumb might be whether any code in the tree uses a given
export, and if not, prune it. Anything which even we don't use or export
across the user-land boundary certainly qualifies as a kernel interna.

Currently, no kernel module seems to use this export. So I'd think such
a point could certainly be made.

Sincerely,
Lars Marowsky-Bree <lmb@suse.de>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett