Date: Sun, 17 Mar 2002 18:11:00 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: hiten@uk.FreeBSD.org Cc: Hans Reiser <reiser@namesys.com>, Chris Mason <mason@suse.com>, Josh MacDonald <jmacd@CS.Berkeley.EDU>, Parity Error <bootup@mail.ru>, freebsd-fs@FreeBSD.ORG, reiserfs-dev@namesys.com Subject: Re: [reiserfs-dev] Re: metadata update durability ordering/soft updates Message-ID: <3C954CB4.DA67635@mindspring.com> References: <20020317225759.82774.qmail@web21109.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hiten Pandya wrote: [ ... ] Any argument you make against ReiserFS in this regard also applies to an XFS port for FreeBSD, or your own efforts to get a JFS port project for FreeBSD going. NOTE: If you don't want to read a licensing discussion, stop reading this message NOW. Look at the facts, from a licensing perspective: 1) There is a GPL'ed ReiserFS, which you can port, and, your code being a derivative work of GPL'ed code, will also be GPL'ed. 2) You can negotiate a non-GPL'ed license for the code, but given that the BSD license is less restrictive, there are likely to be source redistribution restrictions in the license, menaing that there will be source redistribution restrictions on the derivative work of the code, should you port it yourself. 3) You can reverse engineer the code from scratch; this is not an impossible task, given that there are published interfaces, in the form of the GPL'ed code, which could be used as reference material, so long as you wrote your own actual code. What are the ramifications? First, it's possible, contrary to your claim, to port the GPL'ed version, but you could not distribute a bootable FreeBSD CDROM with the FS compiled into it or the boot loader by default, since it would violate the "no additional restrictions" clause of the GPL, and since even if you were talking about the two clause UCB License, you would not be able to change the license on the original code without losing your rights to it or works derived from it (the only rights you have are as a result of that license), and therefore, you are also in conflict with the GPL, which requires that code linked with GPL'ed code be GPL'ed, not UCB licensed, regardless of the number of clauses. You could distribute the code seperately and let people build their own binaries. This is much less useful to most people, since it means that any benefits gained from use of the FS are lost on the partition from which the OS is booted; it also means that there is no support available for a binary version. Legally, this approach is also on shakey ground, since the intent counts, and the intent in this case would be to get around the license terms. The most blatant thing would be to build the local binary for the user including both sets of code during the installation process, and then claim that you weren't really distributing a binary (there is case law that this constitutes a violation of the license, when you subvert it this way). Even putting the onus on the user is still questionable, as it is a matter of degree: the intent is still the same, to violate the spirit of the contract as it was offered in the license terms. You could license the code under another license negotiated seperately. This works because they've gone out of their way to ensure an assignment of rights for any contributed code, specifically to allow licenses under other terms. Unless this was a full "buy out", though, because of the effort involved, and because the situation was intentionally engineered to provide for a revenue model, it's unlikely that the resulting code would be redistributable in source form, and potentially not even in binary form, without a per unit royalty, or some other provision that prevents the code licensed to you from cannibalizing the potential market for licensing the same code under similar or other terms to another party (the intent, remember, was to establish a revenue model). Thus if you were to derive a product from some OS "Z", and add a relicensed version of ReiserFS to the product, then you would be fine, but if your intent was to make a source distribution of a FreeBSD bootable CDROM with ReiserFS support built into the binary, you would be out of luck, unless you were to give them sufficient cache to buy rights for source redistribution under other license terms. The final option of reverse engineering the code is always available, but it's prohibitively expensive. The availability of the source code under the GPL artificially deflates the barrier to entry for non-business users wanting to have the FS on their system, so the only incentive for this is for business use of the file system in a product. So long as the licensing terms are such that the cost of licensing the code under other terms is significantly lower than that of doing the reengineering, then there's an active economic disincentive for reverse engineering the code to get out from under the GPL, and, even if that weren't the cae, there's an ROI argument to be made that, even if you were to reverse engineer the code, once done it represents a substantial enough investment that you are not going to give the code away for free. A per unit royalty clause on a relicense *might* be enough to break the camel's back in this regard, but the people licensing the code are unlikely to make that mistake. These same arguments, minus the relicensing, apply to all GPL'ed code whose operation would place it in the boot path for an OS under a non-GPL license. The relicensing is only an option in the ReiserFS case because of the extraordinary measures which were taken to ensure an assignment of rights. Not all GPL'ed projects insist, or get their legal ducks in a row for, an assignment of rights for contributed code (in fact most of them do not). ReiserFS, Kaffe, and the FSF managed projects are exceptions to this. I rather expect that money would pull a non-GPL JFS license out of IBM. So who would reengineer to get out from under the GPL? People with an interest in targetting the GPL'ed product's revenue model, and cutting it off at the feet. For example, Microsoft reengineered the browser, and then gave it away for free. They also announced a new FS for Windows 9x two years before they shipped the first Alpha version of it, and FUD'ded to death a project in that same ecological niche that was ready to go to market (a product by Artisoft, which included a port of the Heidemann stacking framework, UFS, and FFS from FreeBSD to Windows). The only other people who would do it are egomaniacs, students, and religious zealots. Students are a special cae, because they generally have short enough attention spans (measured in units like "One Master's Thesis") that complexity of a system above a certain level is a barrier to entry. Egomaniacs are in it for the ego gratification, and as a class like their gratification to be immediate, which makes complexity a barrier for them, as well. This leaves the religious nuts, like the people rewriting the ipfilter code for OpenBSD to get out from under the license there (don't get me wrong: I appreciate their efforts, but they are no less the nuts for my appreciation). I believe this is why you do not see hordes of people rushing to port ReiserFS, XFS, JFS, etc., etc., to FreeBSD: with the GPL restriction, any code that lives in the boot path of a non-GPL'ed OS will always be an "also ran" which must be added by the end user, rather than the vendor, and will never replace native components without the restriction of the user having to do additional work. Basically, GPL'ed code is useful for a technology preview and as a demonstration, but rather useless as a reference implementation (unlike the UCB licensed TCP/IP implementation, which is found, among other places, in nearly every router on the Internet and is, today, part of Windows). You might even claim that the users who would do the work to do the same replacement also fall into the category of "religious zealots", in fact... not to single out your JFS project in particular, of course... ;^). -- Terry 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?3C954CB4.DA67635>