Date: Fri, 09 Feb 2001 12:09:14 -0600 From: Russell Cattelan <cattelan@thebarn.com> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-chat@FreeBSD.ORG, Jack Rusher <jar@integratus.com>, Sam Leffler <sam@errno.com>, Zhiui Zhang <zzhang@cs.binghamton.edu>, freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system Message-ID: <3A843249.D93D5952@thebarn.com> References: <200102090856.BAA08304@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > OK, this is not a license war. I will lay it on the line. > > I am offering to do a preliminary port of the XFS code, > potentially to the point of minimally a read-only mount, and > perhaps much further, depending on the effort required. > > The resulting code will have some nasty strings, based on > me assuming your comments are correct, and wanting some > guarantees on that, on my part. The strings go away when > your claims to SGI's actions are met. > > Below is my reply to your message, including the philosophical > basis for the strings, a description of the strings, and the > details of my offer. > > This offer is good for a starting date before 01 March 2001. > > -- > > > I'm not sure who you talked with? but it really it that simple. > > Vijay. The V.P. of Engineering at SGI who negotiated the > release of the code. I will quote one of his statements, > made to me in email: > > ] Can't you just relicense FreeBSD [under the GPL]? > > > The reason the GPL was chosen for XFS. > > It's the license Linux is using, and since > > the port is being done for Linux it makes sense. > > One would think a dual license. Alternately, one would think > they would use the LGPL, which would let people link it into > their kernels, as long as they gave source (which BSD does) > or otherwise permitted relinking. > > In other words, the GPL is not really an optimal license, if > they wanted wide use AND specific Linux license compatability. > I concluded from their choice that they were not going for > wide use, but instead wanted the marketing benefit of being > associated with Linux (lots of press, etc.). > > > SGI is also doing work with the XFree code, the work > > is being released under the X license (which is also > > an anti GPL license). > > The BSD and MIT licenses predate the GPL, so careful with the > word "anti" there... Well yes... but my point was that it is a more open license and the XFree projects has stated they want to keep it that way. > > > > SGI is basically matching license for licensee to > > whatever project they are contributing to. > > This from the lawyer that is doing all the open source work. > > Rather than the use to which the software is put; that's a bit > naieve, then, again. > > > I have stated this in the past but I will bring it up again. > > If sufficient momentum can be generated toward an fbsd port > > of XFS, it may be possible to go to the lawyers and have a another > > license drawn up. > > If we had it in writing that the code would be released under > a license usable by the BSD kernel, preferrably "matching license > for license", as you state, then we would commit to do the work. > > The problem we have is that the code under the current license > is useless to us, and unless we can be ensured that the code we > write to glue it in won't end up also being useless to us, there > is really no reason to commit the effort. > > > But unless the bsd community can show they are serious about > > XFS being ported it would be a waste of time to ask for > > something that SGI has very little business interesting in doing. > > So if we were to do a port, then SGI would have a business interest, > and would relicense the code? Can we have that in writing? > > > Note Darwin might be a big win in terms of making a business case > > for another platform. > > Darwin support would be automatic, with a FreeBSD port. Darwin > can use FreeBSD FS code, unmodified. Ohh? I got the impression the vm system is quite different. vfs and vnode may map quite effortlessly but that's not the part I'm concerned about. 95% of the work for linux port has been in the IO path. > > > > Let get to the point were XFS is in such demand on fbsd > > we can get a petition going if necessary to have the license > > updated. > > Demand is very different; it is an aspect of marketing. How > much demand do you want, and where do you want it directed? I > believe that it would be a trivial exercise to generate as much > demand as you require. I need something to say "hey look" people really want to use this. The half a dozen or so emails I've gotten requesting isn't enough to present to the lawyers say people really really want this. I can't promise anything, but I will send a note to the lawyer and see what kind of suggestion SGI would be open to. Would the LGPL satisfy things? This one might be the easiest to propose since it is close to the GPL (something they already understand), or provide an example of a license I can present. > This won't be an easy task, since the general attitude I will probably encounter... why should we care, we're doing linux not bsd. But I will try. > > > > BTW if anybody is interested a few of us have started looking > > at actually doing the port. Not much has been done at this > > point... basically battling through header file cleanup. > > If you have your head wrapped around it already, file system > code is really very trivial, particularly if you have code that > already works in one environment, and are merely porting it. > > I'll tell you what: give me a pointer to the code without the > Linux modifications, so that I won't inadvertantly include code > that is derived from GPL'ed code, and I will create a FreeBSD > port of the code, with all code additions, which will compile > and link successfully in a FreeBSD kernel, in a matter of a few > days. I will additionally require an image of an XFS FS on a > floppy disk, which I can use for compatability testing. There > should be one file with an example of each thing the FS is > capable of representing, including a directory, a directory > with a subdirectory, a file, and a directory with two files; > the files should be short, but if immediate files exist, one > should be long enough to trigger indirection. It would be most > useful if the image were zero'ed before it was created, so I am > able to distinguish XFS written data from "blank floppy" contents > (and to aid compression of the image). Hmm XFS can't run on a floppy; it's to small. Adrian Chad is working on the user land stuff now. once mkfs is running XFS can be written to a file and by use of proto file the image can be pre populated. > > I will provide my code for FTP, which will be licensed to > explicitly prohibit all but developement use, with a license > which will transform itself to the three clause Berkeley > license, if the XFS code which it's designed to work with > is also released under a Berkeley-style license, and a release > from patent claims in the covered code. > > In other words, the code I provide will be useless to everyone > but FS researchers, unless the SGI license on the XFS components > it must be linked with change to permit BSD to use the code as a > boot FS, and further, permit commercial use by not hiding submerged > patent infringement lawsuits which will be sprung on the unwary, > as soon as someone with deep pockets uses the code. > > Call me distrustful, but I am fully capable of delivering in a > very short time frame, so I'm pretty much the only game. > > > Ohh one other comment: > > The only time SGI may ask for a copy write reassignment is if > > the contributed code affects the filesystem compatibility > > between irix and linux. This would have to be a major > > contribution before something like this would be an issue, and > > some negotiation will most certainly be involved. > > You're damn straight there will be: SGI will be begging the > author to assign rights to a derivative work of SGI's own > code. If that author is philosophically adamant about the > GPL, the assignment of rights will never happen, unless the > author also lacks personal integrity, and SGI is willing to > buy them out of their philosophical stubborness, or pay > their own engineers to recreate the code. > > > Up to to this point all bug fixes have been linux related only > > so it really isn't an issue. > > I maintain it probably never will be. Ask Vijay for my > arguments in this regard; they boil down to the level of > effort and complexity involved in FS hacking. It takes a > professional, someone with academic rigor, to do useful work. > > Consider that the only minds capable of adding Soft Updates > technology to XFS, without a huge capital expenditure, are > existant _only_ in the BSD community. > > > This isn't SGI trying to be an ass... rather SGI trying to > > provide the most compatible FS it can within the constrains > > of many legal issues. > > A library style license of the Mozilla bent would have been > able to accomplish this rather easily, without losing SGI > rights to (putative) improvements, and without limiting the > compatability of the license to nothing but Linux. Linux > could archive it and treat it as a statically linked library > used by the kernel or a kernel module. > > The effect on BSD would have been to require it to do what > it does already, and for systems vendors to provide an "ld -r"'ed > kernel and XFS source code. A pain in the ass, but livable > for most commercial users and embedded systems vendors. > > I can't believe SGI's lawyers didn't know precisely what they > were giving away, and what they weren't. This Open Source thing is need to the closed world... they are struggling to understand how to best protect themselves yet work with the community. > > > -- > > So, are you going to point me at the pure (convertable to > another license, since it contains only SGI contributions) > SGI XFS code, and an image of a sample FS that I can write > to a floppy for testing purposes? I'll try to generate a tree from GPL release day 1. March 2000 Otherwise simply look at the CVS tree for the tag GPL-ENCUMBRANCE it was put on all the XFS code. > > > Meanwhile, I think the FreeBSD community should continue to > pursue their own JFS, under a useful license that could then > trigger commercial support for the programming required... Granted; But given the number of people SGI has doing the initial XFS work and the 3 years it took them ust to get the FS off the ground. I don't think we'll have anything real soon. > That's how the BSD community gets professional programmers > to do complex and unpleasent tasks, while other communities > never get the unpleasent tasks (e.g. Soft Updates [Whistle/IBM], > fully unified VM and buffer cache [Oracle], etc.) done at all, > after all. Marketing is a poor coin for getting long term > work done; it's too ephemeral for a long term investment to > be worthwhile. > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A843249.D93D5952>