GPL and Python modules.
Grant Edwards
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
> 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
> 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
> 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 2004-10-25, Peter Otten <__pet...@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?
Grant Edwards
>> >> 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?
Michael Sparks
> On 2004-10-25, Peter Otten <__pet...@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.
Depends. If you pull in and use a specific GPL module, then yes, it is
GPL'd. If you don't distribute said GPL module, and you can show
reasonable doubt whether:
import foo
imports the GPL foo or the non-GPL foo (say 2 files both independently
implemented to a common test suite for a standard), then it's much more
woolley.
After all if "foo" on the target system is from (say) a BSD'd
implementation and your code uses that, then your code isn't GPL
(obviously). If "foo" on the target system is (say) a GPL'd
implementation and your code uses that, then your code does have
to be GPL.
Put another way, if your code is shipped in the py2exe bundle with GPL'd
code and your code will not run without it, then its a derivative work in
the terms of the GPL.
However you can still hit this if the py2exe bundle has to use GPL'd
code even if you don't distribute it - for example if it's the only
implementation that python will bind the names to at run time because
the only implementation available is GPL.
(These issues are generally why the LGPL was created in the first place if
you're going HUH???!!?!)
Michael.
--
(Not a lawyer, this is not legal advice)
Peter Otten
> 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
> 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> 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
mar...@deepfort.com
>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
>> "import someGPLdmodule"
>>
>> Makes my _source_code_ a derived work, and therefore must be
>> GPL'd? That just doesn't sound right.
>
> Depends. If you pull in and use a specific GPL module, then yes, it is
> GPL'd. If you don't distribute said GPL module, and you can show
> reasonable doubt whether:
>
> import foo
>
> imports the GPL foo or the non-GPL foo
Placing that line in my source code does neither. It's an
instruction to the Python VM which will *at some point in the
future* import that module.
> (say 2 files both independently implemented to a common test
> suite for a standard), then it's much more woolley.
>
> After all if "foo" on the target system is from (say) a BSD'd
> implementation and your code uses that, then your code isn't GPL
> (obviously). If "foo" on the target system is (say) a GPL'd
> implementation and your code uses that, then your code does have
> to be GPL.
But, my souce code doesn't include or contain _either_ of the
foo modules. The import doesn't happen until the program is
run.
> Put another way, if your code is shipped in the py2exe bundle
> with GPL'd code and your code will not run without it, then
> its a derivative work in the terms of the GPL.
Possibly. That depends on whether you view what py2exe does as
"linking the two" or "mere aggregation". AFAIK, there is no
linkage between the two .pyc modules until runtime.
Zipping/tarring up my .pyc module with a GPL'd module seems to
me to be pretty much what's described as "mere aggregation" --
except for the fact that my module isn't useful without the
GPL'd module.
However, what if my code is shipped without the GPL'd code.
What if I ship my souce (or a compiled module) alone. Is it a
derived work do solely to the fact that the user will at some
point in the future use my my .pyc with a GPL'd module?
> However you can still hit this if the py2exe bundle has to use
> GPL'd code even if you don't distribute it - for example if
> it's the only implementation that python will bind the names
> to at run time because the only implementation available is
> GPL.
>
> (These issues are generally why the LGPL was created in the
> first place if you're going HUH???!!?!)
Yup.
--
Grant Edwards grante Yow! Will it improve my
at CASH FLOW?
visi.com
Grant Edwards
> 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
>> 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
>>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
>>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
> That depend's on your definition of "work".
Executes the tasks it is designed to do.
Istvan.
Grant Edwards
>>>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
> 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
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
> 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
>>>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
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
> 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
> 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
> 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
> 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
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
> 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
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!!
Jorge Godoy
> 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>
Alex Martelli
> 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
> 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
> 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
>>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.
Grant Edwards
> Grant Edwards <gra...@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
>>>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
> 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
>
> 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
> 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 <cliffor...@comcast.net>
Cliff Wells
> 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>.
Grant Edwards
>> 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
> 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 && m...@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
> 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
Leif K-Brooks
> However, what if my code is shipped without the GPL'd code.
> What if I ship my souce (or a compiled module) alone. Is it a
> derived work do solely to the fact that the user will at some
> point in the future use my my .pyc with a GPL'd module?
You might be technically right, but the wishes of the library's author
should trump any legalisms which might allow you to violate the spirit
of their license agreement.
Cliff Wells
> On 2004-10-25, Cliff Wells <cliffor...@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.
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.
Tim Churches
> Let's say I use a GPL'd python module (e.g. something installed
> in site-packages) in an application.
>
> 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
> 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.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...
Steve Holden
> 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 +1 800 494 3119
Tim Churches
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.
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.
--
Godoy. <go...@ieee.org>
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
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
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.
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.
> """
Excuse me. I am retarded. Please ignore me.
Cliff Wells
> Tim Churches wrote:
> >
> >
> > "It is OK for a closed-source application to allocate memory on a system
> > running the GPLed Linux kernel"
> >
> > and
> >
> > "It is not OK for a GPL-incompatible Python application to import GPLed
> > code into the runtime namespace it is using."
> >
> > I shudder to think what a judge and jury would make of such a
> > distinction.
>
> I'm sure they would see the explicit exception made in the GPL:
>
> """
> However, as a special exception, the source code distributed need not
> include anything that is normally distributed (in either source or
> binary form) with the major components (compiler, kernel, and so on) of
> the operating system on which the executable runs, unless that component
> itself accompanies the executable.
> """
I'm sure they would see it, I'm less sure they would see its relevance
(I certainly don't). The exception you refer to allows authors to ship
*GPL* applications without including the source for everything under the
sun. It says nothing about allowing non-GPL applications to link
against GPL libraries or import GPL code.
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.
> """
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.
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.
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?
--
Cliff Wells <cliffor...@comcast.net>
Tim Churches
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.
Robert Kern
> On Tue, 2004-10-26 at 11:12, Robert Kern wrote:
>>Whether just using system calls is simply "normal use" for a GPLd OS
>>kernel or this is simply a special exception to the GPL for Linux only
>>is something that a court will have to decide. But such a suit would
>>have to be about some other GPL kernel, not Linux.
>
>
> Looks like it is a special exception for the Linux kernel (or whatever
> other Linux code is distributed with this COPYING file. Doesn't apply to
> other GPLed code.
Well, not necessarily. It certainly isn't phrased as one. It is at least
a statement of someone's (Linus's?) belief that standard applications
that only use system calls and running on Linux are not derivative works
with respect to Linux. Are Windows programs actual derivative works of
the Windows kernel? Does the Windows EULA make a statement about the
derivative status of applications?
Brendan Scott
> On Tue, 2004-10-26 at 11:12, Robert Kern wrote:
>
>>>>>GPL'd system (such as Linux) without becoming GPL'd itself (Unless it
>>>>>doesn't do any I/O or malloc any memory <wink>).
>>>>
>>>>
>>>>
>>>>Yes. It seems to be them is some dissonance between these two positions:
>>>>
>>>>"It is OK for a closed-source application to allocate memory on a system
>>>>running the GPLed Linux kernel"
>>>>
>>>>and
>>>>
>>>>"It is not OK for a GPL-incompatible Python application to import GPLed
>>>>code into the runtime namespace it is using."
>>>>
>>>>I shudder to think what a judge and jury would make of such a
>>>>distinction.
Interestingly, prior to the FTA, there were court judgments which found that the reproduction in RAM in the course of running a program was not a reproduction within the meaning of the Copyright Act and, therefore, arguably such a copy would not be a derivative work within the meaning of the GPL, so it was probably never an issue. However, the FTA requires Australia to implement provisions in the Copyright Act which makes ephemeral copies infringing copies.
Brendan
IAAL
But DNHTAM
And TINLA
--
Brendan Scott IT Law Open Source Law
0414 339 227 http://www.opensourcelaw.biz
Liability limited by the Solicitors' Scheme, approved under the Professional Standards Act 1994 (NSW)
Open Source Law Weekly digest: osw...@opensourcelaw.biz
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
Tim Churches
> [mailto:python-list-bounces+tchur=optushom...@python.org]
> On Behalf Of Robert Kern
> Sent: Tuesday, 26 October 2004 11:34 AM
> To: pytho...@python.org
> Subject: Re: GPL and Python modules.
>
>
> Tim Churches wrote:
> > On Tue, 2004-10-26 at 11:12, Robert Kern wrote:
>
> >>Whether just using system calls is simply "normal use" for a GPLd OS
> >>kernel or this is simply a special exception to the GPL for
> Linux only
> >>is something that a court will have to decide. But such a
> suit would
> >>have to be about some other GPL kernel, not Linux.
> >
> >
> > Looks like it is a special exception for the Linux kernel
> (or whatever
> > other Linux code is distributed with this COPYING file.
> Doesn't apply
> > to other GPLed code.
>
> Well, not necessarily. It certainly isn't phrased as one. It
> is at least
> a statement of someone's (Linus's?) belief that standard applications
> that only use system calls and running on Linux are not
> derivative works
> with respect to Linux.
Yes, so it is a specific exemption to the GPL granted by the copyright
holder(s) of the Linux kernel code. The GPL allows the copyright holder to
grant exemptions to the GPL privisions as they see fit - but no-one else.
> Are Windows programs actual derivative
> works of
> the Windows kernel? Does the Windows EULA make a statement about the
> derivative status of applications?
No, and no. An important point of difference between the world views held
by, say, Steve Ballmer and, say, Richard Stallman.
Tim C
Robert Kern
It's still phrased as Linus's interpretation of what constitutes a
derivative work and what constitutes normal use of the GPLed kernel.
He's specifically saying that userland applications are not derivative
works not "even though they are derivative works, they are excepted from
the requirements of this license."
>>Are Windows programs actual derivative
>>works of
>>the Windows kernel? Does the Windows EULA make a statement about the
>>derivative status of applications?
>
>
> No, and no. An important point of difference between the world views held
> by, say, Steve Ballmer and, say, Richard Stallman.
The world views of Ballmer and Stallman are irrelevant to whether
something is a derivative or not. They may be relevant to whether one
may get sued or not, but that's a different issue.
In any case, Stallman does not appear to believe that userland
applications are automatically derivative works of the kernel:
http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem
"""If the two programs remain well separated, like the compiler and the
kernel, or like an editor and a shell, then you can treat them as two
separate programs--but you have to do it properly."""
Michael Hobbs
> On 2004-10-25, Gerhard Haering <g...@ghaering.de> wrote:
>> It would probably be a smart move to just *ask* the author of
>> the module if it's ok with him what you're planning to do.
>> Only if the two of you disagree, then you need to worry about
>> the legal questions.
>
> I don't really want to have to come to individual agreements
> with 5-10 different module authors. That's why "standard"
> licenses were invented.
It seems to me that any developer who releases a *library* under the
GPL falls into one of two camps:
A) The developer is unaware of the LGPL and/or the distinction between
the GPL and the LGPL.
B) The developer specifically intends to enforce the GPL on any
application that uses the library.
My guess is that 90% of all such developers fall into camp A. A simple
form email to each developer explaining the distinction and asking for
a license revision would probably resolve all problems.
If you happen to find a developer that falls into camp B, well, that's
his intent and there's not much you can do about it other than find a
different library.
-- Mike Hobbs
Tim Churches
> It's still phrased as Linus's interpretation of what constitutes a
> derivative work and what constitutes normal use of the GPLed kernel.
> He's specifically saying that userland applications are not
> derivative
> works not "even though they are derivative works, they are
> excepted from
> the requirements of this license."
Yes, you are quite right. As you imply, it would be better if the Linux
kernel copyright holders provided a specific exemption to the derivative
works provisions of the GPL as it applies to the Linux kernel. It is
surprising that this has not been corrected by now. But we stray off topic -
unless GPLed Python (or other) code provides specific exemptions, any Python
code which imports that GPLed code also needs to be licensed under the GPL
or equivalent if that code is to be distributed to others.
Tim C
Grant Edwards
> But we stray off topic - unless GPLed Python (or other) code
> provides specific exemptions, any Python code which imports
> that GPLed code also needs to be licensed under the GPL or
> equivalent if that code is to be distributed to others.
Now if I could just remember which library I was concerned
about to start with... :/
--
Grant Edwards grante Yow! I like your SNOOPY
at POSTER!!
visi.com
Michael Ströder
> But if someone puts
> a module under the GPL then any integrated use of that module is a
> dervied work and must, if redistributed, be put out under the GPL.
Are you really sure? I had a look at the installation directory of my old
Netscape Communicator 4.8 for Linux. There's an interesting sub-directory in
it containing the GPLed source of movemail.
As it looks to me movemail.c is distributed as source since it's GPLed.
Netscape Communicator itself which IMHO uses movemail but was at that time
still distributed as proprietary closed source app. Well, I could be wrong
since movemail is a separately linked executable and this might not count as
integrated use.
Ciao, Michael.
Michael Hobbs
> Customers seem to have no problem with not getting source code,
> but once you _do_ give them source code then you have to
> support it. Ignoring customers when they ask questions about
> the source code has always proven in past experience to be "not
> an option."
My reading of the GPL indicates that you don't have to supply source
code along with your software; you just have to supply a note indicating
that the source is freely available upon request. One way to socially
engineer this situation is to not include the source by default. If
one of your customers is savvy enough to then request the source, that
customer should also be savvy enough to realize that you won't provide
support for any modifications to the source. It should also be easy
enough to explicitly state the limitations on your support at the time
the request is made.
- Mike
Andrea Griffini
wrote:
>Grant Edwards wrote:
>
>> Let's say I use a GPL'd python module (e.g. something installed
>> in site-packages) in an application.
>
>I'd say everything that uses a GPL'd module is derived work and must also be
>GPL'd. It doesn't matter how you distribute it. If the module is under the
>LGPL you could use it in a closed source app but must make available any
>changes to the original module.
>
>Peter
IIUC in the case of LGPL you've also another obligation; if there
is a new version of the library then your users should be able
to link-in the newer version instead of the one you provided.
This is what IMO basically rules out any use of LGPL-ed code in
closed-source projects with a few exceptions (very very very
VERY stable libraries).
Suppose that a new version of the library changes the *interface*
of a call (this sometimes happens)... how can you be still
compliant if you're not providing the source code ? Are you
promising eternal recompilation/adaptation service ?
I also think this re-link requirement is a complete nonsense;
for example if I provide support for an application I would
surely reserve the right to refuse to provide any support in
case the user tampered the versions of the libraries provided:
break the seal, and you're on your own.
Andrea
Sridhar R
Grant Edwards
> So your customers are non-programmers, right?
Are you addressing me?
Some are, some aren't.
The one's asking for help with OS stuff were.
--
Grant Edwards grante Yow! Yow! Are we wet yet?
at
visi.com
Bernhard Herzog
> IIUC in the case of LGPL you've also another obligation; if there
> is a new version of the library then your users should be able
> to link-in the newer version instead of the one you provided.
No. They have to be able to link a *modified* version of the library,
not necessarily a newer or incompatible one. The LGPL quite explicitly
says that this relinking only has to be possible for sufficiently
compatible modifications.
Bernhard
--
Intevation GmbH http://intevation.de/
Skencil http://sketch.sourceforge.net/
Thuban http://thuban.intevation.org/
mar...@deepfort.com
>On 2004-10-25, Cliff Wells <cliffor...@comcast.net> wrote:
>
>
>
>>> Customer want's help with B.
>>>
>>>Sales is _not_ going to let you tell Customer that you don't
>>>provide support for B.
>>>
>>>
>>You *do* provide support for B. Just not *free* support. Win-win ;)
>>
>>
>
>We tried that. We even set up a system to take credit-card
>numbers over the phone. It never got used.
>
That's another win, right there. :-)
I know, despicable human being. *creeps back under rock*
mar...@deepfort.com
>Let's say I use a GPL'd python module (e.g. something installed
>in site-packages) in an application.
>
>Let's also say I use py2exe to package and distribute said
>application.
>
>Is what I'm distributing a "derived work" of the GPL'd python?
>Or is py2exe's packaging of the module's .pyc file and my
>application code's .pyc files a "mere aggregation" so that I
>only have to provide source code for the GPL'ed module and not
>for my application code?
>
>IOW, do I have to GPL my application code and distribute source
>code for it?
>
>
Here's my personal spin on it - I think that if your distributed binary
will contain GPL'ed code, that simplifies it - it makes your distributed
binary subject to the terms of the GPL.
Yet again, personal interpretation abounds, but in the spirit of the
GPL, if *what you actually distribute* for people to run *contains* the
GPL'ed stuff and uses it, then it's surely a derivative work, is it not?
If you wanted to avoid the issue with the library, it'd be worth
reimplementing it or offering it separately.
Overall, if you're going to release modules and insist GPLness, they
should really be released under the LGPL by convention shouldn't they?
Maybe you should contact the developer about that.
I really wish people would consider the LGPL when they're releasing
libraries etc. - OSS developers need to realise that it's encumbent on
them not to erode or threaten the legal status of the GPL, and that
releasing software under the GPL in this manner not only throws things
into uncertainty, but could (and IANAL so feel free to enlighten me
here) ultimately end up with the GPL being compromised in court in
future IP disputes, couldn't it?
I'd almost prefer to boycott software that uses the GPL frivolously or
inappropriately, because I fear it could threaten the GPL's existence
ultimately.
</high horse>
Anyway, have you come to a conclusion on this one? (or have I missed a post)
Andrea Griffini
wrote:
>No. They have to be able to link a *modified* version of the library,
>not necessarily a newer or incompatible one. The LGPL quite explicitly
>says that this relinking only has to be possible for sufficiently
>compatible modifications.
You're right. I've no excuses for basing my misinformed post
on just hearsay. Now that I took the time to actually read the
license that part is clear.
Thankyou for the correction.
Andrea
Scott Robinson
wrote:
I would be careful in taking legal advise from Richard Stallman. The
GPL merely states that*:
2. You may modify your copy or copies of the Program or
any portion of it, thus forming a work based on the Program,
and copy and distribute such modifications or work under the
terms of Section 1 above, provided that you also meet all of
these conditions:
After that, all notion of "derived work" falls on the appropriate
copyright law of the country in question. I suspect that following
Stallman's verdicts won't cause you to violate the GPL, but I would
hardly be willing to be certain about going to court over a GPLed
module imported into an unfree python program.
Scott Robinson
* note that I believe that this is fair use. According to the GPL,
you can only distribute it unmodified.