hide python code !

[Fuzzyman]

Re: hide python code !


Paul Boddie wrote:
[snip..]

I've previously mentioned a very interesting paper which not only
described the reverse engineering of the Skype protocol and software
but also described how to make interoperating Skype clients. Given that
the well-financed developers spent a lot of time introducing various
protection measures (encryption, verification, etc.) and yet someone
can write the aforementioned stuff up in a paper, I'd recommend an
upgrade to any business plan which relies on obfuscation to prevent
"unauthoris ed" use or modification. Indeed, I'd recommend that any such
entrepreneur think twice about starting a traditional proprietary
software business in this day and age.
>

How many users did skype have before that happened...

Several orders of magnitude above what is required to earn a living
from selling a few programs I suspect.

Fuzzyman

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

Paul

[Paul Boddie]

Re: hide python code !

Fuzzyman wrote:

Bayazee wrote:

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 ...!!

[...]

You can distribute the compiled byte-code files (*.pyc) which are
harder to turn back into source code.

As the man said, and I've seen various proprietary software companies
do just that.

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.

I've got decompyle to work in the recent past (about a year or so ago)
- the trick was to find the Debian package and to make some minor
adjustments to the code to work with whatever breakage the 2.3 -2.4
upgrade caused.

[...]

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...

Well, given the pace of technological development and the disregard in
some environments for perpetual backward compatibility, how much of
your infrastructure would you implement in vendor-supplied binaries,
especially when the vendor is a one man plus dog operation? When the
binaries don't work on your newly-upgraded system and the vendor is on
holiday (possibly for good), it doesn't look like a knee-jerk reaction
any more.

Paul

[Tim Chase]

Re: hide python code !

>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 ...!!

>
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 think the reaction is based mostly in reality...an honest
answer: If you give people the program, then you also give them
the ability to reverse engineer it. It's as simple as that.

No matter how dongled, obfuscated, compiled, encrypted, etc. At
some point the code actually has to be executed/interpreted, and
at that point, it can be intercepted. Thus, "by telling them
that they don't really want to do it", the list is conveying the
futility of attempting to strive for the goal. Obfuscation may
be a shallow speedbump, and for some folks, better than nothing.
However, it's better to have a good relationship with your
customers and know that they will adhere to licensing conditions,
rather than to try and strong-arm them into behaving a particular
way.

My "%s%0.2f" % (currency_marke r, 0.02) on the matter. :)

-tkc

[Fuzzyman]

Re: hide python code !


Paul Boddie wrote:

Fuzzyman wrote:

Bayazee wrote:

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 ...!!

>
[...]
>

You can distribute the compiled byte-code files (*.pyc) which are
harder to turn back into source code.

>
As the man said, and I've seen various proprietary software companies
do just that.
>

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.

>
I've got decompyle to work in the recent past (about a year or so ago)
- the trick was to find the Debian package and to make some minor
adjustments to the code to work with whatever breakage the 2.3 -2.4
upgrade caused.
>
[...]
>

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...

>
Well, given the pace of technological development and the disregard in
some environments for perpetual backward compatibility, how much of
your infrastructure would you implement in vendor-supplied binaries,
especially when the vendor is a one man plus dog operation? When the
binaries don't work on your newly-upgraded system and the vendor is on
holiday (possibly for good), it doesn't look like a knee-jerk reaction
any more.
>

If you distribute applications with py2exe then your application is no
longer dependent on the installed version of Python.

The question keeps getting asked because a lot of new programmers are
looking to create programs that they will sell. A lot of these will be
good programmers, and some of the software will be successful. Telling
them 'you can't do that with Python', does no good to Python itself.

In fact what you can do with Python is not a lot worse than most other
languages, and almost certainly *good enough* for this sort of thing.

Fuzzyman

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

Paul

[Fuzzyman]

Re: hide python code !


Tim Chase wrote:

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 ...!!

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 think the reaction is based mostly in reality...an honest
answer: If you give people the program, then you also give them
the ability to reverse engineer it. It's as simple as that.
[snip..]

But until your number of users gets beyond quite a high level, it's
just extremely likely that any of your individual users will have that
sort of ability - or anyone else will have the motivation to do it.

What you can do with Python is almost certainly *good enough* for most
people who ask this question - and that fact never seems to be included
in the 'reality' propogated by the knee jerk reactionists... :-p


Fuzzyman

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

[Paul Boddie]

Re: hide python code !

Fuzzyman wrote:

Paul Boddie wrote:

[Skype paper]

I'd recommend an
upgrade to any business plan which relies on obfuscation to prevent
"unauthoris ed" use or modification. Indeed, I'd recommend that any such
entrepreneur think twice about starting a traditional proprietary
software business in this day and age.

>
How many users did skype have before that happened...
>
Several orders of magnitude above what is required to earn a living
from selling a few programs I suspect.

The point was that dreaming up exotic "protection " schemes for closed
source software is quite possibly only the highest priority in either a
highly traditional shrinkwrapped proprietary software business (where
the evidence - my spam folder - suggests that the "protection " is only
a marginally effective deterrent) or in some kind of proprietary
software plus services business where you don't want people tampering
with your infrastructure (where the evidence suggests that anyone
determined enough will force you to continually focus on that
"protection " scheme over the long-term).

So, if the questioner just wants to sell a few programs, they might
want to either consider different business models than those
traditionally envisaged, or they might want to be aware that fancy
"protection " is most likely to be a long-term investment yielding
moderately disappointing results, and that their energy is best
directed elsewhere.

Paul

[Fuzzyman]

Re: hide python code !


Tim Chase wrote:
[snip....]

However, it's better to have a good relationship with your
customers and know that they will adhere to licensing conditions,
rather than to try and strong-arm them into behaving a particular
way.
>

Don't forget that distributing your source code is more of a gift to
your competitors (and potential competitors) than it is to your
customers...

Fuzzyman

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

My "%s%0.2f" % (currency_marke r, 0.02) on the matter. :)
>
-tkc

[Paul Boddie]

Re: hide python code !

Fuzzyman wrote:

Paul Boddie wrote:

Fuzzyman wrote:

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...

Note your choice of words: "don't really want to do it".

[...]

If you distribute applications with py2exe then your application is no
longer dependent on the installed version of Python.

But there are numerous other things that might stop whatever binary it
is from working over longer periods of time. Besides, py2exe
executables don't exactly exhibit various typical benefits of normal
Python programs such as being able to run on more than one platform,
unless you recommend that everyone runs those applications in some kind
of Windows virtualisation solution.

The question keeps getting asked because a lot of new programmers are
looking to create programs that they will sell. A lot of these will be
good programmers, and some of the software will be successful. Telling
them 'you can't do that with Python', does no good to Python itself.

But many people admit that solutions do exist, notably py2exe and other
tools which do very similar things but for more than one platform (and
have done so for at least a decade). Now you did say that people are
being made to feel that they "don't really want to do it", but that's a
very different thing from being told that they "can't do that with
Python".

Personally, I'd rather people chose not to do such things with Python,
for various reasons including the inability of the end-user to study or
fix bugs in the code or to take advantage of various well-known
benefits of the Python language, library and runtime. But I do admit
that they at least can achieve some level of obfuscation or
"protection " for such endeavours (and a suitably-phrased Web search
will provide established solutions for doing just that).

Paul

[Helmut Jarausch]

Re: hide python code !

John Machin 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

^^^^^^^^^^^^^^^ ^^^^^^^^^[1]

>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

^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^[2]
>
>
[1] and [2] don't seem to be compatible.

I suppose all of you who have commented about this, are sitting in the

>>free world <<< .

But there are countries (like .ir) where the government has totally different
ideas of 'freedom'. So taking the freedom to write something can be very
dangerous at times. Fortunately most of those guys which intercept every
email and check every web server are not so smart to reverse engineer
everything in a short time since they have to check thousands of pieces of
information each day. Let's make their work a bit harder!

[Ben Sizer]

Re: hide python code !

Paul Boddie wrote:

Fuzzyman wrote:

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...

>
Well, given the pace of technological development and the disregard in
some environments for perpetual backward compatibility, how much of
your infrastructure would you implement in vendor-supplied binaries,
especially when the vendor is a one man plus dog operation? When the
binaries don't work on your newly-upgraded system and the vendor is on
holiday (possibly for good), it doesn't look like a knee-jerk reaction
any more.

It's worth remembering that there is a massive amount of software that
has nothing to do with 'infrastructure ', that won't need to be
maintained, or upgraded. Examples include most retail software for the
home or small office, and most entertainment software. Developers of
such software often have understandable reasons for making it
inconvenient to examine the algorithms at a high level.

--
Ben Sizer

[Duncan Booth]

Re: hide python code !

Fuzzyman wrote:

Tim Chase wrote:
[snip....]

> However, it's better to have a good relationship with your
>customers and know that they will adhere to licensing conditions,
>rather than to try and strong-arm them into behaving a particular
>way.
>>

>
Don't forget that distributing your source code is more of a gift to
your competitors (and potential competitors) than it is to your
customers...
>

I believe Eric Raymond has argued that if your competitors are spending
their time trying to work out how to adapt to using your software, that is
time they aren't spending competing with you. So long as you make regular
releases of your software you can ensure that they are always at least one
step behind you.

[Paul Boddie]

Re: hide python code !

Ben Sizer wrote:

>
It's worth remembering that there is a massive amount of software that
has nothing to do with 'infrastructure ', that won't need to be
maintained, or upgraded. Examples include most retail software for the
home or small office, and most entertainment software. Developers of
such software often have understandable reasons for making it
inconvenient to examine the algorithms at a high level.

It may be the case that certain kinds of applications can go on working
forever on whatever hardware they were intended to run, right until the
point when the hardware ceases to function correctly or when the
end-user gets bored of it, or envious of the neighbour's hardware, or
for whatever other reason. However, I've seen plenty of evidence of
"home or small office" software which arrives as a binary, employs its
own proprietary format, runs on now-legacy hardware and whose users are
now high-and-dry with respect to accessing their old documents.

Sure, developers of such software may not want their competitors to
find out how their products work - certain companies also like to file
patents for that added anticompetitive edge, should their competitors
even consider figuring out the not-so-magic formula - but as end-users
of software ourselves, we don't have to share such an understanding of
their motivations, especially when such motivations directly conflict
with our own: with respect to the above evidence, our own motivations
are to have a reasonable level of control over the tools to manage our
own data.

It may not matter if some console game or other doesn't work after 20
years, although I think it's actually something of a shame given that
such artifacts, no matter how apparently trivial they are, are actually
part of our culture and shouldn't be so readily discarded and
forgotten, but when your own data is not easily accessible within a
much shorter timeframe, the scandal is (at least to me) so much more
obvious.

Paul

[Ben Sizer]

Re: hide python code !

Paul Boddie wrote:

Ben Sizer wrote:

It's worth remembering that there is a massive amount of software that
has nothing to do with 'infrastructure ', that won't need to be
maintained, or upgraded. Examples include most retail software for the
home or small office, and most entertainment software. Developers of
such software often have understandable reasons for making it
inconvenient to examine the algorithms at a high level.

>
Sure, developers of such software may not want their competitors to
find out how their products work - certain companies also like to file
patents for that added anticompetitive edge, should their competitors
even consider figuring out the not-so-magic formula - but as end-users
of software ourselves, we don't have to share such an understanding of
their motivations, especially when such motivations directly conflict
with our own: with respect to the above evidence, our own motivations
are to have a reasonable level of control over the tools to manage our
own data.

I think you're possibly being a bit idealistic here. I use and endorse
open source and open formats wherever possible but I don't believe we
would have the same degree of diversity of software available if
everything was open.

Imagine if you were the single-person developer of a small application
that did something quite innovative, and charged a small fee for your
product. Now imagine you were practically forced to make your algorithm
obvious - a couple of months later, Microsoft bring out a freeware
version and destroy your business in an instant. Sure, they and others
can (and have) done that with closed-source products, but you increase
your chances of survival 10-fold if the key algorithms are not obvious.

The only other way to protect against that would be a software patent,
and I disagree with their existence on the grounds that it punishes
those who discover the techniques independently.

It may not matter if some console game or other doesn't work after 20
years...

Certainly; yet this is a valid example of software that requires a
degree of protection since some of the algorithms employed truly are
'worth stealing'. They can usually be replicated in time, but that may
be months and allows the original company to have a deserved commercial
advantage.

...although I think it's actually something of a shame given that
such artifacts, no matter how apparently trivial they are, are actually
part of our culture and shouldn't be so readily discarded and
forgotten...

Thankfully we have emulators for most platforms, and hopefully
litigation won't kill those off.

...but when your own data is not easily accessible within a
much shorter timeframe, the scandal is (at least to me) so much more
obvious.

I think it's quite possible to have a closed binary but an open
document format, thus allowing the user to migrate away at any point
while still preserving any 'secrets' in the implementation.

--
Ben Sizer

[Terry Reedy]

Re: hide python code !


"Fuzzyman" <fuzzyman@gmail .comwrote in message
news:1155300852 .497741.73230@7 4g2000cwt.googl egroups.com...

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...

Let's clarify the question: "Dear Python programmers: please tell me for
free how I can hide my code from you and others like you."

This question has nothing to do with preventing blind copying of
distributed software, whether in source or binary form.

tjr

[Paul Boddie]

Re: hide python code !

Ben Sizer wrote:

>
Imagine if you were the single-person developer of a small application
that did something quite innovative, and charged a small fee for your
product. Now imagine you were practically forced to make your algorithm
obvious - a couple of months later, Microsoft bring out a freeware
version and destroy your business in an instant. Sure, they and others
can (and have) done that with closed-source products, but you increase
your chances of survival 10-fold if the key algorithms are not obvious.

This point is fairly comprehensively answered in the following article:

http://radar.oreilly.com/archives/2006/08/apple_eats_whiners.html

The only other way to protect against that would be a software patent,
and I disagree with their existence on the grounds that it punishes
those who discover the techniques independently.

And that's not all. Even if you accept the granting of patents for
mathematical or scientific processes (which I don't), it's hard to
justify people privatising the commons by building on the freely
available knowledge which made their own work possible whilst holding a
monopoly which not only prevents others from building on that work, but
also, as you say, from building anything similar independently or
otherwise from the starting point of that prior knowledge.

[...]

Thankfully we have emulators for most platforms, and hopefully
litigation won't kill those off.

Hopefully, yes. But the wider issue is that of ownership of culture and
whether such a concept makes sense. When you're having some popular
music involuntarily pumped into your consciousness through multiple
channels of the media, do you not have the right to say that since
you've heard the song in question umpteen times, and that the "rights
holder" was quite happy to have the work broadcast on the radio, on
television, in the shopping mall, at the airport, and so on, that you
should then be able to record the song, play it back whenever, however
and how often you like, or perhaps remix it, parody it, cover it, or
play it backwards at your leisure?

The stuff about patents, small companies supposedly innovating and
popular culture intersect quite nicely around things like copyright
expiry. I read an article where various aging popular musicians were
lobbying the British government to extend the period of copyright
beyond 50 years because their first works would soon fall into the
public domain and that they'd no longer earn royalties on those works.
But in what percentage of the many other jobs that exist do you still
get paid for a day at work that happened over 50 years ago?

[...]

I think it's quite possible to have a closed binary but an open
document format, thus allowing the user to migrate away at any point
while still preserving any 'secrets' in the implementation.

That's the point of view held by certain software vendors, but many
vendors have sadly failed to resist the temptation to lock users in
completely, using every available technique to make it almost
impossible to migrate. And then the end-users are faced with migrating
away from obsolescence. It doesn't matter if it's a Fortune 500 company
or just some individual whose data is at risk: putting the "competitiv e
advantage" of the vendor before that data is plainly unethical.

Paul