* changing pthreads-win32 license [not found] <3F9347E8.1080105@callisto.canberra.edu.au> @ 2003-10-20 10:06 ` Alexander Terekhov 2003-10-30 7:03 ` Ross Johnson 0 siblings, 1 reply; 10+ messages in thread From: Alexander Terekhov @ 2003-10-20 10:06 UTC (permalink / raw) To: pthreads-win32 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: changing pthreads-win32 license 2003-10-20 10:06 ` changing pthreads-win32 license Alexander Terekhov @ 2003-10-30 7:03 ` Ross Johnson 2003-10-30 9:51 ` Alexander Terekhov 0 siblings, 1 reply; 10+ messages in thread From: Ross Johnson @ 2003-10-30 7:03 UTC (permalink / raw) To: Alexander Terekhov; +Cc: pthreads-win32 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: changing pthreads-win32 license 2003-10-30 7:03 ` Ross Johnson @ 2003-10-30 9:51 ` Alexander Terekhov 2003-10-30 10:49 ` Will Bryant 0 siblings, 1 reply; 10+ messages in thread From: Alexander Terekhov @ 2003-10-30 9:51 UTC (permalink / raw) To: rpj; +Cc: pthreads-win32 [... 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: changing pthreads-win32 license 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 0 siblings, 2 replies; 10+ messages in thread From: Will Bryant @ 2003-10-30 10:49 UTC (permalink / raw) To: pthreads-win32 > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: changing pthreads-win32 license - Practical Comment 2003-10-30 10:49 ` Will Bryant @ 2003-10-30 11:17 ` James Ewing 2003-10-30 11:46 ` changing pthreads-win32 license Alexander Terekhov 1 sibling, 0 replies; 10+ messages in thread From: James Ewing @ 2003-10-30 11:17 UTC (permalink / raw) To: pthreads-win32 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: changing pthreads-win32 license 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 ` Alexander Terekhov 2003-10-30 13:14 ` UNSUBCRIBE Geoffrey Atkinson 2003-10-31 7:00 ` changing pthreads-win32 license Ross Johnson 1 sibling, 2 replies; 10+ messages in thread From: Alexander Terekhov @ 2003-10-30 11:46 UTC (permalink / raw) To: Will Bryant; +Cc: pthreads-win32 > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* UNSUBCRIBE 2003-10-30 11:46 ` changing pthreads-win32 license Alexander Terekhov @ 2003-10-30 13:14 ` Geoffrey Atkinson 2003-10-31 7:00 ` changing pthreads-win32 license Ross Johnson 1 sibling, 0 replies; 10+ messages in thread From: Geoffrey Atkinson @ 2003-10-30 13:14 UTC (permalink / raw) To: pthreads-win32 UNSUBSCRIBE ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: changing pthreads-win32 license 2003-10-30 11:46 ` changing pthreads-win32 license Alexander Terekhov 2003-10-30 13:14 ` UNSUBCRIBE Geoffrey Atkinson @ 2003-10-31 7:00 ` Ross Johnson 2003-10-31 10:56 ` Alexander Terekhov 2003-10-31 16:27 ` Phil Frisbie, Jr. 1 sibling, 2 replies; 10+ messages in thread From: Ross Johnson @ 2003-10-31 7:00 UTC (permalink / raw) Cc: pthreads-win32 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: changing pthreads-win32 license 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. 1 sibling, 0 replies; 10+ messages in thread From: Alexander Terekhov @ 2003-10-31 10:56 UTC (permalink / raw) To: rpj; +Cc: pthreads-win32 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: changing pthreads-win32 license 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. 1 sibling, 0 replies; 10+ messages in thread From: Phil Frisbie, Jr. @ 2003-10-31 16:27 UTC (permalink / raw) To: pthreads-win32 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-10-31 16:27 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3F9347E8.1080105@callisto.canberra.edu.au> 2003-10-20 10:06 ` changing pthreads-win32 license Alexander Terekhov 2003-10-30 7:03 ` Ross Johnson 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.
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).