Selling Python Software

[Alex Martelli]

John J. Lee wrote:

> Alex Martelli <aleax at aleax.it> writes:
> [...]
>> 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
> [...]
> 
> Ah, stop right there (oops, too late!-).  I think we're somewhat at
> cross-purposes.  I was talking about protecting something more at the
> level of source code than running programs.

Oh, "shrouding"?  Sure, you can do that.  Many programs might
actually be _enhanced_ by that approach (at least the variable
and function names, while not helpful, aren't actively hostile:-),
but probably not Python programs.


> I mostly agree with you on the issue of protecting "binaries", but:
> 
>> 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
> [...]
> 
> Though information is indeed always incomplete, it seems a good bet
> that war3zd00dz are not an issue for a consultant being hired by a
> company to write a 1000 line program.  Do you disagree?

A Python 1000-SLOC program may be about 200+ function points --
not exactly trivial (it may be equivalent to more than 10,000
lines of C, easily) though not earth-shaking.  But, anyway,
we weren't talking about somebody being _hired_, but rather
wanting to sell what they independently came up with the idea
of developing -- there's a difference!  And yes, it wouldn't
be the first time that a company deliberately exploits the warez
"circuit" to get programs cracked -- look around and you'll see
it's definitely NOT just games and the like that end up there.


> Anyway, back to source vs. binaries.  Obviously, code that's closer to
> the "source" end of the spectrum has additional value.  I'd got the
> impression that something rather similar to the original source could
> be recovered from Python byte-code, due to its high-level nature
> (albeit obviously missing a lot of stuff -- including all those
> valuable names).  Certainly that's impossible with optimising
> compilers (I should have stated this much more strongly in my last
> message, of course -- there's no "may" or "guessing" involved there,
> unlike the Python case, where I don't know the answer).

If you think you do, "you're in denial".  Check out:

http://www.program-transformation.org/twiki/bin/view/Transform/DecompilationPossible
http://boomerang.sourceforge.net/
http://www.itee.uq.edu.au/~cristina/dcc.html#dcc

I suspect it must in some way be easier (but my multiplicative
constants, not O(N) easier...;-) for lower "semantic gaps" -- but
that intuition might well be misguided (it's close to "it must in
some way be easier to produce optimal machine code for a CISC
than for a RISC", and that's simply not true).


Alex