GPL and Python modules.

[=?ISO-8859-1?Q?Michael_Str=F6der?=]

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.

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]

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."

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]

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

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]

So your customers are non-programmers, right?

 

[Grant Edwards]

So your customers are non-programmers, right?

Are you addressing me?

Some are, some aren't.

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

 

[Bernhard Herzog]

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.

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

 

[marcus]

We tried that. We even set up a system to take credit-card
numbers over the phone. It never got used.

That's another win, right there.

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

 

[marcus]

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?

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]

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.

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