Use of GPLed Python extension modules

[Bengt Richter]

On Nov 22, 2003, at 5:33 PM, Rainer Deyke wrote: [...]

The FSF has no
legal right to restrict the distribution of any software unless that
software contains code which is copyrighted by the FSF.

This is, of course, incorrect, unfortunately.

I see the DMCA effect, but other than such (what I'd call) restraints on trade
in tools-that-COULD-be-put-to-illegal-use, or patent infringement,
or possibly obscenity and such laws if there is public distribution,
what can prevent the distribution of an original program by itself?

For example, the FSF could own the exclusive right to license some
piece of code. Not saying that they do, but they could, and thus, even
without being the copyright owner, would have the right to enforce it's
license.
Any of the rights granted by copyright can be licensed without having
to transfer the copyright itself.

What does that have to do with distributing separate software? It may
prevent the recipient from making legal use of it, but that is not the originator's
responsibility, so that should not be a basis for preventing the distribution,
unless you want to get into prohibition/preemptive-morality-enforcement legislation.

I passed copyright law in law school, so i'm at least sure of this much.

In addition, DMCA grants them the right to prevent distribution of
certain other types of code (code that circumvents effective access
controls).

Overreaching IMO, and the wrong solution for a real problem.

Regards,
Bengt Richter

 

[Patrick Maupin]

If a compiled Python extension module B includes code from some
other software A which is licensed only under the GPL, do other
Python programmes, C, which import module B also need to be
licensed under a GPL-compatible license (assuming C is/are to
be distributed to third parties)?

I think the answer is yes, both from a lay (IANAL) legal and
moral point-of-view, but I am interested in hearing any arguments
to the contrary. Note that I am talking about the GPL, not the
LGPL, and the aim is to honour both the copyleft spirit and
the copyleft legal force of the GPL, not to find clever methods
of circumventing it.

Even though I am also not a lawyer, it appears to me that the legal
issues are fairly cut and dried, AS LONG AS module B is not included
in the actual distribution of program C. In this instance, as I
discuss in another message in this thread, case law (e.g. Sega vs.
Accolade) seems to allow this separate distribution under any license.

As far as I can tell, this is the real legal distinction between the
GPL and the LGPL -- an LGPLed module D could be included with the actual
program C distribution, but module B cannot be included in the distribution.

Ville Vainio questions elsewhere in the thread whether this makes the
GPL useless for libraries. I think that, from the FSF's point of view,
the GPL is extremely useful for some sorts of libraries, especially
libraries with a lot of functionality which are continuously evolving.
If module B is such a library, the authors of program C would have to
warn their users to retrieve a particular version of module B, to
use the correct compilers on it, etc., while the competing authors of
program E can release their program under the GPL, and include the
correct precompiled version of module B in their distribution. This
makes the out-of-the-box experience for program E much more pleasant
than for program C, and gently nudges program C's authors in the
"right" direction (again, from the FSF's viewpoint).

As for the moral issue, IMO the distinction the FSF makes between
loosely-coupled and tightly-coupled programs is false. (Legally,
also, this distinction is false except when the programs are coupled
so tightly they MUST be provided in the same distribution. In other
words, it is the distribution of GPLed code which offends, not any
technical aspects of how non-GPLed code interacts with GPLed code.)

Since I personally believe that the "closeness" issue is a non-starter
(if C is inoperable unless B is in the system, what does it really matter
how they communicate?) then morally, IMO, coding program C in such a way
that it requires module B is no different than coding it in such a way
that it only runs on Linux. So if you believe (as some do and as has
been argued in the past) that anything which only runs in conjunction
with Linux must be GPLed, you should feel the same way about program C
using module B, but if you don't believe this, you should release
program C under any license you care to and tell your users to go
download their own copy of module B.

Pat

 

[Daniel Berlin]

Daniel Berlin wrote

Sure. That's what democracy is all about

Or the less flippant answer is: there are several areas of the
law in which laymen can have a legitimate interest and something
to say. This is true about any subject.


Yes, where "some chance" is an extremely small number.


Repeating this mantra, as you and several others on this thread
have done, simply does not make it true. Like most canards, this
has a kernel of truth, namely that the FSF itself has not been
in litigation over this issue. But if you think that this issue
has never been litigated, you have not boiled it down to its
most basic elements and then looked for case law.

Actually, I have.
On both Lexis, and Westlaw.
Sorry, no caselaw.

As I understand it, the abstract version of the case would boil
down to this:

- A company notices that program A is a useful tool for other
programs to use, and produces program B, which contains no
code from program A, but which invokes and uses program A
at runtime.
- When this company distributes program B, the makers of program
A sue the company for copyright violation. (They do not sue
the users who actually combine the two programs together, because
a) those users probably have a license to do this, and b)
that would be bad for business.)

This issue has come up repeatedly and has been litigated extensively,

Cases and citations please.

by companies with big budgets and good lawyers. I do not personally
know of any cases where the producer of program A has prevailed (absent
literal copying of program A), but I _do_ know of more than one case
where the maker of program B has prevailed (see Sega vs. Accolade for
a start). Note that in these cases, the producer of program B
has usually copied program A in the process of reverse-engineering
it (which would not even need to happen to use a GPLed program),
and this copying has been ruled to be fair use.



I didn't even take copyright law, and I'm sure that either a) you are
deliberately being unreasonably pedantic,
Given.

or b) you are exceedingly
dense. If you were to read the OP in the full context of the thread,
you would find that what he was really saying was that if party X
generates a pile of new code all by himself, the fact that the FSF
has some OTHER copyrighted code (and in the context, I'm sure the OP
means either owns or somehow controls this other code) does not
give the FSF any right to restrict what party X does with his own
code,

It may or may not.
It depends on the code. If it's the same code as the copyrighted code,
they would have such a right.

so party X is free to give his own code to whomever he cares
to, under whatever terms he chooses (but under some circumstances,
party X can certainly be enjoined from distributing the FSF's own code
alongside party X's own code). This is true EVEN IF party X's code
has the ability to make use of the FSF's code. In my opinion, the
OP made this point clearly and succinctly, and I'm sure that everybody
except you understood him perfectly.

Blah blah. More personal attacks for no reason.

Umm, yeah. I'm thinking real hard here to try to come up with a
license that is _less_ compatible with DMCA-style "access controls"
than the GPL. I'm drawing a blank here. Can anyone help me out?

(Hint: The GPL is the "anti-DMCA". Only use it on code you want
to insure is available to anybody, at any time, in any place.)

More of you being an ass for no reason.

 

[Tim Churches]

http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

Thanks, I completely overlooked this section of the FAQ. It
unequivocally gives the FSF's view on this issue - that a GPL license
must be used for Python programs which import and rely on other, GPLed
Python modules. So that's teh moral question answered. In the absence of
clear case law, it seems that it is impossible to say whether the FSF's
view would prevail in court, but clearly there is some chance that it
would, and hence in order to minimise legal risk it would be prudent to
abide by the FSF's wishes as clearly expressed in this section of the
GPL FAQ. Sorry for stirring up a hornet's nest, but it does indicate how
much confusion and disagreement exists over the licensing of Python
extension modules.

If a programming language interpreter is released under the GPL, does
that mean programs written to be interpreted by it must be under
GPL-compatible licenses?
When the interpreter just interprets a language, the answer is no.
The interpreted program, to the interpreter, is just data; a free
software license like the GPL, based on copyright law, cannot limit what
data you use the interpreter on. You can run it on any data (interpreted
program), any way you like, and there are no requirements about
licensing that data to anyone.

However, when the interpreter is extended to provide "bindings" to
other facilities (often, but not necessarily, libraries), the
interpreted program is effectively linked to the facilities it uses
through these bindings. So if these facilities are released under the
GPL, the interpreted program that uses them must be released in a
GPL-compatible way. The JNI or Java Native Interface is an example of
such a facility; libraries that are accessed in this way are linked
dynamically with the Java programs that call them.

Another similar and very common case is to provide libraries with
the interpreter which are themselves interpreted. For instance, Perl
comes with many Perl modules, and a Java implementation comes with many
Java classes. These libraries and the programs that call them are always
dynamically linked together.

A consequence is that if you choose to use GPL'd Perl modules or
Java classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl or Java
interpreter that the combined Perl or Java program will run on.

--

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



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

iD8DBQA/wRZdeJFGqer5k9ARAmGyAKCGX3iqbhk3AYcC/ovpdOa9apfN7ACfQu5y
hufyxsI4E6LqStw5ixKKaQw=
=k7U/
-----END PGP SIGNATURE-----

 

[Alexander Schmolck]

In the light of this, does releasing a library under GPL (as opposed
to LGPL) make any sense at all?

Well Stallman says the above wrong, have a look at how clisp became GPL.

'as

 

[Patrick Maupin]

Well Stallman says the above wrong, have a look at how clisp became GPL.

I think I was pretty upfront about how my opinion contradicts what
Stallman says.

My understanding is that clisp became GPL because Stallman claimed
that its use of readline forced the author to release it under the
GPL, and since the author was basically making free software anyway,
and more concerned about the software than the license, he
agreed to change the license fairly readily.

Likewise, I believe at least one other software package (the non-GPLed
version of Aladdin Ghostscript) has stopped using readline because
of Stallman's position.

As I mentioned in my earlier email, IMO the fact that nobody has gone
to court with the FSF over readline has more to do with other factors
than with the validity of the FSF's legal position on this issue.

For another viewpoint, you might want to look at these two PDFs
(which were written by the OSI's lawyer):

http://www.rosenlaw.com/html/GPL.PDF
http://www.rosenlaw.com/html/GL18.pdf


Pat

 

[Paul Boddie]

My understanding is that clisp became GPL because Stallman claimed
that its use of readline forced the author to release it under the
GPL, and since the author was basically making free software anyway,
and more concerned about the software than the license, he
agreed to change the license fairly readily.

Surely the Python community has been through this already with a
definitive outcome. There's a readline module (whose use is optional)
distributed with Python which uses an appropriate readline library
present on the user's system when Python is installed. However, Python
isn't distributed with the readline library itself because that would
cause the resulting distribution to be available only under the GPL.

I do seem to remember something about non-GPL readline equivalents
which may come into play here, but I don't think that's relevant to
how Python is distributed or installed today. It might also be
interesting to look at the licensing of the Debian packages for
Python, but then the dynamic linking aspects of GPL licensing may also
be involved there, too.

One wonders why the FSF doesn't have a "GPL licensing wizard" on their
Web site. ;-)

Paul

 

[Ben Finney]

One wonders why the FSF doesn't have a "GPL licensing wizard" on their
Web site. ;-)

Almost:

<http://www.gnu.org/licenses/gpl-faq.html>
<http://www.gnu.org/licenses/gpl-howto.html>

Amazing how many questions get continually asked and fallacies repeated,
that are answered by the above two pages.

 

[Andreas Kostyrka]

As for the moral issue, IMO the distinction the FSF makes between
loosely-coupled and tightly-coupled programs is false. (Legally,
also, this distinction is false except when the programs are coupled
so tightly they MUST be provided in the same distribution. In other
words, it is the distribution of GPLed code which offends, not any
technical aspects of how non-GPLed code interacts with GPLed code.)

Well, the big "difference" between C libraries, and Python modules is
that C libraries usually consist of .h files, which get included in
your "dynamically" linked program. That wouldn't be that bad, but .h
files often contain macros and/or inlined function, which makes every
client of the library include some part of the sourcecode of the
library.

Python modules OTOH include only my name, so there is no "code" leaked
into my
program.

If you read the interviews of the FSF Lawyers with this in your head,
it just makes much more sense (yeah, by using readline you are
including it, well at least parts, in your program).

Andreas

 

[Patrick Maupin]

Well, the big "difference" between C libraries, and Python modules is
that C libraries usually consist of .h files, which get included in
your "dynamically" linked program. That wouldn't be that bad, but .h
files often contain macros and/or inlined function, which makes every
client of the library include some part of the sourcecode of the
library.

Python modules OTOH include only my name, so there is no "code"
leaked into my program.

If you read the interviews of the FSF Lawyers with this in your head,
it just makes much more sense (yeah, by using readline you are
including it, well at least parts, in your program).

Well, that does make it read a bit more sensibly, but that is not
really what they are saying. The GPL FAQ on the FSF site talks
about dynamically interpreted languages, and even states very
explicitly that "A consequence is that if you choose to use
GPL'd Perl modules ... you must release the program in a GPL-
compatible way."

As another example, the email exchange leading up to the
GPLing of clisp is quite instructive. Personally, I don't find
"my lawyer made me do it" particularly compelling, especially
since that was tried after "but if I let _you_ do it, then
_anybody_ can get away with it" but I suppose it _could_ have
happened that way:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL?rev=HEAD

It may be true, as Daniel Berlin opines, that the FSF would have some
chance of convincing a judge of the correctness of this position.

However, the copying of small interface portions necessary for
interoperability has been ruled in some cases to be "fair use".
Even if you were worried that this was an issue, you could, in
a few hours, engineer a "clean-room" implementation of the header
files. This would involve someone reading them, describing in his
own words the bare minimum that was necessary to reconstruct an
interoperable .h file, and passing this description to someone
else to reimplement.

As you pointed out, Python's dynamicity makes not using the original
source even easier. This is true in some cases even if the GPLed
library is in C -- you might be able to interface with it via calldll,
and not even use any .h file description of the program in your
system.

But, as the GPL FAQ makes clear, and as many other of Stallmans'
writings make clear, in the opinion of at least some at the FSF
you would be violating the GPL if you were to do this. As I have
posted elsewhere, I have read several things which indicate that
this may not be true (at least if you are not actually distributing
the GPLed software along with your program). The only things I
have seen which indicate that it may be true are Richard Stallman
saying that it's true (without giving a good deep explanation why)
and other people saying "Well, of _course_ it's true! The GPL FAQ
says so!"

As long as everybody (probably correctly) agrees that it's not
worth it to provoke the FSF, then it doesn't really matter to
the FSF whether their position is legally defensible or not, because
obviously their position is having the desired effect if nobody
wants to test it in a courtroom. The reality that some people
are running scared of the "viral" nature of the GPL is actually
viewed as beneficial by Stallman and others who aren't busy trying
to get work done with both free and non-free software in a corporate
environment complete with conservative lawyers and bosses.

Pat

 

[Tim Churches]

One wonders why the FSF doesn't have a "GPL licensing wizard" on their
Web site. ;-)

If it were an avatar of RMS, then surely it would be more accurate to
call it a "GPL licensing curmudgeon" rather than a "GPL licensing
wizard"?

Stubbornness notwithstanding, thank goodness we have curmudgeons like
RMS in the world. He has a philosophical position which he knows to be
correct (and he is essentially correct), and he refuses to budge a
millimetre from it. May <deity-of-your-choice> bless his cotton socks.

--

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



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

iD8DBQA/xlFteJFGqer5k9ARAjCEAJ4+0bQ12a36D1FY2F3MNsx0zAQ8xgCgiKzI
NwD3QXYpEEftiVPO6qzRWzo=
=8Jqi
-----END PGP SIGNATURE-----

 

[Ville Vainio]

RMS in the world. He has a philosophical position which he knows to be
correct (and he is essentially correct), and he refuses to budge a
millimetre from it. May <deity-of-your-choice> bless his cotton socks.

The philosophical positions you are referring to isn't "It's called
GNU/Linux, damnit!", right ;-)?

 

[Paul Rubin]

Stubbornness notwithstanding, thank goodness we have curmudgeons like
RMS in the world. He has a philosophical position which he knows to be
correct (and he is essentially correct), and he refuses to budge a
millimetre from it. May <deity-of-your-choice> bless his cotton socks.

I've seen RMS's socks. I don't know whether they're made of cotton, but
I can attest that they are hole-y. ;-)

 

[KefX]

Stubbornness notwithstanding, thank goodness we have curmudgeons like

RMS in the world. He has a philosophical position which he knows to be
correct (and he is essentially correct), and he refuses to budge a
millimetre from it.

Correct? Perhaps. Currently practical for every case? Hardly.

- Kef

 

[Jarek Zgoda]

Correct? Perhaps. Currently practical for every case? Hardly.

Philosophy is not about practicality. It is about meaning of life, the
structure of universe and social life. If you get back to Aristotle, you
will find nice explanation of that topic in "Politeia".

If you cann't accept GPL, just don't use free software that is licensed
under GPL. Seems simple and reasonable. If you cann't afford buying BMW,
you drive Hyundai and you don't call Bayerische MotorWerke "crooks that
made BMW unavailable to you".

I write free software and license it under GPL, it doesn't matter if I
made it available free of charge, or I want money for that -- everybody
who receives my software, also receives full rights to this software. He
can read sources, modify it and distribute modified versions. If they
think that GPL will interfere with their business, they are free to
choose other software or hire a programmer, who will write the software
to suit their needs.

 

[Paul Boddie]

If you cann't accept GPL, just don't use free software that is licensed
under GPL. Seems simple and reasonable.

Yes, I hate this ill-informed commentary that surfaces regularly,
presumably commissioned by Steve Ballmer, which typically dredges up
the scenario that "your employees somehow download GPL software and
put it in your closed source product", then using it to claim that
upon being busted by the FSF, that the GPL was "viral", has "infected
your product" and was endorsed personally by Karl Marx.

What about the proper conclusion? That "your employees are thieves"?
Or to use a less loaded term: that "your employees and consequently
your company are intellectual property violators"?

I write free software and license it under GPL, it doesn't matter if I
made it available free of charge, or I want money for that -- everybody
who receives my software, also receives full rights to this software. He
can read sources, modify it and distribute modified versions. If they
think that GPL will interfere with their business, they are free to
choose other software or hire a programmer, who will write the software
to suit their needs.

Indeed. It isn't as if anyone is mandating GPL-licensed software just
yet. ;-)

Paul

 

[Jarek Zgoda]

Yes, I hate this ill-informed commentary that surfaces regularly,
presumably commissioned by Steve Ballmer, which typically dredges up
the scenario that "your employees somehow download GPL software and
put it in your closed source product", then using it to claim that
upon being busted by the FSF, that the GPL was "viral", has "infected
your product" and was endorsed personally by Karl Marx.

What about the proper conclusion? That "your employees are thieves"?
Or to use a less loaded term: that "your employees and consequently
your company are intellectual property violators"?

That assumption makes the developers idiots, we call them "polmozg" -- a
half-minded man. I think that we should raise the flag in face of such
mistreatment.