Protect Python Source
hope
If i am to develop a full fledge commercial application using Python :
a. Can i compile my python source into binary ? I have read about py2exe for
windows. Is there one for Linux ?
b. Can I distribute the bytecode only (.pyo, .pyd) and not the source (.py)
? Can the bytecode be 'de-compiled' to source ?
Please advice.
Cheers,
Peter
Alex Martelli
> Hi,
>
> If i am to develop a full fledge commercial application using Python :
>
> a. Can i compile my python source into binary ? I have read about py2exe
> for windows. Is there one for Linux ?
Yes, you can use McMillan's "installer" for both Windows and Linux, see:
http://www.mcmillan-inc.com/install1.html
> b. Can I distribute the bytecode only (.pyo, .pyd) and not the source
Yes, except that .pyd is not an extension used for bytecode but rather
for dynamically lodaed libraries used as Python extensions on Windows
(you may be thinking of .pyc, which IS the extension used for bytecode
that is not optimized, while .pyo indicates bytecode that IS optimized).
> (.py) ? Can the bytecode be 'de-compiled' to source ?
Of course! It's even easier than "dis-assembling" machine code back
into readable symbolic assembly languages, which is something that
'crackers' do for fun -- visit any 'warez' site to see how abundant
are the `cracks` available for all sorts of machine-coded commercial
programs.
Module dis in the Python standard library lets you disassemble
bytecode back to readable form. Recovering actual Python sources
is harder (just as it is if, say, you code in C, to recover actual
C sources rather than disassembled machine code) -- have a look
at decompyle, which you can find with Google, but it's not in
"production" state nor, I think usable with the latest releases
of Python.
> Please advice.
It is conceptually impossible to stop a halfway-competent 'cracker'
from disassembling any compiled form of your program if they have
any interest at all in it (or even if they don't: they DO do it just
for fun even for programs they have no earthly use for), as long as
you distribute your program in a fully executable form for general
purpose computers. If the GP computer can get at your program, as
it must to be able to execute it, so can the cracker. In some cases
you may be able to achieve a measure of protection if your program
can only execute when connected to some Internet site: in that kind
of scenario, you may be able to check that connections only come
from validly registered sites. But in general, you should rely on
the law to protect your programs against unauthorized use, not on
illusory "protection". "Security through obscurity isn't".
Alex
Gerson Kurz
wrote:
>But in general, you should rely on
>the law to protect your programs against unauthorized use, not on
>illusory "protection". "Security through obscurity isn't".
Lets imagine this: you are a small company of specialists that writes
some python module. You are in direct company with a big, possibly
very big company. They do not have any experts in your area (they are
a big company, so they do lots of stuff besides the area you are in).
So, they just take your code, because its readily available - the
source is right there in the installed directory. Chances are that
you, the small company, will never live long enough to see the end of
a lawsuit. Plus, lawsuits can be very *very* expensive. Plus, if
you're a big company, chances are your lawyers are just more and
better than mine. Plus, the best thing you can expect to come out from
a lawsuit against a big company is - an agreement. Does the term
Microsoft anti-monopoly lawsuit ring a bell?
So, poof goes the fine license.
I'm not assuming that code cannot be "cracked" - I'm just thinking
that making it *that* easy doesn't exactly help.
As for a solution, I've toyed around with a import hook that reads
data from encrypted files some time ago, but haven't followed up on it
lately. Encrypted files are enough to stop "casual" cracking - which
is sufficient for the above mentioned goal.
Christian Tismer
In addition to Alex' reply with which I totally agree:
Using the Installer gives you the advantage that
no source code can be seen and even no bytecode
is visible in the first place. It is of course ungzipped
from the executable at execution time, but there are
no visible files, it is in memory, only.
That means, the average user will not be able to read
your source, and the bytecode is not so easy to access.
This doesn't provide safety against true hackers, but
this doesn't exist by definition.
There is one way to do some more obfuscation of the
bytecode which comes for quite cheap and raises the
fence for disasseblers a little:
You can easily create a Python interpreter with permuted
opcodes. You can even use a different interpreter for
every customer. There are lots of variations of this
principle. But it isn't really strong, since the opcodes
can be guessed by a statistical approach, or disassembling
the interpreter.
The problem is that it doesn't take long
until somebody publishes a tool to disassemble it
again, and then those kiddies who think they are
hackers just because they know to use a tool come
into the play.
Some promising idea which I didn't try yet is to combine
the opcode permutation idea with redundancy: Create
many versions of the same functions, which slightly
changed behavior and slightly different opcodes.
Make a huge code bloat out of this, with just a small
percentage of "real" code. The idea is to confuse
the hacker by myriads of similar, slightly different
objects, and by a reasonable total size of the code
that might make him give up earlier.
Yet another way of obfuscation would be to use compilers
like Psyco, and store the compiled code instead of the
.pyc data. This would make the disassembly reasonably
harder. AFAIK, Psyco isn't ready yet to produce
executables, but I guess this will be an option pretty
soon.
but-open-source-is-so-much-more-fun - ciao - chris
--
Christian Tismer :^) <mailto:tis...@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
TuxTrax
Steve Ballmers hair grease:
Hello Peter.
You ask good questions here, and give me an opportunity to present to you
some ideas you may not have yet considered.
First to answer your questions:
As you probably know, python is an interpreted language that does not lend
itself well to compiling. When you use the traditional compiler, you
convert to binary and link to executable, your source code. Think of it
this way: The interpreter is a compiled program that runs your code. In order
for your code to run, the interpreter has to be present. Py2exe therefore has
to compile your program, all it's modules, *and* the interpreter into one
package. I don't know from experience, but have read, that this process can
present difficulties and may not work with all programs. Others who have
real experience can no doubt tell you more on this count. As for whether
or not this type of pseudo-compiler is avaialable for Linux, I am going to
address that question in a bit.
Can you distribute the bytecode and not the source? My friend, you can
distribute it any old way you want. More on this to come. Can bytecode be
decompiled? Anything can be decompiled. You should know that compiling is
not the security that many believe it to be. Just because a program is
compiled does not mean it is safe from prying eyes. It is trivial to obtain
decompiling software for traditionally compiled languages.
I want you to read and consider what I am about to write, and I don't want
you to feel that I am in any way attacking you. I'm not. But I feel a few
well placed observations are in order.
Your comments reveal a thoughtful and curious approach that is quite healthy.
It also reveals a world view that has in large part been shaped by the
philosophies of proprietary software companies.
Is a python compiler available for linux? I don't know. I do know that no
Linux users I know would even consider using one. It would never cross our
minds to make our source closed to others. This is where the whole open source
software movement takes a completely different world view. In open source
software, you retain the right to make a profit from your work, while still
granting others the right to copy, distribute, modify and view the source
code. Just a year ago, this whole concept was horrifying to me. I could
not concieve of allowing others to have free access to my source code. As
a Long time windows user, I had some un-learning to do. But unlearn I did.
I started thinking in terms of the advantages of open source. First, it keeps
you honest; you write your best code because you know that your peers are
going to be seeing it all over the world. Second, with open source, once
you release it, other programmers may modify it helping it to become more
than you ever could have made it on your own (unless you choose to forbid
the modification of your code, but that's another subject). Third, the
distribution of your product using the open source community, has no equal,
and will cost you nothing. You can provide support to your users via
that same community at little or no cost to you, and support is the number
one ongoing cost that software developers get saddled with. You can use
the resources of such organizations as the free software foundation to
defend your copyright (don't let the "free" in FSF throw you; you can still
market your product using the GPL licence).
And finally, you get to give something back. This is a philosophical point
for me, but giving something back to the community that you benefit from,
whether it be your local community, or the computer community, is very
important for us as people. It is a common and refreshing view that you
will find in the open source world, and one reason that I left the
windows world for good. But thats a soapbox for another time. <grin>
Cheers,
Mathew
--
My Family is Microsoft Free. Running Mandrake Linux 8.0 kernel 2.4.3-20
I use quality open source software alternatives on my PC.
Yes, I am a Penguin cult high priest. Flipper readings upon request.
ROT13 this email address to mail me:
bar jbeq abg guerr - uvtu qrfreg zna, ng lnubb qbg pbz
David Brown
"TuxTrax" <Tux...@fortress.tuxnet.net> wrote in message
I think you are making the mistake many "born again" open-source advocates
make, and one that many anti-open-source people also make. There is plenty
of place in the world for both open and closed source software. In some
situations, one is far better than the other, in some cases either will do
the job. Saying that everything should be open source is as bad as saying
everything should be closed source. It's a common misunderstanding about
Linux ("Software companies should not write for Linux because then they
would have to give away all their source code...").
Consider, for example, the program I am writing at the moment. It is in
Python - a language whose licence is very clear in stating that all
Python-licenced code can be used in open and closed source software (keeping
copyright messages intact). The program provides a gui for an embedded
motor controller card, and our customer is paying good money for me to write
the program. He intends to sell the cards on to his customers, with this
controller program to go with it. In the future, he will want a bigger
version of the program (supporting several cards simultaneously). He may
well want to charge his customers for that software upgrade. He certainly
won't want his customers to have full access to the code - they may modify
it for use with other supplier's motor cards. This is not a program for
which either myself or my customer will gain any benifits from releasing it
as open source - no one is going to be making improvements to it that will
benifit us. However, there are certainly *parts* of the program that could
be released seperately. For example, I may seperate out the graphing parts
of the gui into a nice, modular graph widget. That could easily be released
as open source (Python licence), for the benifit of others and for our own
benifit - if people like it, they will contribute improvements which I can
then use. If I make any changes or improvements to the pyserial module that
I am using, then I certainly will pass those changes back to the community.
But by the time I get as far as making distribution copies of the program,
I'll be making two sorts of packages - py2exe packages for easy installation
on Windows machines, and .pyc byte-code files for use on Linux (and for
Windows users who already have Python).
I fully agree that there are often direct benifits from making your own
software open source. There is also the personal satisfaction factor - I
have not written much that could be of direct benifit to others (my job is
embedded systems development - you need our company's hardware to run our
software), but I have enjoyed the feeling I get from the few direct
contributions I have made. But there are many reasons to write closed
source code as well. You do not speak for the Linux-using community when
you say that writing closed source is against your principles. From a
user's viewpoint, open source is definitely an advantage - just like lower
cost, better documentation or more functionality is an advantage. But from
the writer or sellers viewpoint, it is a mixed blessing which must be
considered sensibly - just like the selling price, the level of
documentation and the functionality of the software. The aim of all
businesses is to make money - preferably by providing good products and
services to their customers. If that end can be best achieved by openning
their software, great. If it is best achieved by closing their software,
then that's the way it is.
Armin Steinhoff
> Hi,
>
> If i am to develop a full fledge commercial application using Python :
>
> a. Can i compile my python source into binary ? I have read about py2exe for
> windows. Is there one for Linux ?
Not for Linux.
>
> b. Can I distribute the bytecode only (.pyo, .pyd) and not the source (.py)
> ? Can the bytecode be 'de-compiled' to source ?
Yes it can be de-compiled ... but you can use Pyrex in order to build
C modules out of your critical code modules.
So it's then a little bit harder to de-compile these modules ....
Cheers
Armin
>
> Please advice.
>
> Cheers,
> Peter
dsavitsk
news:3mrw9.71925$TD1.3...@news2.tin.it...
> hope wrote:
> > a. Can i compile my python source into binary ?
>
>
>
> > (.py) ? Can the bytecode be 'de-compiled' to source ?
>
> Of course!
> > Please advice.
>
> It is conceptually impossible to stop a halfway-competent 'cracker'
> from disassembling any compiled form of your program
This discussion seems to go on every few days/weeks and turns on whether
source is safer due to licensing or due to hiding (and the possible failures
of both methods). While I am not technically competent to do so, I wonder
if the merits of both sides might be boiled down into a point-counterpoint
FAQ that could be posted? Jus a thought.
-d
Lothar Scholz
> Lets imagine this: you are a small company of specialists that writes
> some python module. You are in direct company with a big, possibly
> very big company. They do not have any experts in your area (they are
> a big company, so they do lots of stuff besides the area you are in).
> So, they just take your code, because its readily available - the
> source is right there in the installed directory. Chances are that
I don't think they will do this. I never heard about anything like this before.
> you, the small company, will never live long enough to see the end of
> a lawsuit. Plus, lawsuits can be very *very* expensive. Plus, if
> you're a big company, chances are your lawyers are just more and
> better than mine. Plus, the best thing you can expect to come out from
> a lawsuit against a big company is - an agreement. Does the term
> Microsoft anti-monopoly lawsuit ring a bell?
Yes but this only means that the US american law system sucks.
Lemniscate
> Using the Installer gives you the advantage that
> no source code can be seen and even no bytecode
> is visible in the first place. It is of course ungzipped
> from the executable at execution time, but there are
> no visible files, it is in memory, only.
Actually, this isn't quite true. If you open the exe generated by the
Installer with a text editing program (even NotePad works), your code
is visible in the code (just do a search for you imports or a def
statement and you'll find it. Usually, I find it in either the dead
center of the file, or towards the end of the file. In fact, if you
cut and paste, you will have your code back (I've actually done this
before when my wife deleted some of my source back-ups, and it works
perfectly). Just another warning, putting code out there that you
think is secure because it looks obscure is NEVER a good choice.
For some interesting reading (and some nice laughs along the way),
check out: http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&q=obfuscation&meta=group%3Dcomp.lang.python.*
Have fun,
Lem
Bengt Richter
>
>It is conceptually impossible to stop a halfway-competent 'cracker'
>from disassembling any compiled form of your program if they have
>any interest at all in it (or even if they don't: they DO do it just
>for fun even for programs they have no earthly use for), as long as
>you distribute your program in a fully executable form for general
>purpose computers. If the GP computer can get at your program, as
>it must to be able to execute it, so can the cracker. In some cases
>you may be able to achieve a measure of protection if your program
>can only execute when connected to some Internet site: in that kind
>of scenario, you may be able to check that connections only come
>from validly registered sites. But in general, you should rely on
>the law to protect your programs against unauthorized use, not on
>illusory "protection". "Security through obscurity isn't".
I am afraid that the "GP computer" will soon have right in the CPU chip
the microcoded ability to input a byte stream from memory that is
digitally signed and encrypted with the CPU's public key, and
decrypt it into an on-chip cache memory that never gets written to
RAM (or if it does, through an xor prng encryption mask), and execute it.
I think they're moving the concept of a computer receiving trusted code
securely over an insecure network to a concept where the CPU chip
looks at the motherboard as part of the insecure network.
It's not a big conceptual leap. The details are just a bunch of engineering.
(However, no doubt this simple conceptual move from computer to CPU chip
will be loaded with patents on obvious ideas that have been in place in
bigger contexts for ages).
I think you can resign yourself to the idea that it will eventually
become as hard to decrypt a private message to a CPU as it is to do
the same to a PGP-encrypted email message to you. The message will
only be opened on-chip, using the chip's private key. It'll execute
as written or it won't execute at all. Either way only the CPU will see it.
Obviously you have to build stuff into an OS to make use of this stuff,
and no doubt it will start with the BIOS below that.
There will be a lot of opportunities to form exclusive clubs of hardware
and software vendors. Even if the technology itself is as open and royalty-free
as PGP, so that Linux/BSD/etc can also use it for bullet-proofing, it could mean
that the latter will not be able to interoperate except when others choose,
unless non-exclusion is guaranteed by laws with really big teeth.
The technology is neutral, but the temptations it affords are not.
Oh well, I guess it's all part of economic evolution, moving from
selling atoms to selling bits to selling permission ;-/
Regards,
Bengt Richter
hotjava
The intention of my post is not to start a 'comparison war' between open
source and close source.
I agree with David Brown with his reply that each has its own merits.
Let us not hog up the mailing list with 'which is better' as this will be a
very long discussion.
I think I have found what I wanted from Armin Steinhoff's reply. His
suggestion is to use pyrex to translate my 'critical' python source to C
and build it as a library module. But I do not know why he did not suggest
me to use pyrex to translate my full python source to C. Nevertheless, this
idea seems workable.
Now I will have to decide to have:
a. fully closed apps
b. fully open apps
c. partial open and closed source apps
Looks like c. is the best.
thanks.
TuxTrax
Indeed this is true. Did I leave you with the impression that I was
saying
anything against closed source? The fact is I happen to agree with
you, but
shamelessly took an oppotunity to pitch the case for open source since
the OP seemed not to have considered it.
> In some situations, one is far better than the other
OK.
> in some cases either will do
> the job. Saying that everything should be open source is as bad as saying
> everything should be closed source. It's a common misunderstanding about
> Linux ("Software companies should not write for Linux because then they
> would have to give away all their source code...").
And it is a common misconception (perpetuated by some proprietary
software houses) that open_source == zero_profit. The fact is, open
sourcing the program will not negatively impact the profitablility of
the product. This flies in the face of conventional wisdom, but such
companies as red hat have proven the business model.
At any rate, I don't believe I said everything should be open source.
I did not intend to imply it.
> Consider, for example, the program I am writing at the moment. It is in
> Python - a language whose licence is very clear in stating that all
> Python-licenced code can be used in open and closed source software (keeping
> copyright messages intact). The program provides a gui for an embedded
> motor controller card, and our customer is paying good money for me to write
> the program. He intends to sell the cards on to his customers, with this
> controller program to go with it. In the future, he will want a bigger
> version of the program (supporting several cards simultaneously). He may
> well want to charge his customers for that software upgrade. He certainly
> won't want his customers to have full access to the code - they may modify
> it for use with other supplier's motor cards.
fine. Then make a license agreement that forbids the modification of
the code for use with other brands of motor control equipment. That
has nothing to do with open sourcing it. When you open source your
code, you provide greater value to your customers, because you give
them the power to meet future needs as they expand, by applying the
same codebase to new hardware/software platforms. They can also see
and verify that the code is not filled with bugs/backdoors.
> This is not a program for
> which either myself or my customer will gain any benifits from releasing it
> as open source - no one is going to be making improvements to it that will
> benifit us.
see above
Thank you for your thoughts. The OP was asking about securing code and
I wanted to impress two things:
1) you can't secure your code
2) open source is not a bad thing, it is, in fact, a very good option.
cheers,
Mathew
TuxTrax
Steve Ballmers hair grease:
> On Fri, 01 Nov 2002 08:57:35 GMT, Alex Martelli <al...@aleax.it> wrote:
I'll take an order of Palladium with a side of tyrrany.
http://www.epic.org/privacy/consumer/microsoft/palladium.html
Christian Tismer
> Christian Tismer <tis...@tismer.com> wrote in message news:<mailman.1036145342...@python.org>...
>
>>Using the Installer gives you the advantage that
>>no source code can be seen and even no bytecode
>>is visible in the first place. It is of course ungzipped
>>from the executable at execution time, but there are
>>no visible files, it is in memory, only.
>
>
> Actually, this isn't quite true. If you open the exe generated by the
> Installer with a text editing program (even NotePad works), your code
> is visible in the code (just do a search for you imports or a def
> statement and you'll find it.
Only if you turned off the compression.
I just ran my 3.5 mb generated .exe through
a cygwin strings command, and nothing readable
was a little stuff from the installer and
from the zlib.
Did you add your scripts and modules using plain
PYSOURCE or PYMODULE types?
They should of course all end up in a PYZ type
that makes them unreadable by compression.
> Usually, I find it in either the dead
> center of the file, or towards the end of the file. In fact, if you
> cut and paste, you will have your code back (I've actually done this
> before when my wife deleted some of my source back-ups, and it works
> perfectly).
This still works with my .exe as well, given that I add the
sources by hand, too. Usually, only the real scripts are
in source form, al other stuff is in modules, which are
added as .pyc files. So I really wonder how you used
the installer ???
> For some interesting reading (and some nice laughs along the way),
> check out: http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&q=obfuscation&meta=group%3Dcomp.lang.python.*
That's really funny!
Great idea, to just generate Perl :-)
ciao - chrid
Ira Baxter
You build using "clear-text" source code, then
offer obfuscated source code to your users?
Advantages: easy.
Disadvantages: Reverse engineering is possible.
(But then, that's true of any solution. We're arguing
about the amount of effort to do it).
We can build obfuscators for essentially any language.
Haven't done it yet for Python, but we already
have a Python parser, which is most of the battle.
See http://www.semdesigns.com/Products/Formatters/ObfuscatorExample.html
for an example.
--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com
"hotjava" <hot...@pacific.net.sg> wrote in message
news:mailman.103620258...@python.org...
David Brown
"TuxTrax" <bogu...@myself.com> wrote in message
news:30770aa4.02110...@posting.google.com...
Your comments *did* leave me with the impression that you were advocating
writing open-source software to the complete exclusion of closed-source. It
was the "I do know that no Linux users I know would even consider using one.
It would never cross our minds to make our source closed to others" that did
it. If you were just exagerating the one case to counter arguements in
favour of the other, then I guess that's fair enough. But it certainly
looked like fanatisism to me, and that's never good for your cause.
> > In some situations, one is far better than the other
>
> OK.
>
> > in some cases either will do
> > the job. Saying that everything should be open source is as bad as
saying
> > everything should be closed source. It's a common misunderstanding
about
> > Linux ("Software companies should not write for Linux because then they
> > would have to give away all their source code...").
>
> And it is a common misconception (perpetuated by some proprietary
> software houses) that open_source == zero_profit. The fact is, open
> sourcing the program will not negatively impact the profitablility of
> the product. This flies in the face of conventional wisdom, but such
> companies as red hat have proven the business model.
>
True.
> At any rate, I don't believe I said everything should be open source.
> I did not intend to imply it.
>
Again, I think you did imply it (hence my first posting), but it looks like
we have actually have a pretty similar view on open- and closed- source
development.
> > Consider, for example, the program I am writing at the moment. It is in
> > Python - a language whose licence is very clear in stating that all
> > Python-licenced code can be used in open and closed source software
(keeping
> > copyright messages intact). The program provides a gui for an embedded
> > motor controller card, and our customer is paying good money for me to
write
> > the program. He intends to sell the cards on to his customers, with
this
> > controller program to go with it. In the future, he will want a bigger
> > version of the program (supporting several cards simultaneously). He
may
> > well want to charge his customers for that software upgrade. He
certainly
> > won't want his customers to have full access to the code - they may
modify
> > it for use with other supplier's motor cards.
>
> fine. Then make a license agreement that forbids the modification of
> the code for use with other brands of motor control equipment. That
> has nothing to do with open sourcing it. When you open source your
> code, you provide greater value to your customers, because you give
> them the power to meet future needs as they expand, by applying the
> same codebase to new hardware/software platforms. They can also see
> and verify that the code is not filled with bugs/backdoors.
>
Open source gives more to the customer, that is without question. But it is
not necessarily in the supplier's interests to give them more. In a great
many such cases, there is no real advantage to the customer to have the
source code. They want us to write the stuff for them - that's what they
pay us for. Depending on the exact contract, they may also pay for the
source code - not so that they can work with it themselves, but as a
protection in case of problems (such as our company going bankrupt, or
otherwise being unable to continue work on the project). They know the
software has no (intentional) backdoors, and is as bug-free as we can make
it - again, that's what we're paid for. If they did not trust us to do the
job, the customer would go elsewhere (that's part of the benifits of a
competitive world - compare it to closed source software with monopoly
power).
Even though a licence agreement might be as good as closed-source at
stopping abuse of the source code (these sorts of customers are responsible
people - they are not going to knowingly break agreements), there are two
problems with that. Licences that are open-source, yet restrictive about
use, are in a no man's land, and would lead to all sorts of complications.
The biggest problem, though, is how to deal with a customer who has fiddled
with the code. Imagine the joys of supporting code when the user has
"customised" the software, and now it doesn't work. For specialised
software, it is far better that we do the modifications - we get paid for
it, and the customer gets the guarentee that it will work. If they could do
as good a job at writing and modifying the software themselves, they
wouldn't have come to us in the first place.
And for yours.
>The OP was asking about securing code and
> I wanted to impress two things:
>
> 1) you can't secure your code
This is true - you can never be entirely secure. You must look at each
case - what is it that you want to protect, from whom, and how far are you
willing to go for the protection? But there are many levels of security.
>
> 2) open source is not a bad thing, it is, in fact, a very good option.
It often is a good option. My point is merely that, while it often is the
best option, there are many cases where it is *not* the best option.
>
> cheers,
>
> Mathew
mvh.
David