Use of GPLed Python extension modules

[Tim Churches]

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.

Tim C

[Paul Rubin]

Tim Churches <tc***@optushome.com.au> writes:

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

It's not enough for B and C to be under "GPL-compatible licenses".
They have to be under the actual GPL.

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

You have a GPL'ed program that I'd like to link with my code to build
a proprietary program. Does the fact that I link with your program
mean I have to GPL my program?

Yes.

[kk]

Paul Rubin wrote:

Tim Churches <tc***@optushome.com.au> writes:

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

It's not enough for B and C to be under "GPL-compatible licenses".
They have to be under the actual GPL.

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

You have a GPL'ed program that I'd like to link with my code to build
a proprietary program. Does the fact that I link with your program
mean I have to GPL my program?

Yes.

AFAIK, ur python program, which is interpreted, is considered data in
view of the program interpreter. So the GPL license is not needed.
Correct me if I am wrong.

[Jp Calderone]

On Sat, Nov 22, 2003 at 05:37:38PM +0800, kk wrote:

Paul Rubin wrote:

Tim Churches <tc***@optushome.com.au> writes:

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

It's not enough for B and C to be under "GPL-compatible licenses".
They have to be under the actual GPL.

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

You have a GPL'ed program that I'd like to link with my code to build
a proprietary program. Does the fact that I link with your program
mean I have to GPL my program?

Yes.

AFAIK, ur python program, which is interpreted, is considered data in
view of the program interpreter. So the GPL license is not needed.
Correct me if I am wrong.

I'm pretty sure that's wrong.

Jp

[Robert Kern]

In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Tim Churches <tc***@optushome.com.au> writes:

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

It's not enough for B and C to be under "GPL-compatible licenses".
They have to be under the actual GPL.

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

You have a GPL'ed program that I'd like to link with my code to build
a proprietary program. Does the fact that I link with your program
mean I have to GPL my program?

Yes.

Note that the question is phrased as a "proprietary vs. GPL" dichotomy. I think
the following entry is more appropriate:

http://www.gnu.org/licenses/gpl-faq....LModuleLicense

"""
If I add a module to a GPL-covered program, do I have to use the GPL as the
license for my module?

The GPL says that the whole combined program has to be released under the GPL.
So your module has to be available for use under the GPL.

But you can give additional permission for the use of your code. You can, if
you wish, release your program under a license which is more lax than the GPL
but compatible with the GPL. The license list page gives a partial list of
GPL-compatible licenses.
"""

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

[Paul Rubin]

rk***@ucsd.edu (Robert Kern) writes:

Note that the question is phrased as a "proprietary vs. GPL"
dichotomy. I think the following entry is more appropriate:

http://www.gnu.org/licenses/gpl-faq....LModuleLicense

No I don't think it's more appropriate. That entry is about adding
your own module to a GPL'd program. Such a module doesn't have to be
GPL'd, as long as its license is "GPL-compatible". The original
question was not about that. It was about using part of a GPL'd
program in another program. That is prohibited unless the second
program is also GPL'd.

[Bengt Richter]

On 22 Nov 2003 12:14:03 -0800, Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

rk***@ucsd.edu (Robert Kern) writes:

Note that the question is phrased as a "proprietary vs. GPL"
dichotomy. I think the following entry is more appropriate:

http://www.gnu.org/licenses/gpl-faq....LModuleLicense

No I don't think it's more appropriate. That entry is about adding
your own module to a GPL'd program. Such a module doesn't have to be
GPL'd, as long as its license is "GPL-compatible". The original
question was not about that. It was about using part of a GPL'd
program in another program. That is prohibited unless the second
program is also GPL'd.

Yes, but even that wasn't the actual question the way I read it. To requote
[with my annotation]:
"""
If a compiled Python extension module B includes code from some other
software A which is licensed only under the GPL [resulting in B_GPLd_because_of_A],
do other Python programmes, C, which import [this is the key relationship -- importing
a GPL'd module, irrespective of how it became GLP'd] module B also need to be licensed
under a GPL-compatible license (assuming C is/are to be distributed to third parties)?
"""

The question ISTM is whether importing a GPL'd module is enough to trigger GPL obligations
on the part of the importing module. ISTM that is more like a program-program relationship
than incorporation of code (unless it modifies the source. e.g., with an execfile and changes
based on source knowledge). I.e., if a non-GPL module could be substituted without changing
the importer, IWT that would mean plug-compatibility rather than incorporation. But IANAL.
I haven't read the license recently, but I thought there there was some arms-length uses of GPL
software by proprietary software that are allowed, or am I mistaken? I don't know how long the arm
has to be though.

Regards,
Bengt Richter

[Tim Churches]

On Sun, 2003-11-23 at 02:52, Jp Calderone wrote:

On Sat, Nov 22, 2003 at 05:37:38PM +0800, kk wrote:

Paul Rubin wrote:

Tim Churches <tc***@optushome.com.au> writes:

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


It's not enough for B and C to be under "GPL-compatible licenses".
They have to be under the actual GPL.

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

You have a GPL'ed program that I'd like to link with my code to build
a proprietary program. Does the fact that I link with your program
mean I have to GPL my program?

Yes.

AFAIK, ur python program, which is interpreted, is considered data in
view of the program interpreter. So the GPL license is not needed.
Correct me if I am wrong.

I'm pretty sure that's wrong.

So am I, at least on the basis of the following paragraphs from the GPL
FAQ ( http://www.fsf.org/licenses/gpl-faq....ereAggregation )

<begin quote>
"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."<end quote>

Importing a GPLed Python module into the Python namespace seems like a
fairly intimate kind of communication. Personally I doubt that it makes
much difference whether it is Python bytecode which is being combined
and run under the same instance of the Python VM, or compiled machine
code which is being run on the microcode of the CPU chip (and what if
you use Psyco?).

But I am most interested to hear arguments to the contrary.

--

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/v9WqeJFGqer5k9ARAnYsAKCbW/d1t1ssVbnKxgcjou8qhWtg2wCgr3kS
sLmhaIqBAJBnRIiyVl6mRxs=
=fBxR
-----END PGP SIGNATURE-----

[Paul Rubin]

bo**@oz.net (Bengt Richter) writes:

The question ISTM is whether importing a GPL'd module is enough to
trigger GPL obligations on the part of the importing module.
That is a correct statement of the question. According to the FSF,
the answer to the question is yes, that's enough to trigger the obligations.
ISTM that is more like a program-program relationship than
incorporation of code (unless it modifies the source. e.g., with an
execfile and changes based on source knowledge). I.e., if a non-GPL
module could be substituted without changing the importer, IWT that
would mean plug-compatibility rather than incorporation. But IANAL.
The FSF's lawyer IAL, and he says you're in error.
I haven't read the license recently, but I thought there there was
some arms-length uses of GPL software by proprietary software that
are allowed, or am I mistaken? I don't know how long the arm has to
be though.

Somewhat longer than importing a module into your program's address
space and calling it through a subroutine interface.

[Rainer Deyke]

Paul Rubin wrote:

bo**@oz.net (Bengt Richter) writes:

The question ISTM is whether importing a GPL'd module is enough to
trigger GPL obligations on the part of the importing module.

That is a correct statement of the question. According to the FSF,
the answer to the question is yes, that's enough to trigger the
obligations.

Either you are misinterpreting the FSF, or the FSF is wrong. The FSF has no
legal right to restrict the distribution of any software unless that
software contains code which is copyrighted by the FSF. Whether the code
may be linked to GPL code at runtime or not is irrelevant. The FSF does
have the legal right to restrict the use of its own code, but it chooses not
to exercise that right: the only restrictions in the GPL are on the
redistribution (not use) of GPL'd code.
--
Rainer Deyke - ra*****@eldwood.com - http://eldwood.com

[Paul Rubin]

"Rainer Deyke" <ra*****@eldwood.com> writes:

Either you are misinterpreting the FSF, or the FSF is wrong. The
FSF has no legal right to restrict the distribution of any software
unless that software contains code which is copyrighted by the FSF.
Whether the code may be linked to GPL code at runtime or not is
irrelevant. The FSF does have the legal right to restrict the use
of its own code, but it chooses not to exercise that right: the only
restrictions in the GPL are on the redistribution (not use) of GPL'd code.

The FSF does not agree with you, but as they say, it's something only a
court can decide. They have stated their willingness to go to court over
the question. No one so far has taken them up on it.

[Robert Kern]

In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> writes:

rk***@ucsd.edu (Robert Kern) writes:

Note that the question is phrased as a "proprietary vs. GPL"
dichotomy. I think the following entry is more appropriate:

http://www.gnu.org/licenses/gpl-faq....LModuleLicense

No I don't think it's more appropriate. That entry is about adding
your own module to a GPL'd program. Such a module doesn't have to be
GPL'd, as long as its license is "GPL-compatible". The original
question was not about that. It was about using part of a GPL'd
program in another program. That is prohibited unless the second
program is also GPL'd.

I think the same principles apply in both the OP's question and the FAQ answer.
Note that the FAQ answer mixes things up a bit in the following sentence: "But
you can give additional permission for the use of your code. You can, if you
wish, release your *program* under a license which is more lax than the GPL but
compatible with the GPL" [emphasis added]. I think the actual answer tries to
answer both the literal question in the FAQ and the OP's question.

If I have an application ("C") that uses the readline module ("B"), and I wish
to distribute it, I must distribute it under the GPL. Under my interpretation of
the FAQ answer, I can also give the recipients of the application more rights to
*my* code (the parts that are C and not B) such that they can, say, use a
routine that has no relationship to B (for example, a computational routine that
doesn't have a UI and therefore doesn't use readline at all) in a
GPL-incompatible project. I don't think that the GPL makes the distinction
between putting a GPLed module into a GPL-compatible program and putting a
GPL-compatible module into a GPLed program.

C.f.

From RMS
http://mail.gnome.org/archives/found.../msg00034.html

IANAL, and of course, RMS INAL, either, but until there's a court case examining
this issue in particular, I think we're safe.

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

[Bengt Richter]

On 22 Nov 2003 14:41:58 -0800, Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

"Rainer Deyke" <ra*****@eldwood.com> writes:

Either you are misinterpreting the FSF, or the FSF is wrong. The
FSF has no legal right to restrict the distribution of any software
unless that software contains code which is copyrighted by the FSF.
Whether the code may be linked to GPL code at runtime or not is
irrelevant. The FSF does have the legal right to restrict the use
of its own code, but it chooses not to exercise that right: the only
restrictions in the GPL are on the redistribution (not use) of GPL'd code.

The FSF does not agree with you, but as they say, it's something only a
court can decide. They have stated their willingness to go to court over
the question. No one so far has taken them up on it.

IMO once you are into using legal technicalities to do something the authors
don't want you to do, you are in violation of the spirit of the free software
community in any case, whatever free s/w license is involved. I think that is
probably enough for most within the community, so long as they understand the
intended rules.

Still, it's useful to know where the property line is. I think what Rainer is
saying is that if Mr Customer has a right to do something personally, then
(at least separately) selling a tool that makes the exercise of that right
more convenient is probably legal. IOW AFAIK the GPL permits you to do pretty
much anything you like on your home computer (and you don't have to disassemble even ;-)
So if you sell a tool that does any of the permitted things, how can that be restricted?
Especially if you don't even ship an "aggregation," but just reference the GPL'd software?

I.e., suppose I worked up some kind of adaptation kit that made it possible to run gcc/g++
under the MSVC IDE, and sold it as a proprietary migration tool for people who want to
experiment with both at home. I don't know if MS has terms that forbid that, but I
think if they did, it would be like GM or Ford putting legalese into the sales to
prevent you from putting a chrysler engine in your GM/Ford car. And preventing the selling of
the adaptation kit would be like preventing the sale of special engine mounts and
engine-swapping instruction in a kit. Could Chrysler(FSF) legally prevent anyone from
selling an adaptation kit aimed at using a legally acquired instance of their engine(gcc)?
In the real physical-object world, that sort of stuff would never fly. But software seems
to work differently.

Re GPL, misunderstandings are possible, so I think if anyone releases an important
piece of work under GPL intending an extra strict or extra permissive interpretation,
there ought to be some way to express that (of course you can always write your own license).
But I can see an argument for not allowing it to be called GPL. Maybe GPLX, meaning GPL-like,
but you better read the extra conditions? Maybe there already are enough licenses that
one ought to be able to choose a flavor.

Speaking of which, I think it would be nice if one could just publish a notice
containing an URL and md5 for a licence and have that be as legally binding as
incorporating the whole boilerplate. (I find it annoying to have to scroll through
three pages of cut/paste license stuff every time I open a file, just to get
to half a page of code ;-)

Regards,
Bengt Richter

[Daniel Berlin]

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

Paul Rubin wrote:

bo**@oz.net (Bengt Richter) writes:

The question ISTM is whether importing a GPL'd module is enough to
trigger GPL obligations on the part of the importing module.
That is a correct statement of the question. According to the FSF,
the answer to the question is yes, that's enough to trigger the
obligations.

Either you are misinterpreting the FSF, or the FSF is wrong.

Sigh.
Can't we simply leave legal questions to lawyers and judges?
The FSF is entitled to their view, and one could argue it and expect
some chance of success. One could argue the other way, and expect some
chance of success. This is because there simply is no settled law,
precedent, etc, on the subject. So saying they are wrong makes you
wrong, because they are correct in stating that it would have to be
decided by a judge.
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.
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.

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).
Whether the code
may be linked to GPL code at runtime or not is irrelevant.

This may or may not be true.
Stating your opinion as fact is not helping.
--Dan

[Patrick Maupin]

Paul Rubin wrote:

"Rainer Deyke" <ra*****@eldwood.com> writes:

Either you are misinterpreting the FSF, or the FSF is wrong. The
FSF has no legal right to restrict the distribution of any software
unless that software contains code which is copyrighted by the FSF.
Whether the code may be linked to GPL code at runtime or not is
irrelevant. The FSF does have the legal right to restrict the use
of its own code, but it chooses not to exercise that right: the only
restrictions in the GPL are on the redistribution (not use) of GPL'd code.
The FSF does not agree with you, but as they say, it's something only a
court can decide.

Well, the FSF certainly _acts_ like they disagree with Rainer.

Stallman himself has written that a program which dynamically links
with readline violates the GPL even if distributed without readline.
(But as others have noted elsewhere, since purely functional API
behavior cannot be copyrighted, this seems to put the FSF in the
interesting position of saying that if the only implementation of
a particular API is provided by GPLed software, then software which
uses it must also be GPLed, but that this is not a necessity if at
least one other library implements the same API.)

Eben Moglen tries very hard to toe this particular party line as well,
but being a lawyer he tries to do so in a manner which doesn't tell
any explicit lies. For example, in a Slashdot interview he writes:

"The language or programming paradigm in use doesn't determine
the rules of compliance, nor does whether the GPL'd code has been
modified. The situation is no different than the one where your code
depends on static or dynamic linking of a GPL'd library, say GNU
readline. Your code, in order to operate, must be combined with
the GPL'd code, forming a new combined work, which under GPL
section 2(b) must be distributed under the terms of the GPL and
only the GPL. If the author of the other code had chosen to
release his JAR under the Lesser GPL, your contribution to the
combined work could be released under any license of your choosing,
but by releasing under GPL he or she chose to invoke the principle
of "share and share alike."

A casual reading of this certainly supports the idea that it is
impermissible to write code which uses readline without releasing
that code under a GPL-compatible license, but a closer reading
may lead to a different conclusion.

Moglen admits that the combination of "your code" with GPLed code
is "a new combined work" (implicitly acknowledging that "your code"
is a separate work with no GPLed code in it and thus is not covered
by the GPL until it becomes part of the "new combined work").

He (deliberately IMO) fails to address what happens when the author
of "your code" _declines_ to distribute this "new combined work",
and the rest of the paragraph assumes and reinforces the idea that
OF COURSE the "new combined work" will be distributed intact.

Obfuscatory tactics such as writing "in order to operate, must"
instead of "will not be as functional unless" are there to keep
the reader from noticing that "your code" has transmogrified into
"your contribution to the combined work", and then, to drive
his point home without resorting to any concrete statements which
could be proven false, Moglen concludes with the legally meaningless
but morally high-sounding principle of "share and share alike".

The FSF's goals of wanting to coerce _authors_ into releasing new
code under the GPL, and simultaneously wanting _users_ to enjoy
"maximum freedom" have led them into a conundrum in this instance.
Since an author is also a user, as long as he is not actually
distributing the GPLed software, e.g. readline, he is free to
_study_ the software on his system, and he is even free to combine
it with his own software (modify it) for his own use as long as he
follows sections 2a and 2c of the license (which are not at all
restrictive). So it would appear that the FSF has no real legal
ability under the GPL to keep someone from writing and distributing
a package which uses readline, as long as that person does not
simultaneously distribute readline itself.

IMO, disallowing a developer from distributing readline along with
his non-GPLed program which uses readline is perfectly reasonable
and provides gentle guidance to developers that it is much easier
to GPL their programs than to force their users to go out and
download all the parts themselves, but the specious posturing of
trying to claim that any program which could be used in conjunction
with readline must be released under the GPL (see Aladdin Ghostscript)
is not really all that astute.
They have stated their willingness to go to court over
the question. No one so far has taken them up on it.

So far it hasn't been worth it for anybody. There are several
reasons for this, such as the "OS exception" in the GPL, and
the willingness of the FSF in some specific cases to negotiate
special licenses. Basically, for it to be worth it to a company,
they would have to be in all of:

set "a" -- companies completely dependent on the GPLed
software in question (otherwise why waste
time and money litigating the issue?)
set "b" -- companies big enough to contemplate taking
on the direct financial burden of a court
battle with the FSF
set "c" -- companies which won't be damaged by the bad
publicity (or which don't care about the damage)

I respectfully submit that the statement "No one so far has taken
them up on it" can be easily explained by the fact that the number
of companies in the intersection of sets "a", "b", and "c" is
vanishingly small...

Pat

[Ville Vainio]

pm*****@speakeasy.net (Patrick Maupin) writes:

restrictive). So it would appear that the FSF has no real legal
ability under the GPL to keep someone from writing and distributing
a package which uses readline, as long as that person does not
simultaneously distribute readline itself.

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

--
Ville Vainio http://www.students.tut.fi/~vainio24

[kk]

kk wrote:

Paul Rubin wrote:

Tim Churches <tc***@optushome.com.au> writes:

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

It's not enough for B and C to be under "GPL-compatible licenses".
They have to be under the actual GPL.

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

You have a GPL'ed program that I'd like to link with my code to build
a proprietary program. Does the fact that I link with your program
mean I have to GPL my program?

Yes.

AFAIK, ur python program, which is interpreted, is considered data in
view of the program interpreter. So the GPL license is not needed.
Correct me if I am wrong.

http://www.gnu.org/licenses/gpl-faq....terpreterIsGPL

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.

[John Hunter]

>>>>> "Ville" == Ville Vainio <vi********************@spamtut.fi> writes:

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

Yes (re GPL), if you want to place the additional burden on users to
release their derived works under GPL. Ie, if you beliwve all
software should be GPL, and want to coerce others into releasing their
software as GPL, then GPL is a good license for you.

If you want to release your software with a more permissive license,
so that, for example, others can extend it and sell it in closed
source form, then GPL is a bad choice. I prefer a PSF / BSD / MIT
license that mostly lets others use the code however they see fit. If
users in the business world want to use your code in a proprietary
product, you the developer will probably (but not necessarily) see the
benefits of contributed code, bug fixes, bug reports, extensions and
perhaps consulting fees.

John Hunter

[Ville Vainio]

John Hunter <jd******@ace.bsd.uchicago.edu> writes:

>> "Ville" == Ville Vainio <vi********************@spamtut.fi> writes:

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

Yes (re GPL), if you want to place the additional burden on users to
release their derived works under GPL. Ie, if you beliwve all

But if the software is distributed w/o libraries, and the user has to
d/l the libs themselves, then the code is not covered by GPL. So a
library under GPL would effectively be a library under LGPL, with the
difference that the end user has to do some extra legwork to start
using the program. This simple loophole makes the GLP look like it was
never intended for libraries (except static libs).

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Patrick Maupin]

Daniel Berlin wrote

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

Either you are misinterpreting the FSF, or the FSF is wrong.
Sigh.
Can't we simply leave legal questions to lawyers and judges?

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.
The FSF is entitled to their view, and one could argue it and expect
some chance of success.
Yes, where "some chance" is an extremely small number.
One could argue the other way, and expect some chance of sucess.
This is because there simply is no settled law, precedent, etc,
on the subject.
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.

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,
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.
So saying they are wrong makes you wrong, because they are correct
in stating that it would have to be decided by a judge.
Judges and lawyers are so expensive that, instead of hiring
a full set of them to decide a particular issue, people and
companies routinely look at similar situations which have come
up before, and examine the outcome of those situations before
a judge, and then decide to modify their behavior (or not) based on
that outcome. If one did that on this issue, one could reasonably
come to the conclusion that ON THIS ISSUE the FSF is wrong,
and then another could unreasonably come to the conclusion
that the one is wrong, because nothing is ever settled until
it is brought before a judge (as if judges are never wrong and
never overturned).

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

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

I didn't even take copyright law, and I'm sure that either a) you are
deliberately being unreasonably pedantic, 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, 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.
In addition, DMCA grants them the right to prevent distribution of
certain other types of code (code that circumvents effective access
controls).
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.)

Whether the code may be linked to GPL code at runtime
or not is irrelevant.

This may or may not be true.
Stating your opinion as fact is not helping.

Yes, I find your deliberate misunderstanding of the OP _so_ much
more helpful. Throwing in that DMCA red herring was a nice touch
as well.

Pat

[Bengt Richter]

On Sat, 22 Nov 2003 23:40:09 -0500, Daniel Berlin <db*****@dberlin.org> wrote:

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]

Tim Churches wrote:

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]

On Nov 23, 2003, at 11:04 AM, Patrick Maupin wrote:

Daniel Berlin wrote

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

Either you are misinterpreting the FSF, or the FSF is wrong.
Sigh.
Can't we simply leave legal questions to lawyers and judges?

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.

The FSF is entitled to their view, and one could argue it and expect
some chance of success.

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

One could argue the other way, and expect some chance of sucess.
This is because there simply is no settled law, precedent, etc,
on the subject.

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.

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

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.

Whether the code may be linked to GPL code at runtime
or not is irrelevant.

This may or may not be true.
Stating your opinion as fact is not helping.

Yes, I find your deliberate misunderstanding of the OP _so_ much
more helpful. Throwing in that DMCA red herring was a nice touch
as well.

Pat
--
http://mail.python.org/mailman/listinfo/python-list

[Tim Churches]

On Sun, 2003-11-23 at 22:48, kk wrote:

http://www.gnu.org/licenses/gpl-faq....terpreterIsGPL
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]

Ville Vainio <vi********************@spamtut.fi> writes:

pm*****@speakeasy.net (Patrick Maupin) writes:

restrictive). So it would appear that the FSF has no real legal
ability under the GPL to keep someone from writing and distributing
a package which uses readline, as long as that person does not
simultaneously distribute readline itself.

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]

Alexander Schmolck wrote:

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]

pm*****@speakeasy.net (Patrick Maupin) wrote in message news:<65**************************@posting.google. com>...

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]

On 24 Nov 2003 03:20:59 -0800, Paul Boddie wrote:

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.

--
\ "I bought some powdered water, but I don't know what to add." |
`\ -- Steven Wright |
_o__) |
Ben Finney <http://bignose.squidly.org/>

[Andreas Kostyrka]

pm*****@speakeasy.net (Patrick Maupin) wrote in message news:<65**************************@posting.google. com>...

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]

Andreas Kostyrka wrote:

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.p...r-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]

On Mon, 2003-11-24 at 22:20, Paul Boddie wrote:

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+0bQ12a36D1FY2F3MNsx0zAQ8xg CgiKzI
NwD3QXYpEEftiVPO6qzRWzo=
=8Jqi
-----END PGP SIGNATURE-----

[Ville Vainio]

Tim Churches <tc***@optushome.com.au> writes:

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

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Paul Rubin]

Tim Churches <tc***@optushome.com.au> writes:

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]

KefX <ke**********@aol.comNOSPAM> pisze:

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.

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.

--
Jarek Zgoda
Unregistered Linux User #-1
http://www.zgoda.biz/ JID:zg***@chrome.pl http://zgoda.jogger.pl/

[Paul Boddie]

Jarek Zgoda <jz****@gazeta.usun.pl> wrote in message news:<bq**********@atlantis.news.tpi.pl>...

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]

Paul Boddie <pa**@boddie.net> pisze:

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

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

--
Jarek Zgoda
Unregistered Linux User #-1
http://www.zgoda.biz/ JID:zg***@chrome.pl http://zgoda.jogger.pl/