GPL and Python modules.

[Michael Ströder]

Re: GPL and Python modules.

Steve Holden wrote:[color=blue]
> But if someone puts
> a module under the GPL then any integrated use of that module is a
> dervied work and must, if redistributed, be put out under the GPL.[/color]

Are you really sure? I had a look at the installation directory of my old
Netscape Communicator 4.8 for Linux. There's an interesting sub-directory in
it containing the GPLed source of movemail.

As it looks to me movemail.c is distributed as source since it's GPLed.
Netscape Communicator itself which IMHO uses movemail but was at that time
still distributed as proprietary closed source app. Well, I could be wrong
since movemail is a separately linked executable and this might not count as
integrated use.

Ciao, Michael.

[Michael Hobbs]

Re: GPL and Python modules.

Grant Edwards <grante@visi.co m> wrote:[color=blue]
> Customers seem to have no problem with not getting source code,
> but once you _do_ give them source code then you have to
> support it. Ignoring customers when they ask questions about
> the source code has always proven in past experience to be "not
> an option."[/color]

My reading of the GPL indicates that you don't have to supply source
code along with your software; you just have to supply a note indicating
that the source is freely available upon request. One way to socially
engineer this situation is to not include the source by default. If
one of your customers is savvy enough to then request the source, that
customer should also be savvy enough to realize that you won't provide
support for any modifications to the source. It should also be easy
enough to explicitly state the limitations on your support at the time
the request is made.

- Mike

[Andrea Griffini]

Re: GPL and Python modules.

On Mon, 25 Oct 2004 17:33:59 +0200, Peter Otten <__peter__@web. de>
wrote:
[color=blue]
>Grant Edwards wrote:
>[color=green]
>> Let's say I use a GPL'd python module (e.g. something installed
>> in site-packages) in an application.[/color]
>
>I'd say everything that uses a GPL'd module is derived work and must also be
>GPL'd. It doesn't matter how you distribute it. If the module is under the
>LGPL you could use it in a closed source app but must make available any
>changes to the original module.
>
>Peter[/color]

IIUC in the case of LGPL you've also another obligation; if there
is a new version of the library then your users should be able
to link-in the newer version instead of the one you provided.
This is what IMO basically rules out any use of LGPL-ed code in
closed-source projects with a few exceptions (very very very
VERY stable libraries).
Suppose that a new version of the library changes the *interface*
of a call (this sometimes happens)... how can you be still
compliant if you're not providing the source code ? Are you
promising eternal recompilation/adaptation service ?

I also think this re-link requirement is a complete nonsense;
for example if I provide support for an application I would
surely reserve the right to refuse to provide any support in
case the user tampered the versions of the libraries provided:
break the seal, and you're on your own.

Andrea

[Sridhar R]

Re: GPL and Python modules.

So your customers are non-programmers, right?

[Grant Edwards]

Re: GPL and Python modules.

On 2004-10-27, Sridhar R <sridharinfinit y@gmail.com> wrote:
[color=blue]
> So your customers are non-programmers, right?[/color]

Are you addressing me?

Some are, some aren't.

The one's asking for help with OS stuff were.

--
Grant Edwards grante Yow! Yow! Are we wet yet?
at
visi.com

[Bernhard Herzog]

Re: GPL and Python modules.

Andrea Griffini <agriff@tin.i t> writes:
[color=blue]
> IIUC in the case of LGPL you've also another obligation; if there
> is a new version of the library then your users should be able
> to link-in the newer version instead of the one you provided.[/color]

No. They have to be able to link a *modified* version of the library,
not necessarily a newer or incompatible one. The LGPL quite explicitly
says that this relinking only has to be possible for sufficiently
compatible modifications.

Bernhard

--
Intevation GmbH http://intevation.de/
Skencil http://sketch.sourceforge.net/
Thuban http://thuban.intevation.org/

[marcus@deepfort.com]

Re: GPL and Python modules.

Grant Edwards wrote:
[color=blue]
>On 2004-10-25, Cliff Wells <clifford.wells @comcast.net> wrote:
>
>
>[color=green][color=darkred]
>>> Customer want's help with B.
>>>
>>>Sales is _not_ going to let you tell Customer that you don't
>>>provide support for B.
>>>
>>>[/color]
>>You *do* provide support for B. Just not *free* support. Win-win ;)
>>
>>[/color]
>
>We tried that. We even set up a system to take credit-card
>numbers over the phone. It never got used.
>[/color]

That's another win, right there. :-)

I know, despicable human being. *creeps back under rock*

[marcus@deepfort.com]

Re: GPL and Python modules.

Grant Edwards wrote:
[color=blue]
>Let's say I use a GPL'd python module (e.g. something installed
>in site-packages) in an application.
>
>Let's also say I use py2exe to package and distribute said
>application.
>
>Is what I'm distributing a "derived work" of the GPL'd python?
>Or is py2exe's packaging of the module's .pyc file and my
>application code's .pyc files a "mere aggregation" so that I
>only have to provide source code for the GPL'ed module and not
>for my application code?
>
>IOW, do I have to GPL my application code and distribute source
>code for it?
>
>[/color]

Here's my personal spin on it - I think that if your distributed binary
will contain GPL'ed code, that simplifies it - it makes your distributed
binary subject to the terms of the GPL.

Yet again, personal interpretation abounds, but in the spirit of the
GPL, if *what you actually distribute* for people to run *contains* the
GPL'ed stuff and uses it, then it's surely a derivative work, is it not?

If you wanted to avoid the issue with the library, it'd be worth
reimplementing it or offering it separately.

Overall, if you're going to release modules and insist GPLness, they
should really be released under the LGPL by convention shouldn't they?

Maybe you should contact the developer about that.

I really wish people would consider the LGPL when they're releasing
libraries etc. - OSS developers need to realise that it's encumbent on
them not to erode or threaten the legal status of the GPL, and that
releasing software under the GPL in this manner not only throws things
into uncertainty, but could (and IANAL so feel free to enlighten me
here) ultimately end up with the GPL being compromised in court in
future IP disputes, couldn't it?

I'd almost prefer to boycott software that uses the GPL frivolously or
inappropriately , because I fear it could threaten the GPL's existence
ultimately.

</high horse>

Anyway, have you come to a conclusion on this one? (or have I missed a post)

[Andrea Griffini]

Re: GPL and Python modules.

On Wed, 27 Oct 2004 11:45:40 +0200, Bernhard Herzog <bh@intevation. de>
wrote:
[color=blue]
>No. They have to be able to link a *modified* version of the library,
>not necessarily a newer or incompatible one. The LGPL quite explicitly
>says that this relinking only has to be possible for sufficiently
>compatible modifications.[/color]

You're right. I've no excuses for basing my misinformed post
on just hearsay. Now that I took the time to actually read the
license that part is clear.

Thankyou for the correction.

Andrea