Re: Patch to build filesystems as modules ...

[Andrew Clausen]

On Thu, Mar 14, 2002 at 02:39:27AM +1100, Timshel Knoll wrote:
> On Wed, Mar 13, 2002 at 11:36:48AM +1100, Andrew Clausen wrote:
> > On Mon, Feb 11, 2002 at 01:07:37AM +1100, Timshel Knoll wrote:
> > > I've done some hacking to make filesystems build as modules.
> > 
> > RMS convinced me this is a bad idea, since it isn't clear
> > if the GPL is enforcable in this situation.
> 
> Why not? Is this to do with the specific text (or lack thereof) of the
> GPL?

It's very non-trivial to explain, since many concepts in the GPL
haven't been tested in court.

Take this passage for example:

"But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it."

If you have a plugin system, then the plugin need not be distributed
"as a whole" with "the Program" (perhaps).  It depends on all
kinds of legal arguments, like whether the plugin is dependent (and
in what sense... merely an API sense, or some fundamental sense?) on
the program, and so on.

There are several issues like this that get rather iffy in the
case of plugins.  (IMHO, they are even iffy in the general case...
I personally doubt the "viral" nature of the GPL is enforcable
at all, but IANAL, and law is usually stranger than you think, hehe.
I don't know much about it, just my uncle is an IP barrister, so
he explained a bit to me...)

> If so, you could explicitly say that non-free module linking is not
> allowed, then people will legally have to follow that.

Then you would be incompatible with the GPL (unless it was GPL2.1)

> Also, surely RMS
> has the power to add this point in the GPL, and release GPLv2.1 ... is
> there a reason why he shouldn't do this?

I believe the GPL3 will have changes relevant to this.  But it
seems like a difficult problem to solve.

> I agree that FS libraries are the way to go, but realistically, how soon
> is this going to happen? The ext2/3 code in parted 1.4 compiles to
> just over 64k, the fat code to ~ 75k. Parted 1.6 versions are slightly
> smaller (61k and 73k). With only these two "major" supported
> filesystems, having stuff all together is fine, but if people start
> implementing new fs code (reiser is already done, isn't it?), then we
> could have a large amount of unnecessary bloat on our hands. libdl on
> linux is 9k, so it is much more efficient to have libparted link with
> libdl and install the needed filesystem modules than have all the
> filesystems compiled into libparted itself.

Support could be enable/disabled at compile time.  Also, the reiser
code already in a state such that the amount of code (compiled)
that would be in libparted (as opposed to libreiser, or whatever)
is really small... like 5k or something.

> Also, with the issue of getting code into the filesystem libraries, is
> directly dynamically linking with these libraries a good idea? I'm just
> imagining a parted dynamically linked with libreiserfs, libext2, libxfs,
> libntfs, libufs, liblinux-swap and libfat. Now that would be a _huge_
> amount of cruft that would have to be installed just to get libparted
> working.

We can probably make libparted use libdl to dynamically link against
these libs "softly", so support just gets disabled if the libs
can't be found.

> At some stage you're going to need a dynamic run-time loading
> interface to these libraries. Modules will not be required in this
> situation, because the library stubs will be in libparted itself, and
> will be tiny. Will this have the same issues as the GPL currently has
> with modules? 

No, because the stubs would be per-fs, and require code in libparted
in each case.

Dynamic linking != plugins

(This is largely rms/fsf legal opinion, which differs from my
own...)

Andrew