This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]