GPL and Python modules.

[Jorge Godoy]

I really think it says that about the *product*, not its source code.
The source code is not being provided as part of the sale, it is being
made available separately.

IANAL, but if the license requires me to give the source code if it was
requested without costs -- except for the media and delivery of it --
then it looks like part of the package to me (i.e., the product works
but is not "complete").

On the other hand, I agree that supporting the source code is not an
obligation.

It's not even necessary that it be possible to use that source to
rebuild the product without purchasing other pieces of software, such
as commercial compilers.

Here I agree with you. You also don't have to give the source code for
compilers, system libraries or the OS itself. You don't either have to
give a license of the OS where the software will run in, so that makes
it clear that these are separate things.

On the other hand, selling something and saying that if the customer
wants he can get the "diagrams, specs and building rules" to rebuild the
same product -- making it clear what the requirements are -- might make
some judge interpret that as if the given source code would have to work
and be able to rebuild everything given that all required tools are
available. I don't know if support for setting up the environment
variables, locating libraries, fixing some Makefile, etc. would be
considered an extra or not. I digress here, of course, but it is hard
to think of what an unchanged code might need in terms of support.

Reading some new posts from Grant, I saw that these support requests
arrive through their sales people, so I think they aren't too complex or
related to something like building an entirely new product using their
software as a module.


What I think? I'd like to get that support if I were buying and I'd
hate to give it for free if I were selling. I'd try making it very
clear on the contract.

Grant was talking about the cost of supporting the *source code* when
its required that it be made available because of GPL-type license
terms, and I really would be very surprised if Brazilian law had
anything to say about that.

No, it doesn't even make it clear if GPL is or not supported at all. I
think that it is the same everywhere, but software here is treated like
art, like a book. It is subject to intelectual properties laws. We
don't have -- AFAIR -- specific software laws. Yet.

I could be wrong. You're right about the rocks though: sorry about
that.

Don't worry. I'll still read your posts and try learning something
from them

-Peter

Be seeing you,

 

[Cliff Wells]

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


I'm not arguing agains open source. I'm arguing against the
statement that releasing source code doesn't cost anything.

I'd argue just the opposite: if properly managed, providing source opens
the doors to additional revenue (e.g. assisting the customer with
modifications). The fact that your company doesn't charge for this is
only a statement about your company, nothing else. And to be quite
honest, perhaps that is a positive statement from your customer's point-
of-view. I am not making a judgment about which approach is better,
only that it doesn't have to be that way.

Regards,
Cliff

 

[Cliff Wells]

That doesn't stop them from asking "just one question". Usually
forwaded through sales.

Indeed. And nothing stops you from explaining to them that you'll be
happy to answer their question at your usual rate.

IMO, it's usually worthwile to answer the questions. It
generates customer loyalty.

Agreed. It's just a question of when to draw the line. I usually draw
it if the answer to their questions is going to take me more than, say,
5 to 10 minutes. One thing I've noticed is that if you *always* provide
free support, customers don't appreciate it. Rather they come to
*expect* it and will get angry if you refuse to provide it. But if you
only give them free support *sometimes*, then they realize that you are
giving them something for free that usually costs money. This they
appreciate.

But, pretending that it deoesn't
cost time/effort to support GPL'd source code when you give it
to a customer is being delusional.

It's no different than providing anything else to a customer. If they
didn't ask questions about the source, then it would be about use of the
application or about the operating system or about... the only way to
stop customer questions is not have customers (or to charge them
ridiculous prices for support). The typical model for making money from
open source is to provide support for a fee. If you aren't getting paid
for that support then the open source model isn't going to work well for
you.


Regards,
Cliff

 

[Tim Churches]

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?

See the GPL FAQ at
http://www.fsf.org/licenses/gpl-faq.html#MereAggregation :

<quote from above URL>
What is the difference between "mere aggregation" and "combining two
modules into one program"?

Mere aggregation of two programs means putting them side by side on the
same CD-ROM or hard disk. We use this term in the case where they are
separate programs, not parts of a single program. In this case, if one
of the programs is covered by the GPL, it has no effect on the other
program.

Combining two modules means connecting them together so that they form a
single larger program. If either part is covered by the GPL, the whole
combination must also be released under the GPL--if you can't, or won't,
do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes,
rpc, function calls within a shared address space, etc.) and the
semantics of the communication (what kinds of information are
interchanged).

If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But
if the semantics of the communication are intimate enough, exchanging
complex internal data structures, that too could be a basis to consider
the two parts as combined into a larger program.
</quote>

Thus, if you combine your code with GPLed code using py2exe, the GPL
clearly applies. If you import GPLed Python code into the same namespace
as your code, the GPL clearly applies. If your code calls a GPLed Python
module via an "intimate" RPC mechanism like PyRO, then the GPL may
applies (but it is not so clear-cut). If your code calls GPLed code via
a less intimate mechanism, like XML-RPC or HTTP, the GPL clearly doesn't
apply. If your code and GPL code are just on the same disc, the GPL
clearly doesn't apply.
--

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]

See the GPL FAQ at
http://www.fsf.org/licenses/gpl-faq.html#MereAggregation :

If this interpretation is true, then I suppose I'm going to have to
reassess my position on the GPL and agree with Microsoft <gasp> that the
GPL is "viral". I had always dismissed this claim as pure FUD, but the
following gives pause:

'''
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But
if the semantics of the communication are intimate enough, exchanging
complex internal data structures, that too could be a basis to consider
the two parts as combined into a larger program.
'''

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>). While it's true that
the LGPL is far more lenient in this regard (and is used by many system
libraries, along with the BSD license), the LGPL is also now disdained
by the FSF and *might* not be used universally by the long chain of
libraries/system calls any non-trivial application might inadvertently
use. The bottom line is that any developer of GPL'd software on that
platform is going to need to review every single library that the
program might use. It also raises questions about what the GPL means
when calls are made into the (GPL'd) kernel. If I malloc some memory
(via libc) and libc calls into the kernel, how does that affect me?
Clearly the linkage is "intimate" as I doubt the memory will be passed
to my program via a pipe or command line argument <wink>. Does libc
(which I believe to be LGPL or at least provides a clause for linking)
somehow "launder" the licensing of the kernel call before it gets to my
program?

Now, I know that in practical day-to-day terms, this means little.
Linus clearly has no intention of preventing closed-source apps from
running on Linux. Nevertheless, to a corporate attorney reviewing this
sort of thing, it would seem clear that non-GPL apps cannot easily exist
on Linux.

Suddenly thinking that BSD-style licenses might be better after all...

Regards,
Cliff

 

[Steve Holden]

Grant Edwards wrote:




Yes, and for an author to GPL a module is the standard way of saying use it
as you like in your program, but distribute your part of the work under the
same terms. Basically an embrace-and-extend antidote for code.

I think talking to an author and maybe offering a moderate fee if you want
terms more favourable to your purpose shouldn't be too much.

Otherwise you have to stick to modules with BSD/MIT/Python Licenses - not
that rare in Python land.

Looks that way. Time was, authors would use the LGPL for libraries
(which was why it was developed in the first place). 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.

regards
Steve

 

[Tim Churches]

If this interpretation is true, then I suppose I'm going to have to
reassess my position on the GPL and agree with Microsoft <gasp> that the
GPL is "viral". I had always dismissed this claim as pure FUD, but the
following gives pause:

'''
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But
if the semantics of the communication are intimate enough, exchanging
complex internal data structures, that too could be a basis to consider
the two parts as combined into a larger program.
'''

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

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

 

[Jorge Godoy]

Looks that way. Time was, authors would use the LGPL for libraries
(which was why it was developed in the first place). 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.

Reading a prior post here, there was one thing that could be done:
writing an interface module, releasing the source for such an interface
module, and communicating with it through pipes, RPC, etc. It would
separate your code from the other and free you from the obligation of
using GPL.

 

[Robert Kern]

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

--
Robert Kern
(e-mail address removed)

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

 

[Cliff Wells]

Reading a prior post here, there was one thing that could be done:
writing an interface module, releasing the source for such an interface
module, and communicating with it through pipes, RPC, etc. It would
separate your code from the other and free you from the obligation of
using GPL.

Hm. Much like the NVidia drivers for Linux do (the "shim" interface
between the kernel and their proprietary code is open source, which
solves a couple problems at once for them [licensing and changing
kernels]). However, I also doubt they are using pipes or command line
arguments for communication, so I wonder how they've resolved that
issue.

Regards,
Cliff

 

[Robert Kern]

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
(e-mail address removed)

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

 

[Cliff Wells]

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

 

[Robert Kern]

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
(e-mail address removed)

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

 

[Cliff Wells]

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?

 

[Tim Churches]

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]

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

 

[Robert Kern]

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
(e-mail address removed)

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

 

[Brendan Scott]

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

 

[Peter Hansen]

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]

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