Date: Thu, 13 Dec 2001 01:33:10 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: hiten@uk.FreeBSD.org Cc: chat@FreeBSD.org, grog@FreeBSD.org, phk@FreeBSD.org Subject: Re: IBM suing (was: RMS Suing was [SUGGESTION] - JFS for FreeBSD) Message-ID: <3C1875D6.5DE4F996@mindspring.com> References: <3C186381.6AB07090@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hiten Pandya wrote: > IBM has release JFS code under the 'General Public License'. What > we have to do is ask this question internally to IBM, which Greg > might do that for us, if possible; and then we see what the JFS > Team from IBM's views are about this. This whole legal discussion stemmed from whether or not you can have a root FS that was JFS, and still comply with the GPL. There are several ways to do this with a JFS port; the last five skate by on technicalities, while the first simply disregards the license entirely: 1) Statically link JFS into a distribution kernel, and then distribute it, in violation of the GPL. o IBM would hate this; they hate people violating licenses. 2) Statically link a kernel as part of the installation process, so that you are technically not distributing a kernel that has GPL'ed code linked into it. o IBM would hate this, and RMS has sued over this before, and won a settlement (no binding case law in the U.S., yet). This is legally risky, if Greg is right, and the intent was to prevent commercial use of the code, since you defeat their intent. Further, case law in the U.S. favors the plaintiff, due to historical interface copyright issues (RMS argued a crypto library was GPL'ed for being written to interface only to GPL'ed code, since there were no other instances, and thus this was an attempt to subvert the intent of the licensor). 3) Provide the capability to build a kernel with a JFS, but provide no means of installing a FreeBSD system configured this way automatically. o This holds the least risk; it is also the least generally useful implementation, since people would need to build their own release CDROMs locally to be able to successfully obtain native JFS installs; you will never be able to ship a product with such a FreeBSD preinstalled on it. This is potentially legally risky if the company is ever sold, most particularly if its assets are sold seperately (the company is a legal entity, so a bulk sale might be OK), since you can not legally transfer ownership of the binaries, since it is impossible to compy with the GPL on the JFS code. FWIW: IBM made Whistle rip SQUID out _before_ the sale of Whistle to IBM was made final; however Whistle was privately held at the time. 4) Build boot code that can at least read JFS, and load the real JFS as a kernel module. o Since you have to deal with all the lookup and log version selection issues, this is more than half way to a reimplementation without the GPL. This is legally risky, if Greg is right, and the intent was to prevent commercial use of the code, since you defeat their intent. 5) Use an alternate boot partition of a different FS type (e.g. FAT32 or FFS), and load the JFS module from there. o This is harder than option #3, since it requires minimally that union mounts work, since mounts over mount points before the kernel is booted can't work, and therefore for your / to be JFS, it will have to be mounted over top of the boot /, which would be non-JFS. This is legally risky, if Greg is right, and the intent was to prevent commercial use of the code, since you defeat their intent. 6) Write a JFS compatible FS, not using the IBM JFS code. o It would be difficult to prove "clean room" techniques, and court cases in the U.S. recently have decided in increasingly high barriers to clean-room coding. This is legally risky, if Greg is right, and the intent was to prevent commercial use of the code, since you defeat their intent. > If they think that porting JFS to FreeBSD is a waste of time and > energy, because of the licensing issues, than we can take an > alternate approach to 'crash recovery' problems and journalling, As I said before: feel free to write the code. Just don't expect people who, philosophically, want the FreeBSD code to be usable (and used!) as a source of reference implementations to participate in this process. -- Terry 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?3C1875D6.5DE4F996>