Selling Python Software
bokr at oz.net
Tue Nov 4 04:56:03 CET 2003
On Mon, 03 Nov 2003 13:54:52 GMT, Alex Martelli <aleax at aleax.it> wrote:
>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
(or maybe it can't, for practical purposes, see below)
>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.
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,
and built so they can accept your precious program code wrapped in a PGP encrypted
message that you have encrypted with its public key. The computer owner can
say run it or not, but other than i/o nothing can be observed, because decryption
happens in cache memory that you can't reach the address/data busses of, and execution
likewise passes no instructions or temporary data through any tappable wire. A separate
execution unit commpunicates via a restricted protocol to a normal CPU unit that has
normal OS stuff running and can do the rest, but can't reach into that private space.
This is not so magic. You could design a PC with a locked enclosure and special BIOS
to simulate this, except that that wouldn't be so hard to break into. But the principle
is there. Taking the idea to SOC silicon is a matter of engineering, not an idea break-through
(though someone will probably try to patent on-chip stuff as if it were essentially different
and not obvious ;-/)
I think this will come. It can be a good thing _if used right_, but that's a big if. I just hope
it won't be used to make artificial obstacles to interoperability of free vs proprietary. And doing
it between proprietary stuff just raises the prices for what can't compete on merit.
I have a hunch FSF/EFF lawyers should be preparing to lobby against laws that will permit such
market manipulations, if they aren't already. Or maybe get law enacted mandating free interoperability.
Maybe I'm just a worrywart ;-)
More information about the Python-list