Joerg Shilling,
Putting the license issues aside for a moment.
If their is "INTEREST" in ZFS within Linux, should
a small Linux group be formed to break down ZFS in
easily portable sections and non-portable sections.
And get a real-time/effort assessment as to what is
needed to get it done.
Assuming their is interest and usage, if ported, I
would assume that someone/some group would make sure
that the code is resynced on a periodic basis.
I know a FS from Veritas and SGI were reviewed in
these manners. The Veritas's FS originally was
developed using the Sun's VFS layer.
So, if the license issues are removed, I am sure
that ZFS could be ported over to Linux. It is just
time and effort...
Mitchell Erblich
Ex: Sun Kernel Engineer
Joerg Schilling wrote:
>
> Nicolas Williams <[EMAIL PROTECTED]> wrote:
>
> > Sigh. We have devolved. Every thread on OpenSolaris discuss lists
> > seems to devolve into a license discussion.
>
> It is funny to see that in our case, the tecnical problems (those caused
> by the fact that linux implements a different VFS interface layer) are
> creating much bigger problem than the license issue does.
>
> > I have seen mailing list posts (I'd have to search again) that indicate
> > [that some believe] that even dynamic linking via dlopen() qualifies as
> > making a derivative.
>
> There is no single place in the GPL that mentions the term "linking".
> For this reason, the GPL FAQ from the FSF is wring as it is based on the
> term "linking".
>
> There is no difference whether you link statically or dynamically.
>
> Whether using GPLd code from a non-GPLd program creates a "derived work"
> thus cannot depend on whether you link agaist it or not. If a GPLd program
> however "uses" a non-GPLd library, this is definitely not a problem or
> every GPLd program linked against the libc from HP-UX would be a problem.
>
> > If true that would mean that one could not distribute an OpenSolaris
> > distribution containing a GPLed PAM module. Or perhaps, because in that
> > case the header files needed to make the linking possible are not GPLed
> > the linking-makes-derivatives argument would not apply.
>
> If the GPLd PAM module just implements a well known plug in interface,
> a program that uses this odule cannot be a derivate of the GPLd code.
>
> Jörg
>
> --
> EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
> [EMAIL PROTECTED] (uni)
> [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
> URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
