Date: Fri, 9 Feb 2001 08:56:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cattelan@thebarn.com (Russell Cattelan) Cc: freebsd-chat@FreeBSD.ORG, jar@integratus.com (Jack Rusher), tlambert@primenet.com (Terry Lambert), sam@errno.com (Sam Leffler), zzhang@cs.binghamton.edu (Zhiui Zhang), freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system Message-ID: <200102090856.BAA08304@usr08.primenet.com> In-Reply-To: <3A8396B9.CA8C09E4@thebarn.com> from "Russell Cattelan" at Feb 09, 2001 01:05:29 AM
next in thread | previous in thread | raw e-mail | index | archive | help
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... > 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. > The license shouldn't be that big of an issue. It shouldn't, but it is. I would have been ecstatic to use XFS in the Whistle InterJet, as a means of getting rid of the need for a UPS; as a technology for doing exactly that, it's superior to Soft Updates (Soft Updates has other valuable attributes, but that was the one we were interested in obtaining). The is not a chance in hell of IBM shipping a product based on code without a license grant in perpetuity already locked in a vault. > Lots of fbsd uses GPL'ed code... hmm gcc for example. FreeBSD _utilizes_ this code, it does not _use_ it. The gcc code can be diked out of a FreeBSD system, without crippling the utility of the system. In an embeded product, that code _is_ diked out. There is no gcc code linked into the FreeBSD kernel. > 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. > 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). 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. -- 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? 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... 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102090856.BAA08304>