public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <rpj@ise.canberra.edu.au>
To: vkt@india.hp.com
Cc: "Turner, Jay" <Jay.Turner@sabre-holdings.com>,
	pthreads-win32@sources.redhat.com, Hugues.Talbot@csiro.au
Subject: Re: LGPL and a proprietary application
Date: Sat, 24 May 2003 06:36:00 -0000	[thread overview]
Message-ID: <3ECF11CA.3000208@ise.canberra.edu.au> (raw)
In-Reply-To: <3ECD0C45.10509@india.hp.com>

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
>>
>>
>>  
>>
>

  reply	other threads:[~2003-05-24  6:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-22 17:27 Turner, Jay
2003-05-22 17:40 ` Vinaya Kumar T
2003-05-24  6:36   ` Ross Johnson [this message]
2003-05-23  4:18 Vikas Gandhi
2003-05-23  5:13 ` Hugues Talbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ECF11CA.3000208@ise.canberra.edu.au \
    --to=rpj@ise.canberra.edu.au \
    --cc=Hugues.Talbot@csiro.au \
    --cc=Jay.Turner@sabre-holdings.com \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=vkt@india.hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).