From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8260 invoked by alias); 24 May 2003 06:36:19 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 8227 invoked from network); 24 May 2003 06:36:18 -0000 Received: from unknown (HELO real.ise.canberra.edu.au) (137.92.140.34) by sources.redhat.com with SMTP; 24 May 2003 06:36:18 -0000 Received: from ise.canberra.edu.au (special.ise.canberra.edu.au [137.92.140.39]) by real.ise.canberra.edu.au (8.11.6/8.11.6) with ESMTP id h4O6Vir31495; Sat, 24 May 2003 16:31:44 +1000 Message-ID: <3ECF11CA.3000208@ise.canberra.edu.au> Date: Sat, 24 May 2003 06:36:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vkt@india.hp.com CC: "Turner, Jay" , pthreads-win32@sources.redhat.com, Hugues.Talbot@csiro.au Subject: Re: LGPL and a proprietary application References: <0A4834C63AA59242BD8A4C9CF8494E29FF46A7@sghdqms02.global.ad.sabre.com> <3ECD0C45.10509@india.hp.com> In-Reply-To: <3ECD0C45.10509@india.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00055.txt.bz2 Hi, Just to reinforce what Vinaya and Hugues have already said and hopefully not muddy the water too much ... First of all, see the pthreads-win32-specific file named 'COPYING' in the distribution, and specifically the last section. It states the objectives of the project, which includes use with commercial and/or proprietry code, and the reasons for choosing the LGPL over the GPL. It may be a gross simplification (see the disclaimer at the end of this message) but, if you can answer the following question and also act on it when you distribute your application, then I would say you're complying with the essentials of the LGPL. The question is ... What does your customer need in order to continue to use your application if they want to use a version of pthreads-win32 that is different, perhaps a later version, from the one that you provide, even after you've stopped supporting your application, or have gone out of business? As Vinaya has pointed out, the simplest case is if your application is dynamically linked with the mailine pthreads-win32 version. Then you only need to tell your customers where they can get the mainline version and display the pthreads-win32 copyright notice along with yours. The worst case is if your application is statically linked, possibly with modifications to pthreads-win32. Then you need to provide everything that your customer may need in order to build pthreads-win32 from source code, including any modifications that aren't adopted by the mainline pthreads-win32, and then link it with your application. At the least they need your .o file/s, and your modifications have to be released under the LGPL. Re the inclusion of the header files, there are macros in the headers that will generate code that becomes part of your proprietry object files. I don't think anyone would suggest that this renders your code a derivative work according to the LGPL provided it's intended to allow your code work with the pthreads-win32 library. I think section 5 is where the LGPL starts to get confusing. For example ... "However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables." Where this says "the executable is therefore covered by this License", this doesn't mean that your code must be given away as LGPLed code. Section 6 is just a more complete statement of the question posed for you above. If you make modifications to pthreads-win32 itself then you must make them redistibutable under the LGPL. The easiest way to do that is to offer them back to the pthreads-win32 project maintainers, where the chances are they will be adopted. You must at least give your customers access to the modifications if they want it. The LGPL allows you to charge a fee to cover the costs of providing that access. Hope that helps. Disclaimer: the LGPL is the sole license document and no other opinion or interpretation, including those contained here, will override the terms set out in the LGPL. Regards. Ross Vinaya Kumar T wrote: > Hello Jay, > > ru linking to this LGPL library statically or dynamically...?? > if statically linked ,then u should make only that of the ur src code > open ,so that , changes in LGPL can > be done effectively. > On other hand ,if it dynamically linked,then u don't have to worry > about ur src code to be made open. > > hope this helps > vinaya > > > Turner, Jay wrote: > >> In reading the LGPL for pthreads-win32 I find I am confused. My >> application is company proprietary and one reading says that an >> application that "uses the library" does not itself fall under the >> LGPL. Another reading says that it does (mainly because it uses >> pthread.h and semaphore.h). >> >> Can I link to pthreads-win32 in my application without the license >> requiring that I provide my source or object code to my customers? >> >> Is there anything that my legal department would accept that would >> confirm this? >> >> Thanks, Jay >> >> >> >> >