Hi All,
At KQ Infotech, we have always looked at challenging ourselves by
trying to scope out new technologies. Currently we are porting ZFS to
Linux and would like to share our progress and the challenges faced,
we would also like to know your thoughts/inputs regarding our efforts.
Though we are at early stages of porting ZFS to Linux, we have gained
some insight into how we can move forward. So far we have been
successful in achieving the following milestones.
We have a ZFS building as a module and the following primitive
operations are possible.
* Creating a pool over a file (devices not supported yet)
* Zpool list, remove
* Creating filesystems and mounting them
But we are still not at a stage, where we can create files and read
and write to them. Once we are able to successfully achieve that we
will make the same available for download.
One of the biggest questions around this effort would be ?licensing?.
As far as our understanding goes; CDDL doesn?t restrict us from
modifying ZFS code and releasing it. However GPL and CDDL code cannot
be mixed, which implies that ZFS cannot be compiled into Linux Kernel
which is GPL. But we believe the way to get around this issue is to
build ZFS as a module with a CDDL license, it can still be loaded in
the Linux kernel. Though it would be restricted to use the non-GPL
symbols, but as long as that rule is adhered to there is no problem of
legal issues.
For any queries please contact us at zfs at kqinfotech.com
Stay tuned for latest updates on http://twitter.com/KQInfotech and our
blog http://kqinfotech.wordpress.com.
regards
--
Anand Mitra
CTO, Founder
KQ Infotech
www.kqinfotech.com
Anand Mitra wrote:> Hi All, > > At KQ Infotech, we have always looked at challenging ourselves by > trying to scope out new technologies. Currently we are porting ZFS to > Linux and would like to share our progress and the challenges faced, > we would also like to know your thoughts/inputs regarding our efforts. > > Though we are at early stages of porting ZFS to Linux, we have gained > some insight into how we can move forward. So far we have been > successful in achieving the following milestones. > > We have a ZFS building as a module and the following primitive > operations are possible. > > * Creating a pool over a file (devices not supported yet) > * Zpool list, remove > * Creating filesystems and mounting them > > But we are still not at a stage, where we can create files and read > and write to them. Once we are able to successfully achieve that we > will make the same available for download.That is great process thanks for sharing. Why not share the source now so that others can help you ?> One of the biggest questions around this effort would be ?licensing?. > As far as our understanding goes; CDDL doesn?t restrict us from > modifying ZFS code and releasing it. However GPL and CDDL code cannot > be mixed, which implies that ZFS cannot be compiled into Linux Kernel > which is GPL. But we believe the way to get around this issue is to > build ZFS as a module with a CDDL license, it can still be loaded in > the Linux kernel. Though it would be restricted to use the non-GPL > symbols, but as long as that rule is adhered to there is no problem of > legal issues.That is my personal understanding as well, however this is not legal advice and I am not qualified to (or even wish to) give it in any case. Good luck with the port. -- Darren J Moffat
Darren J Moffat <darrenm at opensolaris.org> wrote:> > One of the biggest questions around this effort would be ?licensing?. > > As far as our understanding goes; CDDL doesn?t restrict us from > > modifying ZFS code and releasing it. However GPL and CDDL code cannot > > be mixed, which implies that ZFS cannot be compiled into Linux Kernel > > which is GPL. But we believe the way to get around this issue is to > > build ZFS as a module with a CDDL license, it can still be loaded in > > the Linux kernel. Though it would be restricted to use the non-GPL > > symbols, but as long as that rule is adhered to there is no problem of > > legal issues. > > That is my personal understanding as well, however this is not legal > advice and I am not qualified to (or even wish to) give it in any case.>From what I have been told by various lawyers, as long as ZFS is a separatework (which means that you cannot tell other people that you mixed the "work" Linux-kernel with ZFS) there is no legal problem. If you like to ask a lawyer, be careful to ask an independent lawyer and not the SFLC (which is unfortunately giving biased advise). I good choice for an independent lawyer seems to be Lawrence Rosen: Check e.g. http://www.rosenlaw.com/Rosen_Ch06.pdf and http://www.rosenlaw.com/ J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Fri, 23 Oct 2009, Anand Mitra wrote:> > One of the biggest questions around this effort would be ?licensing?. > As far as our understanding goes; CDDL doesn?t restrict us from > modifying ZFS code and releasing it. However GPL and CDDL code cannot > be mixed, which implies that ZFS cannot be compiled into Linux Kernel > which is GPL. But we believe the way to get around this issue is to > build ZFS as a module with a CDDL license, it can still be loaded in > the Linux kernel. Though it would be restricted to use the non-GPL > symbols, but as long as that rule is adhered to there is no problem of > legal issues.The legal issues surrounding GPLv2 is what constitutes the "Program" and "work based on the Program". In the case of Linux, the "Program" is usually the Linux kernel, and things like device drivers become a "work based on the Program". Conjoining of source code is not really the issue. The issue is what constitutes the "Program". About 10 years ago I had a long discussion with RMS and the (presumably) injured party related to dynamically loading a module linked to GPLv2 code into our application. RMS felt that loading that module caused the entire work to become a "work based on the Program" while I felt that the module was the "work based on the Program" but that the rest of our application was not since that module could be deleted without impact to the application. Regardless, it has always seemed to me that (with sufficient care), a loadable module can be developed which has no linkages to other code, yet can still be successfully loaded and used. In this case it seems that the module could be loaded into the Linux kernel without itself being distributed under GPL terms. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Bob Friesenhahn wrote:> On Fri, 23 Oct 2009, Anand Mitra wrote: >> >> One of the biggest questions around this effort would be ?licensing?. >> As far as our understanding goes; CDDL doesn?t restrict us from >> modifying ZFS code and releasing it. However GPL and CDDL code cannot >> be mixed, which implies that ZFS cannot be compiled into Linux Kernel >> which is GPL. But we believe the way to get around this issue is to >> build ZFS as a module with a CDDL license, it can still be loaded in >> the Linux kernel. Though it would be restricted to use the non-GPL >> symbols, but as long as that rule is adhered to there is no problem of >> legal issues. > > The legal issues surrounding GPLv2 is what constitutes the "Program" > and "work based on the Program". In the case of Linux, the "Program" > is usually the Linux kernel, and things like device drivers become a > "work based on the Program". > > Conjoining of source code is not really the issue. The issue is what > constitutes the "Program". > > About 10 years ago I had a long discussion with RMS and the > (presumably) injured party related to dynamically loading a module > linked to GPLv2 code into our application. RMS felt that loading that > module caused the entire work to become a "work based on the Program" > while I felt that the module was the "work based on the Program" but > that the rest of our application was not since that module could be > deleted without impact to the application. > > Regardless, it has always seemed to me that (with sufficient care), a > loadable module can be developed which has no linkages to other code, > yet can still be successfully loaded and used. In this case it seems > that the module could be loaded into the Linux kernel without itself > being distributed under GPL terms. >Disclaimer: I am not a lawyer, nor do I play one on TV. I could be very wrong about this. Along these lines, it''s always struck me that most of the restrictions of the GPL fall on the entity who distrbutes the ''work'' in question. I would thinkthat distributing the source to a separate original work for a module, leaves that responsibility up to who-ever compiles it and loads it. This means the end-users, as long as they never distribute what they create, are (mostly?) unaffected by the Kernel''s GPL, and if they do distribute it, the burden is on them. Arguably that line might even be shifted from the act of compiling it, to the act of actually loading (linking) it into the Kernel, so that distributing a compiled module might even work the same way. I''m not so sure about this though. Presumably compiling it before distribution would require the use of include files from the kernel, and that seems a grey area to me. Maybe clean room include files could be created? -Kyle> Bob > -- > Bob Friesenhahn > bfriesen at simple.dallas.tx.us, > http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > ------------------------------------------------------------------------ > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
On Fri, 23 Oct 2009, Kyle McDonald wrote:> > Along these lines, it''s always struck me that most of the restrictions of the > GPL fall on the entity who distrbutes the ''work'' in question.A careful reading of GPLv2 shows that restrictions only apply when distributing binaries.> I would thinkthat distributing the source to a separate original work for a > module, leaves that responsibility up to who-ever compiles it and loads it. > This means the end-users, as long as they never distribute what they create, > are (mostly?) unaffected by the Kernel''s GPL, and if they do distribute it, > the burden is on them.If the end user builds from source then there are no GPL license issues whatsoever. This is the nature of "free" software.> Arguably that line might even be shifted from the act of compiling it, to the > act of actually loading (linking) it into the Kernel, so that distributing a > compiled module might even work the same way. I''m not so sure about this > though. Presumably compiling it before distribution would require the use of > include files from the kernel, and that seems a grey area to me. Maybe clean > room include files could be created?This is where the lawyers get involved. :-) There are a few vendors who have managed to distribute proprietary drivers as binaries for Linux. Nvidia is one such vendor. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
On Fri, October 23, 2009 11:57, Kyle McDonald wrote:> > Along these lines, it''s always struck me that most of the restrictions > of the GPL fall on the entity who distrbutes the ''work'' in question. > > I would thinkthat distributing the source to a separate original work > for a module, leaves that responsibility up to who-ever compiles it and > loads it. This means the end-users, as long as they never distribute > what they create, are (mostly?) unaffected by the Kernel''s GPL, and if > they do distribute it, the burden is on them.The problem with this, I think, is that to be used by any significant number of users, the module has to be included in a distribution, not just distributed by itself. (And the different distributions have their own policies on what they will and won''t consider including in terms of licenses.) I am also not a lawyer. And I suspect that one important answer to many of these questions is that the issues aren''t totally clear and there isn''t precedent in case law to guide our understanding much yet. Most of these things haven''t been litigated even once yet. -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info
Bob Friesenhahn wrote:> On Fri, 23 Oct 2009, Kyle McDonald wrote: >> >> Along these lines, it''s always struck me that most of the >> restrictions of the GPL fall on the entity who distrbutes the ''work'' >> in question. > > A careful reading of GPLv2 shows that restrictions only apply when > distributing binaries. > >> I would thinkthat distributing the source to a separate original work >> for a module, leaves that responsibility up to who-ever compiles it >> and loads it. This means the end-users, as long as they never >> distribute what they create, are (mostly?) unaffected by the Kernel''s >> GPL, and if they do distribute it, the burden is on them. > > If the end user builds from source then there are no GPL license > issues whatsoever. This is the nature of "free" software. > >> Arguably that line might even be shifted from the act of compiling >> it, to the act of actually loading (linking) it into the Kernel, so >> that distributing a compiled module might even work the same way. I''m >> not so sure about this though. Presumably compiling it before >> distribution would require the use of include files from the kernel, >> and that seems a grey area to me. Maybe clean room include files >> could be created? > > This is where the lawyers get involved. :-) > > There are a few vendors who have managed to distribute proprietary > drivers as binaries for Linux. Nvidia is one such vendor.Exactly. I can think of several Companies that do the same. Packaging it in a single kernel RPM, might be too close for comfort, but packaging it in it''s own optionally installed RPM, and including that on the distribution DVD should also be safe - There is a cluase that allows non-GPL works to be distributed on the same media. -Kyle> > Bob > -- > Bob Friesenhahn > bfriesen at simple.dallas.tx.us, > http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Kyle McDonald <KMcDonald at Egenera.COM> wrote:> Arguably that line might even be shifted from the act of compiling it, > to the act of actually loading (linking) it into the Kernel, so that > distributing a compiled module might even work the same way. I''m not so > sure about this though. Presumably compiling it before distribution > would require the use of include files from the kernel, and that seems a > grey area to me. Maybe clean room include files could be created?In Germany/Europe, we have something called "Wissenschaftliches Kleinzitat", in the USA, there is "fair use". For this reason, I don''t believe that using include files or calling kernel functions is a problem. Also note that the FSF was asked by the Open Source Initative on whether the GPL follows the 10 rules from the OSS definition at: http://www.opensource.org/docs/definition.php The FSF did reply to the OSI that the GPL has to interpreted in a way that makes it OSS compliant. I would like to direct you in special to section 9 of the OSS definition. People who claim to see problems usually ignore the rules from the OSS definition or from the Copyright law. Also, looking at the substanciations of the adjucations from the lawsuits driven by Harald Welte shows that the German judges have the same doubts about the legality of many claims from the GPL as you see in the GPL review from Lawrence Rosen in http://www.rosenlaw.com/Rosen_Ch06.pdf I would be relaxed even if I did plan to ship ZFS binaries for Linux. If in doubt, ask a specialized completely independend lawyer. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:> On Fri, 23 Oct 2009, Kyle McDonald wrote: > > > > Along these lines, it''s always struck me that most of the restrictions of the > > GPL fall on the entity who distrbutes the ''work'' in question. > > A careful reading of GPLv2 shows that restrictions only apply when > distributing binaries.These "restrictions" in substance require you to that you need to make everything (except things that wre usually distributed with the system) available to allow a recompilation (including linking) for a GPLd work. You have to do this in case that you ship binaries from the GPLd work. If you ship a ZFS binary, I see no reason why someone could try to argue that you ship binaries from GPLd code ;-)> There are a few vendors who have managed to distribute proprietary > drivers as binaries for Linux. Nvidia is one such vendor.But ZFS is no proprietary driver, it is OSS. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
"David Dyer-Bennet" <dd-b at dd-b.net> wrote:> The problem with this, I think, is that to be used by any significant > number of users, the module has to be included in a distribution, not just > distributed by itself. (And the different distributions have their own > policies on what they will and won''t consider including in terms of > licenses.)For this argument, I recommend to read the OpenSource Definition at: http://www.opensource.org/docs/definition.php in special look at section 9. The FSF grants you that the GPL is an OSS compliant license, so there is no difference between shipping ZFS separately and shipping it as part of a distro. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Hi Joerg, Thanks for this clarification. We understand that we can distribute ZFS binary under a non GPL license, as long as it does not use GPL symbols. Our plan regarding ZFS is to first port it to Linux kernel and then make its binary distributions available for various different distributions of Linux. These binary distribution will be in form of loadable kernel modules and commands. Once we get ready with ZFS port then we will start sharing our plans for its binary distributions. Feel free to contact us if anyone is interested in ZFS port on specific linux distribution. Regards, Anurag. On Sat, Oct 24, 2009 at 12:20 AM, Joerg Schilling < Joerg.Schilling at fokus.fraunhofer.de> wrote:> "David Dyer-Bennet" <dd-b at dd-b.net> wrote: > > > The problem with this, I think, is that to be used by any significant > > number of users, the module has to be included in a distribution, not > just > > distributed by itself. (And the different distributions have their own > > policies on what they will and won''t consider including in terms of > > licenses.) > > For this argument, I recommend to read the OpenSource Definition at: > http://www.opensource.org/docs/definition.php in special look at section > 9. > > The FSF grants you that the GPL is an OSS compliant license, so there is no > difference between shipping ZFS separately and shipping it as part of a > distro. > > J?rg > > -- > EMail:joerg at schily.isdn.cs.tu-berlin.de<EMail%3Ajoerg at schily.isdn.cs.tu-berlin.de>(home) J?rg Schilling D-13353 Berlin > js at cs.tu-berlin.de (uni) > joerg.schilling at fokus.fraunhofer.de (work) Blog: > http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-- Anurag Agarwal CEO, Founder KQ Infotech, Pune www.kqinfotech.com 9881254401 Coordinator Akshar Bharati www.aksharbharati.org Spreading joy through reading -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20091024/d1c0023a/attachment.html>