GPL and Python modules.

[Grant Edwards]

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?

--
Grant Edwards grante Yow! SHHHH!! I hear SIX
at TATTOOED TRUCK-DRIVERS
visi.com tossing ENGINE BLOCKS into
empty OIL DRUMS...

[Robert Kern]

Robert Kern wrote:

Tim Churches wrote:

On Tue, 2004-10-26 at 09:29, Cliff Wells wrote:

[snip]

If this is true, I can't think of any way for a program to run on a
GPL'd system (such as Linux) without becoming GPL'd itself (Unless it
doesn't do any I/O or malloc any memory <wink>).

Yes. It seems to be them is some dissonance between these two positions:

"It is OK for a closed-source application to allocate memory on a system
running the GPLed Linux kernel"

and

"It is not OK for a GPL-incompatible Python application to import GPLed
code into the runtime namespace it is using."

I shudder to think what a judge and jury would make of such a
distinction.

I'm sure they would see the explicit exception made in the GPL:

"""
However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that component
itself accompanies the executable.
"""

Excuse me. I am retarded. Please ignore me.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Cliff Wells]

On Mon, 2004-10-25 at 17:30 -0700, Robert Kern wrote:

Tim Churches wrote:

Yes. It seems to be them is some dissonance between these two positions:

"It is OK for a closed-source application to allocate memory on a system
running the GPLed Linux kernel"

and

"It is not OK for a GPL-incompatible Python application to import GPLed
code into the runtime namespace it is using."

I shudder to think what a judge and jury would make of such a
distinction.

I'm sure they would see the explicit exception made in the GPL:

"""
However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that component
itself accompanies the executable.
"""

I'm sure they would see it, I'm less sure they would see its relevance
(I certainly don't). The exception you refer to allows authors to ship
*GPL* applications without including the source for everything under the
sun. It says nothing about allowing non-GPL applications to link
against GPL libraries or import GPL code.

Regards,
Cliff

--
Cliff Wells <cl************@comcast.net>

[Robert Kern]

Robert Kern wrote:

Tim Churches wrote:

On Tue, 2004-10-26 at 09:29, Cliff Wells wrote:

[snip]

If this is true, I can't think of any way for a program to run on a
GPL'd system (such as Linux) without becoming GPL'd itself (Unless it
doesn't do any I/O or malloc any memory <wink>).

Yes. It seems to be them is some dissonance between these two positions:

"It is OK for a closed-source application to allocate memory on a system
running the GPLed Linux kernel"

and

"It is not OK for a GPL-incompatible Python application to import GPLed
code into the runtime namespace it is using."

I shudder to think what a judge and jury would make of such a
distinction.

I'm sure they would see the explicit exception made in the GPL:

"""
However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that component
itself accompanies the executable.
"""

Okay, a not-so-retarded reply this time:

From COPYING in the Linux kernel distribution:

"""
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
"""

Whether just using system calls is simply "normal use" for a GPLd OS
kernel or this is simply a special exception to the GPL for Linux only
is something that a court will have to decide. But such a suit would
have to be about some other GPL kernel, not Linux.

IANAL. TINLA.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Tim Churches]

On Tue, 2004-10-26 at 11:12, Robert Kern wrote:

Robert Kern wrote:

Tim Churches wrote:

On Tue, 2004-10-26 at 09:29, Cliff Wells wrote:

[snip]

If this is true, I can't think of any way for a program to run on a
GPL'd system (such as Linux) without becoming GPL'd itself (Unless it
doesn't do any I/O or malloc any memory <wink>).

Yes. It seems to be them is some dissonance between these two positions:

"It is OK for a closed-source application to allocate memory on a system
running the GPLed Linux kernel"

and

"It is not OK for a GPL-incompatible Python application to import GPLed
code into the runtime namespace it is using."

I shudder to think what a judge and jury would make of such a
distinction.

I'm sure they would see the explicit exception made in the GPL:

"""
However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that component
itself accompanies the executable.
"""

Okay, a not-so-retarded reply this time:

From COPYING in the Linux kernel distribution:

"""
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
"""

OK, thanks. In other words, the above special exemption added to the
Linux kernel license gets around the problem of non-GPLed code running
on a GPLed kernel. I knew there had to be a clear answer to this.
Whether just using system calls is simply "normal use" for a GPLd OS
kernel or this is simply a special exception to the GPL for Linux only
is something that a court will have to decide. But such a suit would
have to be about some other GPL kernel, not Linux.

Looks like it is a special exception for the Linux kernel (or whatever
other Linux code is distributed with this COPYING file. Doesn't apply to
other GPLed code.

Personally I am now completely satisfied that Python code which imports
GPLed Python (or other) code must itself be distributed under the GPL or
a GPL-compatible license, and that there are no contradictions between
this requirement and the ability to run closed-source applications on
systems which use the Linux kernel.

--

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0

[Cliff Wells]

On Mon, 2004-10-25 at 17:52 -0700, Robert Kern wrote:

Excuse me. I am retarded. Please ignore me.

If one person had ignored me for every retarded post I've made to this
list you'd be the only person reading this.

Um, other people *are* reading this... right?

--
Cliff Wells <cl************@comcast.net>

[Cliff Wells]

On Mon, 2004-10-25 at 18:12 -0700, Robert Kern wrote:

Okay, a not-so-retarded reply this time:

From COPYING in the Linux kernel distribution:

"""
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
"""

Good enough. It doesn't address licensing issues with so-called system
libraries (i.e. libc, et al [and yes, I know many of them are LGPL -
that isn't really the point]), but it at least provides exception for
the kernel.

Regards,
Cliff

--
Cliff Wells <cl************@comcast.net>

[Robert Kern]

Tim Churches wrote:

On Tue, 2004-10-26 at 11:12, Robert Kern wrote:

Whether just using system calls is simply "normal use" for a GPLd OS
kernel or this is simply a special exception to the GPL for Linux only
is something that a court will have to decide. But such a suit would
have to be about some other GPL kernel, not Linux.

Looks like it is a special exception for the Linux kernel (or whatever
other Linux code is distributed with this COPYING file. Doesn't apply to
other GPLed code.

Well, not necessarily. It certainly isn't phrased as one. It is at least
a statement of someone's (Linus's?) belief that standard applications
that only use system calls and running on Linux are not derivative works
with respect to Linux. Are Windows programs actual derivative works of
the Windows kernel? Does the Windows EULA make a statement about the
derivative status of applications?

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Brendan Scott]

Tim Churches wrote:

On Tue, 2004-10-26 at 11:12, Robert Kern wrote:

>If this is true, I can't think of any way for a program to run on a
>GPL'd system (such as Linux) without becoming GPL'd itself (Unless it
>doesn't do any I/O or malloc any memory <wink>).

Yes. It seems to be them is some dissonance between these two positions:

"It is OK for a closed-source application to allocate memory on a system
running the GPLed Linux kernel"

and

"It is not OK for a GPL-incompatible Python application to import GPLed
code into the runtime namespace it is using."

I shudder to think what a judge and jury would make of such a
distinction.

Interestingly, prior to the FTA, there were court judgments which found that the reproduction in RAM in the course of running a program was not a reproduction within the meaning of the Copyright Act and, therefore, arguably such a copy would not be a derivative work within the meaning of the GPL, so it was probably never an issue. However, the FTA requires Australia to implement provisions in the Copyright Act which makes ephemeral copies infringing copies.
Brendan
IAAL
But DNHTAM
And TINLA

--
Brendan Scott IT Law Open Source Law
0414 339 227 http://www.opensourcelaw.biz
Liability limited by the Solicitors' Scheme, approved under the Professional Standards Act 1994 (NSW)
Open Source Law Weekly digest: os****@opensourcelaw.biz

[Peter Hansen]

Brendan Scott wrote:

Brendan IAAL
Wow! finding a real live lawyer around here is a rarity.
But DNHTAM
Okay, we won't hold it against you.
And TINLA

Check: _not_ legal advice. We promise not to act on it,
and in return you promise not to bill us $250 for reading
it, right?

;-)

-Peter

[Michael Hobbs]

Grant Edwards <gr****@visi.com> wrote:

On 2004-10-25, Gerhard Haering <[e-mail]> wrote:

It would probably be a smart move to just *ask* the author of
the module if it's ok with him what you're planning to do.
Only if the two of you disagree, then you need to worry about
the legal questions.

I don't really want to have to come to individual agreements
with 5-10 different module authors. That's why "standard"
licenses were invented.

It seems to me that any developer who releases a *library* under the
GPL falls into one of two camps:
A) The developer is unaware of the LGPL and/or the distinction between
the GPL and the LGPL.
B) The developer specifically intends to enforce the GPL on any
application that uses the library.

My guess is that 90% of all such developers fall into camp A. A simple
form email to each developer explaining the distinction and asking for
a license revision would probably resolve all problems.

If you happen to find a developer that falls into camp B, well, that's
his intent and there's not much you can do about it other than find a
different library.

-- Mike Hobbs

[Michael Ströder]

Steve Holden wrote:

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]

Grant Edwards <gr****@visi.com> wrote:

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]

On Mon, 25 Oct 2004 17:33:59 +0200, Peter Otten <__*******@web.de>
wrote:

Grant Edwards wrote:

Let's say I use a GPL'd python module (e.g. something installed
in site-packages) in an application.

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]

On 2004-10-27, Sridhar R <sr*************@gmail.com> wrote:

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.

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

[Bernhard Herzog]

Andrea Griffini <ag****@tin.it> writes:

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

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

[marcus]

Grant Edwards wrote:

On 2004-10-25, Cliff Wells <cl************@comcast.net> wrote:

Customer want's help with B.

Sales is _not_ going to let you tell Customer that you don't
provide support for B.

You *do* provide support for B. Just not *free* support. Win-win ;)

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]

Grant Edwards wrote:

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]

On Wed, 27 Oct 2004 11:45:40 +0200, Bernhard Herzog <[e-mail]>
wrote:

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