Use of GPLed Python extension modules

T

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
 
P

Paul Rubin

Tim Churches said:
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.
 
K

kk

Paul said:
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.
 
J

Jp Calderone

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
 
R

Robert Kern

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.html#TOCGPLModuleLicense

"""
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
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
 
P

Paul Rubin

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.html#TOCGPLModuleLicense

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

Tim Churches

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.html#MereAggregation )

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

Bengt Richter

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
 
P

Paul Rubin

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

Rainer Deyke

Paul said:
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.
 
P

Paul Rubin

Rainer Deyke said:
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.
 
R

Robert Kern

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/foundation-list/2001-December/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
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
 
B

Bengt Richter

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
 
D

Daniel Berlin

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
 
P

Patrick Maupin

Paul said:
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
 
V

Ville Vainio

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

kk

kk said:
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.html#IfInterpreterIsGPL

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

John Hunter

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
 
V

Ville Vainio

John Hunter said:
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).
 
P

Patrick Maupin

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

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top