Selling Python Software

[Will Stuyvesant]

Suppose I want to sell a (small, 1000 lines) Python program. It is a
commandline program for database applications and I have a customer.
The customer wants to "try it out" before buying. The try-out version
should be a full, complete, version.

As much as I like the opensource movement, I have a problem now. If I
just give them the Python source code then they can show it to their
programmers and they have no reason anymore to pay money to me. Sure
that would break our agreements, but you know bussiness, legal issues.
The thing the customer is interested in is the algorithm used in the
program. Not much I could do about such a scenario effectively.

I tried py2exe before, but someone told me it is always possible to
decompile...rev ealing the source code.

Anybody has a solution to this, besides more legal paperwork (I am in
europe...forget about claiming your rights here)? Is it not possible
to give away a Windows .exe file that can not be decompiled (or only
with *extreme* difficulty)?

[Erik Max Francis]

Re: Selling Python Software

Will Stuyvesant wrote:
[color=blue]
> I tried py2exe before, but someone told me it is always possible to
> decompile...rev ealing the source code.[/color]

It's always possible to decompile programs compiled to machine code, as
well, you know. Ultimately, every software developer must defend
himself with licenses and legal means, not technical ones.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ The most exhausting thing in life is being insincere.
\__/ Anne Morrow Lindbergh

[Alex Martelli]

Re: Selling Python Software

Erik Max Francis wrote:
[color=blue]
> Will Stuyvesant wrote:
>[color=green]
>> I tried py2exe before, but someone told me it is always possible to
>> decompile...rev ealing the source code.[/color]
>
> It's always possible to decompile programs compiled to machine code, as
> well, you know. Ultimately, every software developer must defend
> himself with licenses and legal means, not technical ones.[/color]

....unless said SW developer keeps the extremely precious parts of his
SW safely on a network server under his control (yes, it IS possible
to technically secure that -- start with an OpenBSD install...:-) and
only distributes the run-of-the-mill "client-oid" parts he doesn't
particularly mind about. The server-side SW can supply the precious
parts of the overall program's functionality to the client-side SW
via secure webservices or proprietary protocols; this also allows you
to enforce different business models (subscription, pay-per-use, ...)
more easily than distributing things does.

Very little software is WORTH protecting so closely, but for that
1 in 1000, or whatever, this option IS, IMHO, worth considering.


Alex

[Alex Martelli]

Re: Selling Python Software

Will Stuyvesant wrote:
[color=blue]
> Suppose I want to sell a (small, 1000 lines) Python program. It is a
> commandline program for database applications and I have a customer.
> The customer wants to "try it out" before buying. The try-out version
> should be a full, complete, version.
>
> As much as I like the opensource movement, I have a problem now. If I
> just give them the Python source code then they can show it to their
> programmers and they have no reason anymore to pay money to me. Sure
> that would break our agreements, but you know bussiness, legal issues.
> The thing the customer is interested in is the algorithm used in the
> program. Not much I could do about such a scenario effectively.
>
> I tried py2exe before, but someone told me it is always possible to
> decompile...rev ealing the source code.[/color]

Yes, exactly as could be done if you coded your precious algorithm
in C, machine-language, or whatever: if you distribute executable
code it CAN be cracked and the algorithm reverse-engineered (see any
warez site: game companies go to HUGE length to defend their programs
and they STILL get cracked anyway).

[color=blue]
> Anybody has a solution to this, besides more legal paperwork (I am in
> europe...forget about claiming your rights here)? Is it not possible
> to give away a Windows .exe file that can not be decompiled (or only
> with *extreme* difficulty)?[/color]

"Can not be decompiled" is impossible whatever language you're using.

"*extreme* difficulty" is in the eye of the beholder. You can e.g.
add layers of encryption/decription to the bytecode, etc, but whatever
you do somebody else can undo. Depending on the relative skills of
you and the "somebody else" the ratio (your effort to keep things
secret, to theirs to uncover them) can be any.

Couldn't you keep some crucial part of your precious algorithm OFF
the code you distribute, and have said code access said part via
webservices towards your personally-controlled, secure host?


Alex

[Radovan Garabik]

Re: Selling Python Software

Will Stuyvesant <hwlgw@hotmail. com> wrote:[color=blue]
> Suppose I want to sell a (small, 1000 lines) Python program. It is a
> commandline program for database applications and I have a customer.
> The customer wants to "try it out" before buying. The try-out version
> should be a full, complete, version.
>
> As much as I like the opensource movement, I have a problem now. If I
> just give them the Python source code then they can show it to their
> programmers and they have no reason anymore to pay money to me. Sure
> that would break our agreements, but you know bussiness, legal issues.
> The thing the customer is interested in is the algorithm used in the
> program. Not much I could do about such a scenario effectively.
>
> I tried py2exe before, but someone told me it is always possible to
> decompile...rev ealing the source code.
>
> Anybody has a solution to this, besides more legal paperwork (I am in
> europe...forget about claiming your rights here)? Is it not possible
> to give away a Windows .exe file that can not be decompiled (or only
> with *extreme* difficulty)?[/color]

use upx to pack it. Of course, it is always possible to unpack
the executable, but if an effort to do so is bigger that money they would
pay you, it would not be in their interest. Or enter into google
"encrypt executable" and it will give you a plethora of links.

--
-----------------------------------------------------------
| Radovan GarabÃk http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__ garabik @ kassiopeia.juls .savba.sk |
-----------------------------------------------------------
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

[John J. Lee]

Re: Selling Python Software

Alex Martelli <aleax@aleax.it > writes:
[...][color=blue]
> "Can not be decompiled" is impossible whatever language you're using.
>
> "*extreme* difficulty" is in the eye of the beholder. You can e.g.
> add layers of encryption/decription to the bytecode, etc, but whatever
> you do somebody else can undo. Depending on the relative skills of
> you and the "somebody else" the ratio (your effort to keep things
> secret, to theirs to uncover them) can be any.[/color]
[...]

Whie this is all true, you seem to put undue emphasis on the fact that
it's always *possible* to decompile stuff. Isn't the point you make
in your last sentence actually crucial here? The game is to make your
opponent (customer ;-) incur more expense in decompiling it than it
would cost to just go ahead and pay you, is it not? And yeah, you
also have to take into account how much it costs you to come up with
the protection scheme, of course.

So, is there a good practical solution of that form, for Python code
of this sort of size (or any other size)? I suspect the answer for
standard Python may be no, while the answer for optimising compilers
may be yes -- but that's just a guess.


John

[Peter Hansen]

Re: Selling Python Software

Will Stuyvesant wrote:[color=blue]
>
> Suppose I want to sell a (small, 1000 lines) Python program. It is a
> commandline program for database applications and I have a customer.
> The customer wants to "try it out" before buying. The try-out version
> should be a full, complete, version.
>
> As much as I like the opensource movement, I have a problem now. If I
> just give them the Python source code then they can show it to their
> programmers and they have no reason anymore to pay money to me. Sure
> that would break our agreements, but you know bussiness, legal issues.
> The thing the customer is interested in is the algorithm used in the
> program. Not much I could do about such a scenario effectively.
>
> I tried py2exe before, but someone told me it is always possible to
> decompile...rev ealing the source code.
>
> Anybody has a solution to this, besides more legal paperwork (I am in
> europe...forget about claiming your rights here)? Is it not possible
> to give away a Windows .exe file that can not be decompiled (or only
> with *extreme* difficulty)?[/color]

I've read the other answers here, which pretty much just repeat past
discussions, but I think the various respondents have to some extent
not paid close attention to your *specific* needs here.

Alex is pretty close to the mark, but there's no need to be as extreme
as his "start with OpenBSD install" response to Erik Max Francis, as
you definitely don't need the high security of this approach.

Nevertheless, the server-based-code approach is definitely the only
one that is worth the effort here, considering that the effort is
practically nil (or should be, as if you're really trying to sell
commercial software, having access to an Internet server should be
a pretty trivial thing). You could use Pyro to make the fact that
part of the system is running on a server practically transparent
both to the potential customer and to you. Moving the server-based
code into the real application once they've paid you would be a
tiny last step.

"Only decompiled with *extreme* difficulty?" There is no such approach
within your means, I'm afraid, and there are any number of stories
from the real world which ipso facto prove it. There *are* hardware-key
based solutions, but I can tell you from personal experience that
they will really not stop a determined attacker and in any case they
will cost more to implement than the potential income from your
1000-line Python program.

On another note, having been in the consulting business myself for
years (before my current job) I would give you this advice. Don't
underestimate the value of a trusting business relationship, nor
the value of a decent written contract. If you are right that this
customer would cheat you at the earliest opportunity, you are
likely going to find yourself cheated in some manner no matter
what you do. Without adequate attention to written agreements and
a good mutual understanding, you could just as well find yourself
in the position of having delivered the final, unprotected version
to them and still not get paid because "it doesn't meet the
requirements you promised to implement" or something like that.

A decent license *should* be adequate for just about any customer
with whom you ought to be doing business. IMHO.

-Peter

[Alex Martelli]

Re: Selling Python Software

John J. Lee wrote:
[color=blue]
> Alex Martelli <aleax@aleax.it > writes:
> [...][color=green]
>> "Can not be decompiled" is impossible whatever language you're using.
>>
>> "*extreme* difficulty" is in the eye of the beholder. You can e.g.
>> add layers of encryption/decription to the bytecode, etc, but whatever
>> you do somebody else can undo. Depending on the relative skills of
>> you and the "somebody else" the ratio (your effort to keep things
>> secret, to theirs to uncover them) can be any.[/color]
> [...]
>
> Whie this is all true, you seem to put undue emphasis on the fact that
> it's always *possible* to decompile stuff. Isn't the point you make
> in your last sentence actually crucial here? The game is to make your[/color]

Of course it's crucial. But so what?
[color=blue]
> opponent (customer ;-) incur more expense in decompiling it than it
> would cost to just go ahead and pay you, is it not? And yeah, you
> also have to take into account how much it costs you to come up with
> the protection scheme, of course.[/color]

Of course. It can be framed as a zero-sum game of incomplete
information on both sides. You don't really know that anybody
will ever try to steal your code -- any eurocent you invest in
protecting it might be a complete waste, if nobody ever even
dreams of so trying. At the other extreme, whoever tries to do
the stealing might be technically good and well informed, as well
as dishonest, so that in 5 minutes they destroy 5 days' worth of
work by you on "protection ". In both cases, investing in such
protection is throwing money away from your POV. The hypothetical
adversary, for his part, may not know and be unable to gauge the
effort needed to crack and steal your code -- if he's not well
informed nor competent, he might just be flailing around for 10
days and stop just before the 11th day's effort WOULD deliver the
illegal goods he's after.

Of course, guess what IS the effect on this game's payoff matrix
of discussing technical possibilities in a public forum. "I give
you three guesses, but the first two don't count"...:-).

[color=blue]
> So, is there a good practical solution of that form, for Python code
> of this sort of size (or any other size)? I suspect the answer for
> standard Python may be no, while the answer for optimising compilers
> may be yes -- but that's just a guess.[/color]

The answer is no for either case. I've spent too high a proportion of
my life (at my previous employer) putting "protection systems" in
place (including optimising compilers, weird machine-code tricks,
even in one case some microcode hacks), and it was the worst waste of
my time anybody could possibly devise.

Part of the problem is, that the "warezdoodz culture" is stacked
against you. If you DO come up with a novel approach, that is a
challenge to guys who SPEND THEIR LIFE doing essentially nothing
but cracking software-protection schemes *for fun*. Even if it's
taken you 10 hours and it makes them spend 20 hours, they _do not
account this as a cost_, any more than a crossword enthusiast sees
as "a cost" the hours he spends cracking a particularly devious
crossword -- indeed, once said enthusiast is good enough, unless
the puzzle it's hard it's no fun. But don't think that therefore
using an obviously weak scheme is a counter: just below the top
crackerz there are layers and layers of progressively less capable
ones desperate to put notches in their belt.

To me, playing such zero-sum games is a net loss and waste of time
because with the same investment of my time and energy I could
be playing games with sum _greater_ than zero, as is normally the
case for technical development not connected to security issues
(i.e., where the only "net benefit" of the development doesn't
boil down to frustrating somebody else's attempts at cracking and
stealing) and even for much security-related work (e.g., most of
OpenBSD's developments help against plain old BUGS and crashes just
as much as they help against wilfull attacks against you).

There exist technical solutions that DO make it impossible for
anybody to crack your precious algorithms: just make those precious
algorithms available only from a network server under your total
control, NEVER giving out executable code for them. (You can then
work on securing the network server, etc, but these ARE problems
that are technically susceptible to good solutions). If anybody
refuses this solution (surely a costly one on some parameters) it
probably means their algorithms aren't worth all that much after
all (there may be connectivity, latency or bandwidth problems in
some cases, of course, but with the spread of network technologies
these are progressively less likely to apply as time goes by). If
the algorithms aren't worth all that much, they're not worth me
spending my time in zero-sum games to protect them -- lawyers are
probably more emotionally attuned than engineers to playing zero-
sum games, since so much of legal practice vs so little engineering
practice is like that, so that may be a back-up possibility.

It's not about programming languages at all. In the end, "clever"
schemes that are presumed to let people run code on machines under
their control yet never be able to "read" the code must rely on
machinecode tricks of some sort, anyway, since obviously, from a
technical viewpoint, if the code must be executable, it must be
*read* on the way to the execution engine -- if it's encrypted it
must exist in decrypted form at some point (and it can then be
captured and examined at that point), etc. Some of the code that
I was supposed to "protect" for my previous employer was in C,
Fortran, C++, and other high-level languages; some was in
machine code; other yet was in intermediate-code generated by a
proprietary scripting language; ... in the end it made no real
difference one way or another.


Alex

[Lulu of the Lotus-Eaters]

Re: Selling Python Software

hwlgw@hotmail.c om (Will Stuyvesant) wrote previously:
|Is it not possible to give away a Windows .exe file that can not be
|decompiled (or only with *extreme* difficulty)?

NO! It is NOT possible.

It is not possible in Python. It is not possible in VB. It is not
possible in C#. It is not possible in C. It is not possible in
Fortran. It is, in fact, not possible in Assembly.

However, distributing a .pyc or an .exe make it require a little bit of
effort to find the underlying code... enough that someone needs to make
a conscious decision to do so, rather than "accidental ly" open the .py
file in Notepad.

Yours, Lulu...

--
mertz@ _/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: \_\_\_\_ n o
gnosis _/_/ Postmodern Enterprises \_\_
..cx _/_/ \_\_ d o
_/_/_/ IN A WORLD W/O WALLS, THERE WOULD BE NO GATES \_\_\_ z e

[Bengt Richter]

Re: Selling Python Software

On Tue, 04 Nov 2003 09:03:51 GMT, "Andrew Dalke" <adalke@mindspr ing.com> wrote:
[color=blue]
>Bengt Richter:[color=green]
>> OTOH, we are getting to the point where rather big functionality can be[/color]
>put[color=green]
>> on a chip or tamper-proof-by-anyone-but-a-TLA-group module. I.e.,[/color]
>visualize[color=green]
>> the effect of CPUs' having secret-to-everyone private keys, along with[/color]
>public keys,
>
>Actually, we aren't. There have been various ways to pull data of
>of a smart card (I recall readings some on RISKS, but the hits I
>found are about 5+ years old). In circuit emulators get cheaper and
>faster, just like the chips themselves. And when in doubt, you can
>buy or even build your own STM pretty cheap -- in hobbiest range
>even (a few thousand dollars).[/color]
Even if you knew exactly where on a chip to look, and it wasn't engineered
to have the key self-destruct when exposed, what would you do with the key?
You'd have the binary image of an executable meant to execute in the secret-room
processing core. How would you make it available to anyone else? You could re-encrypt
it with someone else's specific public key. Or distribute a program that does that,
along with the clear binary. But what if the program contains an auth challenge for the target
executing system? Now you have to reverse engineer the binary and see if you can modify it
to remove challenges and checks and still re-encrypt it to get it executed by other processors.
Or you have to translate the functionality to a program that runs in clear mode on the ordinary cores.
Sounds like real work to me, even if you have a decompyler and the inter-core comm specs.
Of course, someone will think it's fun work. And they would get to start over on the next program,
even assuming programs encrypted with the public key of the compromised system would be provided,
so there better not be a watermark left in the warez images that would indentify the compromised
system. Or else they would get to destroy another CPU module to find its key. Probably easier the
second time, assuming no self-destruct stuff ;-)
[color=blue]
>[color=green]
>> and built so they can accept your precious program code wrapped in a PGP[/color]
>encrypted[color=green]
>> message that you have encrypted with its public key.[/color]
>
>Some of the tricks are subtle, like looking at the power draw.
>Eg, suppose the chip stops when it finds the key is invalid. That
>time can be measured and gives clues as to how many steps it
>went through, and even what operations were done. This can
>turn an exponential search of key space into a linear one.[/color]
That was then. Plus remember this would not be an isolated card chip that you can
probe, it's one or more specialized cores someplace on a general purpose
multi-cpu chip that you can't get at as a hobbyist, because opening it without destroying
what you want to look at requires non-hobby equipment, by design.
[color=blue]
>[color=green]
>> This is not so magic. You could design a PC with a locked enclosure and[/color]
>special BIOS[color=green]
>> to simulate this, except that that wouldn't be so hard to break into. But[/color]
>the principle[color=green]
>> is there. Taking the idea to SOC silicon is a matter of engineering, not[/color]
>an idea break-through[color=green]
>> (though someone will probably try to patent on-chip stuff as if it were[/color]
>essentially different[color=green]
>> and not obvious ;-/)[/color]
>
>But the counter principle (breaking into a locked box in an uncontrolled
>environment) is also there. There are a lot of attacks against smart
>cards (eg, as used in pay TV systems), which cause improvements (new
>generation of cards), which are matched by counter attacks.
>
>These attacks don't require the resources of a No Such Agency,
>only dedicated hobbiest with experience and time on their hands.
>[/color]
Sounds like an article of faith ;-)
[color=blue]
> Andrew
> dalke@dalkescie ntific.com
>P.S.
> I did have fun breaking the license protection on a company's
>software. Ended up changing one byte. Took about 12 hours.
>Would have been less if I knew Solaris assembly. And I did
>ask them for permission to do so. :)[/color]

Changed a conditional jump to unconditional? Some schemes aren't so
static and centralized ...

I once ran into a scheme that IIRC involved a pre-execution snippet of code that had to
run full bore for _lots_ of cycles doing things to locations and values in
the program-to-be-executed that depended on precise timing and obscured info.
I guess the idea was that if someone tried to trace or step through it, it would
generate wrong locations and info and also stop short and the attacker would have
to set up to record memory addresses and values off the wires to figure out what to change,
but even then they would run into code that did mysterious randomly sprinkled
milestone checks, so capturing the core image after start wasn't free lunch either.
Plus it had to run in a privileged CPU mode, and it wasn't a stand-alone app, it
was part of an OS ... that wasn't open source ... and you didn't have to tools to rebuild...
This was just some code I stumbled on, I may have misunderstood, since I didn't
pursue it, being there for other reasons. But that was primitive compared to what you
could do with specialized chip design.

Regards,
Bengt Richter

[Andrew Dalke]

Re: Selling Python Software

Bengt Richter:[color=blue]
> Even if you knew exactly where on a chip to look, and it wasn't engineered
> to have the key self-destruct when exposed, what would you do with the[/color]
key?

As I mentioned, I'm not a hardware guy. What I know is that
trying to hide code on a chip is open to its own sorts of attacks and
that at least some companies which have tried to do so (like pay-TV
companies) have had their systems broken, and not broken by the
efforts of a three letter agency.
[color=blue]
> That was then.[/color]

Yup.

Crypto software is notoriously hard to write. Even with the good
libraries we have now, people make mistakes and misuse them.
Similarly, while it people can make chips that are hard to decode,
doing so in practice is likely to be even harder.
[color=blue]
> Plus remember this would not be an isolated card chip that you can
> probe, it's one or more specialized cores someplace on a general purpose
> multi-cpu chip that you can't get at as a hobbyist, because opening it[/color]
without destroying[color=blue]
> what you want to look at requires non-hobby equipment, by design.[/color]

Then perhaps a small business instead of a hobbyist. Still
doesn't require large government-based efforts to crack it.
[color=blue]
> Changed a conditional jump to unconditional? Some schemes aren't so
> static and centralized ...[/color]

That's what I did for that one.

Another time I was working for a company. We were shipping a time-locked
program and had forgotten about it (there was a big lay off a few months
before I came in). Then one day our customers started complaining that
it wasn't working. The builds were done at another site, so as a backup
plan I figured out how to break our own scheme. In that one I looked
for the time call then added some code to shift the return value some
arbitrary time in the future.
[color=blue]
> I once ran into a scheme that IIRC involved a pre-execution snippet of[/color]
code that had to[color=blue]
> run full bore for _lots_ of cycles doing things to locations and values in
> the program-to-be-executed that depended on precise timing and obscured[/color]
info.

Another one is the code in an old copy of MS Windows which gave a
warning message when run on top of DR-DOS (which had about 1/300th
of the marketplace). See

http://www.ddj.com/documents/s=1030/ddj9309d/

But these are defeatable. For example, run the program under an
emulator, save the state after the license check occurs, and restart
by reloading from that state. Or write a wrapper which intercepts
all I/O calls and returns the results from a known, good call (a
replay attack).

The system you propose seems to require a lot of changes to how
existing computer hardware is built, so that people can attach
dedicated compute resources. It's definitely an interesting idea,
and not just for program hiding. But a big change.

I'll end with a quote from E.E. "Doc" Smith's "Gray Lensman"
(p10 in my copy)

Also, there was the apparently insuperable difficulty of
the identification of authorized personnel. Triplanetary's best
scientists had done there best in the way of a non-counter-
feitable badge -- the historic Golden Meteor, of which upon
touch impressed upon the toucher's consciousness an unpro-
nounceable, unspellable symbol -- but that best was not
enough. /What physical science could devise and synthesize,
physical science could analyze and duplicate/; and that analy-
sis and duplication had caused trouble indeed.

(I realize this is not at issue and that everyone agrees this
to be the case. I just like the quote ;)

Andrew
dalke@dalkescie ntific.com

[Will Stuyvesant]

Re: Selling Python Software

Thank you all for your input and thoughts! I am replying to my first
post since otherwise I would have to choose one of the threads and I
can't: several are useful.

I got the customer's interest via a CGI based webservice that did show
what I can do. Given this, now it would be very simple for me to keep
it as a webservice and give them a client script using the urllib
module or something like that...it would access the webservice and
they would never see the algorithm (I want to keep that to myself).
That is the solution I would like best. Not only because I want to
keep stuff to myself, but also because then I can easily upgrade to
new versions in one fell swoop if they or others are interested.

But a program that has to be connected to the internet is not
acceptable, their boss says. Humph.

Maybe I should trust them and do normal bussiness as I did before with
other customers already: just send them the commandline version of the
program; but somewhere in the back of my mind I feel uneasy about
this. Dunno why. Maybe just because they have a pointy haired boss.

Alex Martelli told about software bussiness in southern europe, well,
it's one big EU now, with the italian Berlusconi as chairman (soon
appointed invulnerable for that job too?), and I feel it's the same
thing now here in mideurope too.

I guess I am going to send them an MIT licence (although I am afraid
those licences are pretty useless in The Netherlands), the .pyc files
for the algorithm and the utility modules, and a .py file for the main
program. Or maybe I am going to use upx or another .exe encrypter
(but then I have to find out first if I can wrap my head around the
usage of the latest py2exe thing). Then if I find out later they
copied the algorithm then maybe I have a case against them. Just
let's not hope it comes to that, I'd rather start another project.
But this little thing I like and it would be great if I could make
some extra money with it. Curious? It does XML transformations .
With a twist.

Will let you know how it works out, takes a couple of weeks perhaps
until they decide.

Thank you!

[Peter Hansen]

Re: Selling Python Software

Will Stuyvesant wrote:[color=blue]
>
> I guess I am going to send them an MIT licence (although I am afraid
> those licences are pretty useless in The Netherlands), the .pyc files
> for the algorithm and the utility modules, and a .py file for the main
> program.[/color]

No need even for that .py file, is there? You can easily execute
a .pyc file directly if the .py doesn't exist. To create it,
easiest way is just to do "import mymainmodule" from the interactive
prompt, then copy the resulting .pyc somewhere else.

Alternatively, keep you .py as the main entry point, but do nothing
inside it except import another module and execute code in it.
But if you can do that, then invoking that module directly is easy
too: "python -c 'import main; main.main()'" does the trick...

-Peter

[Erik Max Francis]

Re: Selling Python Software

Will Stuyvesant wrote:
[color=blue]
> Maybe I should trust them and do normal bussiness as I did before with
> other customers already: just send them the commandline version of the
> program; but somewhere in the back of my mind I feel uneasy about
> this. Dunno why. Maybe just because they have a pointy haired boss.[/color]

I'd be a little concerned why they're asking for a trial demo which
they'll decide whether to pay you for afterward given that, as you've
said, you've already demonstrated the ability to do the job with a CGI
based service that they've already explored and is what in fact drew
them to you in the first place. At this point I'd probably press on
about what the difficulty is in agreeing on contract fees up front would
be.

I agree with Peter's response, though -- it sounds like in this case,
simply distributing .pyc files (make sure you make it clear which
version of Python the .pyc files were created with, since the format
changes with releases!) would be sufficient obscurity to encourage them
to actually pay you once they've gotten the package and have
demonstrated it to work. I'd still wonder why they're insisting on in
effect a second trial demo, here; I now understand your initial
hesitation.
[color=blue]
> I guess I am going to send them an MIT licence (although I am afraid
> those licences are pretty useless in The Netherlands) ...[/color]

If you're planning on reselling this to other customers, why would you
want an MIT license?

I'd also make it very clear, if you haven't already -- before you give
them anything -- on whether or not they think you're transferring the
copyright to them or merely buying a license to use it which leaves you
with the ability to resell it to other clients.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ To understand is to forgive, even oneself.
\__/ Alexander Chase

[John J. Lee]

Re: Selling Python Software

bokr@oz.net (Bengt Richter) writes:
[color=blue]
> On Tue, 04 Nov 2003 09:03:51 GMT, "Andrew Dalke" <adalke@mindspr ing.com> wrote:
>[color=green]
> >Bengt Richter:[color=darkred]
> >> OTOH, we are getting to the point where rather big functionality can be put
> >> on a chip or tamper-proof-by-anyone-but-a-TLA-group module. I.e., visualize
> >> the effect of CPUs' having secret-to-everyone private keys, along with
> >> public keys,[/color]
> >
> >Actually, we aren't. There have been various ways to pull data of
> >of a smart card (I recall readings some on RISKS, but the hits I
> >found are about 5+ years old). In circuit emulators get cheaper and
> >faster, just like the chips themselves. And when in doubt, you can
> >buy or even build your own STM pretty cheap -- in hobbiest range
> >even (a few thousand dollars).[/color]
>
> Even if you knew exactly where on a chip to look, and it wasn't[/color]

(Which knowledge is bound to become available -- I don't think any
leak is required.)

[color=blue]
> engineered to have the key self-destruct when exposed, what would[/color]

Exposed to what?

[color=blue]
> you do with the key? You'd have the binary image of an executable
> meant to execute in the secret-room processing core. How would you[/color]

No, you already have that -- it's on your hard drive (the current
scheme is only about the processor & associated gubbins, if I read
Ross Anderson's page right).

[color=blue]
> make it available to anyone else?[/color]
[...]

Copy it.

I think the idea is something like this (got from Ross Anderson's TC
FAQ). The processor makes sure that a single process can only see
it's own memory space. The processor also has a private key, and
knows how to take an md5 sum (or whatever), sign it with the key, and
send that off to the software author's server along with your
identity. The server checks that it was signed with your processor's
private key, and that you've paid for the software, and a sends a
signed message back that tells your machine "OK". Obviously (hmm... I
should hesitate to use that word about anything related to security!),
if you have your machine's private key, you can play
"man-in-the-middle".

Presumably the next phase is to make hard drives, etc. 'trusted'. I
couldn't find much useful stuff on this on the web. Anybody have any
good links to overviews of this?


John