public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Alexander Terekhov" <TEREKHOV@de.ibm.com>
To: rpj@callisto.canberra.edu.au
Cc: pthreads-win32@sources.redhat.com
Subject: Re: changing pthreads-win32 license
Date: Fri, 31 Oct 2003 10:56:00 -0000	[thread overview]
Message-ID: <OFB29BD4D5.61B7C843-ONC1256DD0.003BE2D0-C1256DD0.003BFA1F@de.ibm.com> (raw)
In-Reply-To: <3FA20890.5050005@callisto.canberra.edu.au>

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

  reply	other threads:[~2003-10-31 10:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3F9347E8.1080105@callisto.canberra.edu.au>
2003-10-20 10:06 ` 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 [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=OFB29BD4D5.61B7C843-ONC1256DD0.003BE2D0-C1256DD0.003BFA1F@de.ibm.com \
    --to=terekhov@de.ibm.com \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=rpj@callisto.canberra.edu.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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