From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 22:19:30 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7522816A4CE for ; Tue, 19 Apr 2005 22:19:30 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3959C43D1F for ; Tue, 19 Apr 2005 22:19:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 325237A425; Tue, 19 Apr 2005 15:19:30 -0700 (PDT) Message-ID: <426583F2.7040104@elischer.org> Date: Tue, 19 Apr 2005 15:19:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Julian Elischer References: <20050419200039.GA12673@cirb503493.alcatel.com.au> <426582FF.9080100@elischer.org> In-Reply-To: <426582FF.9080100@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Peter Jeremy cc: dragonfly dragonfly cc: freebsd-arch@freebsd.org Subject: Re: How about porting LVS to FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 22:19:30 -0000 Julian Elischer wrote: > > > Peter Jeremy wrote: > >> On Tue, 2005-Apr-19 09:08:29 +0800, dragonfly dragonfly wrote: >> >> >>> LVS(http://www.linuxvirtualserver.org/) is a widely used server >>> cluster schedule system,which is be included in Linux official >>> kernel 2.4 and 2.6 release. >>> Recently i ported LVS/ipvs to FreeBSD,and released 0.1.0 version >>> (http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm). >>> >> >> >> In its current form, this code cannot be technically or legally >> incorporated into the FreeBSD base. >> >> > > If you look at the website, you'll notice that the person you are > talking to is one of the > original authors and can therefore assign a a BSD/dual copyright. SO > the legal > aspects are really just a case of "getting around to doingthe > wordsmithing" sorry ignore this email > >> Looking at the legal aspects: LVS is covered by the GPL which is >> incompatible with the BSD license. This is a significant impediment >> to LVS being included in the base system. As a minimum, all GPL code >> must be clearly identified and it must be possible to remove the code >> from the kernel compilation. >> >> Whilst you have segregated some of the code into a kernel module >> (ipvs), there are still 14 files added or changed in the base kernel. >> I also note that there are no sources to ipvsadm - which is supplied >> as a Linux executable. >> >> Of the 14 files affecting the base kernel: >> - 1 includes a copyright statement with no rights statement. This code >> cannot be legally used since the authors have implicitly retained all >> rights to the code and it therefore cannot be used by anyone else. >> - 4 files have no copyright statement, though in at least once case, >> the comments imply that a GPL copyright statement has been deleted. >> Again, this code cannot be legally used. >> - The remaining 9 files are replacements for existing FreeBSD files and >> include existing copyrights. There is no obvious legal impediment to >> those files, though studying the changes would be necessary to >> confirm that. >> >> As to the technical issues: The "patch" includes 9 existing files >> that replace existing files. This is a totally impractical way of >> supplying code changes. The CVS ID's in those files imply that they >> come from RELENG_5, possibly 5.3-RELEASE. FreeBSD rules require that >> all new features must be applied to HEAD (currently 6.x) first. This >> ensures that: >> 1) The new features are not lost as FreeBSD moves forward. >> 2) New, potentially buggy, code is tested in the "development" branch >> before being added to a "production" branch. >> The changes to the existing code must be supplied as context or >> unified diffs to ensure that other changes to the code are not lost. >> Much of the new code is not style(9) compliant which would also prevent >> its inclusion into the base system. >> >> >> >