public inbox for
 help / color / mirror / Atom feed
From: Ross Johnson <>
To: Alexander Terekhov <>
Subject: Re: changing pthreads-win32 license
Date: Thu, 30 Oct 2003 07:03:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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:
>"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
Taking the FAQ quote above, and the your reference to

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


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


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.
I've been looking through version 1.0 of the CPL license at

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


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.


  reply	other threads:[~2003-10-30  7:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2003-10-20 10:06 ` Alexander Terekhov
2003-10-30  7:03   ` Ross Johnson [this message]
2003-10-30  9:51     ` Alexander Terekhov
2003-10-30 10:49       ` Will Bryant
2003-10-30 11:17         ` changing pthreads-win32 license - Practical Comment James Ewing
2003-10-30 11:46         ` changing pthreads-win32 license Alexander Terekhov
2003-10-30 13:14           ` UNSUBCRIBE Geoffrey Atkinson
2003-10-31  7:00           ` changing pthreads-win32 license Ross Johnson
2003-10-31 10:56             ` Alexander Terekhov
2003-10-31 16:27             ` Phil Frisbie, Jr.

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:

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

  git send-email \ \ \ \ \

* 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).