changing pthreads-win32 license

changing pthreads-win32 license

[Alexander Terekhov]

Ross Johnson wrote:
[...]
> But, before guessing, I have to ask you what your issue is 
> exactly with the LGPL. 

My issue with [L]GPL is that FSF "advocates" totally idiotic
("SCOish" so to speak) notion of "derivative work", to begin 
with. This is just one example:

http://www.gnu.org/licenses/gpl-faq.html#OOPLang

"Subclassing is creating a derivative work. Therefore, the 
 terms of the GPL affect the whole program where you create 
 a subclass of a GPL'ed class. "

Of course, this doesn't make sense and is totally wrong.  The 
real problem with [L]GPL is that both try to go "way too far" 
with the reciprocity provision (quote taken from LGPL, emphasis
added): "the intent is to exercise the right to control the 
distribution of derivative or COLLECTIVE works based on the 
Library". This is what people call "viral effect". Even folks
like creativecommons.org DON'T TRY TO DO THAT.

http://creativecommons.org/licenses/sa/1.0/legalcode

The problems with [L]GPL are nicely illustrated here:

http://www.mail-archive.com/license-discuss@opensource.org/msg05842.html
http://www.mail-archive.com/license-discuss@opensource.org/msg05865.html
http://www.mail-archive.com/license-discuss@opensource.org/msg05867.html
http://www.mail-archive.com/license-discuss@opensource.org/msg05882.html
http://www.mail-archive.com/license-discuss@opensource.org/msg05888.html

and also here:

http://www.catb.org/~esr/writings/taoup/html/ch16s07.html

Now, as for *L*GPL silliness, just read this:

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html

> And especially which license you'd prefer to use. 

The CPL, of course.

http://ntxshape.sourceforge.net/opensource.html

I like this:

"The Lesser GPL used to be called the Library GPL. For 
 historical reasons this license still refers to the software 
 application as "the Library" which can be confusing for 
 licensees. Also, a licensee is allowed to convert the Lesser 
 GPL to a full GPL, after which their enhancements could not 
 be incorporated back into our version of the software. So, 
 for us, LGPL is out. "

Please read this:

http://www-106.ibm.com/developerworks/opensource/library/os-cplfaq.html

> There have been a few expressions of interest in changing to 
> another license, such as the BSD license. 

Fine with me. Just take the CPL and remove the reciprocity 
provision.

http://www.mail-archive.com/license-discuss@opensource.org/msg06420.html

"Reciprocal and non-reciprocal open source licenses ought to 
 be the same -- except with respect to provisions dealing with 
 reciprocity."

Well, I'd have no real problems with the AFL/OSL either, but 
to me, the CPL is better. I like the language/style, to begin 
with. ;-)

> In order to change, I think a concensus of [at least] the major 
> project contributors would be required. 

I think that all contributors will have to agree to license 
their contributions under the new terms in order to change the 
license.

> It's certainly not up to me.

I understand. That's why I'm replying to the list.

regards,
alexander. 

Re: changing pthreads-win32 license

[Ross Johnson]

Alexander Terekhov wrote:

>Ross Johnson wrote:
>[...]
>  
>
>>But, before guessing, I have to ask you what your issue is 
>>exactly with the LGPL. 
>>    
>>
>
>My issue with [L]GPL is that FSF "advocates" totally idiotic
>("SCOish" so to speak) notion of "derivative work", to begin 
>with. This is just one example:
>
>http://www.gnu.org/licenses/gpl-faq.html#OOPLang
>  
>
>"Subclassing is creating a derivative work. Therefore, the 
> terms of the GPL affect the whole program where you create 
> a subclass of a GPL'ed class. "
>
>Of course, this doesn't make sense and is totally wrong.  The 
>real problem with [L]GPL is that both try to go "way too far" 
>with the reciprocity provision (quote taken from LGPL, emphasis
>added): "the intent is to exercise the right to control the 
>distribution of derivative or COLLECTIVE works based on the 
>Library". This is what people call "viral effect". Even folks
>like creativecommons.org DON'T TRY TO DO THAT.
>
>http://creativecommons.org/licenses/sa/1.0/legalcode
>
>  
>
Taking the FAQ quote above, and the your reference to

>Now, as for *L*GPL silliness, just read this:
>
>http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html
>
which says

<quote>

*Q: How is that different from the GNU {Lesser,Library} GPL?*
A: The LGPL requires that users be able to replace the LGPL code with a 
modified version; this is trivial if the library in question is a C 
shared library. But there's no way to make that work with C++, where 
much of the library consists of inline functions and templates, which 
are expanded inside the code that uses the library. So to allow people 
to replace the library code, someone using the library would have to 
distribute their own source, rendering the LGPL equivalent to the GPL.

</quote>

I agree it would make using the LGPL for a C++ library pretty hairy. But
pthreads-win32 is C and I don't believe (at this moment) that it has this
problem. Pthreads-win32 does contain bits of source code that must be
included in application code to be useful, e.g. the pthread_cleanup_*()
macros in pthread.h. These are the only potential cause for concern that
I see, but apart from being only small sections, these could also be
regarded as part of the API prototype definitions that any LGPL'ed work
must provide, and allow to be copied, to be usable.

The CCPL (not CPL) license is dealing with, essentially, end-product
type material (analogous to object code) - it doesn't appear to deal with
the distribution of the means of re-creating that material (analogous
to source code). It doesn't attempt to, or necessarily need to, ensure
that the recipient of a work is able to upgrade or enhance any of the
CCPL'ed components in the same way that software users might
need to.

>>And especially which license you'd prefer to use. 
>>    
>>
>
>The CPL, of course.
>
>http://ntxshape.sourceforge.net/opensource.html
>  
>
I've been looking through version 1.0 of the CPL license at

http://www.opensource.org/licenses/cpl.php

and it includes provisions that require giving users access to the source
code when CPL'ed programs are distributed in object form only, i.e.:

*3. REQUIREMENTS*

A Contributor may choose to distribute the Program in object code form 
under its own license agreement, provided that:

    a) it complies with the terms and conditions of this Agreement; and

    b) its license agreement:

    ...

    iv) states that source code for the Program is available from such
    Contributor, and informs licensees how to obtain it in a reasonable
    manner on or through a medium customarily used for software exchange.

Here 'Program' means the collection of contributed code under the CPL.

This looks a little like the GPL, except that section 1)b)ii) of the CPL
allows the exclusion of code that:

(i) are separate modules of software distributed in conjunction with the 
Program under their own license agreement, and (ii) are not derivative 
works of the Program.

This is similar to the LGPL, but in the CPL there's no definition of
'derivative work'. Is there no need to define 'derivative work'?

But how does the CPL avoid the same problem the LGPL has with
distributing CPL'ed C++ libraries for use in closed applications, like
the specially GPL'ed libstdc++ example above?

>I like this:
>
>"The Lesser GPL used to be called the Library GPL. For 
> historical reasons this license still refers to the software 
> application as "the Library" which can be confusing for 
> licensees. Also, a licensee is allowed to convert the Lesser 
> GPL to a full GPL, after which their enhancements could not 
> be incorporated back into our version of the software. So, 
> for us, LGPL is out. "
>  
>
This is a bit spooky, because pthreads-win32 was deliberately intended
to be useful to commercial as well as 'free' application developers, in
order to encourage use of Open Standards. This is clear from the
project web page, and it hasn't changed since it started.

However, this does not convert any existing LGPL'ed copies of the
library to GPL, it just means there would be an irreconcileable fork
created. It also doesn't prevent a contributor providing identical code
to both sides. Or does it?

Here's the actual section of the LGPL on this issue:

"3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library.  To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License.  (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.)  Do not make any other change in
these notices."

"Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy."
                                                                                              
"This option is useful when you wish to copy part of the code of
the Library into a program that is not a library."


This last para explains the purpose of the section but doesn't limit 
it's use,
and I suppose it was necessary to add this provision for the LGPL to
work with the rest of the FSF's GPL'ed project suite.

I think it would be very uncool for anyone to add a minor addition to
an LGPL'ed project and then begin distributing that copy under the GPL
in direct competition with the original. But it could happen.

Regards.
Ross

Re: changing pthreads-win32 license

[Alexander Terekhov]

[... users be able to replace the LGPL ...]

> But pthreads-win32 is C and I don't believe (at this moment) 
> that it has this problem.

My usual answer to that is this:

A)

#include <stdio.h>

void f() { printf("f-function\n"); }

#define f() printf("f-macro\n")

int main() {
  void (*g)() = f;
  f();
  g();
}

B) http://tinyurl.com/sz2e

C) IOW, according to FSF, you shall never use things like 
macros, inlines, and whatnot that can render the Lesser General 
Public Virus equivalent to the 'full' General Public Virus. 
Even in C.  While I agree that the ability to 'seamlessly' 
upgrade the libraries represent some value to a customer, this 
is an issue between the vendor shipping the product using the
library and its customers. Of course, it's always better not to
break binary compatibility but this is not always possible, to
begin with.

> This is similar to the LGPL, but in the CPL there's no 
> definition of 'derivative work'. Is there no need to define 
> 'derivative work'?

http://www.rosenlaw.com/html/GL18.pdf

> But how does the CPL avoid the same problem the LGPL has 
> with distributing CPL'ed C++ libraries for use in closed 
> applications, like the specially GPL'ed libstdc++ example 
> above?

http://www.mail-archive.com/license-discuss@opensource.org/msg05882.html
http://finance.messages.yahoo.com/bbs?.mm=FN&action=m&board=1600684464&tid=cald&sid=1600684464&mid=56003
http://finance.messages.yahoo.com/bbs?.mm=FN&action=m&board=1600684464&tid=cald&sid=1600684464&mid=56451
http://finance.messages.yahoo.com/bbs?.mm=FN&action=m&board=1600684464&tid=cald&sid=1600684464&mid=56481
http://finance.messages.yahoo.com/bbs?.mm=FN&action=m&board=1600684464&tid=cald&sid=1600684464&mid=56495
http://digital-law-online.info/lpdi1.0/treatise27.html
http://www.theinquirer.net/?article=10574

Does this make it clear? Read also this:

http://www.softpanorama.org/Copyright/License_classification/social_roots_of_GPL.shtml

And also this:

http://www.alwayson-network.com/comments.php?id=1303_0_1_0_C

The language of the LGPL is no better.

regards,
alexander.

Please respond to rpj@callisto.canberra.edu.au 
To:     Alexander Terekhov/Germany/IBM@IBMDE
cc:     pthreads-win32@sources.redhat.com 
Subject:        Re: changing pthreads-win32 license


Alexander Terekhov wrote:

>Ross Johnson wrote:
>[...]
> 
>
>>But, before guessing, I have to ask you what your issue is 
>>exactly with the LGPL. 
>> 
>>
>
>My issue with [L]GPL is that FSF "advocates" totally idiotic
>("SCOish" so to speak) notion of "derivative work", to begin 
>with. This is just one example:
>
>http://www.gnu.org/licenses/gpl-faq.html#OOPLang
> 
>
>"Subclassing is creating a derivative work. Therefore, the 
> terms of the GPL affect the whole program where you create 
> a subclass of a GPL'ed class. "
>
>Of course, this doesn't make sense and is totally wrong.  The 
>real problem with [L]GPL is that both try to go "way too far" 
>with the reciprocity provision (quote taken from LGPL, emphasis
>added): "the intent is to exercise the right to control the 
>distribution of derivative or COLLECTIVE works based on the 
>Library". This is what people call "viral effect". Even folks
>like creativecommons.org DON'T TRY TO DO THAT.
>
>http://creativecommons.org/licenses/sa/1.0/legalcode
>
> 
>
Taking the FAQ quote above, and the your reference to

>Now, as for *L*GPL silliness, just read this:
>
>http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html
>
which says

<quote>

*Q: How is that different from the GNU {Lesser,Library} GPL?*
A: The LGPL requires that users be able to replace the LGPL code with a 
modified version; this is trivial if the library in question is a C 
shared library. But there's no way to make that work with C++, where 
much of the library consists of inline functions and templates, which 
are expanded inside the code that uses the library. So to allow people 
to replace the library code, someone using the library would have to 
distribute their own source, rendering the LGPL equivalent to the GPL.

</quote>

I agree it would make using the LGPL for a C++ library pretty hairy. But
pthreads-win32 is C and I don't believe (at this moment) that it has this
problem. Pthreads-win32 does contain bits of source code that must be
included in application code to be useful, e.g. the pthread_cleanup_*()
macros in pthread.h. These are the only potential cause for concern that
I see, but apart from being only small sections, these could also be
regarded as part of the API prototype definitions that any LGPL'ed work
must provide, and allow to be copied, to be usable.

The CCPL (not CPL) license is dealing with, essentially, end-product
type material (analogous to object code) - it doesn't appear to deal with
the distribution of the means of re-creating that material (analogous
to source code). It doesn't attempt to, or necessarily need to, ensure
that the recipient of a work is able to upgrade or enhance any of the
CCPL'ed components in the same way that software users might
need to.

>>And especially which license you'd prefer to use. 
>> 
>>
>
>The CPL, of course.
>
>http://ntxshape.sourceforge.net/opensource.html
> 
>
I've been looking through version 1.0 of the CPL license at

http://www.opensource.org/licenses/cpl.php

and it includes provisions that require giving users access to the source
code when CPL'ed programs are distributed in object form only, i.e.:

*3. REQUIREMENTS*

A Contributor may choose to distribute the Program in object code form 
under its own license agreement, provided that:

    a) it complies with the terms and conditions of this Agreement; and

    b) its license agreement:

    ...

    iv) states that source code for the Program is available from such
    Contributor, and informs licensees how to obtain it in a reasonable
    manner on or through a medium customarily used for software exchange.

Here 'Program' means the collection of contributed code under the CPL.

This looks a little like the GPL, except that section 1)b)ii) of the CPL
allows the exclusion of code that:

(i) are separate modules of software distributed in conjunction with the 
Program under their own license agreement, and (ii) are not derivative 
works of the Program.

This is similar to the LGPL, but in the CPL there's no definition of
'derivative work'. Is there no need to define 'derivative work'?

But how does the CPL avoid the same problem the LGPL has with
distributing CPL'ed C++ libraries for use in closed applications, like
the specially GPL'ed libstdc++ example above?

>I like this:
>
>"The Lesser GPL used to be called the Library GPL. For 
> historical reasons this license still refers to the software 
> application as "the Library" which can be confusing for 
> licensees. Also, a licensee is allowed to convert the Lesser 
> GPL to a full GPL, after which their enhancements could not 
> be incorporated back into our version of the software. So, 
> for us, LGPL is out. "
> 
>
This is a bit spooky, because pthreads-win32 was deliberately intended
to be useful to commercial as well as 'free' application developers, in
order to encourage use of Open Standards. This is clear from the
project web page, and it hasn't changed since it started.

However, this does not convert any existing LGPL'ed copies of the
library to GPL, it just means there would be an irreconcileable fork
created. It also doesn't prevent a contributor providing identical code
to both sides. Or does it?

Here's the actual section of the LGPL on this issue:

"3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library.  To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License.  (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.)  Do not make any other change in
these notices."

"Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy."
  
"This option is useful when you wish to copy part of the code of
the Library into a program that is not a library."


This last para explains the purpose of the section but doesn't limit 
it's use,
and I suppose it was necessary to add this provision for the LGPL to
work with the rest of the FSF's GPL'ed project suite.

I think it would be very uncool for anyone to add a minor addition to
an LGPL'ed project and then begin distributing that copy under the GPL
in direct competition with the original. But it could happen.

Regards.
Ross

Re: changing pthreads-win32 license

[Will Bryant]

> C) IOW, according to FSF, you shall never use things like 
> macros, inlines, and whatnot that can render the Lesser General 
> Public Virus equivalent to the 'full' General Public Virus. 

It specifically exempts macro definitions and the like.  Read it.

Re: changing pthreads-win32 license - Practical Comment

[James Ewing]

While working as a consultant a couple of years ago, I suggested using 
the phreads-win32 library as part of a cross-platform (*nix/Windows) 
product. We moved ahead with pthreads-win32 on Windows and POSIX 
pthreads on *nix. Unfortunately when legal reviewed the licenses, the  
"new, improved" LGPL version had been released. Legal refused to approve 
the product with the LGPL code and the WIN32 version was dropped  (as 
was my contract about 2 months later - I took major heat for the call to 
use an LGPL lib).

If the intent is to offer pthreads-win32 for commercial use, the LGPL is 
not an acceptable risk in certain commercial enterprises.

Just thought I'd add a practical comment to the licensing discussion.

Best Regards,

James Ewing

Re: changing pthreads-win32 license

[Alexander Terekhov]

> It specifically exempts macro definitions and the like.  Read it.

You mean "ten lines or less in length"? Yeah, given that the 
length of lines seem to be unrestricted. [L]GPL is totally 
brian-damaged technically and legally. Really.

regards,
alexander.



Sent by:        pthreads-win32-owner@sources.redhat.com
To:     <pthreads-win32@sources.redhat.com>
cc:      
Subject:        Re: changing pthreads-win32 license


> C) IOW, according to FSF, you shall never use things like 
> macros, inlines, and whatnot that can render the Lesser General 
> Public Virus equivalent to the 'full' General Public Virus. 

It specifically exempts macro definitions and the like.  Read it.

UNSUBCRIBE

[Geoffrey Atkinson]

UNSUBSCRIBE

Re: changing pthreads-win32 license

[Ross Johnson]

Alexander Terekhov wrote:

>>It specifically exempts macro definitions and the like.  Read it.
>>    
>>
>
>You mean "ten lines or less in length"? Yeah, given that the 
>length of lines seem to be unrestricted. [L]GPL is totally 
>brian-damaged technically and legally. Really.
>
>  
>
Personally, I'd be inclined to regard any work that included only
the unmodified LGPL'ed header files, specifically supplied for that
purpose, and dynamically linked to the unmodified main body of the
library, to be an independent and separate work as far as the LGPL
goes - static linking and assorted tricks aside for the moment.

If the LGPL really doesn't permit that, then I'd be in favour of
changing to an appropriate alternative license. But for the moment
I'm trying to convince myself that the CPL (Alexander's preferred
license) would serve the purpose any better if it was adopted.

I still don't see how the CPL differs fundumentally from the LGPL with
it's so-called 'virus' effect.

Here's the URL for the CPL again:

http://www.opensource.org/licenses/cpl.php

- OK, it relies on some common definition of 'derivative work'.
- section 1/b/ii appears to regard any distributed derivative
work as a 'Contribution' to the 'Program' I.e. is covered by
the CPL. I note that this does not confine the term only to code
contributed to the primary project maintainer/s for includion.
- NOW, section 3/b/iv then effectively says that re-distribution
of the CPL'ed 'Program' (which is now the combined derivative work)
is only allowed if, amongst other things, the source code for the
[combined] work is made accessible.

Using the aformentioned (in a previous message) libstdc++ library as
the example,

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html

if the library was CPL'ed, how would the CPL free the author of a
program that uses this library from having to disclose the full program
source code?

Ross

Re: changing pthreads-win32 license

[Alexander Terekhov]

Ross Johnson wrote:
[...]
> - OK, it relies on some common definition of 'derivative work'.

Well. 

http://www.pbwt.com/Attorney/files/ravicher_1.pdf
http://www.eclipse.org/legal/legalfaq.html

[...]
> if the library was CPL'ed, how would the CPL free the author 
> of a program that uses this library from having to disclose 
> the full program source code?

AFAIK, a mere use (#include, linking, whatnot) of unmodified 
{library} code does *NOT* constitute creation of "derivative 
work". You'll simply have a "compilation". 

http://digital-law-online.info/lpdi1.0/treatise27.html
(see VI.D.4. Derivative Works and Compilations)

http://www-106.ibm.com/developerworks/opensource/library/os-cplfaq.html
(see Q15 and Q19)

Does this answer the question?

regards,
alexander.

Please respond to rpj@callisto.canberra.edu.au 
Sent by:        pthreads-win32-owner@sources.redhat.com
To: 
cc:     pthreads-win32@sources.redhat.com 
Subject:        Re: changing pthreads-win32 license


Alexander Terekhov wrote:

>>It specifically exempts macro definitions and the like.  Read it.
>> 
>>
>
>You mean "ten lines or less in length"? Yeah, given that the 
>length of lines seem to be unrestricted. [L]GPL is totally 
>brian-damaged technically and legally. Really.
>
> 
>
Personally, I'd be inclined to regard any work that included only
the unmodified LGPL'ed header files, specifically supplied for that
purpose, and dynamically linked to the unmodified main body of the
library, to be an independent and separate work as far as the LGPL
goes - static linking and assorted tricks aside for the moment.

If the LGPL really doesn't permit that, then I'd be in favour of
changing to an appropriate alternative license. But for the moment
I'm trying to convince myself that the CPL (Alexander's preferred
license) would serve the purpose any better if it was adopted.

I still don't see how the CPL differs fundumentally from the LGPL with
it's so-called 'virus' effect.

Here's the URL for the CPL again:

http://www.opensource.org/licenses/cpl.php

- OK, it relies on some common definition of 'derivative work'.
- section 1/b/ii appears to regard any distributed derivative
work as a 'Contribution' to the 'Program' I.e. is covered by
the CPL. I note that this does not confine the term only to code
contributed to the primary project maintainer/s for includion.
- NOW, section 3/b/iv then effectively says that re-distribution
of the CPL'ed 'Program' (which is now the combined derivative work)
is only allowed if, amongst other things, the source code for the
[combined] work is made accessible.

Using the aformentioned (in a previous message) libstdc++ library as
the example,

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html

if the library was CPL'ed, how would the CPL free the author of a
program that uses this library from having to disclose the full program
source code?

Ross

Re: changing pthreads-win32 license

[Phil Frisbie, Jr.]

Ross Johnson wrote:

> Alexander Terekhov wrote:
> 
>>> It specifically exempts macro definitions and the like.  Read it.
>>
>> You mean "ten lines or less in length"? Yeah, given that the length of 
>> lines seem to be unrestricted. [L]GPL is totally brian-damaged 
>> technically and legally. Really.
>>
> Personally, I'd be inclined to regard any work that included only
> the unmodified LGPL'ed header files, specifically supplied for that
> purpose, and dynamically linked to the unmodified main body of the
> library, to be an independent and separate work as far as the LGPL
> goes - static linking and assorted tricks aside for the moment.

Sony Entertainment's lawyers did not seem to have a problem including my LGPL'ed 
HawkVoice library as a DLL in their new game Planetside.

-- 
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

UNSUBCRIBE

[Mijares Rivas, Hector Hugo]

-----Mensaje original-----
De: Geoffrey Atkinson [mailto:geoffrey.atkinson@solipsys.com]
Enviado el: jueves, 30 de octubre de 2003 14:14
Para: pthreads-win32@sources.redhat.com
Asunto: UNSUBCRIBE


UNSUBSCRIBE

-------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente.

The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail

Re: UNSUBCRIBE

[Ross Johnson]

A reminder to all that easy to follow instructions for unsubscribing are 
included on the
project web site

http://sources.redhat.com/pthreads-win32

Sending requests to unsubscribe to the main list is not only annoying to 
others, but
probably the slowest way to get off the list.

Regards.
Ross