GPL and Python modules.

[Jorge Godoy]

Re: GPL and Python modules.

Grant Edwards <grante@visi.co m> writes:
[color=blue]
> On 2004-10-25, Peter Hansen <peter@engcorp. com> wrote:[color=green]
>>
>> Evil, nasty customers, we hates them! They asks us questions
>> and pays us money for our precioussssss time.[/color]
>
> Except they don't. (Pay that is.)[/color]

And I thought that just us down here didn't get paid for work and had to
go after the customer to receive... I see there's no safe place in the
world that protects us from the customer...

If they only knew what they wanted, it would save us a *lot* of time...

--
Godoy. <godoy@ieee.org >

[Ian Bicking]

Re: GPL and Python modules.

Istvan Albert wrote:[color=blue]
> Ian Bicking wrote:
>[color=green]
>> don't even have to GPL your code, you just have to abide by the GPL
>> (i.e., provide source); you could distribute your code under any
>> GPL-compatible license, such as a BSD-style license.[/color]
>
>
> No if you derive from GPL then you must release your program
> as GPL and you may not release it with a "GPL compatible"
> license.[/color]

If you derive the code, yes -- like, you take the GPL code and edit it.
At that point there's little way to distinguish your modifications
from the original code.

If the code is a separate entity, but used in the same program, then
it's not so clear. You can always release it under multiple licenses,
but that's usually only done if there is a question of GPL-compatibility
(e.g., Artistic License).

When you release code under the GPL you retain copyright to that code,
including a copyright to any changes or additions you make. You can
take that code and release it under any license, though you can only
relicense code you have the copyright to.

So if you use libreadline (or some GPL library) in your program, you
must abide by the *terms* of the GPL, which implies some licensing that
allows people to view and edit the source, since those rights are not
implied. If you use, say, a BSD-style license (w/o advertising clause,
to make it GPL-compatible), that's cool. If someone comes along and
takes your code and separates it from libreadline (reimplements the
functionality, just stubs it out, whatever), they would then only be
bound by the terms of the BSD license.
[color=blue]
> Otherwise it would be to easy to circumvent it, just get a
> GPL program, add a comment, call it something else
> and re-release it as BSD.
>
> From the GPL FAQ:
>
> Q: If a library is released under the GPL (not the LGPL),
> does that mean that any program which uses it has to be under the GPL?
> A: Yes, because the program as it is actually run includes the library.[/color]

Well, that doesn't seem right to me. But since dual licensing is common
and allowed under the GPL, putting your code under the BSD license is
equivalent to dual licensing. (Especially since anyone *can* make
modifications to a piece of BSD, and release it under the GPL.)

The GPL definitely does not require any transfer of copyright, so you
can look at it a bunch of different ways, but in the end the effect is
the same.

--
Ian Bicking / ianb@colorstudy .com / http://blog.ianbicking.org

[Ian Bicking]

Re: GPL and Python modules.

Grant Edwards wrote:[color=blue][color=green]
>>Whatever gave you the idea you are obligated to provide support?![/color]
>
>
> Experience.
>
> 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]

Well, it sounds like an issue for your contract; i.e., an explicit
clause about not supporting code that has been modified in any way. Or
maybe make it explicit that a higher level of support contract is
required, or something of the sort. That's a sales issue. If the
contract has already been signed, I think that's okay -- that level of
support is never implied.

But sales issues are boring, we can only help with technical solutions.
A technical solution might be to make hashes of all the files you
release, and include something that checks those hashes; maybe when the
program is started, or in a support screen, or whatever. If they've
modified any files, put a big message up that they have modified the
product and there is no warrantee or support for the product in that
state. It's like a tamper-proof sticker on hardware, but easier on them
because they can put the sticker back if they want (i.e., undo their
modifications).

If they are sneaky they'd change the hashes. But that'd be more than
sneaky, they'd have to be assholes with an intent to defraud if they go
that far. And if you are dealing with customers of that sort, then
you're doomed.

And if they just want help making modifications, well gee, it should be
pretty darn easy to turn them down on that.

--
Ian Bicking / ianb@colorstudy .com / http://blog.ianbicking.org

[Grant Edwards]

Re: GPL and Python modules.

On 2004-10-25, Jorge Godoy <godoy@ieee.org > wrote:[color=blue]
> Grant Edwards <grante@visi.co m> writes:
>[color=green]
>> On 2004-10-25, Peter Hansen <peter@engcorp. com> wrote:[color=darkred]
>>>
>>> Evil, nasty customers, we hates them! They asks us questions
>>> and pays us money for our precioussssss time.[/color]
>>
>> Except they don't. (Pay that is.)[/color]
>
> And I thought that just us down here didn't get paid for work and had to
> go after the customer to receive...[/color]

It's not really that. The situation is more like:

Customer orders A.
Customer pays for A.
Customer needs support for A.
Customer gets support for A.

No problem, so far.

You give customer some GPL software B along with written
statement that free support is not provided for B.

Customer want's help with B.

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

--
Grant Edwards grante Yow! Is there something
at I should be DOING with a
visi.com GLAZED DONUT??

[Grant Edwards]

Re: GPL and Python modules.

On 2004-10-25, Ian Bicking <ianb@colorstud y.com> wrote:[color=blue]
> Grant Edwards wrote:[color=green][color=darkred]
>>>Whatever gave you the idea you are obligated to provide support?![/color]
>>
>>
>> Experience.
>>
>> 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]
>
> Well, it sounds like an issue for your contract; i.e., an explicit
> clause about not supporting code that has been modified in any way.[/color]

Oh, it says that.
[color=blue]
> Or maybe make it explicit that a higher level of support
> contract is required, or something of the sort.[/color]

It says that too.

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

IMO, it's usually worthwile to answer the questions. It
generates customer loyalty. 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.

--
Grant Edwards grante Yow! .. I want a COLOR
at T.V. and a VIBRATING BED!!!
visi.com

[Peter Hansen]

Re: GPL and Python modules.

Jorge Godoy wrote:[color=blue]
> Peter Hansen <peter@engcorp. com> writes:[color=green]
>>Are you taking my question out of context? I really doubt
>>Brazilian law says that if I provide access to the source[/color]
>
> It says you must provide some kind of guarantee and a certain level of
> support, no matter if the source is or isn't included.[/color]

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.

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.

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.

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

-Peter

[Cliff Wells]

Re: GPL and Python modules.

On Mon, 2004-10-25 at 15:37 -0400, Peter Hansen wrote:[color=blue]
> Jorge Godoy wrote:[color=green]
> > Jorge Godoy <godoy@ieee.org > writes:
> >
> >[color=darkred]
> >>Peter Hansen <peter@engcorp. com> writes:
> >>
> >>
> >>>Whatever gave you the idea you are obligated to provide support?!
> >>
> >>One has such an obligation here in .br. Our law demands that and a
> >>license can't override what is stated in the law, so...[/color]
> >
> >
> > Just to make it clear: I was referring to obligations to software
> > distributed/sold here...[/color]
>
> Now you tell me. :-)
>
> It's probably the case in the majority of markets that one is
> obligated to provide some kind of support for the products one
> sells.[/color]

Certainly here in the U.S. there is little chance of supplying things
without warranty. That applies to almost anything, not just software.
Even if you state upfront that something is provided "as is", most
states provide additional protections to the customer. The extent of
the protection varies from state-to-state, so even if the state that you
are based in doesn't impose such restrictions on freedom from liability,
if the customer is in a different state, you may find yourself bound by
the guarantees provided in the customer's state of residence.

As far as protecting oneself against liability, the only real guarantee
of that is to simply not provide *anything*. Frankly I fail to see how
open-source versus closed-source matters at all in this area. If I
write a program in Visual Basic and the program fails due to some bug in
the programming language or libraries, I'm still going to be the one
liable to the customer (especially since it was my choice to use sub-par
tools). I suppose I might be able to sue Microsoft in return, but I
have doubts about how well that's going to fly in practical terms ;) In
fact, I'd forward that open source is superior in this respect since I
can either fix it myself or pay someone to fix it for me if I'm unable
(and I've done this in the last week, so I hereby invoke the voice of
experience <wink>).


Regards,
Cliff

--
Cliff Wells <clifford.wells @comcast.net>

[Cliff Wells]

Re: GPL and Python modules.

On Mon, 2004-10-25 at 20:52 +0000, Grant Edwards wrote:
[color=blue]
> It's not really that. The situation is more like:
>
> Customer orders A.
> Customer pays for A.
> Customer needs support for A.
> Customer gets support for A.
>
> No problem, so far.
>
> You give customer some GPL software B along with written
> statement that free support is not provided for B.
>
> 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 ;)

Somehow I find your company sales department's failure to abide by your
own company's written agreements to be a somewhat less than convincing
argument against open source <wink>.

Regards,
Cliff

--
Cliff Wells <clifford.wells @comcast.net>

[Grant Edwards]

Re: GPL and Python modules.

On 2004-10-25, Cliff Wells <clifford.wells @comcast.net> wrote:
[color=blue][color=green]
>> 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=blue]
> Somehow I find your company sales department's failure to
> abide by your own company's written agreements to be a
> somewhat less than convincing argument against open source
> <wink>.[/color]

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

--
Grant Edwards grante Yow! PEGGY FLEMING is
at stealing BASKET BALLS to
visi.com feed the babies in VERMONT.

[Erik Max Francis]

Re: GPL and Python modules.

Grant Edwards wrote:
[color=blue]
> I'm not arguing agains open source. I'm arguing against the
> statement that releasing source code doesn't cost anything.[/color]

But it's only costing you something because you choose to let it.
Nothing compels you legally to provide support, so making the connection
between one and the other is a personal choice, not a requirement
regarding open source in and of itself.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Liberty without learning is always in peril; learning without
liberty is always in vain. -- John F. Kennedy

[Jorge Godoy]

Re: GPL and Python modules.

Peter Hansen <peter@engcorp. com> writes:
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> I could be wrong. You're right about the rocks though: sorry about
> that. :-)[/color]

Don't worry. :-) I'll still read your posts and try learning something
from them :-)
[color=blue]
> -Peter[/color]


Be seeing you,
--
Godoy. <godoy@ieee.org >

[Cliff Wells]

Re: GPL and Python modules.

On Mon, 2004-10-25 at 21:20 +0000, 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=green]
> > Somehow I find your company sales department's failure to
> > abide by your own company's written agreements to be a
> > somewhat less than convincing argument against open source
> > <wink>.[/color]
>
> I'm not arguing agains open source. I'm arguing against the
> statement that releasing source code doesn't cost anything.[/color]

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 <clifford.wells @comcast.net>

[Cliff Wells]

Re: GPL and Python modules.

On Mon, 2004-10-25 at 20:55 +0000, Grant Edwards wrote:
[color=blue]
>
> That doesn't stop them from asking "just one question". Usually
> forwaded through sales.[/color]

Indeed. And nothing stops you from explaining to them that you'll be
happy to answer their question at your usual rate.
[color=blue]
> IMO, it's usually worthwile to answer the questions. It
> generates customer loyalty.[/color]

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.
[color=blue]
> 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.[/color]

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

--
Cliff Wells <clifford.wells @comcast.net>

[Tim Churches]

Re: GPL and Python modules.

On Tue, 2004-10-26 at 01:16, 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?[/color]

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

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

Re: GPL and Python modules.

On Tue, 2004-10-26 at 08:37 +1000, Tim Churches wrote:[color=blue]
> On Tue, 2004-10-26 at 01:16, 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.
> >
> > 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?[/color]
>
> See the GPL FAQ at
> http://www.fsf.org/licenses/gpl-faq....ereAggregation :[/color]

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

--
Cliff Wells <clifford.wells @comcast.net>