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

[Peter Otten]

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

[Phil Thompson]

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

I hate trying to answer questions like this (IANAL etc), but here goes...

If your code imports a GPL module then it is a derived work in the same
way that C code linked against a GPL library is a derived work. If you
want to distribute your code then you must use a GPL compatible license.
py2exe doesn't make any difference to what you can and cannot do.

Phil

[Grant Edwards]

On 2004-10-25, 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.

So my application code must be GPL'd even if I never distribute
the module? The mere act of inserting the line

"import someGPLdmodule"

Makes my _source_code_ a derived work, and therefore must be
GPL'd? That just doesn't sound right.
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.

--
Grant Edwards grante Yow! TAILFINS!!...click...
at
visi.com

[Gerhard Haering]

On Mon, Oct 25, 2004 at 03:46:31PM +0000, Grant Edwards wrote:

On 2004-10-25, 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.

So my application code must be GPL'd even if I never distribute
the module? The mere act of inserting the line

"import someGPLdmodule"

Makes my _source_code_ a derived work, and therefore must be
GPL'd? That just doesn't sound right.

The GPL only applies if you distribute your work (outside your
organization).

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 cra^w
questions.

Gerhard
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBfSI7dIO4ozGCH14RAlirAJ0VV6Cuzkphek7NXaLjcp YoBqx5ywCghaRI
10S1Sje3Zq6JCvSzZDRa2MY=
=dMQ9
-----END PGP SIGNATURE-----

[Grant Edwards]

On 2004-10-25, Gerhard Haering <[e-mail]> 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.
So my application code must be GPL'd even if I never distribute
the module? The mere act of inserting the line=20

"import someGPLdmodule"

Makes my _source_code_ a derived work, and therefore must be
GPL'd? That just doesn't sound right.

The GPL only applies if you distribute your work (outside your
organization).

Yes, I realize that, and it has nothing to do with my question.
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.

--
Grant Edwards grante Yow! Didn't I buy a 1951
at Packard from you last March
visi.com in Cairo?

[Peter Otten]

Grant Edwards wrote:

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.

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.

Peter

[Istvan Albert]

Grant Edwards wrote:

Makes my _source_code_ a derived work, and therefore must be
GPL'd? That just doesn't sound right.

Well doesn't your work derive some functionality
from the imported code? Does your code work without
the import?

People need to understand once and for all that
GPL is about "forcing" you to make your program
open source. Whether that sounds right
or wrong to you, whether you like it or hate it
is irrelevant.

Obviously no one like suddenly realize that they are
bound by GPL but everyone must keep this in mind
*before* choosing that path.

Istvan.

[Ville Vainio]

>>>>> "Grant" == Grant Edwards <gr****@visi.com> writes:

Grant> That just doesn't sound right.

That sentence pretty much summarizes the issue of GPL'd libraries. The
most practical approach is to rather post a question about "is there a
non-GPL'd version of <foo> around?"

--
Ville Vainio http://tinyurl.com/2prnb

[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?

Just a thought..

Why don't you just GPL the whole lot? Headache over, and a warm fuzzy
feeling in its place.

If your work could be used to extend or wrap the module, it's possible
someone else may find it useful...

Notwithstanding, obviously, any considerations you might have that would
stop you, that's what I'd do - besides which, if you're benefiting from
GPL stuff, give something back.. go on, you know you want to.. :-)

Like I said, just a thought.

[Grant Edwards]

On 2004-10-25, Peter Otten <__*******@web.de> wrote:

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
Or LGPL, which was intended for this specific situation.
- not that rare in Python land.

--
Grant Edwards grante Yow! I am having FUN... I
at wonder if it's NET FUN or
visi.com GROSS FUN?

[Grant Edwards]

On 2004-10-25, Istvan Albert <ia*****@mailblocks.com> wrote:

Makes my _source_code_ a derived work, and therefore must be
GPL'd? That just doesn't sound right.
Well doesn't your work derive some functionality
from the imported code?

Not until it's actually been imported. That doesn't happen
until runtime.
Does your code work without the import?

That depend's on your definition of "work".

--
Grant Edwards grante Yow! If I had a Q-TIP, I
at could prevent th' collapse
visi.com of NEGOTIATIONS!!

[Grant Edwards]

On 2004-10-25, ma****@deepfort.com <ma****@deepfort.com> 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?

Why don't you just GPL the whole lot? Headache over, and a
warm fuzzy feeling in its place.
I haven't said I won't. :) That said, providing a mechanism for
people to get the source does impose some overhead and cost.
And then there's the time/cost associated with supporting the
GPL'd source code _after_ you've provided somebody with it.
If your work could be used to extend or wrap the module,
It doesn't.
it's possible someone else may find it useful...
I doubt it, but you never know.
Notwithstanding, obviously, any considerations you might have
that would stop you, that's what I'd do - besides which, if
you're benefiting from GPL stuff, give something back..
I do try, though it isn't always accepted. The last set of
patches I submitted to gcc were declined. :(

You will find code by me in the socket and pyserial modules, in
gcc, binutils, gdb, fetchmail, rcs, mutt, and probably others
which I have forgotten.
go on, you know you want to.. :-)

I also wrote a ladder diagram editor and a compiler
code-generator which are GPL'd.

--
Grant Edwards grante Yow! I always liked FLAG
at DAY!!
visi.com

[Ian Bicking]

Grant Edwards wrote:

Why don't you just GPL the whole lot? Headache over, and a
warm fuzzy feeling in its place.

I haven't said I won't. :) That said, providing a mechanism for
people to get the source does impose some overhead and cost.
And then there's the time/cost associated with supporting the
GPL'd source code _after_ you've provided somebody with it.

You don't have to provide any mechanism, nor provide any support. If
you are giving them .pyc files, just include the .py files as well. You
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.

All the GPL asks is that you distribute the source with the program, and
allow that source to be modified and redistributed. Anything less is
against the spirit of the GPL, and as such against the spirit that the
original author had in mind when releasing that GPL code; you can try to
get around it, but even if it's legal it's not right. And it's probably
not legal, since intent *does* matter. If you don't think the GPL is
really the intent of the original author, then contact them; they may
very well be willing to relicense the code.

But as long as you don't mind people seeing, redistributing, and
modifying your source, then the GPL is not a problem, just a few extra
kilobytes in your distribution. Well, you are also supposed to note
somewhere that the source is available under the GPL -- so an extra line
in Help>About (or something like that) should be included.

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

[Istvan Albert]

Grant Edwards wrote:

That depend's on your definition of "work".

Executes the tasks it is designed to do.

Istvan.

[Grant Edwards]

On 2004-10-25, Ian Bicking <ia**@colorstudy.com> wrote:

Why don't you just GPL the whole lot? Headache over, and a
warm fuzzy feeling in its place.

I haven't said I won't. :) That said, providing a mechanism
for people to get the source does impose some overhead and
cost. And then there's the time/cost associated with
supporting the GPL'd source code _after_ you've provided
somebody with it.

You don't have to provide any mechanism, nor provide any
support. If you are giving them .pyc files, just include the
.py files as well.

I guess I could just tell py2exe to also include the .py files
in the install directory. There's still the problem of the
time/cost required to support them.
But as long as you don't mind people seeing, redistributing,
and modifying your source,

The problem is the time spent answering questions and helping
the people who have the source code.

--
Grant Edwards grante Yow! I brought my BOWLING
at BALL -- and some DRUGS!!
visi.com

[Istvan Albert]

Ian Bicking wrote:

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.

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.

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.

Istvan.

[Charles Hixson]

Peter Otten 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

I don't think that's correct. If you distribute the source, then I
don't think that you need to GPL the code (and if you GPL the code, you
*must* distribute the source anyway...so....).

The thing is, the source, although it depends on the GPL code to execute
is not itself linked to the GPL code. It tells you (in the import
statement) that you'll need it, but that's a different matter. You
might just want to study how some part of it worked.

I doubt that this is much help to you though. Usually when people ask
such a question it's because they intend to distribute a closed source
version, and I don't think you can do that. (But don't take my advice
as a certainty. I'm quite biased in favor of the GPL.)

[Peter Hansen]

Grant Edwards wrote:

I guess I could just tell py2exe to also include the .py files
in the install directory. There's still the problem of the
time/cost required to support them.

But as long as you don't mind people seeing, redistributing,
and modifying your source,

The problem is the time spent answering questions and helping
the people who have the source code.

Whatever gave you the idea you are obligated to provide support?!

-Peter

[Grant Edwards]

On 2004-10-25, Charles Hixson <ch**********@earthlink.net> 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.

I don't think that's correct. If you distribute the source, then I
don't think that you need to GPL the code (and if you GPL the code, you
*must* distribute the source anyway...so....).

The thing is, the source, although it depends on the GPL code to execute
is not itself linked to the GPL code.

This is equally true of a .pyc file that will require a GPL'd
module at runtime.
It tells you (in the import statement) that you'll need it,
but that's a different matter. You might just want to study
how some part of it worked.

I doubt that this is much help to you though. Usually when
people ask such a question it's because they intend to
distribute a closed source version, and I don't think you can
do that. (But don't take my advice as a certainty. I'm quite
biased in favor of the GPL.)

The simplest thing to do is to just tell py2exe to install the
source code as well -- until the questions about "why my
modified souce code doesn't work" start arriving.

--
Grant Edwards grante Yow! Now that we're
at in LOVE, you can BUY
visi.com this GOLDFISH for a 48%
DISCOUNT.

[Grant Edwards]

On 2004-10-25, Peter Hansen <pe***@engcorp.com> wrote:

Grant Edwards wrote:

I guess I could just tell py2exe to also include the .py files
in the install directory. There's still the problem of the
time/cost required to support them.

But as long as you don't mind people seeing, redistributing,
and modifying your source,

The problem is the time spent answering questions and helping
the people who have the source code.

Whatever gave you the idea you are obligated to provide support?!

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

--
Grant Edwards grante Yow! If elected, Zippy
at pledges to each and every
visi.com American a 55-year-old
houseboy...

[Peter Hansen]

Grant Edwards wrote:

On 2004-10-25, Peter Hansen <pe***@engcorp.com> wrote:

Grant Edwards wrote:

The problem is the time spent answering questions and helping
the people who have the source code.

Whatever gave you the idea you are obligated to provide support?!

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

Evil, nasty customers, we hates them! They asks us questions
and pays us money for our precioussssss time.

-Gollum

[Jorge Godoy]

Peter Hansen <pe***@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...

--
Godoy. <go***@ieee.org>

[Peter Hansen]

Jorge Godoy wrote:

Peter Hansen <pe***@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...

Are you taking my question out of context? I really doubt
Brazilian law says that if I provide access to the source
code for open source software, I *must* provide "support".

What does this law say is the form of the support? Do I have
to provide a 24x7 call centre staffed with nice knowledgeable
people? Do I have to provide a detailed design document
showing how the modules interrelate? What kind of turnaround
on fixing bugs or responding to emailed questions is required
by this law?

I'm not a lawyer, but I'm guessing you aren't either, so
I suspect the argument is pointless. I don't believe that
I would have an significant obligation in the context in
which my comments were made, and in the unlikely event I
did, I really doubt that I would be required to provide
such support for free. I know, you didn't say that it
had to be for free. Well, I charge $1,000,000 per incident
for support requests for my open source software (at my
whim, usually waived though ;-). What does Brazilian
law say about that?

-Peter

[Jorge Godoy]

Jorge Godoy <go***@ieee.org> writes:

Peter Hansen <pe***@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...

Just to make it clear: I was referring to obligations to software
distributed/sold here...

--
Godoy. <go***@ieee.org>

[Peter Hansen]

Jorge Godoy wrote:

Jorge Godoy <go***@ieee.org> writes:

Peter Hansen <pe***@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...

Just to make it clear: I was referring to obligations to software
distributed/sold here...

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.

I'm betting these laws have not yet been applied to the
*freely provided source code* that accompanies open source
software, even if the distribution of the software itself
(not the source) is matched by a big fat cheque from the
customer. And I'll bet they won't be any time soon.

-Peter

[Jorge Godoy]

Peter Hansen <pe***@engcorp.com> writes:

Are you taking my question out of context? I really doubt
Brazilian law says that if I provide access to the source
code for open source software, I *must* provide "support".
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.

I was not trying to take anything out of context, just citing one
occasion where you might have obligation to give support to a product
and the example was a law requirement.
What does this law say is the form of the support? Do I have
to provide a 24x7 call centre staffed with nice knowledgeable
people? Do I have to provide a detailed design document
showing how the modules interrelate? What kind of turnaround
on fixing bugs or responding to emailed questions is required
by this law?
Read above and please, drop the rocks from your hands. I hope we are
here to sum up and share knowledge instead of fighting. If these are
serious questions, I might answer later. If they are just to start a
some kind of silly fight, I won't have lost my time.
I'm not a lawyer, but I'm guessing you aren't either, so
I suspect the argument is pointless. I don't believe that
No, I'm not. But I know some of these obligations -- and our lawiers
check the agreements to see if we are acting accordingly to the law
everytime there's some need (e.g. with a new client, with some new
development, etc.).
I would have an significant obligation in the context in
which my comments were made, and in the unlikely event I
did, I really doubt that I would be required to provide
such support for free. I know, you didn't say that it
had to be for free. Well, I charge $1,000,000 per incident
for support requests for my open source software (at my
whim, usually waived though ;-). What does Brazilian
law say about that?

You are allowed to charge it if it's the agreement your client signed /
accepted.
See you,
--
Godoy. <go***@ieee.org>

[Grant Edwards]

On 2004-10-25, Peter Hansen <pe***@engcorp.com> wrote:

Whatever gave you the idea you are obligated to provide support?!

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

Evil, nasty customers, we hates them! They asks us questions
and pays us money for our precioussssss time.

Except they don't. (Pay that is.)

--
Grant Edwards grante Yow! ... this must be what
at it's like to be a COLLEGE
visi.com GRADUATE!!

[Alex Martelli]

Istvan Albert <ia*****@mailblocks.com> wrote:

Grant Edwards wrote:

Makes my _source_code_ a derived work, and therefore must be
GPL'd? That just doesn't sound right.
Well doesn't your work derive some functionality
from the imported code? Does your code work without
the import?

Interesting questions. As long as there exists somewhere a module with
the same name, which you can import for the same purpose, I would say,
'no'.

For example, assume there is a commercial foo.py that is distributed
only under some costly and onerous license. An enterprising paladin of
free software implements and distributes a work-alike foo.py that
follows the same specifications of the commercial one, but is GPL'd.

Now, I write my masterpiece oof.py:

import foo
while foo.bar():
foo.baz()

Is this a derived work from the commercial foo.py? I don't see how --
it doesn't use _one bit_ from it. Is this a derived work from the GPL'd
foo.py? Again I don't see how -- it's perfectly able to work with the
commercial version instead of the GPL one.

Now suppose the commercial enterprise producing the original foo.py,
wilting under the competition of the GPL version, goes bankrupt. The
commercial foo.py is no longer available. Does this suddenly and
retroactively make my oof.py, whose existence predated the event, a
"derivative work" of the GPL foo.py?

I am not a lawyer, and it wouldn't matter much if I was, because it's
the _courts'_ opinion that counts; I don't think the GPL in general has
ever been tested in the courts, much less the specific provision that a
bunch of bits (oof.pyc, or oof.o if I process that a bit, etc) may be a
derived work of
another bunch of bits (foo.py), with which neither them nor any of their
predecessors in the chain (oof.py) share anything, just because, among
the many potential interface-compliant implementations of (foo.pyc,
foo.o, etc), with which oof.pyc might be dynamically connected to
perform intended purpose, one happens to be covered by GPL.

If I choose to link statically (to make oof.exe, etc), then it does
strike me as reasonable doctrine that the whole oof.exe IS a derived
work of foo.py, because it contains bits derived from it (a processed
foo.pyc). Since oof.exe (if the courts concur) is a derived work of (a
specific implementation of) foo.py, that implementation-foo.py's license
_should_ govern the conditions for copying/distributing oof.exe, which
may (and do, in the case of GPL) require source distribution under
certain licenses, etc, etc.

But if I distribute an oof.exe which does NOT include foo.pyc, and
requires the latter (in some interface-compatible implementation) to be
made available otherwise, then we're back into the contentious "dynamic
linking" issue. Until some courts start ruling on that issue, I guess
we'll all just have to be curious and fruitlessly debate our opinions.

People need to understand once and for all that
GPL is about "forcing" you to make your program
open source. Whether that sounds right
or wrong to you, whether you like it or hate it
is irrelevant.
Yes; what's most relevant is the courts' opinions in the matter, which
unfortunately so far we do not know.
Obviously no one like suddenly realize that they are
bound by GPL but everyone must keep this in mind
*before* choosing that path.

Of course: in particular, choosing to fight in court the GPL, or some
specific provision of it, including the specific one of interest (under
which condition is my oof.o a derived work of anything that is not part
of its precursor sources), will no doubt entail a large amount of odium
coming from large parts of the free software community. Even if a given
corporation's IP lawyers were certain that the "derived work from
dynamic linking" doctrive won't hold up in court, that corporation's
management still has a duty to the shareholders to consider whether the
PR costs of fighting that battle might not exceed the value to the
shareholders of doing that bit of dynamic linking. Personally, I'm very
curious to know how the case would go, but not curious enough to risk
spending my own money and attracting the odium on myself to make a test
case!-)

In practice, the issue is moot, since we _will_ all be submerged by
software patents anyway, compared to which these copyrights issues will
(I predict) soon appear as trifles.
Alex

[Jorge Godoy]

Peter Hansen <pe***@engcorp.com> writes:

Now you tell me. :-)
OK. You see you made some effort lifting those rocks agains me and you
didn't need that :-) I just thought I should make that clear after I
read my own post.
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.
And the license isn't a factor that redeems one from that obligation
here. That was my point. It doesn't matter what is written in GPL: all
parts of it that goes against the law for a software sold here to a
brazilian client are considered automatically invalid and disregarded in
court or somewhere else the problem is taken to.
I'm betting these laws have not yet been applied to the *freely
provided source code* that accompanies open source software, even if
the distribution of the software itself (not the source) is matched by
a big fat cheque from the customer. And I'll bet they won't be any
time soon.

There are several discussions on the validity of GPL here. Some say
that it is a valid license, other that it needs to be remodeled, and
other say that it isn't appliable at all.

I am subscribed to three or four mailing list with lots of lawyers
discussing that (IANAL, but I know a lot of them ;-)).

As a side note... Our government is going towards free (as in free
speech) software (one example of that is http://www.softwarelivre.gov.br
-- which is powered by Zope and uses Plone ;-)) so that might make
things easier should a conflict come true (but, then, even the
government can't go against the law -- but they have some power to
change it... ;-)).

There is an "approved" version of a translation of GPL (yes, if the
license isn't in Brazilian Portuguese it is also invalid) and some work
at the congress to make free software completely viable and end with the
uncertainty I talked above.

I hope it succeeds.
Be seeing you,
--
Godoy. <go***@ieee.org>

[Jorge Godoy]

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

On 2004-10-25, Peter Hansen <pe***@engcorp.com> wrote:

Evil, nasty customers, we hates them! They asks us questions
and pays us money for our precioussssss time.

Except they don't. (Pay that is.)

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. <go***@ieee.org>

[Ian Bicking]

Istvan Albert wrote:

Ian Bicking wrote:

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.

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.

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

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 / ia**@colorstudy.com / http://blog.ianbicking.org

[Ian Bicking]

Grant Edwards wrote:

Whatever gave you the idea you are obligated to provide support?!

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

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 / ia**@colorstudy.com / http://blog.ianbicking.org

[Grant Edwards]

On 2004-10-25, Jorge Godoy <go***@ieee.org> wrote:

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

On 2004-10-25, Peter Hansen <pe***@engcorp.com> wrote:

Evil, nasty customers, we hates them! They asks us questions
and pays us money for our precioussssss time.

Except they don't. (Pay that is.)

And I thought that just us down here didn't get paid for work and had to
go after the customer to receive...

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]

On 2004-10-25, Ian Bicking <ia**@colorstudy.com> wrote:

Grant Edwards wrote:

Whatever gave you the idea you are obligated to provide support?!

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

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.

Oh, it says that.
Or maybe make it explicit that a higher level of support
contract is required, or something of the sort.

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]

Jorge Godoy wrote:

Peter Hansen <pe***@engcorp.com> writes:

Are you taking my question out of context? I really doubt
Brazilian law says that if I provide access to the source

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.

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]

On Mon, 2004-10-25 at 15:37 -0400, Peter Hansen wrote:

Jorge Godoy wrote:

Jorge Godoy <go***@ieee.org> writes:

Peter Hansen <pe***@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...

Just to make it clear: I was referring to obligations to software
distributed/sold here...

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.

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 <cl************@comcast.net>

[Cliff Wells]

On Mon, 2004-10-25 at 20:52 +0000, Grant Edwards wrote:

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.

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 <cl************@comcast.net>

[Grant Edwards]

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

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]

Grant Edwards wrote:

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

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 && ma*@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]

Peter Hansen <pe***@engcorp.com> writes:

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,
--
Godoy. <go***@ieee.org>

[Cliff Wells]

On Mon, 2004-10-25 at 21:20 +0000, 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.

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

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 <cl************@comcast.net>

[Cliff Wells]

On Mon, 2004-10-25 at 20:55 +0000, Grant Edwards wrote:

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

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

[Tim Churches]

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

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]

On Tue, 2004-10-26 at 08:37 +1000, Tim Churches wrote:

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

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

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 <cl************@comcast.net>

[Steve Holden]

Peter Otten wrote:

Grant Edwards wrote:

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.

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
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC [phone]

[Tim Churches]

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

On Tue, 2004-10-26 at 08:37 +1000, Tim Churches wrote:

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

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

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]

Steve Holden <st***@holdenweb.com> writes:

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.

--
Godoy. <go***@ieee.org>

[Robert Kern]

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

--
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 21:04 -0300, Jorge Godoy wrote:

Steve Holden <st***@holdenweb.com> writes:

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.

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

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