From dev-return-11156-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Feb 24 18:22:34 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 66084 invoked from network); 24 Feb 2004 18:22:34 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 24 Feb 2004 18:22:34 -0000 Received: (qmail 85882 invoked by uid 500); 24 Feb 2004 18:22:26 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 85625 invoked by uid 500); 24 Feb 2004 18:22:24 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 85612 invoked from network); 24 Feb 2004 18:22:24 -0000 Message-ID: <403B9639.6090403@attglobal.net> Date: Tue, 24 Feb 2004 13:21:45 -0500 From: Jeff Trawick User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: gdbm licence issue References: <200402232125.i1NLPib19292@devsys.jaguNET.com> <1077573218.1612.7.camel@localhost.localdomain> <20040223170433.C15000@lyra.org> <2147483647.1077567033@localhost> <20040224103019.GA13785@manyfish.co.uk> <2147483647.1077612413@localhost> <403B8BD7.6050603@attglobal.net> <2147483647.1077615766@localhost> In-Reply-To: <2147483647.1077615766@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Justin Erenkrantz wrote: > --On Tuesday, February 24, 2004 12:37 PM -0500 Jeff Trawick > wrote: > >> Perhaps the default build should disable any features which could make >> the >> licensing of the generated "product" different than the licensing of the >> source code, and if the user is happy otherwise then they can enable such >> features? >> >> What I have done thus far where this has been a potential issue is to add >> >> --without-gdbm --without-berkeley-db >> >> to the configure invocation. > > > That'd be fair, I think. BTW, what's the issue with BDB's license? -- > justin Actually there were other reasons that Berkeley db support was disabled, so that was a bad example :( IANAL, but I'm pretty sure that there are no requirements placed on you by merely using the Berkeley db libraries already installed on the end-user's system. Bundling Berkeley db support in a product would be a completely different issue however, and would require either licensing fees to be paid or source code of the product to be published. But none of this issue with Berkeley db seems to be apr's problem.