From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 22:15:28 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 0A73716A4CE for ; Tue, 19 Apr 2005 22:15:28 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BABA443D2D for ; Tue, 19 Apr 2005 22:15:27 +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 B22467A403; Tue, 19 Apr 2005 15:15:27 -0700 (PDT) Message-ID: <426582FF.9080100@elischer.org> Date: Tue, 19 Apr 2005 15:15:27 -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: Peter Jeremy References: <20050419200039.GA12673@cirb503493.alcatel.com.au> In-Reply-To: <20050419200039.GA12673@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:15:28 -0000 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" >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. > > >