By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,168 Members | 1,178 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,168 IT Pros & Developers. It's quick & easy.

Two questions

P: n/a
Hi,

I've developed in several other languages and have recently found
Python and I'm trying to use it in the shape of the PythonCard
application development tool.

My two questions:

1. What is the easiest way to create a for loop in the style I'm used
to from Delphi ie:
for I:=0 to 2 do begin
//code
end;

2. Philospohy(sp?) aside, I could potentially want to create a
binary-only distribution of my finished apps. I noticed the
documentation on .pyc files: how do I create these and, aside from
being basically read-only, are they used just like ordinary .py source
files? And can they be easily reverse-engineered?

Thanks,
- QS Computing.

Jul 19 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a

On 2 Jun 2005 06:45:18 -0700, qs*********@gmail.com said:
Hi,

I've developed in several other languages and have recently found
Python and I'm trying to use it in the shape of the PythonCard
application development tool.

My two questions:

1. What is the easiest way to create a for loop in the style I'm used
to from Delphi ie:
for I:=0 to 2 do begin
//code
end;
for i in range(0, 2):
do stuff

The range([start], stop, [step]) function generates a sequence of
numbers which the the for loop iterates over.

(You can also use xrange() for a more memory efficient solution for very
large ranges).
2. Philospohy(sp?) aside, I could potentially want to create a
binary-only distribution of my finished apps. I noticed the
documentation on .pyc files: how do I create these and, aside from
being basically read-only, are they used just like ordinary .py source
files? And can they be easily reverse-engineered?

To create binary only distributions for Windows you can use py2exe. Its
distributions files can be fairly easily reverse engineered.

Cheers,
Richard
Jul 19 '05 #2

P: n/a
qs*********@gmail.com wrote:
I've developed in several other languages and have recently found
Python and I'm trying to use it in the shape of the PythonCard
application development tool.

My two questions:

1. What is the easiest way to create a for loop in the style I'm used
to from Delphi ie:
for I:=0 to 2 do begin
//code
end;
for i in xrange(0, 3):
# code

Please read the tutorial. I'm fairly sure this and many more things
you'll want to know are covered adequately.
2. Philospohy(sp?) aside, I could potentially want to create a
binary-only distribution of my finished apps. I noticed the
documentation on .pyc files: how do I create these and, aside from
being basically read-only, are they used just like ordinary .py source
files? And can they be easily reverse-engineered?


They are compiled versions of the .py files, so definitely not the same.
They are created automatically and transparently when you import .py
modules, so normally you don't pay any attention to them. They can
easily be reverse-engineered, if by that you mean turned back into
source code. See "decompyle" for example. Using the "compileall"
module you can manually compile .py to .pyc but, again, that's generally
not needed. Use of tools like py2exe is generally advised for packaging
and distibution if you don't want to distribute source, though few of
the existing tools do much more than package up .pyc files inside
archives, bundle the runtime library, and add wrapper code to make the
execution transparent.

Philosophy not entirely aside, you should note that object code in any
language can "easily" be reverse-engineered in the same way, with the
only difference being the degree of ease involved. If the code is worth
enough to someone that they are willing to risk violating your license
terms, they *will* be able to recover enough source code (whether it was
Python, C, or assembly) to do what they need. The only certain
protection is to keep the valuable code on a server and use some kind of
web service (or whatever) to control access to its execution. (There
have been *many* past discussions of all this in the forum -- it's a
very tired topic by now -- so please feel free to peruse the archives
via Google Groups before asking lots of the same questions over again.
You'll be doing yourself a favour.)

-Peter
Jul 19 '05 #3

P: n/a
qs*********@gmail.com wrote:
Hi,

I've developed in several other languages and have recently found
Python and I'm trying to use it in the shape of the PythonCard
application development tool.

My two questions:

1. What is the easiest way to create a for loop in the style I'm used
to from Delphi ie:
for I:=0 to 2 do begin
//code
end;
Um, assuming that this loops through the numbers 0 to 2 and assigns them
to the variable I, and then does something in code with I after it's
been assigned, the python equivalent is:

for I in range(0,3):
//code

(Note the whitespace after opening the for loop?)
And then break the indenting to finish the for loop. So you're next
piece of code (Whatever you had after end;) would go here:

//morecode.
2. Philospohy(sp?) aside, I could potentially want to create a
binary-only distribution of my finished apps. I noticed the
documentation on .pyc files: how do I create these and, aside from
being basically read-only, are they used just like ordinary .py source
files? And can they be easily reverse-engineered?
As long as you have write access to the directory that you're .py files
are in, when you run python, it will generate the .pyc files for you as
they are loaded.
There is also a utility script in the main distribution called
py_compile.py.
E.g. compiling a whole directory of .py files:

python /path/to/main/install/py_compile.py *.py

And to compile them as optimised binary files (.pyo):
python -O /path/to/main/install/py_compile.py *.py

They are used like ordinary .py source files. (Python actually executes
from the .pyc files it builds from your .py files.)
They can be reverse-engineered, but then so can Java/C++/Assembler. Have
a look through the group for something about being able to distribute
your modules.pyc as a zipfile - I remember something about being able to
do a -tiny- bit of extra protection by having them as a passworded zip file.
Thanks,
- QS Computing.


Welcome.

Joal
Jul 19 '05 #4

P: n/a
rbt
Peter Hansen wrote:
Philosophy not entirely aside, you should note that object code in any
language can "easily" be reverse-engineered in the same way, with the
only difference being the degree of ease involved. If the code is worth
enough to someone that they are willing to risk violating your license
terms, they *will* be able to recover enough source code (whether it was
Python, C, or assembly) to do what they need.


Don't intend to hijack this thread, but this bit interests me. I know
several accomplished C/assembly programmers who have told me that
reverse engineering object code from either of these two languages is
anything but trivial. Yet, I *hear* and *read* the opposite all of the
time. Can anyone actually demonstrate a decompile that mirrors the
original source?

Also, I'd venture to say that the number of people in the world who can
consistently reverse engineer object code is almost statistically
insignificant... sure, they are out there, but you'll win the lottery
before you meet one of them and most of them work for big, bad
government agencies ;)

Jul 19 '05 #5

P: n/a
rbt wrote:
Peter Hansen wrote:
Philosophy not entirely aside, you should note that object code in any
language can "easily" be reverse-engineered in the same way, with the
only difference being the degree of ease involved. If the code is
worth enough to someone that they are willing to risk violating your
license terms, they *will* be able to recover enough source code
(whether it was Python, C, or assembly) to do what they need.

Don't intend to hijack this thread, but this bit interests me. I know
several accomplished C/assembly programmers who have told me that
reverse engineering object code from either of these two languages is
anything but trivial. Yet, I *hear* and *read* the opposite all of the
time. Can anyone actually demonstrate a decompile that mirrors the
original source?


I give you one example: Online/Multiplayer GTA 3 or 4
(http://gta3mta.tk/)

A C-App never intended to work that way - but skillfully patched so that
it works! And that even only as OSS - no commercial interest (and thus
funding). So I day Peter's statement has full validity - it's a question
of interest.

Diez
Jul 19 '05 #6

P: n/a
Richard Lewis wrote:
On 2 Jun 2005 06:45:18 -0700, qs*********@gmail.com said:
Hi,

I've developed in several other languages and have recently found
Python and I'm trying to use it in the shape of the PythonCard
application development tool.

My two questions:

1. What is the easiest way to create a for loop in the style I'm used
to from Delphi ie:
for I:=0 to 2 do begin
//code
end;
for i in range(0, 2):
do stuff


Eh, no. range(0, 3) would be correct, since the Python range function
generates a list from start to stop-1.
The range([start], stop, [step]) function generates a sequence of
numbers which the the for loop iterates over.

(You can also use xrange() for a more memory efficient solution for very
large ranges).
2. Philospohy(sp?) aside, I could potentially want to create a
binary-only distribution of my finished apps. I noticed the
documentation on .pyc files: how do I create these and, aside from
being basically read-only, are they used just like ordinary .py source
files? And can they be easily reverse-engineered?


They are a binary representation of bytecode, just like in Java. They can be
reverse-engineered more easily than machine code, but it still is no no-brainer.
Btw, they are created automatically...

Reinhold
Jul 19 '05 #7

P: n/a
Thanks to you all for the quick response.

I've noticed that when I do
$ python myprog.py
the file myprog.pyc file is not created, but the .pyc files for files I
import *are* created. Is this intentional and, if so, how do I get the
myprog.pyc file?

Thanks,
- QS Computing.

Jul 19 '05 #8

P: n/a
qs*********@gmail.com wrote:
Thanks to you all for the quick response.

I've noticed that when I do
$ python myprog.py
the file myprog.pyc file is not created, but the .pyc files for files I
import *are* created. Is this intentional and, if so, how do I get the
myprog.pyc file?


I thought the docs covered this, so I left it out. The
"main" .py file is not converted to a .pyc file for reasons I can't
remember (and don't care... after it, that's just the way it is). If
you really need a .pyc for it, the simplest thing to do is "import
myprog" from the interactive prompt. The compileall module I mentioned
would also be able to do this.

-Peter
Jul 19 '05 #9

P: n/a
On Thu, 02 Jun 2005 06:45:18 -0700, qscomputing wrote:
Hi,

I've developed in several other languages and have recently found
Python and I'm trying to use it in the shape of the PythonCard
application development tool.

My two questions:

1. What is the easiest way to create a for loop in the style I'm used
to from Delphi ie:
for I:=0 to 2 do begin
//code
end;
Use Delphi.

If you insist on using Python (and why wouldn't you?), then I'm afraid
you will have to create for loops in the Python style:

for i in range(3):
do_something
Notice the small gotcha: if you want to loop over the values 0, 1, and 2,
you have to use range(3), NOT range(2). This may seem strange now, but it
is actually very useful and prevents a lot of off-by-one errors.
2. Philospohy(sp?) aside,
Philosophy.
I could potentially want to create a
binary-only distribution of my finished apps. I noticed the
documentation on .pyc files: how do I create these
In PythonCard? I have no idea. Sorry.

In ordinary Python?

When you run or import a Python module, the Python interpreter first looks
for a .pyc file of the same name that is more recent than the .py file. If
it doesn't find one, it compiles the .py file into byte-code, stores the
byte-code in the .pyc file, and runs that.

In other words, to create your .pyc file, just run your .py file and
Python will do it automatically.
and, aside from
being basically read-only, are they used just like ordinary .py source
files? And can they be easily reverse-engineered?


Yes, they can be easily reverse-engineered.

The short answer is, Python has not been designed to hide your code. If
that's what you are trying to do, perhaps you need to think about _why_
you want to go to all that extra effort to keep your software secret,
rather than just _how_ to keep it secret.

I can think of a number of reasons why somebody might want to hide their
code. In no particular order:

(1) You are ashamed of the quality of your buggy code, and don't want
people to see how bad it is. If so, learn to write better code, and the
best way of doing that is to let people see your code and give you advice.

(2) You have stolen somebody else's code, and are trying to keep that fact
secret. If so, pay the licence fee, or legally reverse-engineer the code,
or use OpenSource software that allows copying. If the code you have
stolen is valuable enough, the legal owners will find out, even without
the source code.

(3) You have create an incredibly valuable piece of code that will be
worth millions, but only if nobody can see the source code. Yeah right.

(4) "It's MY CODE, nobody is allowed to use it unless I SAY SO!!!" Fine,
whatever you say, there are tens or hundreds of thousands of OpenSource
software packages competing with your software without those restrictions.
Good luck.

(5) Your code has security holes and you hope that the bad guys won't find
them without access to the source code. Be prepared for serious
embarrassment, because the crackers WILL crack your code, source code or
no source code. Obscurity is no substitute for security.

(6) You are worried about people copying the code for their friends
without paying you for it. How does keeping the source code secret stop
them from copying the .pyc files and giving them to their friends?

(7) You are using secret programs licenced from another programmer or
company, and the conditions of use are that the source code isn't made
available. Good luck, I hope it works out for you.

(8) You are programming a game or puzzle, and you don't want players to
cheat by reading the source code. Consider pulling out the information
they need to cheat and putting it in an encrypted data file instead.

There may be other reasons for wanting to keep the code secret. Some of
them might even be good reasons, for some value of "good".

The reality is, the more valuable your code is, the more effort people
will put into reverse-engineering it. People will find out how it works,
if they care enough, and the more valuable your program, the more they
will care.

On the other hand, there are incredible advantages to making your code
available to the users of your software. I'm sure you already know those
advantages: you are learning Python, which is based on those principles of
openness.

If you want to discuss these issues further, please feel free.

If you really what to hide your code, you might like to think about using
C-extensions instead.

--
Steven

Jul 19 '05 #10

P: n/a
rbt wrote:
Peter Hansen wrote:
Philosophy not entirely aside, you should note that object code in any
language can "easily" be reverse-engineered in the same way, with the
only difference being the degree of ease involved. If the code is
worth enough to someone that they are willing to risk violating your
license terms, they *will* be able to recover enough source code
(whether it was Python, C, or assembly) to do what they need.


Don't intend to hijack this thread, but this bit interests me. I know
several accomplished C/assembly programmers who have told me that
reverse engineering object code from either of these two languages is
anything but trivial. Yet, I *hear* and *read* the opposite all of the
time. Can anyone actually demonstrate a decompile that mirrors the
original source?


It all depends on the definition of "reverse engineering".

In my opinion and experience, very little code in the world is so
sophisticated that it is not roughly as easy to write equivalent code
from scratch (with the original, working program as a guide of what the
code actually does) as it would be to convert the object code back into
source. (Exceptions such as "decompyle" which may make the job near
trivial aside.)

If that's true, it leaves us with a very small subset of the code in any
given program, that might actually be worth the effort of converting
back to source. That bit of code will generally turn out to be so small
that once again an automated conversion to source is not really
necessary, since analysis of the object code would with relatively
little effort allow one to "reverse engineer" some equivalent source, in
whatever language (or pseudo-code) one chose.

So, for languages like C, where the compilation process is fairly
"destructive" to things like the variable names and control structures
used, "reverse engineering" in the sense of "automated conversion back
to equivalent source code" is rather difficult, probably infeasibly so
for most non-trivial programs. I personally don't understand the need
for this, other than in the case of "I lost my source", and the correct
answer there is a session of pummelling, followed by tarring and
feathering with the pages of the Subversion Book.

On the other hand, "reverse engineering" in the sense of "creating
source code capable of reproducing the effects of the valuable and
interesting parts of the object code" is not that difficult, and in the
sense of "understanding how this code works" is even easier, being just
the first part of that step.

Software development is far more about choosing the right problems to
solve and the right ways to solve them than it is about writing source
code for the program that will do the job.

And if I had an automated tool to reproduce source code for a given
program, I'd still be very concerned that I didn't end up with any of
its automated test cases. ;-)

-Peter
Jul 19 '05 #11

P: n/a
> > 1. What is the easiest way to create a for loop in the style I'm used
to from Delphi
Use Delphi.


Very literal interpretation of my text: I should have said "in a
similar style to". :-)
I can think of a number of reasons why somebody might want to hide their
code.


I can't really think of any pressing reasons for wanting to hide code
other than a habit developed from coding in Windows where, as I'm sure
you'll know, doing otherwise is considered a bit odd. Like all habits,
it's a hard one to break. :-(

Jul 19 '05 #12

P: n/a
Peter Hansen wrote:
qs*********@gmail.com wrote:
Thanks to you all for the quick response.

I've noticed that when I do
$ python myprog.py
the file myprog.pyc file is not created, but the .pyc files for files I
import *are* created. Is this intentional and, if so, how do I get the
myprog.pyc file?

I thought the docs covered this, so I left it out. The
"main" .py file is not converted to a .pyc file for reasons I can't
remember (and don't care... after it, that's just the way it is). If
you really need a .pyc for it, the simplest thing to do is "import
myprog" from the interactive prompt.


*Provided* the "main" .py file has been set up properly, in the sense
that the scripty bits are guarded by "if __name__ == '__main__':"

Otherwise side effects (possibly horrid) may occur upon import.

Another way around this is for myprog.py to be a stub which merely does
something like this:

if __name__ == "__main__":
import myrealprog
myrealprog.main()
The compileall module I mentioned
would also be able to do this.

-Peter

Jul 19 '05 #13

P: n/a
Steven D'Aprano wrote:
On Thu, 02 Jun 2005 06:45:18 -0700, qscomputing wrote:
2. Philospohy(sp?) aside,

Philosophy.

I could potentially want to create a
binary-only distribution of my finished apps. I noticed the
documentation on .pyc files: how do I create these

In PythonCard? I have no idea. Sorry.

In ordinary Python?

When you run or import a Python module, the Python interpreter first looks
for a .pyc file of the same name that is more recent than the .py file. If
it doesn't find one, it compiles the .py file into byte-code, stores the
byte-code in the .pyc file, and runs that.

In other words, to create your .pyc file, just run your .py file and
Python will do it automatically.


The notion that just running a .py file will create a .pyc file is
contrary to widely-held belief, and (admittedly small, but very recent,
on Python 2.4.1, in a directory to which I have and had write access)
empirical evidence. I can't be bothered checking *all* sightings of the
time machine but my copy of 1.5.2 exhibits the same behaviour.

Is it possible that you could be mistaken?
Jul 19 '05 #14

P: n/a
Steven D'Aprano wrote:
I can think of a number of reasons why somebody might want to hide their
code. In no particular order: (3) You have create an incredibly valuable piece of code that will be
worth millions, but only if nobody can see the source code. Yeah right.
- id software makes a lot of money licensing their 3D FPS engine

- stock market trading companies make money in part by having
specialized software to help with market trading, forecasts, etc.
(8) You are programming a game or puzzle, and you don't want players to
cheat by reading the source code. Consider pulling out the information
they need to cheat and putting it in an encrypted data file instead.
But code is data ...

There may be other reasons for wanting to keep the code secret. Some of
them might even be good reasons, for some value of "good".
You are the US government developing software to design/test the
next generation nuclear weapons system and don't want any other
country to use it. (GnuNuke?)

You are a student working on a take-home example and you aren't
allowed to work with/help anyone else

If you really what to hide your code, you might like to think about
using C-extensions instead.


Or go the Amazon/EBay/Google approach and provide only client access
to your code.

Andrew
da***@dalkescientific.com

Jul 19 '05 #15

P: n/a
John Machin wrote:
In other words, to create your .pyc file, just run your .py file and
Python will do it automatically.


The notion that just running a .py file will create a .pyc file is
contrary to widely-held belief, and (admittedly small, but very recent,
on Python 2.4.1, in a directory to which I have and had write access)
empirical evidence. I can't be bothered checking *all* sightings of the
time machine but my copy of 1.5.2 exhibits the same behaviour.

Is it possible that you could be mistaken?


Well, its been known to happen before. Especially at 3am.

So yes, it is certainly possible that I'm mistaken.
However, I'm assured that in Python3000, the Python
byte-code interpreter will be integrated with Guido's
time machine so that the .pyc file will be created
before you even write the .py file, thus saving a lot
of development time.
--
Steven.

Jul 19 '05 #16

P: n/a
Andrew Dalke wrote:
You are the US government developing software to design/test the
next generation nuclear weapons system and don't want any other
country to use it. (GnuNuke?)


Hmmm... if these are GPL weapons, if you want to fire
them at anyone you'll *have* to make them available to
all other countries as well... not good for
non-proliferation...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Jul 19 '05 #17

P: n/a
Greg Ewing wrote:
Hmmm... if these are GPL weapons, if you want to fire
them at anyone you'll *have* to make them available to
all other countries as well... not good for
non-proliferation...


I think the source code only needs to be sent to the
country which receive the weapons. Include a DVD with
the warhead (in a usable form for further development)
and the GPL should be satisfied.

Andrew
da***@dalkescientific.com

Jul 19 '05 #18

P: n/a
Sorry to continue with the thread hijack...

Steven D'Aprano wrote:
(3) You have create an incredibly valuable piece of code that will be
worth millions, but only if nobody can see the source code. Yeah right.


An interesting corollay that comes from source code transparency is
that it generally makes it a lot easier to see who has stolen from you.

-alex23

Jul 19 '05 #19

P: n/a
Andrew Dalke wrote:

Steven D'Aprano wrote:
I can think of a number of reasons why somebody might want to hide their
code. In no particular order:
(3) You have create an incredibly valuable piece of code that will be
worth millions, but only if nobody can see the source code. Yeah right.

- id software makes a lot of money licensing their 3D FPS engine


The existence of one or two or a thousand profitable
software packages out of the millions in existence does
not invalidate my skepticism that some random piece of
software will directly make money for the developer.
Even assuming that the money-making ability would be
lost if the source code was available, which is not a
given (id software open-sources old versions of their
rendering engines, and MySQL is quite profitable and
their software is available source code and all).

Software rarely makes money for the developers
directly. The odds are against any developer, hence my
skepticism.
- stock market trading companies make money in part by having
specialized software to help with market trading, forecasts, etc.
You are mixing up a number of seperate issues here.

If the trading company keeps the software in-house,
then the issue of making the source code available is
irrelevent since they don't distribute the object code
either.

If they distribute the software externally, then they
almost certainly have more protection from licence
agreements and copyright than they get from merely
hiding the source. If they even do hide the source
code, which is not a given.

As for the issue of them making money, I'm not
suggesting that software can't make money for a
business. I work for a business that makes money from
Linux, Apache, perl, Python and other FOSS in the same
way that a carpenter makes money from a hammer: they
are tools that we use to provide products and services
that we sell for profit.

In-house use of market forecasting software falls into
the "carpenter's hammer" category, not the "make money
by selling software" category.

As for selling forecasting software, well, you haven't
demonstrated that making the source code available
would harm the ability to make money from it. Firstly,
very often the value of the software is not the
algorithms they use (curve fitting software and
extrapolation algorithms are hardly secret), but the
data used by the algorithm. So long as you keep the
financial data proprietary, keeping the source code
secret adds nothing.

Secondly, even if the software is rubbish, and the
forecasts give results no better than chance, doesn't
mean the company can't make money selling it. Look at
the popularity of "systems" for predicting lottery numbers.
(8) You are programming a game or puzzle, and you don't want players to
cheat by reading the source code. Consider pulling out the information
they need to cheat and putting it in an encrypted data file instead.

But code is data ...


A pedantic point that doesn't add anything to the
discussion :-) Not all the data in a puzzle allows the
player to cheat, does it? Case in point: knowing how
Solitaire draws the cards on the screen doesn't help
you win any games.
There may be other reasons for wanting to keep the code secret. Some of
them might even be good reasons, for some value of "good".

You are the US government developing software to design/test the
next generation nuclear weapons system and don't want any other
country to use it. (GnuNuke?)


Then don't distribute the software, object or source code.

You are a student working on a take-home example and you aren't
allowed to work with/help anyone else


Er, I don't see how this is supposed to work. An
example of what? How does keeping the source code
secret prevent the student from working with others?

If you really what to hide your code, you might like to think about
using C-extensions instead.

Or go the Amazon/EBay/Google approach and provide only client access
to your code.


Yes, good point. That's another way of telling your
customers under what circumstances they are allowed to
use the software. And who knows, if your software is
valuable enough and unique enough, they may even be
prepared to work the way you want them to work instead
of the way they want to work.
--
Steven.

Jul 19 '05 #20

P: n/a
Steven D'Aprano wrote:
The existence of one or two or a thousand profitable software packages
out of the millions in existence does not invalidate my skepticism that
some random piece of software will directly make money for the
developer.
'Tis true. I think (but have no numbers to back me up) that most software
in the world is developed in-house and is not distributed. Eric Raymond
at http://www.catb.org/~esr/writings/ma...auldron-3.html
says it's <5%

For example, all my income has been from consulting and contract work, and
none from product development.
Even assuming that the money-making ability would be lost if the source
code was available, which is not a given (id software open-sources old
versions of their rendering engines, and MySQL is quite profitable and
their software is available source code and all).
Regarding id, see section 10.3 of
http://www.catb.org/~esr/writings/ma...uldron-10.html

They open their software when there isn't much money to be made from it.
See also John Carmack's comments at
http://slashdot.org/interviews/99/10/15/1012230.shtml
Going open-source from development day one with a game probably doesn't
make much sense. Design by committee doesn't work particularly well, and
for something with as much popular appeal as games, the signal to noise
ratio would probably be very low. ... I am going to be releasing the majority of the code for Q3 soon, but
there will still be proprietary bits that we reserve all rights to.
We make a fairly good chunk of income from technology licensing, so
it would take some damn good arguments to convince everyone that giving
it all away would be a good idea.
MySQL isn't relevant; I know there's companies that make money
that way. There's also those that don't, and there are times
when obsfucation (compiling, .pyc, etc) changes the economic landscape
enough to bring in enough extra money that overrides what is to
many the low or non-existent moral obligation to provide the
original source in an easily usable and re-distributable form.
Software rarely makes money for the developers directly. The odds are
against any developer, hence my skepticism.
Software and restaurant startups have high failure rates. But
people like to think they are special and can beat the odds. Some do.
- stock market trading companies make money in part by having
specialized software to help with market trading, forecasts, etc.


You are mixing up a number of seperate issues here.


Yes, I am.
If they distribute the software externally, then they almost certainly
have more protection from licence agreements and copyright than they get
from merely hiding the source. If they even do hide the source code,
which is not a given.
Ahh, I thought by "hide the source" you meant "not open source". Of
course there are many schemes whereby purchasers also get access
to the code but don't have redistribution rights.
In-house use of market forecasting software falls into the "carpenter's
hammer" category, not the "make money by selling software" category.
I was actually thinking of market trading software that was sold.
It's rather absurd to hide software from yourself.

One story I heard at the Python conference in Houston ('98, I think)
was of a company that developed this sort of package. They redid
it and in-house used the newer version but sold the older and less
capable version to other companies, including competitors.

Nothing to do with open/closed/hidden/etc. but an interesting story.
As for selling forecasting software, well, you haven't demonstrated that
making the source code available would harm the ability to make money
from it. Firstly, very often the value of the software is not the
algorithms they use (curve fitting software and extrapolation algorithms
are hardly secret), but the data used by the algorithm. So long as you
keep the financial data proprietary, keeping the source code secret adds
nothing.


At the 2000 Python conference in DC, Eric Raymond was the keynote.
He presented his ideas from "The Magic Cauldron"
http://www.catb.org/~esr/writings/ma...-cauldron.html

One of the examples he gave of a program that should not be open-sourced
was from a company that developed software to optimize lumber cutting
from a tree. In that case the value *was* the algorithm used.

Note by the way that there were several objections to his presentation.
One was to his "Give Away the Recipe, Open A Restaurant"
http://www.catb.org/~esr/writings/ma...n-9.html#ss9.3

In his talk he mentioned a famous restaurant, and pointed out you could
get the recipes for the meals. One guy from the audience said he
worked for a sister restaurant to the one cited, that they signed
NDAs, and that the published recipes often excluded a few key parts, to
make it hard to duplicate.
You are the US government developing software to design/test the next
generation nuclear weapons system and don't want any other country to
use it. (GnuNuke?)


Then don't distribute the software, object or source code.


What about the software in the weapon itself? When used it's
certainly delivered. As I joked with Greg Ewing - might as well
include the source code with the warhead.
You are a student working on a take-home example and you aren't
allowed to work with/help anyone else


Er, I don't see how this is supposed to work. An example of what? How
does keeping the source code secret prevent the student from working
with others?


There's an ethical obligation. I could modify the situation a bit;
turn it into an assignment instead of a test, and have the user
testing & QA with other classmates be part of the assignment but
that sharing code isn't. Distributing a .pyc might be considered
sufficient protection if a plagarism charge is investigated.
Andrew
da***@dalkescientific.com

Jul 19 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.