hide python code !

[Armin Steinhoff]

Re: hide python code !

Bayazee wrote:

hi
can we hide a python code ?
if i want to write a commercial software can i hide my source code from
users access ?
we can conver it to pyc but this file can decompiled ... so ...!!
do you have any idea about this ...?

Use Pyrex in order to build C-Modules from the critical parts of your
software.

>
---------------------------------------
First Iranian Open Source Community : www.python.ir

Interesting ... but you are not a member of this community. Right?

--Armin

[Bayazee]

Re: hide python code !


Armin Steinhoff wrote:

Bayazee wrote:

hi
can we hide a python code ?
if i want to write a commercial software can i hide my source code from
users access ?
we can conver it to pyc but this file can decompiled ... so ...!!
do you have any idea about this ...?

>
Use Pyrex in order to build C-Modules from the critical parts of your
software.
>

---------------------------------------
First Iranian Open Source Community : www.python.ir

>
Interesting ... but you are not a member of this community. Right?
>
--Armin

Hi
thanx for your answers . i read all of your replys carefully ...
i am an open source Programmer ! i love to distribute my sources and
use other ideas ! but asking a question is't reason of using it ! i
want to find a way to hide python source codes ! can we do it ? how ?
but i dont want to use it ....
this is a question that i must be answer to a friend !

[Gerhard Fiedler]

Re: hide python code !

On 2006-08-15 05:40:31, Armin Steinhoff wrote:

>First Iranian Open Source Community : www.python.ir

>
Interesting ... but you are not a member of this community. Right?

You know how to read a thread, right? :)

Gerhard

[Philippe Martin]

Re: hide python code !

Bayazee wrote:

>
Armin Steinhoff wrote:

>Bayazee wrote:

hi
can we hide a python code ?
if i want to write a commercial software can i hide my source code from
users access ?
we can conver it to pyc but this file can decompiled ... so ...!!
do you have any idea about this ...?

>>
>Use Pyrex in order to build C-Modules from the critical parts of your
>software.
>>

>
---------------------------------------
First Iranian Open Source Community : www.python.ir

>>
>Interesting ... but you are not a member of this community. Right?
>>
>--Armin

>
>
Hi
thanx for your answers . i read all of your replys carefully ...
i am an open source Programmer ! i love to distribute my sources and
use other ideas ! but asking a question is't reason of using it ! i
want to find a way to hide python source codes ! can we do it ? how ?
but i dont want to use it ....
this is a question that i must be answer to a friend !

Then the answer could be a question: can we hide any source/binary ?

Hardware tokens (ex: smart cards) are used just for that purpose. So as long
as you distribute a PC with your package and are certain it cannot be
tempered with (the correct O/S, administrative rights, encrypted
partitions .....) ... but I do not think there is such a PC out there.

You might want to read this:

http://www.commoncriteriaportal.org/

https://www.commoncriteriaportal.org/public/files/ccintroduction.pdf

http://en.wikipedia.org/wiki/Common_Criteria

Philippe

[Alex Martelli]

Re: hide python code !

Gerhard Fiedler <gelists@gmail. comwrote:

On 2006-08-14 20:48:45, Damjan wrote:
>

I think you increase your chances of Microsoft not even being in the same
room with your software 100-fold if you release it under.. say GPL.

>
... and have the money to run a law suit? Patents, licenses etc are only as
strong as the money that backs them, mostly.

I guess that's an advantage of GPL: there's a foundation (with much
better funding than you could raise as an individual) which will gladly
fight for GPL, both in the courts and in the arena of public opinion --
I believe that, so, far, they've won every single fight they've picked,
by just the joint threat of lawsuits and public shaming campaigns.

It just isn't worth Microsoft's while to take the public-relations hit
of such a fight: much cheaper for them to re-implement your ideas than
to copy your GPL'd code.


Alex

[Ben Sizer]

Re: hide python code !

Paul Boddie wrote:

Successful software businesses are not merely founded on the process of
having ideas and implementing them - they might also need to be
effective at delivering those ideas and going through the whole process
again and again. Writing a neat utility for Windows is not by itself
the foundation of a successful business - other factors are critical,
whether they be continuous improvements, service, support, or a number
of other things.

Yes, but this was never about 'successful software businesses' as such.
I'm not saying anyone deserves to earn a living just because they
created something, but that it is useful for them to be able to reduce
the ways in which others with more resources can replicate that
creation. You don't even need to be a 'successful' business to kill a
competitor, just to have more money in the bank for as long as the
competition exists. (eg. MS vs Netscape, Creative vs Aureal.)

So, if we decide to ignore people waving pieces of paper around which
make some claim to an idea or some way of solving some problem, instead
investigating the actual code, others have pointed out already that if
you provide just a binary and there exist people who want to know what
you've done, those people will find it out whether you make it easy for
them or not.

Yes, in much the same way that there is no point ever locking your
doors or installing burglar alarms, as a determined thief will
eventually steal your belongings.

I find it strange that people (at least on c.l.py) often equate
'imperfect protection' with 'pointless protection'. The all-or-nothing
attitude makes no sense. If you can halve the number of people who can
deduce your algorithm, that helps. If you can double the time it takes
for those people to deduce it, that also helps. If it took you months
of R&D, the value of even imperfect protection rises.

Now, if we sidestep the issue of decompiling binaries and
cast the affected work as some kind of service, the question can now be
expressed as whether you should expect to be rewarded forever for
providing such a service.

But what is 'forever'? Is it a single service for one customer that
persists forever? Or is it a service that will be invoked many times by
different customers forever? Since these are completely different
scenarios, the answer is "it depends".

such issues could possibly increase competitive
pressure rather than enhance any supposed competitive advantage if
people felt that the market wasn't providing enough in the way of
choice in that area.

I'm not interested in whether it's a sound business decision or not.
I'm just interested in the developer's right and/or ability to make
that call.

I'm not saying I agree with extending the copyright period, however I
do think you can't just compare it to 'a day at work'. It's a totally
different set of circumstances which requires a different set of rules
to both encourage artists to continue creating while benefitting
society in the long run too.

>
For some of those musicians (ie. probably not Sir Cliff Richard), it
probably was a day at work for which they were badly paid, whilst
others (eg. Sir Cliff Richard) went on to make quite a bit of money. Of
course, one can always argue that the result of this particular kind of
day at work is something that can be enjoyed again and again, but then
you should consider the issue of why the person working at the car
factory doesn't get paid royalties every time you turn the key in the
ignition (even if it's just $0.0001 each time).

There's a key distinction to be made here, at least legally.

Session musicians do work for hire - they're paid by the
hour/day/whatever, and typically have no copyright to the work they
perform on. They are analogous to the person at the car factory. Any
royalties they receive - typically none - would be from the contractual
agreement and nothing to do with copyright.

On the other hand, writing musicians/composers typically will be paid
absolutely nothing for their original creation. They never get paid for
it as such, but they can (and typically do) yield the copyright to a
publishing company in return for an agreed royalty rate on sales of the
reproduced item. They don't so much get paid forever for a service
rendered long ago, they just have their payment spread out over an
indefinite period of time, and that is dependent on people buying that
item.

This is no different from me investing my own time and money into
manufacturing 10,000 cars and selling them between now and 50 years
from now. The major difference is that replicating creative work is
typically much cheaper and easier than replicating automobiles, hence
the existence of various laws safeguarding intellectual property, as
without such laws there would be little incentive to create any such
works that were non-trivial. No-one is going to pay you up front for
it, so you need a way of protecting future potential income. Since that
future income is typically strongly linked to the quality of your work,
it's arguable that this is in fact a fairer business model than being
paid a normal salary.

--
Ben Sizer

[Paul Boddie]

Re: hide python code !

Ben Sizer wrote:

Paul Boddie wrote:

Successful software businesses are not merely founded on the process of
having ideas and implementing them - they might also need to be
effective at delivering those ideas and going through the whole process
again and again. Writing a neat utility for Windows is not by itself
the foundation of a successful business - other factors are critical,
whether they be continuous improvements, service, support, or a number
of other things.

>
Yes, but this was never about 'successful software businesses' as such.

If success is defined as staying in business whilst making a profit,
then the issue is inseparable from being successful. As "the
single-person developer of a small application that did something quite
innovative" who charges "a small fee for your product", isn't the goal
at least to cover your costs? If you're making software purely to
contribute to society, where the money isn't important, what relevance
does this have to you increasing "your chances of survival 10-fold"?
Few people contribute to society whilst deliberately obscuring the
thing they're trying to contribute.

I'm not saying anyone deserves to earn a living just because they
created something, but that it is useful for them to be able to reduce
the ways in which others with more resources can replicate that
creation. You don't even need to be a 'successful' business to kill a
competitor, just to have more money in the bank for as long as the
competition exists. (eg. MS vs Netscape, Creative vs Aureal.)

While that is often true, I've already noted several disadvantages that
can outweigh pure financial superiority in such large businesses.

So, if we decide to ignore people waving pieces of paper around which
make some claim to an idea or some way of solving some problem, instead
investigating the actual code, others have pointed out already that if
you provide just a binary and there exist people who want to know what
you've done, those people will find it out whether you make it easy for
them or not.

>
Yes, in much the same way that there is no point ever locking your
doors or installing burglar alarms, as a determined thief will
eventually steal your belongings.

Despite the pictures various people seem intent on painting, most
contributions to this thread have focused on the tradeoffs involved in
"securing" algorithms via compilation, obfuscation, and so on.
Analogies about houses and alarms fail to capture the sophistication of
the matter, especially considering the different views on what your
belongings in the context of writing software for profit actually are.

I find it strange that people (at least on c.l.py) often equate
'imperfect protection' with 'pointless protection'. The all-or-nothing
attitude makes no sense. If you can halve the number of people who can
deduce your algorithm, that helps. If you can double the time it takes
for those people to deduce it, that also helps. If it took you months
of R&D, the value of even imperfect protection rises.

Imperfect protection isn't pointless but it comes at a cost. Perhaps
Skype's elaborate protection scheme gave that company such an advantage
over its competitors that having the scheme described publicly has had
little impact on its market position. However, such work doesn't just
happen at zero cost, and where people decide to "roll their own" rather
than purchase some kind of system to do the job, it can be quite a
distraction (both strategically and financially) from just focusing on
the rest of the business.

Now, if we sidestep the issue of decompiling binaries and
cast the affected work as some kind of service, the question can now be
expressed as whether you should expect to be rewarded forever for
providing such a service.

>
But what is 'forever'? Is it a single service for one customer that
persists forever? Or is it a service that will be invoked many times by
different customers forever? Since these are completely different
scenarios, the answer is "it depends".

That a continuous stream of possibly different people keep demanding
your service and rewarding you for having provided it. The real,
non-computing world exhibits an abundance of services, of course, and
the area where the "right" to profit from providing a service becomes
controversial is where monopolies are providing such services.
Technical protections (reinforced by strict legislation) and patents
also serve to impose monopolies, which is why people feel so strongly
about such matters.

[...]

I'm not interested in whether it's a sound business decision or not.
I'm just interested in the developer's right and/or ability to make
that call.

Of course the developer can make that call. The intention was to inform
such developers that yes, there are ways of protecting your "trade
secrets", but that it's better to understand the tradeoffs than to rely
totally on some potentially flawed solution.

[Cliff Richard's day at work]

On the other hand, writing musicians/composers typically will be paid
absolutely nothing for their original creation. They never get paid for
it as such, but they can (and typically do) yield the copyright to a
publishing company in return for an agreed royalty rate on sales of the
reproduced item. They don't so much get paid forever for a service
rendered long ago, they just have their payment spread out over an
indefinite period of time, and that is dependent on people buying that
item.

Agreed. The contracted sessions musician or car worker takes a
guaranteed amount home and bears little or no financial risk in
relation to the success of the product. If the worker had the
possibility of changing the nature of their remuneration, they might
expect to receive a lot less money initially for that day at work, but
to be rewarded more over the lifetime of a successful product. Still,
despite various share ownership incentives, it must still be puzzling
for someone with experiences of decades of work, having had very little
control over their means of reward, to see very well-rewarded people
(yes, even though they exposed themselves to a degree of risk) to be
requesting higher levels of reward, even if such requests are
ostensibly philanthropic.

This is no different from me investing my own time and money into
manufacturing 10,000 cars and selling them between now and 50 years
from now. The major difference is that replicating creative work is
typically much cheaper and easier than replicating automobiles, hence
the existence of various laws safeguarding intellectual property, as
without such laws there would be little incentive to create any such
works that were non-trivial. No-one is going to pay you up front for
it, so you need a way of protecting future potential income. Since that
future income is typically strongly linked to the quality of your work,
it's arguable that this is in fact a fairer business model than being
paid a normal salary.

The critical issues around the concept of "intellectu al property"
legislation involve various things you've mentioned in the above
paragraph, notably the cost of replicating creative work (but also the
cost of creating such works in many cases), the model through which new
products originate (manufacturing vs. other processes) and are provided
(sales vs. services), incentives (guaranteed financial rewards vs.
other motivations), as well as things like the apparent need for
society to encourage people to contribute new things. However, all this
has to be balanced against the effect on society: you selling 10000
cars over 50 years even with some kind of "right" to demand a
reasonable price for every single one of them may not in itself be
negative, but if it stops someone else from selling cars then the
people in society who make the rules have to then consider whether
their promises to you were overly generous, to the detriment of others
in society, or not.

Paul

[Gerhard Fiedler]

Re: hide python code !

On 2006-08-15 12:04:18, Alex Martelli wrote:

It just isn't worth Microsoft's while to take the public-relations hit
of such a fight: much cheaper for them to re-implement your ideas than
to copy your GPL'd code.

Exactly. So by publishing the ideas as GPL code, the author presents them
not only the ideas very clearly and well documented, but also an example
implementation. If there was some R&D work involved, it may be a better
thing (in terms of protection) not to publish it. The protection from GPL
is pretty much worthless if the worth is more in the principle than it the
execution.

Gerhard

[Alex Martelli]

Re: hide python code !

Gerhard Fiedler <gelists@gmail. comwrote:

On 2006-08-15 12:04:18, Alex Martelli wrote:
>

It just isn't worth Microsoft's while to take the public-relations hit
of such a fight: much cheaper for them to re-implement your ideas than
to copy your GPL'd code.

>
Exactly. So by publishing the ideas as GPL code, the author presents them
not only the ideas very clearly and well documented, but also an example
implementation. If there was some R&D work involved, it may be a better
thing (in terms of protection) not to publish it. The protection from GPL
is pretty much worthless if the worth is more in the principle than it the
execution.

Indeed, copyright is specifically meant not to cover ideas. However, if
you DO care specifically about Microsoft (and that was the company that
was specifically being discussed), I believe you could take advantage of
their policy forbidding employees from accessing GPL-covered materials
(for fear of them being "tainted" by it). If your fear is not
specifically one of Microsoft, then GPL is less likely to help (and I
won't get into a discussion of trade-secrets vs patents -- things vary
far too much amongst jurisdictions, differently from Copyright which
thanks to the Berne convention is "kinda" internationally standardized).

However, as may already have been mentioned in this thread, distributing
executable code _is_ "publishing " of the ideas it embodies, to all
intents and purposes, since many jurisdictions allow reverse
engineering, and the costs of the reverse engineering are not large for
ideas embodied in software (assuming those ideas _do_ have any
substantial value from a financial viewpoint, of course). It may be
worth looking into ways of monetizing the ideas that are less easy to
reverse engineer, such as webservices and custom hardware -- that is, as
always, for ideas of substantial worth, financially speaking (that is
different from the cost of the "R&D work", if any, which is a sunk cost
weakly correlated to a competitor's cost for re-developing the ideas
based even just on knowing that what they enable is indeed feasible).


Alex

[danielx]

Re: hide python code !

Fuzzyman wrote:

Bayazee wrote:

hi
can we hide a python code ?
if i want to write a commercial software can i hide my source code from
users access ?
we can conver it to pyc but this file can decompiled ... so ...!!
do you have any idea about this ...?

---------------------------------------
First Iranian Open Source Community : www.python.ir

>
>
You can distribute the compiled byte-code files (*.pyc) which are
harder to turn back into source code.
>
There was a product called decompyle which could do it, but although
there is a version floating around which works for Python 2.4 I've
never heard of anyone getting it to work.
>
Import hooks and encrypted source are a good option.
>
Py2exe embeds the byte-code file for your main script into the
executable which is also pretty good.
>
All of these make it hard enough to deter most people who will ever
want to abuse your source code. Until you have *lots* of users this is
probably enough.
>
I never understand the knee-jerk reaction on this mailing list to
answer people who ask this question by telling them they don't really
want to do it...

I'm I've compained about this before, but I'd say people apply that
response to alot of other things too here on this mailing list.

***

Earlier in this thread, people were making alot of noise about Bayazee
trying to protect the code while it seemed he was part of an open
source group. He never mentioned that he intended to hide any code
produced for this open source group; indeed, he never mentioned any
code he wished to hide at all. People must have been inferring that if
one is part of an open source group, that all work one produces is for
the group and must therefore be open source. Otherwise, people might
have been thinking that being a member of an open source group makes
you an open source evangelist.

If the latter is true (and these cases are neither mutually exclusive
nor exhaustive), then those who were so vocal in pointing out the
"appearant discrepency" must have been projecting their own views on
Bayazee. I'm not sure if this needs to be said, but just because
someone posts on comp.lang.pytho n does not mean he or she believe (or
even should believe) the same things as you!

My last statement applies to a few other things I've read around here,
but I'm going to be done for now...

>
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

[Steven D'Aprano]

Re: hide python code !

On Tue, 15 Aug 2006 09:00:16 -0700, Ben Sizer wrote:

Yes, in much the same way that there is no point ever locking your
doors or installing burglar alarms, as a determined thief will
eventually steal your belongings.

That's an utterly pointless and foolish analogy.

(1) If a thief breaks into your house and steals your TV, you no longer
have a TV. If a developer sees your code, you still have your code, *even
if they subsequently copy it*. You haven't lost your code, it is just no
longer secret. Since secrecy is rarely valuable in and of itself, you've
lost nothing.

Yes, I've heard all the stories about "valuable algorithms" and the like.
Some of them might even be true. But for 99+% of code, spending even one
cent to keep it secret is just wasting money.

(2) Compiling code to machine language isn't like locking your door.
Compiling code doesn't prevent me from seeing your code or your algorithm,
it just means I see it written in machine language instead of C. If I know
how to read machine code, or if I have a decompiler, then I can read it,
no problems at all. Would you argue that Python source code hides your
algorithm because it is inscrutable to people who can't read and
understand Python? Surely not. So why do you argue that compiled code is
hidden merely because it is inscrutable to people who don't know how to
download a decompiler off the Internet?

(3) Compiling code is certainly not like installing a burglar alarm. When
I decompile your code, no alarms ring and you are not notified.

I find it strange that people (at least on c.l.py) often equate
'imperfect protection' with 'pointless protection'.

Nonsense. Can I remind you that the Original Poster *explicitly* rejected
using Python's imperfect code-hiding technique (distribute only the
compiled .pyc files) because they can be disassembled, but failed to
realise that EXACTLY the same argument holds for compiled C code?

Let me make it clear with a better analogy than your locked door one: the
O.P. says "I don't want people to look through the windows of my Python
house. I thought about hanging curtains, but people with thermal imaging
equipment can see right through the walls. Can I hang vertical blinds in
Python like my C programmer friends?"

The answers are:

(1) No, Python uses curtains. If you want vertical blinds, use another
language.

(2) Even if you hang vertical blinds, it isn't going to stop people with
thermal imaging equipment from seeing into your house and copying your
algorithm, just like they can with Python.

The all-or-nothing
attitude makes no sense. If you can halve the number of people who can
deduce your algorithm, that helps. If you can double the time it takes
for those people to deduce it, that also helps. If it took you months
of R&D, the value of even imperfect protection rises.

Fine. But you haven't demonstrated how to do that. You're just plucking
figures out of the air. Anyone can do that: I claim that going to the
trouble of hiding code with (say) py2exe reduces the number of people who
can deduce your algorithm by 0.1%, and increases the time it takes them by
0.01%. Who is to say that my figures are not as good or better than yours?
Do you really think that (say) Microsoft has got neither decompilers nor
people who can operate them?



--
Steven D'Aprano

[danielx]

Re: hide python code !

Steven D'Aprano wrote:

On Tue, 15 Aug 2006 09:00:16 -0700, Ben Sizer wrote:
>

Yes, in much the same way that there is no point ever locking your
doors or installing burglar alarms, as a determined thief will
eventually steal your belongings.

>
That's an utterly pointless and foolish analogy.
>
(1) If a thief breaks into your house and steals your TV, you no longer
have a TV. If a developer sees your code, you still have your code, *even
if they subsequently copy it*. You haven't lost your code, it is just no
longer secret. Since secrecy is rarely valuable in and of itself, you've
lost nothing.

But haven't you lost your control over the code? If you were trying to
sell a program (regardless of whether this is a good way to make money
from it), hasn't your ability to do so been undercut? This is the loss.

>
Yes, I've heard all the stories about "valuable algorithms" and the like.
Some of them might even be true. But for 99+% of code, spending even one
cent to keep it secret is just wasting money.

That may be true, but for someone who has determined that the hiding
the code would be best, it would seem to be quite a good investment.
Besides, these kinds of decisions are made case by case. We would not
throw a dice to see whether some code should be released or not. Of
course, these kinds of statistics _should_ moderate any decision, but I
don't think you can expect that "99+%" will make sense to most
(intelligent) people.

But we have only considered the economics of such a decision. Even if
there is no market value to a work, a person has an understandable
desire to exercise the rights of ownership over a work, given the
amount of personal investment one makes in producing it. It's reall
just a form of acknowledgement (you may consider an alternative form of
acknowledgement more rewarding, but we are talking about the author,
not you). Considering the "investment " justificiation, I find it
difficult to deny an author the right to his or her own work (the right
to a work, of course, implies the option to protect it).

I think the above idea is frequently missed in discussions about
copyrights/patents in the open source world. There, the focus seems to
be on the marketability granted by protections (legal or physical). The
post I am responding to illustrates this focus. Do we believe an author
forfeits ownership of a work merely by sharing it? As a matter of
conscience, I don't believe the answer can be imposed on anyone. Every
person must answer this for him or herself.

>
(2) Compiling code to machine language isn't like locking your door.
Compiling code doesn't prevent me from seeing your code or your algorithm,

If a house is locked, it can still be entered (without the key). The
point is not that it is impossible to break in, but that it is more
difficult.

it just means I see it written in machine language instead of C. If I know
how to read machine code, or if I have a decompiler, then I can read it,
no problems at all. Would you argue that Python source code hides your

I know how to read asm, but if you say anyone can read asm just as
easily as one can read Python or even C, then you must be referring to
a machine.

algorithm because it is inscrutable to people who can't read and
understand Python? Surely not. So why do you argue that compiled code is
hidden merely because it is inscrutable to people who don't know how to
download a decompiler off the Internet?

It's all a matter of degree. The question of plausibility is always
relevant.

>
(3) Compiling code is certainly not like installing a burglar alarm. When
I decompile your code, no alarms ring and you are not notified.

That's pretty nit-picky...

>
>

I find it strange that people (at least on c.l.py) often equate
'imperfect protection' with 'pointless protection'.

>
Nonsense. Can I remind you that the Original Poster *explicitly* rejected
using Python's imperfect code-hiding technique (distribute only the
compiled .pyc files) because they can be disassembled, but failed to
realise that EXACTLY the same argument holds for compiled C code?
>
Let me make it clear with a better analogy than your locked door one: the
O.P. says "I don't want people to look through the windows of my Python
house. I thought about hanging curtains, but people with thermal imaging
equipment can see right through the walls. Can I hang vertical blinds in
Python like my C programmer friends?"
>
The answers are:
>
(1) No, Python uses curtains. If you want vertical blinds, use another
language.
>
(2) Even if you hang vertical blinds, it isn't going to stop people with
thermal imaging equipment from seeing into your house and copying your
algorithm, just like they can with Python.
>
>
>

The all-or-nothing
attitude makes no sense. If you can halve the number of people who can
deduce your algorithm, that helps. If you can double the time it takes
for those people to deduce it, that also helps. If it took you months
of R&D, the value of even imperfect protection rises.

>
Fine. But you haven't demonstrated how to do that. You're just plucking
figures out of the air. Anyone can do that: I claim that going to the
trouble of hiding code with (say) py2exe reduces the number of people who
can deduce your algorithm by 0.1%, and increases the time it takes them by
0.01%. Who is to say that my figures are not as good or better than yours?
Do you really think that (say) Microsoft has got neither decompilers nor
people who can operate them?

I think the point still stands. You seem to acknowledge it at first.
Your m$ example even supports it, because the number of people that
work there is relatively small, not to mention the fact that m$
employees need to be paid (they are paying with their souls aren't they
:P). Your way of getting around the point is just nit-picking at the
figures. Even if we don't take the "twice" figure literally, I imagine
that most of us would agree that the amount that the bar can be raise
is considerable and not insignificant.

An ancillary point: If the bar can be raised (considerably) at little
cost, then a person who wants to protect his or her code (for economic
reasons or otherwise) profits from going through the trouble.

In the end, if he find that the trouble was not worth the cost, it is
his or her loss. Anyone else's loss due to the (relative)
inaccessibility of the code should not be the author's responsibility.
ie, the author should be under no obligation to save someone else the
trouble of accessing the code unfettered (imho).

>
>
>
--
Steven D'Aprano

[enigmadude]

Re: hide python code !

I'm pretty sure that just because someone is familiar with the PGP
sources, for example, doesn't mean that they have the necessary keys to
access other people's data across the internet. Also, I'm pretty sure I
know how a prison door lock works, but if I'm behind bars and don't
have the key, I'm still screwed.

I believe the same things applies here. Just because you can see the
import code, depending upon what it does, if it requires (for example)
a key in order to decrypt the binary data before the modules can be
loaded, then no matter how much you understand the import code, the
data itself (that is the binary encrypted modules) is still useless to
you.

In any case, everyone is correct in that any program can be reverse
engineered, just like any vehicle can be car-jacked. The point is to
have an at least rudimentary deterrent that makes it not worth their
while. Someone who's smart enough to crack a scheme like this is
probably a smarter programmer than the person who wrote the code in the
first place, and so has no need to be stealing newbie's code.

In any case, I prefer that people get over their greed and paranoia and
just keep Python code open. I agree with most people here. I'm not an
expert programmer, and many people I know aren't either, but for some
reason the whole "intellectu al property" boogeyman keeps making
programmers believe that they have to hide even every example of a
linked list or sort function. Geez. Just keep the sources open people.

Slawomir Nowaczyk wrote:

On Thu, 10 Aug 2006 17:35:27 -0700
enigmadude <enigmadude@roc k.comwrote:
>
#2. I've never done this, but you might be able to encrypt or otherwise
#turn you modules into binary form, and then use a clever import
#hook.
>
Please observe that whatever the "clever import hook" is, it actually
needs to know the way to *decrypt* the module (secret key or
whatever). It means that if somebody decompiles the importing code, he
can just as well decompile the "hidden" one.
>
--
Best wishes,
Slawomir Nowaczyk
( Slawomir.Nowacz yk@cs.lth.se )
>
Children are natural mimics, who act like their parents despite
every effort to teach them good manners.

[Steven D'Aprano]

Re: hide python code !

On Wed, 16 Aug 2006 13:39:10 -0700, danielx wrote:

Steven D'Aprano wrote:

>On Tue, 15 Aug 2006 09:00:16 -0700, Ben Sizer wrote:
>>

Yes, in much the same way that there is no point ever locking your
doors or installing burglar alarms, as a determined thief will
eventually steal your belongings.

>>
>That's an utterly pointless and foolish analogy.
>>
>(1) If a thief breaks into your house and steals your TV, you no longer
>have a TV. If a developer sees your code, you still have your code, *even
>if they subsequently copy it*. You haven't lost your code, it is just no
>longer secret. Since secrecy is rarely valuable in and of itself, you've
>lost nothing.

>
But haven't you lost your control over the code? If you were trying to
sell a program (regardless of whether this is a good way to make money
from it), hasn't your ability to do so been undercut? This is the loss.

Maybe so. And if a competitor creates a better product than yours, hasn't
your ability to sell your program been undercut too?

Either scenario has NOTHING to do with thieves breaking into your house
and locks on doors. The analogy is bogus. Undercutting your ability to
sell a product is not theft, and compiling source code to machine code is
not analogous to a lock on the door.

>Yes, I've heard all the stories about "valuable algorithms" and the like.
>Some of them might even be true. But for 99+% of code, spending even one
>cent to keep it secret is just wasting money.

>
That may be true, but for someone who has determined that the hiding
the code would be best, it would seem to be quite a good investment.

Whether it "seems" to be a good investment is quite different from whether
it *is* a good investment.

If they ask me for advice, I'll tell them that they're almost certainly
wasting their time, that their algorithm almost certainly isn't as
valuable as they think, and that if they disagree, well, Python supports
..pyc files, there are tools like py2exe which will put their Python code
inside an exe file, there is a Python obfuscator, and a few other tricks.
If none of those things are good enough for them, then Python is not the
language they want to be using.

As for the rest of your post, it is mostly irrelevant. However, I will
answer one last point:

[snip]

Even if we don't take the "twice" figure literally, I imagine
that most of us would agree that the amount that the bar can be raise
is considerable and not insignificant.

I dispute that "most of us" agree that the bar can be raised a
considerable amount. It is my position that in the real world, as opposed
to the fantasies of amateur programmers, compiling code is virtually NO
BARRIER to your competitors understanding your algorithm.

Perhaps you would like to consider how it is that black-hat hackers and
virus writers can analyse Microsoft Windows for vulnerabilities and
security holes *without access to the source code*?

(And by the way: your suggestion that Microsoft has very few workers is
wrong. Microsoft has approximately 60,000 employees, and that almost
certainly doesn't include the many sub-contractors they hire.
http://www.networkworld.com/news/fin...microsoft.html )



--
Steven D'Aprano

[Paul Boddie]

Re: hide python code !

danielx wrote:

>
But we have only considered the economics of such a decision. Even if
there is no market value to a work, a person has an understandable
desire to exercise the rights of ownership over a work, given the
amount of personal investment one makes in producing it.

There are other motivations, too. An author might wish that their work
convey a particular message and that others should not be able to make
derived works which distort or contradict that message. However, there
are various established principles of fair use which limit the author's
control over such derived works.

[...]

I think the above idea is frequently missed in discussions about
copyrights/patents in the open source world. There, the focus seems to
be on the marketability granted by protections (legal or physical). The
post I am responding to illustrates this focus. Do we believe an author
forfeits ownership of a work merely by sharing it? As a matter of
conscience, I don't believe the answer can be imposed on anyone. Every
person must answer this for him or herself.

As we've mentioned above, one crucial issue is control over published
works and over the potentially related works of others. With software,
such control is mediated by the licence which is often prominent, even
unavoidable when using proprietary software; thus, people using or
distributing software should be aware of the licence which applies to
the work. In contrast, works in areas such as popular music are not
prominently "labelled" with licensing information if you're listening
to that music playing on the radio, television, in a public space, and
so on. This apparent "promiscuit y" with such works leads people to
believe that they are freely exchangeable and that the author is not
exercising control, even if that isn't really the case due to the
framework established by the recording industry for broadcasters.

So, people perceive an apparent lack of control as some kind of lack of
ownership, that the work has, by being shared in an apparently
unconditional way, become part of their common culture - a sentiment or
an understanding that can presumably be traced back throughout the
history of human culture itself. At the opposite end of the spectrum of
control, when mechanisms of control are used to restrict the
distribution of derived works or the production of coincidentally
related works, is it unfair that people wish to disregard such
apparently counter-intuitive mechanisms? An interesting example in
popular culture was the legal argument about whether silence
constitutes an original work
(http://news.bbc.co.uk/1/hi/entertain...c/2133426.stm), but
things like patents affect the ability of others to create works in a
fashion that can be much harder to predict.

Paul