From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28689 invoked by alias); 30 Oct 2003 09:51:34 -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 28680 invoked from network); 30 Oct 2003 09:51:31 -0000 Received: from unknown (HELO d12lmsgate.de.ibm.com) (194.196.100.235) by sources.redhat.com with SMTP; 30 Oct 2003 09:51:31 -0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9U9pAoS134946; Thu, 30 Oct 2003 10:51:12 +0100 Received: from d12ml007.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9U9p3Lh214006; Thu, 30 Oct 2003 10:51:03 +0100 In-Reply-To: <3FA0B7D0.6070004@callisto.canberra.edu.au> Importance: Normal MIME-Version: 1.0 Sensitivity: To: rpj@callisto.canberra.edu.au Cc: pthreads-win32@sources.redhat.com Subject: Re: changing pthreads-win32 license Message-ID: From: "Alexander Terekhov" Date: Thu, 30 Oct 2003 09:51:00 -0000 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2003/txt/msg00123.txt.bz2 [... 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 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 *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. > >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