Python obfuscation
petantik
code or byte code and what are their relative advantages or
disadvantages. I wonder because there are some byte code protection
available for java and .NET, although from what i've read these seem to
be not comprehensive as protection schemes
http://petantik.blogsome.com - Telling it like it is
Fredrik Lundh
> Are there any commercial, or otherwise obfuscators for python source
> code or byte code and what are their relative advantages or
> disadvantages. I wonder because there are some byte code protection
> available for java and .NET, although from what i've read these seem to
> be not comprehensive as protection schemes
hmm. is google down today?
http://www.lysator.liu.se/~astrand/projects/pyobfuscate/
pyobfuscate is a source code obfuscator: It makes Python source code
hard to read for humans, while still being executable for the Python
interpreter.
</F>
bon...@gmail.com
kind of code hard(hopefully impossible) ? The most effective would be
renaming function and may be variables but if the functions are kept
short, they would at most looks like haskell ;-)
Steve Holden
> Are there any commercial, or otherwise obfuscators for python source
> code or byte code and what are their relative advantages or
> disadvantages. I wonder because there are some byte code protection
> available for java and .NET, although from what i've read these seem to
> be not comprehensive as protection schemes
>
some code worth protecting, which is to say it should have some novel
features or represent a lot of work that offers useful integrated
functionality for a task or a skill area.
Most inquiries of this nature appear to fall at that first hurdle.
There are things you can do, but I'm always keenly aware that very few
users of a program have both the skills and the inclination to rip off
the code even when the source is distributed as part of the product.
Personally I've never bothered with obfuscation, and prefer to rely on
copyright when I deliver code to customers.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
The Eternal Squire
1) Add a system path for decryption keys.
2) Add a system path for optional decryptors supplied by user
(to satisfy US Export Control)
3) When importing a module try: import routine except importation
error : for all decryptors present for all keys present run decryptor
upon module and retry, finally raise importation error.
With PGP encryption one could encrypt the pyc's with the private key
and sell a public key to the end user.
The Eternal Squire
Jean-Paul Calderone
What's to stop someone from publishing the decrypted code online for anyone to download?
Jean-Paul
Yu-Xi Lim
> Before adding complex protection mechanisms to your code you first need
> some code worth protecting, which is to say it should have some novel
> features or represent a lot of work that offers useful integrated
> functionality for a task or a skill area.
>
> Most inquiries of this nature appear to fall at that first hurdle.
>
> There are things you can do, but I'm always keenly aware that very few
> users of a program have both the skills and the inclination to rip off
> the code even when the source is distributed as part of the product.
> Personally I've never bothered with obfuscation, and prefer to rely on
> copyright when I deliver code to customers.
As you said, if you have some novel features, you will need obfuscation.
Copyright doesn't protect the process and patents may take a while. In
the meanwhile, good obfuscation is reasonable protection, imho.
But I think you failed to note that it may not be a novel feature or
useful functionality. In fact, it might be the opposite: a function the
users want removed. A typical example would be a shareware registration
or nag screen. When the users have to start paying, they might then feel
inclied to "rip off the code", or in this case, rip out the code.
Mike Meyer
> How effective can it be when python is designed to make writing this
> kind of code hard(hopefully impossible) ? The most effective would be
> renaming function and may be variables but if the functions are kept
> short, they would at most looks like haskell ;-)
I haven't looked at obfuscator, so I have *no idea* how it works. The
following is how I'd do it.
Step one: globally replace all names in all python module withb names
that are composed of long strings of l, 1, 0 and 0. Fixing
cross-module references should be fun. Don't just make them random -
make them all start with the same sequence, and end with the same
sequence, having differences only in the middle.
Step two: repeat this process for the contents of binary modules, not
neglecting __builtins__. In this case, you probably can't remove the
old names, but you can add new things to the module, and make sure you
only reference those.
I'm not sure how to go about fixing things that are referenced by name
in binary modules. Maybe you'll have to leave those names in the
modules. But you an make sure that all references in Python source use
the new, binary-like names.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
petantik
This is what I am talking about. If you look at programs written in C,
or others that compile into native binaries, there are many protection
schemes which are mainly used not to protect some novel process but to
ensure that their commercial software remains marketable.
People who download cracks/serial numbers rarely care about copyright.
So when python is used in more commercial software some sort of high
grade obfuscation may be needed. These packers sometimes also have an
embedded compression so that it can decompress the code 'on the fly'
reducing filesizes
http://petantik.blogsome.com - A Lucid Look at Reality
sjde...@yahoo.com
> Step one: globally replace all names in all python module withb names
> that are composed of long strings of l, 1, 0 and 0. Fixing
> cross-module references should be fun. Don't just make them random -
> make them all start with the same sequence, and end with the same
> sequence, having differences only in the middle.
Eliminating the original variable names may be useful in obfuscation,
but this doesn't seem to buy much over just replacing with random
strings; it's trivial to do a similar replacement to go from "10Oll10"
strings to "firstVariable", "secondVariable", etc strings.
Anand S Bisen
would be to convert some of the meat inside my programs to C/C++ and
then provide the interface to those novel ideas to Python using swig.
And for another level of protection maybe use these offuscator on the
remaining Python source. What do you think ?
Anand S Bisen
Grant Edwards
> I dont know much !! But if somebody asks me this question my
> answer would be to convert some of the meat inside my programs
> to C/C++ and then provide the interface to those novel ideas
> to Python using swig. And for another level of protection
> maybe use these offuscator on the remaining Python source.
> What do you think ?
Um... sounds like an excellent way to burn hours while
introducing bugs and security problems?
--
Grant Edwards grante Yow! I feel... JUGULAR...
at
visi.com
Carl Friedrich Bolz
bon...@gmail.com wrote:
> How effective can it be when python is designed to make writing this
> kind of code hard(hopefully impossible) ? The most effective would be
> renaming function and may be variables but if the functions are kept
> short, they would at most looks like haskell ;-)
>
There just cannot be a python obfuscator that works for a general python
program. The problem is that on the one hand regular strings can be used
to lookup values in namespaces (e.g. with getattr) and on the other hand
the lookup of names can be controlled (e.g. with __getattr__ and
friends). Therefore any string can potentially contain a name that would
have to be changed to keep the code working after obfuscation. For
example how would you automatically obfuscate the following code:
class HelloWorld(object):
def hello(self):
return "world"
def world(self):
return "!"
if __name__ == '__main__':
h = HelloWorld()
s = "hello"
while 1:
f = getattr(h, s, None)
print s,
if f is None:
break
s = f()
While this is surely a contrived case that intentionally mixes names and
strings that are used for something in the application there are also
quite often legitimate use cases for this sort of behaviour. Duck typing
is basically based on this.
Cheers,
Carl Friedrich Bolz
Alex Martelli
> I dont know much !! But if somebody asks me this question my answer
> would be to convert some of the meat inside my programs to C/C++ and
> then provide the interface to those novel ideas to Python using swig.
> And for another level of protection maybe use these offuscator on the
> remaining Python source. What do you think ?
I think that's feeble protection. If you have valuable code, and
distribute it, people WILL crack it -- just check the warez sites for
experimental proof... EVERYTHING that people are really interested in
DOES get cracked, no matter what tricky machine-code the "protections"
are coded in.
There's ONE way to have uncrackable code -- don't distribute it, but
rather put it up on the net on a well-secured machine under your
control, available as (say) a webservice (subscription-only, pay per
use, or whatever business model you want). You can distribute all the
parts of your app that aren't worth protecting as a "fat client" app (in
Python or whatever) and keep those which ARE worth protecting on the
server that YOU control (and make sure it's very, VERY safe, of course);
and you may write the precious parts in Python, too, no problem.
This is (a minor) one of the many reasons that make webservices the way
of the future (hey, even *MSFT* noticed that recently, it seems...).
There are many other advantages, especially if you keep the clients
thin. The only issue is, your apps will require network connectivity to
execute... but these days, with airlines and train lines busy adding
wi-fi, and towns busily blanketing themselves with free wi-fi, etc, etc,
that's less and less likely to be a big problem...
Alex
The Eternal Squire
1) The decrypted modules should only reside in RAM, never in virtual
memory. Those RAM locations should be rendered inaccessible to Python
code.
2) Only sell to an honest customer willing to be locked into
nondisclosure agreements. This goes back to the maxim of good
salesmanship: Know Your Customer.
By definition, a lock keeps honest people out. The object of a lock is
to make it too expensive for all but the most dishonest, desperate, or
nihilistic to get into the house, because they can always smash a
window or a door open.
IMHO, I have never encountered a dishonest developer or business owner
who at the same time possessed anything remotely resembling a rational
business model. A person who cannot afford to get tools honestly is
seldom able to accomplish anything significant or constructive from a
business point of view with tools obtained dishonestly.
Consider EDA software like Cadence, Matlab, or BEACON that is guarded
by network license servers. The temptation is very strong for an
individual to rip it off, but then consider all the user technical
support and bug fixes that go into the package. Most relatively honest
people see a strong lock and get the message not to try. The others
who may rip off a locked package, but then the package becomes
worthless not because it doesn't work, but because the thief has to
work completely outside the knowledge base that an honest copy has
access to.
I have heard of the warez culture, but it seems to be nihilistic in the
extreme. I don't search for warez, I don't touch warez, and I do not
recommend anyone else to do so, because using it is simply bad business
practice and will get one ostracised by the very people one wants to
sell to. But at the end of the day it seems to serve as an
unauthorized marketing and sales channel to whet the appetites for
people to try the real thing.
The Eternal Squire
yepp
>
> 1) The decrypted modules should only reside in RAM, never in virtual
> memory. Those RAM locations should be rendered inaccessible to Python
> code.
I'm starting to understand why FOSS developers are said to be productive
above the average: they don't have to mess their brains with stuff like
that.
> snip
>
> IMHO, I have never encountered a dishonest developer or business owner
> who at the same time possessed anything remotely resembling a rational
> business model.
>
Ah, what was the name of that company in ... mh, was it Redmond?
Once you got the model of free and open source software you can't but shake
your head at obfuscating people treating their users as enemies.
Intellectual property suffers in most cases from a significant lack of the
intellectual part.
Steven D'Aprano
> As you said, if you have some novel features, you will need obfuscation.
> Copyright doesn't protect the process and patents may take a while. In
> the meanwhile, good obfuscation is reasonable protection, imho.
>
> But I think you failed to note that it may not be a novel feature or
> useful functionality. In fact, it might be the opposite: a function the
> users want removed. A typical example would be a shareware registration
> or nag screen. When the users have to start paying, they might then feel
> inclied to "rip off the code", or in this case, rip out the code.
Which leads to the important counter-question. Since there is a Python
obfuscator, is there a Python un-obfuscator? I am aware that not all
obfuscations can be reversed, but some can.
--
Steven.
Steven D'Aprano
> The Eternal Squire wrote:
>
>>
>> 1) The decrypted modules should only reside in RAM, never in virtual
>> memory. Those RAM locations should be rendered inaccessible to Python
>> code.
>
> I'm starting to understand why FOSS developers are said to be productive
> above the average: they don't have to mess their brains with stuff like
> that.
That's not *quite* true. There are FOSS programs that actually do care
about security. For instance, if you are encrypting data, you don't want
the memory containing the plaintext to be swapped to your swap
partition, where raw disk tools can recover it.
But as a general rule, you're right. If you, the developer, don't have to
think of your users as the enemy, you'd be amazed the amount of make-work
you don't have to do.
--
Steven.
sk...@pobox.com
Steven> But as a general rule, you're right. If you, the developer,
Steven> don't have to think of your users as the enemy, you'd be amazed
Steven> the amount of make-work you don't have to do.
+1 QOTW.
Skip
petantik
I think that is not workable because it is easy to say the the internet
is available everywhere.
It is not available in developing countries or in rural areas and so
these people who live/work there will never benefit from a webservice
type protection scheme, and what if the network in your area goes down?
bye bye app that I *really* need for tomorrow. Reliability is
important but so is protecting your code in an effective manner
I do believe that you are right about those that crack software for
kicks or money. If you look around at you local market place i'm sure
there are many 'discounted' commercial softwares/games sold. of course
the big software companies might say 'trusted computing will save us'
but I for one will never truly trust it.
Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?
Ben Sizer
> If you have valuable code, and
> distribute it, people WILL crack it -- just check the warez sites for
> experimental proof... EVERYTHING that people are really interested in
> DOES get cracked, no matter what tricky machine-code the "protections"
> are coded in.
That is very black and white thinking. It may be true that everything
gets cracked, but there are different degrees to which it might harm
your business model. On top of that, some users may be reluctant to
install binary cracks from obviously disreputable sources. Who knows
what spyware or viruses you could catch? Compare that to the simplicity
and safety of someone posting instructions to "open secure.py in
notepad, and change the 'if license_found:' line to 'if 1:'", for
example. No risk and even less effort than applying a patch.
If someone wants to break into your house, they will get in. But it's
still worth taking some precautions (locks, alarms, whatever) to reduce
the probability.
> There's ONE way to have uncrackable code -- don't distribute it, but
> rather put it up on the net on a well-secured machine under your
> control, available as (say) a webservice (subscription-only, pay per
> use, or whatever business model you want).
This is all well and good when:
- web access is free (it's not if you're on dialup, or on a portable
device/phone)
- web access is fast enough (it's not if you're working with certain
types of real-time games or multimedia)
- web access is convenient (it's not if you're behind a restrictive
firewall, or your country/area is poorly connected)
For example, I'd like to write a game in Python. I'd like to give the
game away free and charge for extra content. In C++ I can make it
difficult for users to share content with others who haven't paid for
it, with cryptographic hashes and the like. No, not impossible, but
difficult enough to deter most people. In Python it's much harder, when
the end user can open up the relevant file and quickly remove the
license check. No doubt this is another of the reasons why Python isn't
catching on quickly for game development, sadly.
(I'm not saying this is a deficiency of Python as such. It's just a
comment on the situation.)
> This is (a minor) one of the many reasons that make webservices the way
> of the future (hey, even *MSFT* noticed that recently, it seems...).
But they are not suitable for all applications, and probably never will
be.
--
Ben Sizer
The Eternal Squire
method to fit his business model, based on techniques passed on to me
by my various teachers at school and my senseis at workplaces..
Please don't judge me for attempting to pass on experience. It's his
choice.
While I'd like to figure out myself a nice software package to write
and market and earn a good living now that I've walked away from the
rat race, I can also see myself having humanity as my client (the FOSS
model).
The Eternal Squire
Bill Mill
> Alex Martelli wrote:
>
> > This is (a minor) one of the many reasons that make webservices the way
> > of the future (hey, even *MSFT* noticed that recently, it seems...).
>
> But they are not suitable for all applications, and probably never will
> be.
>
Your only solution, then, is to write unpopular code. Because, as Alex
said, it will otherwise be broken into. Let's look at two very popular
pieces of code: Half-Life 2 and Windows XP. How are they secured?
Previous version of these software products used sophisticated
client-side programming to try and be secure, but the security was
nonexistant. Users share keys and cracks with each other.
Now, both of these programs require verification (phone and/or web) to
be used. The only truly secure method of assuring that they're not
used in ways you don't intend is to require the user to contact you to
use it, and that's a deal with the devil. One you might need to make
if security is that important to you, as Microsoft and Valve have
decided it is, but it's a deal with the devil nonetheless.
Peace
Bill Mill
bill.mill at gmail.com
Mike Meyer
> Perhaps a comprehensive protection for interpreted languages can never
> be built because of their high level nature?
Nah. Compiling/interpreting is an implementation detail, and
orthogonal to the issue of "high level". There are compilers for high
level languages, and interpreters for low level languages. At the
lowest level, a machine emulator is an interpreter for machine code,
which is the lowest level most programmers deal with (at least I think
it is....).
If you really wanted "compiler-like" security for Python, you could
write a Python compiler. There have been posts about a compiler that
generated C++ recently, though it's still under development, and I
haven't followed it closely. You might also consider retargetting one
of the existing Python compilers to your architecture of choice, or to
another language. You might also consider translating Python to a
language with similar capabilities for which a compiler exists, like
Common LISP.
Of course, once you've got machine code, it doesn't matter how high
level the source was. That may make getting the source back harder,
but people who are cracking your program don't want to do that - they
just want to find the place where the security happens, and either
figure out the input that will make it happy, or invert the behavior
after a test.
Steven D'Aprano
> Perhaps a comprehensive protection for interpreted languages can never
> be built because of their high level nature?
Dude, a comprehension protection for *any* software can never be built
because of the fundamental nature of computers. Trying to stop bytes from
being copyable is like trying to stop water from being wet, and once
copied, all copies are identical and therefore indistinguishable.
It isn't a matter of protecting software or data. It is a question of how
hard do you want to make it for people to copy/crack? That itself has
costs, costs of time, space, complexity, bugs, lost opportunities,
customer dissatisfaction, and even legality.
Sony has just found that out: having been caught installing root-kits on
peoples computers, they are now being sued.
--
Steven.
Timothy Smith
> Reliability is
>important but so is protecting your code in an effective manner
>
>
otherwise. once you give then the program they can easily take it apart.
no if's, no but's; do NOT rely on binary's for security.
>
>the big software companies might say 'trusted computing will save us'
>but I for one will never truly trust it.
>
>
trusted computing it about your computer not trusting YOU. the computer
you pay for will decied based on some other company's whim's what you
are and are not allowed to do.
>Perhaps a comprehensive protection for interpreted languages can never
>be built because of their high level nature?
>
>
i repeat. there is no such thing as protected code. i've seen people de
construct exe's written in C.
Mike Meyer
> For example, I'd like to write a game in Python. I'd like to give the
> game away free and charge for extra content. In C++ I can make it
> difficult for users to share content with others who haven't paid for
> it, with cryptographic hashes and the like. No, not impossible, but
> difficult enough to deter most people. In Python it's much harder, when
> the end user can open up the relevant file and quickly remove the
> license check. No doubt this is another of the reasons why Python isn't
> catching on quickly for game development, sadly.
What makes you think this is the case? There are ways to distribute
Python modules so that the user can't just open them in a text
editor. There are also ways to get cryptographic security for
distributed modules. Yes, if you use the same methods you use in C++,
it's "much harder". But by the same token, if you tried to use the
methods you'd use in a Python program in C++, you'd find that the C++
version was "much harder".
Of course, as Alex pointed out, all of these are just keeping honest
people honest. The crooks have all the advantages in this game, so you
really can't expect to win.
Not that I'm convinced that putting everything on a "secure server" is
proof against getting your code stolen. Last time I was involved with
security people, it was commonly acknowledge that there were two types
of security people: those who knew when their systems were last broken
into, and those who didn't. Source - and other things - gets stolen
from "secure servers" on a regular basis, and those machines don't
have to provide some way for the potential thieves to execute the
code. But at least with this model, some of the advantages are on your
side, so you stand a fighting chance.
Carsten Haese
> Dude, a comprehension protection for *any* software can never be built
> because of the fundamental nature of computers. Trying to stop bytes from
> being copyable is like trying to stop water from being wet, and once
> copied, all copies are identical and therefore indistinguishable.
+1 QOTW!
--
Carsten Haese - Software Engineer | Phone: (419) 794-2531
Unique Systems, Inc. | FAX: (419) 893-2840
1687 Woodlands Drive | Cell: (419) 343-7045
Maumee, OH 43537 | Email: car...@uniqsys.com
Yu-Xi Lim
> Your only solution, then, is to write unpopular code. Because, as Alex
> said, it will otherwise be broken into. Let's look at two very popular
> pieces of code: Half-Life 2 and Windows XP. How are they secured?
> Previous version of these software products used sophisticated
> client-side programming to try and be secure, but the security was
> nonexistant. Users share keys and cracks with each other.
and
Mike Meyer wrote:
> What makes you think this is the case? There are ways to distribute
> Python modules so that the user can't just open them in a text
> editor. There are also ways to get cryptographic security for
> distributed modules. Yes, if you use the same methods you use in C++,
> it's "much harder". But by the same token, if you tried to use the
> methods you'd use in a Python program in C++, you'd find that the C++
> version was "much harder".
>
> Of course, as Alex pointed out, all of these are just keeping honest
> people honest. The crooks have all the advantages in this game, so you
> really can't expect to win.
Funny you should mention Half-Life 2. I actually went out and bought
Half-Life 2 from the store instead of waiting for a crack to be released
(the unique scheme they used meant that crackers will take a little
longer than usual). I really wanted to play this game (i.e., it's very
popular) and couldn't wait.
My brother is bugged by Civilization IV's copy protection. A couple of
days ago, after consulting me on what other options he could try, he
finally said in frustration, "Maybe I should go buy the game."
This is a personal anecdote, but I'm sure it applies to at least some
people. Obviously I'm not an honest person. But I'm not so against
spending money on software that I won't buy it if there's a pretty good
copy protection system on it. The "keeping honest people honest"
argument is simplistic and as Ben said, "black and white thinking".
Ben's analogy of the house is not a perfect example, but it's still a
fair one. You know that if some one really wants to break into your
house, he will get in, regardless of your sophisticated laser trip wire
system, ex-SAS guards, and genetically-engineered guard dogs. But as
long as the cost of protection is less than the cost of the item you're
protecting (multiplied by the relevant probabilities, factoring
recurring costs, etc), it's worthwhile to spend money on protection. If
that fails, then you will of course fall back on the law, but you still
try to prevent it from happening in the first place.
I do believe that code obfuscation and copy protection measures work, to
a limited extent. Few software companies believe that their copy
protection will be uncrackable (though their marketing droids may say
otherwise), but are most willing to invest in it to at least temporarily
stave off the piracy.
Distribution of python modules as compiled bytecode is a limited form of
obfuscation. Some believe it's enough. But if there's a free obfuscator
out there than can increase the difficulty of reverse engineering, why
not use that too? Costs you nothing, and may get you a customer or two
more before some one manages to crack that.
Obfuscation has it's place. It's not the final solution for software
protection (and there probably isn't one), but it is one more lock you
can use to deter or delay theives. You can't expect to win against
determined theives, but you can remove as many advantages that they have.
> Now, both of these programs require verification (phone and/or web) to
> be used. The only truly secure method of assuring that they're not
> used in ways you don't intend is to require the user to contact you to
> use it, and that's a deal with the devil. One you might need to make
> if security is that important to you, as Microsoft and Valve have
> decided it is, but it's a deal with the devil nonetheless.
This seems to be opposite to what you said in the previous paragraph.
Contacting and verifying with the company every time you use the
software is obviously not "the only truly secure method", since there
are cracks and keys floating around. It is also not quite as evil as it
may seem, since authorization is only required on initial use (and
online gaming).
Mike Meyer
> Bill Mill wrote:
>> Your only solution, then, is to write unpopular code. Because, as Alex
>> said, it will otherwise be broken into. Let's look at two very popular
>> pieces of code: Half-Life 2 and Windows XP. How are they secured?
>> Previous version of these software products used sophisticated
>> client-side programming to try and be secure, but the security was
>> nonexistant. Users share keys and cracks with each other.
> > What makes you think this is the case? There are ways to distribute
> > Python modules so that the user can't just open them in a text
> > editor. There are also ways to get cryptographic security for
> > distributed modules. Yes, if you use the same methods you use in C++,
> > it's "much harder". But by the same token, if you tried to use the
> > methods you'd use in a Python program in C++, you'd find that the C++
> > version was "much harder".
> people. Obviously I'm not an honest person. But I'm not so against
> spending money on software that I won't buy it if there's a pretty
> good copy protection system on it. The "keeping honest people honest"
> argument is simplistic and as Ben said, "black and white thinking".
And how much software is out there that you actually want so badly
that you'll buy it rather than wait unti it's cracked? Does it make up
a significant portion of the software you use? If not, then you as an
example of not merely "keeping honest people honest" are that it's
difference from reality is insignificant.
> Ben's analogy of the house is not a perfect example, but it's still a
> fair one. You know that if some one really wants to break into your
> house, he will get in, regardless of your sophisticated laser trip
> wire system, ex-SAS guards, and genetically-engineered guard dogs. But
> as long as the cost of protection is less than the cost of the item
> you're protecting (multiplied by the relevant probabilities, factoring
> recurring costs, etc), it's worthwhile to spend money on
> protection. If that fails, then you will of course fall back on the
> law, but you still try to prevent it from happening in the first place.
Sounds like you just said that manufacturers should improve their
protection until they aren't making any profit on the product. That's
silly. The goal isn't to maximize protection, it's to maximize
profit. That means it only makes sense to spend money on better
protection if the cost of the protection is less than the expected
profit from adding it. The cost of the item you're protecting is
irrelevant. The cost of adding copy protection is *noticably* more
than the cost of the copy protection bits. A recent, heavily
publicized case where Sony added copy protection to a product cost
them sales, and from what I've heard, even legal fees.
> I do believe that code obfuscation and copy protection measures work,
> to a limited extent. Few software companies believe that their copy
> protection will be uncrackable (though their marketing droids may say
> otherwise), but are most willing to invest in it to at least
> temporarily stave off the piracy.
Anything at all acts in the "keeping honest people honest"
capacity. It also delays the inevitable cracking - which is all you
can do. The only thing spending more on it does is lengthen the
delay. Hard data on how many sales that extra delay is responsible for
is, by it's very nature, impossible to come by. You've provided
anecdotal evidence that copy protection can improve sales. I've
provided anecdotal evidence that adding copy protection cost sales.
> Distribution of python modules as compiled bytecode is a limited form
> of obfuscation. Some believe it's enough. But if there's a free
> obfuscator out there than can increase the difficulty of reverse
> engineering, why not use that too? Costs you nothing, and may get you
> a customer or two more before some one manages to crack that.
Um, if you think adding steps to the release process costs you
nothing, you don't understand the release process. If you've got a way
to obfuscate the code that doesn't require extra steps in the release
or development process, I'd love to hear about it.
Alex Martelli
...
> My brother is bugged by Civilization IV's copy protection. A couple of
> days ago, after consulting me on what other options he could try, he
> finally said in frustration, "Maybe I should go buy the game."
It's interesting, in this context, that Civilization IV is mostly
written in Python (interfaced to some C++ via BoostPython).
It took me 12 seconds with a search engine to determine that CivIV's
protection uses "SafeDisc 4.60" and 30 more seconds to research that
issue enough to convince myself that there's enough information out
there that I could develop a crack for the thing (if I was interested in
so doing), quite apart from any consideration of the languages and
libraries used to develop it -- and I'm not even a particularly good
cracker, nor am I wired into any "underground channels", just looking at
information easily and openly available out on the web and in the index
of a major search engine.
> Obfuscation has it's place.
What I think of this thesis is on a par of what I think of this way of
spelling the possessive adjective "its" (and equally unprintable in
polite company). If I could choose to eradicate only one of these two
from the world, I'd opt for the spelling -- the widespread and totally
unfounded belief in the worth of obfuscation is also damaging, but less
so, since it only steals some time and energy from developers who (if
they share this belief) can't be all that good anyway;-).
Alex
Alex Martelli
...
> I think that is not workable because it is easy to say the the internet
> is available everywhere.
This implies that, if it were difficult to say it, then the scheme WOULD
be workable... which I doubt is what you mean, of course;-)
> It is not available in developing countries or in rural areas and so
Things are getting better all the time in these respects - and they will
keep getting better, quite apart from "web apps", because access to
information is MUCH more precious than mere computation.
> these people who live/work there will never benefit from a webservice
> type protection scheme,
It's debatable whether the customer BENEFITS from having their ability
to run an application RESTRICTED. It appears that the trend (in
developing countries even more than in rich ones) is towards using open
source, anyway.
> and what if the network in your area goes down?
> bye bye app that I *really* need for tomorrow. Reliability is
But the risk of your specific MACHINE going down is much higher than
that of the NET going down in all of its forms at once! If I rely on a
web app, and need to use it tonight to have something ready tomorrow,
then if my machine goes down (or I suffer a power brown-out in my area,
an occurrence that is frequent in many developing countries, and not
unheard of in developed ones), then I stand a chance to rush elsewhere,
to a library, town hall, internet cafe, or ANY other location where I
may be able to grab a machine, ANY machine, connect to the net, identify
and authenticate myself, and keep using that crucial web app. If said
app is well designed and mature, it will have autosaved most of my work
up to the point of my machine's crash (or the area brown-out, etc), too.
The importance of reliability speaks in FAVOUR of keeping important
stuff on the internet, rather than on unreliable, crash-prone local
machines (...and when's the last time you did a full backup of all of
your work with all proper precautions...? For most users, "never" --
for users of web apps hosted on well-maintained sites, on the other
hand, backups ARE taken care of, professionally and properly!).
> important but so is protecting your code in an effective manner
There is no effective manner of protecting your code, except running it
only on well-secured machines you control yourself. If you distribute
your code, in ANY form, and it's at all interesting to people with no
interest in respecting the law, then, it WILL be cracked (and if users
choose to respect the law, then you need no "protecting").
> I do believe that you are right about those that crack software for
> kicks or money. If you look around at you local market place i'm sure
> there are many 'discounted' commercial softwares/games sold. of course
> the big software companies might say 'trusted computing will save us'
> but I for one will never truly trust it.
>
> Perhaps a comprehensive protection for interpreted languages can never
> be built because of their high level nature?
Many, perhaps most, of those cracked commercial programs have NOT been
written in "interpreted languages" (whatever that means), but in
assembly code, C, C++... so your last paragraph is easily shown to be an
irrelevant aside -- it's not an issue of what language the code is in.
Alex
Magnus Lycka
> Alex Martelli wrote:
>>I think that's feeble protection. If you have valuable code, and
>>distribute it, people WILL crack it -- just check the warez sites for
>>experimental proof... EVERYTHING that people are really interested in
>>DOES get cracked, no matter what tricky machine-code the "protections"
>>are coded in.
>>
>>There's ONE way to have uncrackable code -- don't distribute it, but
>>rather put it up on the net on a well-secured machine under your
>>control, available as (say) a webservice (subscription-only, pay per
>>use, or whatever business model you want).
> I think that is not workable because it is easy to say the the internet
> is available everywhere.
>
Erh, the internet is certainly spreading to most of the
world, and there is an abundance of cracked and pirated
software in the poorer countries in the world, so the
obfuscation part has certainly proven not to work there.
Magnus Lycka
> Two things:
...
> 2) Only sell to an honest customer willing to be locked into
> nondisclosure agreements. This goes back to the maxim of good
> salesmanship: Know Your Customer.
If you have this, you don't need the obfuscation.
Ben Sizer
> Yu-Xi Lim <yu...@ece.gatech.edu> writes:
> > Ben's analogy of the house is not a perfect example, but it's still a
> > fair one. You know that if some one really wants to break into your
> > house, he will get in, regardless of your sophisticated laser trip
> > wire system, ex-SAS guards, and genetically-engineered guard dogs. But
> > as long as the cost of protection is less than the cost of the item
> > you're protecting (multiplied by the relevant probabilities, factoring
> > recurring costs, etc), it's worthwhile to spend money on
> > protection. If that fails, then you will of course fall back on the
> > law, but you still try to prevent it from happening in the first place.
>
> Sounds like you just said that manufacturers should improve their
> protection until they aren't making any profit on the product. That's
> silly. The goal isn't to maximize protection, it's to maximize
> profit. That means it only makes sense to spend money on better
> protection if the cost of the protection is less than the expected
> profit from adding it.
I agree with what you're saying, but it seems like you're arguing
against what was said rather than what was intended. Without wishing to
put words into anybody's mouths, I'm pretty sure what Yu-Xi Lim meant
was just that even imperfect protection is worthwhile if you estimate
that it will benefit you more than it will cost you. This is in
contrast to the opinion that any protection is useless because someone
will break it if they want to.
> A recent, heavily
> publicized case where Sony added copy protection to a product cost
> them sales, and from what I've heard, even legal fees.
I think that's a poor example - the cost hasn't come from the mere act
of adding protection, but the method in which that protection operates.
I don't think anybody here - certainly not me - is talking about
infecting a user's system to protect our property, or taking any other
intrusive steps. I'd just like to make it non-trivial to make or use
additional copies.
--
Ben Sizer.
Ben Sizer
> There are ways to distribute
> Python modules so that the user can't just open them in a text
> editor. There are also ways to get cryptographic security for
> distributed modules.
I know distributing as bytecode helps, but I was under the impression
that the disassembers worked pretty well. With the dynamic nature of
the language I expect that all the variable names are largely left
intact. You win some, you lose some, I guess.
As for cryptographic security, could you provide a link or reference
for this? I am quite interested for obvious reasons. I'd be concerned
that there's a weak link in there at the decoding stage, however.
I have considered distributing my program as open source but with
encrypted data. Unfortunately anyone can just read the source to
determine the decryption method and password. Maybe I could put that
into an extension module, but that just moves the weak link along the
chain.
> Yes, if you use the same methods you use in C++,
> it's "much harder". But by the same token, if you tried to use the
> methods you'd use in a Python program in C++, you'd find that the C++
> version was "much harder".
Well, I'm not sure what you mean here. A compiled C++ program is much
harder to extract information from than a compiled Python program.
That's without applying any special 'methods' on top of the normal
distribution process.
> Of course, as Alex pointed out, all of these are just keeping honest
> people honest. The crooks have all the advantages in this game, so you
> really can't expect to win.
No, certainly not. But if you can mitigate your losses easily enough -
without infringing upon anyone else's rights, I must add - then why not
do so.
--
Ben Sizer.
Mike Meyer
>> A recent, heavily
>> publicized case where Sony added copy protection to a product cost
>> them sales, and from what I've heard, even legal fees.
> I think that's a poor example - the cost hasn't come from the mere act
> of adding protection, but the method in which that protection operates.
That was sort of the point - that the effect on the bottom line of
adding copy protection is usually worse than just the cost of the
software, and can be much worse. This is a particularly egregious
example, but that just makes it an egregious example, not a poor one.
> I don't think anybody here - certainly not me - is talking about
> infecting a user's system to protect our property, or taking any other
> intrusive steps. I'd just like to make it non-trivial to make or use
> additional copies.
I've returned software that wouldn't run from a backup copy. Would I
return your software? If yes, have you factored the loss of sales to
people like me into your profit calculations?
petantik
The economics of software distribution must certainly come into it,
doing a cost/benefit analysis of whether it's worth the effort to
protect your code from would be crackers.
The problem with code protection methodology in general is that once
its cracked everyone has access to code for, maybe, all software using
the particular protection scheme.
the argument that most people buy software rather than get a pirated
version depends on the country that they are in e.g. china's piracy
problem where shops sell pirated software with no retribution by the
state - remember china is about to be the worlds largest economic
superpower
The above problem illustrate why code needs to be protected in an
effective way, by law and code protection schemes
With python there is no comfort factor in knowing that your code is
being protected, well not than I can see, compared with protection
schemes for compiled code which are used by many commercial software
companies.
Of course, we know that there can never be a 100% way to protect code
that some pirate won't overcome but it still stops the casual user or
beginner 'crackers' from stealing the code and digging in to your
profit margin.
btw i'm no expert on copy protection mechanism but the question I
raised originally, i believe, is valid and should be discussed
http://petantik.blogsome.com - A Lucid Look at Reality
Mike Meyer
> Mike Meyer wrote:
>> There are ways to distribute
>> Python modules so that the user can't just open them in a text
>> editor. There are also ways to get cryptographic security for
>> distributed modules.
> for this? I am quite interested for obvious reasons. I'd be concerned
> that there's a weak link in there at the decoding stage, however.
How about some ideas: Store your code in a zip file, and add it to the
search path. That immediately takes you out of the "just open the file
with a text editor" mode. For cryptographic security, use the ihooks
module to make "import" detect and decode encrypted modules before
actually importing them. Or digitally sign the modules, and check the
signature at import time. All of these are dead simple in Python.
> I have considered distributing my program as open source but with
> encrypted data. Unfortunately anyone can just read the source to
> determine the decryption method and password. Maybe I could put that
> into an extension module, but that just moves the weak link along the
> chain.
This isn't aPython problem, it's a problem with what you're doing. Try
Alex's solution, and put the data on a network server that goes
through whatever authentication you want it to.
>> Yes, if you use the same methods you use in C++,
>> it's "much harder". But by the same token, if you tried to use the
>> methods you'd use in a Python program in C++, you'd find that the C++
>> version was "much harder".
> Well, I'm not sure what you mean here. A compiled C++ program is much
> harder to extract information from than a compiled Python program.
It is? Is the Python disassembler so much advanced over the state of
the art of binary disassemblers, then? Or maybe it's the Python
decompilers that are so advanced? As far as I can tell, the only real
difference between Python bytecodes and x86 (for instance) binaries is
that Python bytecodes keep the variable names around so it can do
run-timme lookups. That's not that big a difference.
As for what I meant - Python has ihooks and imp, that make it simple
to customize import behavior. Doing those kinds of things with C++
code requires building the tools to do that kind of thing from
scratch.
>> Of course, as Alex pointed out, all of these are just keeping honest
>> people honest. The crooks have all the advantages in this game, so you
>> really can't expect to win.
> No, certainly not. But if you can mitigate your losses easily enough -
> without infringing upon anyone else's rights, I must add - then why not
> do so.
Elsewhere in the thread, you said:
> I'd just like to make it non-trivial to make or use additional copies.
How do you do that without infringing my fair use rights?
Steven D'Aprano
>> I'd just like to make it non-trivial to make or use additional copies.
>
> How do you do that without infringing my fair use rights?
And that is the million dollar question.
So-called "intellectual property" is a government-granted monopoly which
is not based on any principle of ownership. Ideas are not something you
can own in any real sense (as opposed to the legal fiction), ideas are
something that you can *have* -- but having had an idea, you can't
naturally prevent others from having the same idea independently, or
making use of your idea if you tell them about it -- and should you tell
them your idea so that now they have it as well, that does not diminish
the fact that you also have that idea.
Given the absolute lack of real evidence that strong "intellectual
property" laws are good for either innovation or the economy, and given
the absolute artificiality of treating ideas as if they were scarce goods,
I don't understand why the artificial monopoly rights of copyright holders
are allowed to trump the natural rights of copyright users.
--
Steven.
Steven D'Aprano
> the argument that most people buy software rather than get a pirated
> version depends on the country that they are in e.g. china's piracy
> problem where shops sell pirated software with no retribution by the
> state - remember china is about to be the worlds largest economic
> superpower
>
> The above problem illustrate why code needs to be protected in an
> effective way, by law and code protection schemes
I'm sorry, what problem? You haven't actually stated a problem -- in fact,
you have just given a perfect example of why the so-called "problem" is
not a problem at all. Let us see:
Historically, the UK had no concept of intellectual property rights until
very recently, and even when it was introduced, it was very limited until
the late 20th century.
Likewise for continental Europe.
Nevertheless, the UK and Europe became economic superpowers.
The USA, like China and Russia today, was a pirate nation for the first
century or two of its existence. American publishers simply reprinted
English books without paying royalties until well into the 20th century.
Hollywood got its start by fleeing the east coast to California, where
enforcement of Thomas Edison's patents on motion picture technology was
not enforced.
The USA has become an economic superpower.
China has little effective protection for artificial monopoly rights over
ideas. China is becoming an economic superpower.
So where is the problem?
Ah, now I understand it. Having become rich and powerful by ignoring
so-called intellectual property, the UK, Europe and especially the USA is
desperate to ensure that the developing world does not also become rich
and powerful. One way of doing so is to force a system of artificial
government-granted monopolies, together with all the proven economic
inefficiencies of such monopolies, on the developing world.
--
Steven.
Steven D'Aprano
>> Obfuscation has it's place.
>
> What I think of this thesis is on a par of what I think of this way of
> spelling the possessive adjective "its" (and equally unprintable in
> polite company).
Aside: given that "it's" is "it is", how would you spell the possessive
case of it?
> If I could choose to eradicate only one of these two
> from the world, I'd opt for the spelling -- the widespread and totally
> unfounded belief in the worth of obfuscation is also damaging, but less
> so, since it only steals some time and energy from developers who (if
> they share this belief) can't be all that good anyway;-).
Not that I disagree with you about obfuscation in general, but I can think
of one particular usage case for obfuscation which is neither useless nor
morally suspect:
"Now listen carefully class, your homework for this week is to write a
program to blurgle a frobnitz. As a test of correctness, your program
must return the same results as the test function blurglise. Before you
get any clever ideas of copying the code from blurglise, keep in mind
firstly that the source code is obfuscated, and secondly that I am not an
idiot, I will recognise my own code if you try to pass it off as yours."
--
Steven.
Mike Meyer
Steven D'Aprano <st...@REMOVETHIScyber.com.au> writes:
> On Fri, 11 Nov 2005 11:17:43 -0500, Mike Meyer wrote:
>>> I'd just like to make it non-trivial to make or use additional copies.
>> How do you do that without infringing my fair use rights?
> And that is the million dollar question.
>
> So-called "intellectual property" is a government-granted monopoly which
> is not based on any principle of ownership. Ideas are not something you
> can own in any real sense (as opposed to the legal fiction), ideas are
> something that you can *have* -- but having had an idea, you can't
> naturally prevent others from having the same idea independently, or
> making use of your idea if you tell them about it -- and should you tell
> them your idea so that now they have it as well, that does not diminish
> the fact that you also have that idea.
It's a common misconception that ideas are protected by intellectual
property laws. They're not. Well, they're not supposed to be.
Copyright doesn't protect ideas, plot lines or similar
things. Copyright protects expression of those things in a tangible
medium. So if you read a book, then write a book with the same plot
line, you aren't in violation of copyright. Characters can be
protected by copyright, so you do have to be a bit careful about that.
Patents aren't supposed to protect ideas - they're supposed to protect
inventions. That's a fuzzy line, and the interpretation of 35 USC
Section 101 that allows the patenting of software has made it even
fuzzier. This broad interpretation has recently been used to patent
story lines <URL:
http://www.groklaw.net/article.php?story=20051103183218268 >, which is
close enough to patenting ideas that I can't really tell the
difference.
> Given the absolute lack of real evidence that strong "intellectual
> property" laws are good for either innovation or the economy, and given
> the absolute artificiality of treating ideas as if they were scarce goods,
> I don't understand why the artificial monopoly rights of copyright holders
> are allowed to trump the natural rights of copyright users.
Because the copyright holders are organized, and have money to
influence congress that outweighs the funds that - since they're
generally unorganized - individual copyright holders have
available. So you get laws that help copyright holders enforce and
extend their copyright at the expense of the rights of the general
public.
Alex Martelli
> On Thu, 10 Nov 2005 21:41:52 -0800, Alex Martelli wrote:
>
> >> Obfuscation has it's place.
> >
> > What I think of this thesis is on a par of what I think of this way of
> > spelling the possessive adjective "its" (and equally unprintable in
> > polite company).
>
> Aside: given that "it's" is "it is", how would you spell the possessive
> case of it?
As I was thought and have always seen it spelled in good literature --
"its". I'm not at all tempted to affix "'s" to make possessives out of
pronouns -- "I's", "you's", "we's"...?!-) Remember, English is not my
native language, so what I have internalized are _rules_, not a native
speaker's magical communion with the language...;-)
> Not that I disagree with you about obfuscation in general, but I can think
> of one particular usage case for obfuscation which is neither useless nor
> morally suspect:
>
> "Now listen carefully class, your homework for this week is to write a
> program to blurgle a frobnitz. As a test of correctness, your program
> must return the same results as the test function blurglise. Before you
> get any clever ideas of copying the code from blurglise, keep in mind
> firstly that the source code is obfuscated, and secondly that I am not an
> idiot, I will recognise my own code if you try to pass it off as yours."
Sure, that's one example -- but the instructor SHOULD really consider
placing burglise on a secure server on the intranet instead, making it
available (via CGI, webservice, whatever) to check input/output
relationships, rather than making the obfuscated code available and
raising questions of obfuscation and reverse engineering.
Alex
The Eternal Squire
novel? And I submit that many ISD's are only a single person burning
with that one software idea of a lifetime, the equivalent of the Great
American Novel. Are we to punish that impulse by denying that person
a legal monopoly on that idea?
I believe piracy is bad for everyone: the consumer, the writer, and
the country as a whole. I don't oppose copyleft, but then, I don't
oppose copyright either. Let's distribute the former for free, and
honor the need for the writer of the latter to earn a living.
The Eternal Squire
Yu-Xi Lim
> It's interesting, in this context, that Civilization IV is mostly
> written in Python (interfaced to some C++ via BoostPython).
>
> It took me 12 seconds with a search engine to determine that CivIV's
> protection uses "SafeDisc 4.60" and 30 more seconds to research that
> issue enough to convince myself that there's enough information out
> there that I could develop a crack for the thing (if I was interested in
> so doing), quite apart from any consideration of the languages and
> libraries used to develop it -- and I'm not even a particularly good
> cracker, nor am I wired into any "underground channels", just looking at
> information easily and openly available out on the web and in the index
> of a major search engine.
Yes, I never said it's uncrackable. The cracks available are iffy and
the alternatives are sufficiently inconvenient to dissuade the
less-savvy user from attempting them. In which case, the copy protection
has succeeded.
> What I think of this thesis is on a par of what I think of this way of
> spelling the possessive adjective "its" (and equally unprintable in
> polite company). If I could choose to eradicate only one of these two
> from the world, I'd opt for the spelling -- the widespread and totally
> unfounded belief in the worth of obfuscation is also damaging, but less
> so, since it only steals some time and energy from developers who (if
> they share this belief) can't be all that good anyway;-).
The level of pedantry here is amazing and it doesn't apply only to
programming languages. While we are discussing my typos, I'd like to
note that I may accidentally interchange "you're" and "your", "there",
"they're", and "their", and a bunch of other homonyms.
I hadn't seen any damage done from misusing "it's". Certainly not on par
with the Sony case which Mike Meyer cites as evidence against copy
protection (and presumably obfuscation, which was the topic of the
discussion)
This topic seems to be drifting. I thought I might clarify what I mean
by "code obfuscation" to get things back on track.
Code obfuscation is a transformation of the program (whether at source
code level, intermediate object code level, binary executable level,
etc) to hinder (prevention seems impossible) reverse engineering
(attempts to determine the workings of the code, to modify the function
of the code, etc). While there are many possible transformations that
can be done on programs (compression, run-time optimizations, etc), the
key here is the intent to hinder reverse engineering. I hope this is
agreeable to everyone.
Python already conveniently supports certain transformations on
programs. Off the top of my head, I think of compiled bytecode (pyc and
pyo files), and modules in zip archives. Any of these can be used as a
means of obfuscation. (Compiled languages naturally undergo
transformations which tend to have more effectiveness against reverse
engineering)
Now, to address points made by Mike Meyer. He says that obfuscation adds
steps to the release process and also cites Sony's XCP fiasco as an
example of unseen costs of "copy protection".
Indeed, everything has a cost, and I was wrong in saying "free".
However, if convenient language-supported transforms are used, the
direct cost of using obfuscation would be miniscule in comparison to
just about everything else. Implementing it should be one simple step,
and testing it shouldn't be required (if you reasonably assume the
language isn't broken).
I am going to ignore certain aspects of the Sony XCP case, such as the
bad EULA and the bad PR (we shall leave that to the lawyers and
marketing folk and stick to something we programmers can actually fix).
What we have left is a broken software implementation of copy
protection. If language-supported (or even OS-supported, which would
have helped Sony*) transformations are used, we can expect to rule out
such brokenness, i.e. no obfuscation-induced incompatibilities and
related help-desk calls. This further reduces the unexpected costs of
code obfuscation to zero (did I miss anything?)
This form of obfuscation is certainly weak, but given that the costs are
so tiny, why not use it? Even if you could gain one customer (and a few
dollars if you're a shareware developer), you have more than recuperated
your costs. If you don't, you probably lost 5 minutes of development
time. Is this a worthwhile gamble? I believe so.
Mike Meyer may reiterate his point about "keeping honest people honest"
and thus such obfuscation has little ("insignificant") benefit. Whether
this little difference is "insignificant" is up to the
developer/publisher/etc to decide. My thesis (to borrow Alex Martelli's
language) is that it is possible to obtain *some* benefit from
obfuscation with *minimal* costs.
There are physical examples of attempts to hinder reverse engineering:
glueing the cases of devices shut and sealing integrated circuits in a
blob of epoxy, among others. With such examples, I don't think it's
unreasonable to believe that similar possibilities exist for software
products. This is not cited as concrete evidence, just something that
hints at a possibility.
* Someone may start crying out, "DRM-supporter! Burn him at the stake!"
I think code obfuscation and DRM should be approached as seperate
issues, unless one believes that the user's right to software includes
unlimited access to the source code. That itself is also a separate
discussion, imo.
Yu-Xi Lim
> There is no effective manner of protecting your code, except running it
> only on well-secured machines you control yourself. If you distribute
> your code, in ANY form, and it's at all interesting to people with no
> interest in respecting the law, then, it WILL be cracked (and if users
> choose to respect the law, then you need no "protecting").
Indeed. An this extends to web services too. If you have input which can
be observed (or even better, controlled) and output that can be observed
too, one would be able to infer the workings of the code (reverse
engineering in one of its purest forms).
If your business strategy relies heavily on a proprietary algorithm or
even something as weak as lock-in via a proprietary "un-interoperable"
data format, then web services is not the final answer. It may work for
certain applications (Microsoft's for example) where the cost of reverse
engineering is equivalent to the cost of building from scratch.
Paul Rubin
> Without copyright, how could one possibly earn a living writing a
> novel?
This guy seems to be doing ok: http://craphound.com
His publishers are the only ones allowed to sell his novels commercially,
but you can download them all and print them out noncommercially for
your own personal enjoyment or to share with your friends. No obfuscation
is needed.
> And I submit that many ISD's are only a single person burning with
> that one software idea of a lifetime, the equivalent of the Great
> American Novel. Are we to punish that impulse by denying that
> person a legal monopoly on that idea?
You know, there's lots of people who would like to make a living as
actors or musicians or novelists or whatever, and maybe they even have
enough talent and skill to do it, but for whatever reason it's just
not in the cards for them, copyright or not. So they do other things
instead. Maybe it's also not in the cards for some people to be
programmers even though they'd like to be, so they do other things
instead too. For the most part, I don't feel any sense of tragedy
about this.
> I believe piracy is bad for everyone: the consumer, the writer, and
> the country as a whole. I don't oppose copyleft, but then, I don't
> oppose copyright either. Let's distribute the former for free, and
> honor the need for the writer of the latter to earn a living.
Everyone has the right to try to earn a living from programming, but
no one is entitled to be guaranteed success at it.
Ben Finney
> Code obfuscation is a transformation of the program (whether at
> source code level, intermediate object code level, binary executable
> level, etc) to hinder (prevention seems impossible) reverse
> engineering (attempts to determine the workings of the code, to
> modify the function of the code, etc). While there are many possible
> transformations that can be done on programs (compression, run-time
> optimizations, etc), the key here is the intent to hinder reverse
> engineering.
That's a workable definition.
> I hope this is agreeable to everyone.
The definition is agreeably solid.
The intention is disagreeably sickening.
--
\ "Room service? Send up a larger room." -- Groucho Marx |
`\ |
_o__) |
Ben Finney
Mike Meyer
> Indeed, everything has a cost, and I was wrong in saying
> "free". However, if convenient language-supported transforms are used,
> the direct cost of using obfuscation would be miniscule in comparison
> to just about everything else. Implementing it should be one simple
> step, and testing it shouldn't be required (if you reasonably assume
> the language isn't broken).
Failng to test what you ship is simply poor engineering and poor
marketing. If you're incompetent, you might skip those
steps. Otherwise, you have to test with obfuscation in place.
> I am going to ignore certain aspects of the Sony XCP case, such as the
> bad EULA and the bad PR (we shall leave that to the lawyers and
> marketing folk and stick to something we programmers can actually
> fix). What we have left is a broken software implementation of copy
> protection. If language-supported (or even OS-supported, which would
> have helped Sony*) transformations are used, we can expect to rule out
> such brokenness, i.e. no obfuscation-induced incompatibilities and
> related help-desk calls. This further reduces the unexpected costs of
> code obfuscation to zero (did I miss anything?)
You ignored the fact that the *act* of copy protection cost them
customers. It wasn't the poor implementation or the EULA, it was the
fact that people who were denied their fair use rights returned or
refused to buy their product. The rest of it merely made it widely
publicized.
> This form of obfuscation is certainly weak, but given that the costs
> are so tiny, why not use it? Even if you could gain one customer (and
> a few dollars if you're a shareware developer), you have more than
> recuperated your costs. If you don't, you probably lost 5 minutes of
> development time. Is this a worthwhile gamble? I believe so.
And if instead you lose one customer because you've denied them their
fair use rights, then your copy protection has lost you more in the
form of a cost that you overlooked than all the costs you actually
considered.
> Mike Meyer may reiterate his point about "keeping honest people
> honest" and thus such obfuscation has little ("insignificant")
> benefit. Whether this little difference is "insignificant" is up to
> the developer/publisher/etc to decide. My thesis (to borrow Alex
> Martelli's language) is that it is possible to obtain *some* benefit
> from obfuscation with *minimal* costs.
Actually, obfuscation by itself has *no* benefit. If all you do is
obfuscate the code, none of the pirates will ever notice - they'll
just copy the code without ever trying to read it. It's the copy
protection mechanisms you're trying to obfuscate that gains you the
alleged benefit. Once you provide a copy protection mechanism,
obfuscation has some benefit, though the costs aren't clearly minimal,
not if you're a cometent engineer. It's the benefits of the copy
protection that I claim are insignificant.
Alex Martelli
> "The Eternal Squire" <eterna...@comcast.net> writes:
> > Without copyright, how could one possibly earn a living writing a
> > novel?
>
> This guy seems to be doing ok: http://craphound.com
> His publishers are the only ones allowed to sell his novels commercially,
> but you can download them all and print them out noncommercially for
> your own personal enjoyment or to share with your friends. No obfuscation
> is needed.
One might also quip (not truthfully in Cory's specific case, I hasten to
add!-) that many of today's novels are intrinsically obfuscated enough
to need no further technological help on that front;-).
Quips aside, the question is a sensible one to ask -- not as a
rhetorical question, as TES apparently intended, of course, and not just
about novels (many different creative endeavours may require different
answers). The "novel" as a specific literary form is not that old, just
a few centuries, but the issues were not very different for many other
literary forms over the ages and cultures, and many different answers
have been given or attempted.
For example, Virgil was writing poems (epic and otherwise), not novels,
but that's not very relevant to the question of how he made a living;
the classic solution, in his case, was to find rich patrons willing to
pay him to do so. Of course, there are obvious problems with this
model... for example, Virgil was paid to write the Aeneid because his
patrons liked its patriotism (as well as its towering artistic
qualities), but a work with equally good art but an anti-patriotic
ideology would have been much harder to monetize at that time (and also
risked landing the author in the soup, as Ovid found out, but that's
another issue, quite unrelated to monetization).
Zooming forwards a couple of millennia, we see the model of
"serialization" -- having the novel published in periodic installments
by a magazine. Avid readers, we're told, crowded the piers of New York
waiting for ship to land which carried the magazine with the latest
installment of some Dickens novel -- and Dumas and Sue, in France, had
fully comparable success in similar ways. At that time, copyright
existed, in theory, but practically wasn't very well enforced (most
particularly, I believe, in the USA, where the probability of a British
publisher of actually enforcing a copyright was laughably low...) --
nevertheless, the reasonable cheapness of magazines coupled with the
readers' urgency for the next installment let these authors earn a
comfortable living anyway. Here, the problem is presumably that you
need VERY popular novels for this to work -- but then, a tiny fraction
of novelists actually make a comfortable living from just their novels,
even with today's monetization approaches.
Modern equivalent of serialization (publishing one chapter at a time on
the web, the next chapter to come only if the author receives enough
payment for the previous one) have been attempted, but without much
success so far; however, the holy grail of "micropayments" might yet
afford a rebirth for such a model -- if paying for a chapter was
extremely convenient and cheap, enough people might choose to do so
rather than risk the next chapter never appearing. Remember that, by
totally disintermediating publishers and bookstores, a novelist may
require maybe 1/10th of what the book would need to gross in stores, in
order to end up with the same amount of cash in his or her pockets.
One could go on for a long time, but the key point is that there may or
may not exist viable monetization models for all sorts of endeavours,
including the writing of novels, depending on a lot of other issues of
social as well as legal structures. Let's not be blinded by one model
that has worked sort of decently for a small time in certain sets of
conditions, into believing that model is the only workable one today or
tomorrow, with conditions that may be in fact very different.
Alex
Alex Martelli
> I hadn't seen any damage done from misusing "it's". Certainly not on par
You should see my pharmacy bill for Maalox... and my liver ain't too
happy about it either;-)
Alex
Alex Martelli
> Alex Martelli wrote:
> > There is no effective manner of protecting your code, except running it
> > only on well-secured machines you control yourself. If you distribute
> > your code, in ANY form, and it's at all interesting to people with no
> > interest in respecting the law, then, it WILL be cracked (and if users
> > choose to respect the law, then you need no "protecting").
>
> Indeed. An this extends to web services too. If you have input which can
> be observed (or even better, controlled) and output that can be observed
> too, one would be able to infer the workings of the code (reverse
> engineering in one of its purest forms).
...unless you have "nonobservable state", of course, in which case the
inference is conceptually impossible. For example, say that you have
developed a new and revolutionary system to predict weather, much better
than anything the competition has. You offer it as a for-pay web
service, the customer-supplied inputs being the space-time coordinates
at which prediction is required, while the customer-provided outputs are
a vector of possible weather conditions each with an attached
probability, just as they might be for ANY weather-prediction web
service, except that (by hypothesis, or else you won't make much money
on this;-) the outputs of your weather predictor match reality much
better than the competitors'. "To infer" whatever would essentially
mean to reinvent your whole "revolutionary system" from scratch.
Much the same would apply if what your system is able to predict better
than your competitors' is any other kind of phenomenon of economic
interest in a sufficiently complex real-world system -- from interest
rates to the probability that two would-be online daters will like each
other. And it doesn't have to be prediction -- one famous system where
ESR, as a consultant, advised his clients to keep their program a trade
secret, was "just" a better heuristic than any of their competitors' for
cutting a set of given shapes with automated tools out of a slab of
wood, if I recall correctly... a problem that's computationally
intractable to solve anything but heuristically, and a better heuristic
saves wood, worktime, and/or wear and tear on the tools, therefore is
worth money.
In practice, you ARE going to be able to operate your system
successfully bases on keeping a good innovative algorithm or heuristic
secret, for a while -- until somebody else independently reinvents it
(or, invents something even better, in which case your secret may become
irrelevant). IP protection is a possibility, but copyright per se might
be too weak, and whether patents apply in any given case is always
controversial (Europe soundly defeated a proposed software patent
directive, after a bitter fight, less than a year ago).
> If your business strategy relies heavily on a proprietary algorithm or
> even something as weak as lock-in via a proprietary "un-interoperable"
> data format, then web services is not the final answer. It may work for
> certain applications (Microsoft's for example) where the cost of reverse
> engineering is equivalent to the cost of building from scratch.
...and the latter is going to be the case for many important
"proprietary algorithms", as above exemplified.
A cryptographically sound "proprietary data format" may be essentially
impossible to break, too -- although, differently from many potential
algorithms, it has per se no added value, and may run afoul of sensible
legislation (or sensible would-be customers), such as Massachussets',
mandating the use of standard data formats.
Alex
Mike Meyer
> "The Eternal Squire" <eterna...@comcast.net> writes:
>> Without copyright, how could one possibly earn a living writing a
>> novel?
> This guy seems to be doing ok: http://craphound.com
> His publishers are the only ones allowed to sell his novels commercially,
> but you can download them all and print them out noncommercially for
> your own personal enjoyment or to share with your friends. No obfuscation
> is needed.
Not really a good counterexample, because "His publishers are the only
ones allowed to sell his novels commercially" is only possible because
of copyright. Without that, anyone could take the downloadable copy of
his novels and start competing with his publishers - presumably with
lower overhead, because they didn't have to pay Cory.
Asking about novels is an excellent question - it's one of the few
forms of copyrightable material where it's not the final end product
and you have to give the public access to the media for them to use
it. If either one of those isn't true, you can probably find a
business model that doesn't depend on copyright.
Steven D'Aprano
> And if instead you lose one customer because you've denied them their
> fair use rights, then your copy protection has lost you more in the
> form of a cost that you overlooked than all the costs you actually
> considered.
In a competitive marketplace, why would I choose to buy DRMed software if
there is a non-DRMed equivalent with the same functionality and equivalent
cost? DRM is both an extra cost and a lower functionality applied to the
software: an extra cost because if I can only run three simultaneous
instances when I want four, then I need to pay more; lower functionality
because things I may wish to do (like lock the original disk in the
fireproof safe and install off a backup copy) may be impossible.
If you are supplying to a non-competitive market, you may decide that you
don't mind losing some sales. In non-competitive markets, the pressure to
improve the ratio of functionality to cost is weak.
[snip]
> Actually, obfuscation by itself has *no* benefit. If all you do is
> obfuscate the code, none of the pirates will ever notice - they'll just
> copy the code without ever trying to read it. It's the copy protection
> mechanisms you're trying to obfuscate that gains you the alleged
> benefit.
I don't think you mean copy protection, as in preventing copies -- it is
difficult for an application to prevent the OS from making physical
copies, and by difficult I mean "essentially impossible". Perhaps you mean
access control, for example the software will only run for three people
simultaneously.
> Once you provide a copy protection mechanism, obfuscation has
> some benefit, though the costs aren't clearly minimal, not if you're a
> cometent engineer. It's the benefits of the copy protection that I claim
> are insignificant.
That's not quite true -- there may be instances where there is a real or
perceived benefit from keeping the algorithms used secret: perhaps you
have found a more efficient way to do something, or perhaps you just want
to hide from your users just how bad your code really is, or perhaps
you've conned^H^H^H^H convinced them to pay a premium price for reduced
functionality and don't want them bypassing your access control mechanisms.
The problem is, developers often have a ridiculously over-inflated opinion
of the worth of their code, and the business people behind them even more
so. Everybody[1] thinks that their two-bit Visual Basic calculator app is
going to be the next Microsoft Windows and make them a fortune, but only
if they keep the source code secret. Because so much code is secret,
people fail to appreciate just how little innovation there really is in
the IT industry, and imagine that just because they personally sweated
blood for months writing the code, it must be valuable.
Anyway, I think this is all a storm in a teacup. With the possible
exception of game console software, I think the idea of shrink-wrapped
software generally and software licencing particularly is a temporary
aberration. In a decade, software obfuscation will only exist as a way for
hackers to prove how clever they are, as in the Obfuscated C Contest.
Until then, well, if you think you can a commercial advantage by annoying
your customers, knock yourselves out.
[1] By "everyone" I mean "lots of people who should know better".
--
Steven.
Steven D'Aprano
> Without copyright, how could one possibly earn a living writing a
> novel?
I don't know. How did William Shakespeare make a living from writing plays
and sonnets and poems? How did Sir Walter Scott make a living from writing
novels? How do chefs make a living from creating new recipes, and stand-up
comedians from telling jokes?
Perhaps there is no way to make a living from writing novels without
copyright. There is no way to make a living from playing solitaire either
-- should the government pass a law giving a legal monopoly on playing red
queen on a black king to my granny, so that everyone playing that move
has to pay her ten cents? That would make her old age so much more
comfortable. If you object to my proposal, I can ask "But without it, how
could one possibly make a living playing solitaire?"
Do we care if novelists can make a living writing novels? Most of them
don't anyway. The Stephen Kings, Tom Clancys and J.K. Rowlings are the
exception, not the rule -- for every Terry Pratchett who has "had to
change banks because [he] filled the first one up", there are a hundred
thousand who never make a living from writing at all.
If you've been involved in writing novels, you will know that the real
difference between an interesting idea and a great novel is usually a good
editor. A good editor does maybe a quarter or a third of the intellectual
labour of creating a novel -- not the grunt work of hitting typewriter
keys and putting ink to paper, but the brain work of making sure that the
story actually tells a story well. Why should the author get the monopoly
and the editor nothing? How do editors make money without a monopoly
granted by the government like copyright?
How do magazine and newspaper writers make a living when they don't get
the copyright on the things they write?
These are all important questions, and you will notice I deliberately am
not giving answers -- but they are also irrelevant because I didn't say
that I was against copyright. What I asked was why the artificial rights
of creators are given more importance than the natural rights of users.
> And I submit that many ISD's are only a single person burning
> with that one software idea of a lifetime, the equivalent of the Great
> American Novel.
If their "one software idea of a lifetime" is as pointless, useless and
just *bad* as the average would-be "Great American Novel", then copyright
or no copyright nobody will want their poxy code. Sourceforge is full of
software projects, 90% of which go nowhere. The world is filled with
millions of wanna-be poets, writers and creators whose sum total
contribution to the artistic wealth of the world is negative.
I'm not just using hyperbole. By poisoning the well with their garbage,
they just make it that little bit harder for genuinely talented artists to
be heard. Only 2% of books sell more than 5,000 copies, ever, and many
wonderful books never get a second print-run because they just can't get
people's attention.
Despite this, people keep trying to write the Great American Novel.
Creative artists will create, even if they would be economically better
off washing dishes at Greasy Joe's Diner for a buck an hour. Michaelangelo
didn't stop painting because he had no copyright protection.
> Are we to punish that impulse by denying that person
> a legal monopoly on that idea?
Who's talking about *punishment*?
The natural state of things is not copyright. "No copyright" is not
punishing the author any more than "no flying unicorns" is punishing
little girls with a fantasy for flying through the sky on the back of a
horned horse. It is just the way things are.
Copyright is a gift granted by the government, not the natural state of
the world. When kings and emperors and presidents give commercial and
economic gifts, like monopolies, they rarely are for the benefit of the
majority.
Lots of ideas have no legal monopoly. There is no legal monopoly on (say)
good gardening skills, or the specific way of mixing the batter to make
extra light and fluffy bread. Why should some ideas be privileged over
others?
Lack of copyright doesn't need to be defended, as it is the natural state
of the world. Copyright is the special state which needs to be defended,
and there is precious little evidence that copyright makes sense
economically for *anyone*, author, publisher, readers or society as a
whole.
That's not to say that copyright isn't good for one or more of the above:
I have my intuitions as to who copyright benefits. But my point is that
there is a serious lack of evidence one way or the other, and what
evidence there is suggests strongly that over-strong copyright laws (like
we have now) are bad for *everyone*, and that weaker copyright (as in the
early 20th century) would be better.
> I believe piracy is bad for everyone: the consumer, the writer, and
> the country as a whole. I don't oppose copyleft, but then, I don't
> oppose copyright either. Let's distribute the former for free, and
> honor the need for the writer of the latter to earn a living.
Who mentioned copyleft? Copyleft is just a version of copyright: instead
of "All Rights Reserved", copyleft gives the user additional rights they
may not have got otherwise. Copyleft is not opposed to copyright, it _is_
copyright (despite the cute name).
In any case, piracy is demonstrably *not* bad for everyone. The entire US
movie industry would not exist if not for patent infringement: the baby
industry was being choked out of existence by the high royalties and
licence fees demanded by the holders of Thomas Edison's patents, until
they fled to California where enforcement was lax.
Likewise radio, which got its start from unauthorized transmission of
music, what we would call "piracy". The US government recognised that
"piracy = theft" was just propaganda, and legislated to give the radio
stations a compulsory licence rather than shut them down.
Likewise cable TV, which got its start from outright theft of transmitted
signals: in 1972 Jack Valenti of the MPAA testified to the American
Congress that the cable TV industry would destroy the movie industry
utter, and described cable TV as a parasite. Congress didn't swallow
it, and thirty years later both Hollywood and cable TV are thriving.
Having got it his first prediction that the sky is falling so badly wrong,
Valenti tried again ten years later, when he testified that the personal
home VCR would destroy the American movie industry -- he described it as
being to the American public and the movie industry as the Boston
Strangler was to women living alone. Instead, the VCR saved Hollywood
from collapse, with cheap direct-to-video movies now their
bread-and-butter, making up for all those big budget flops.
Going for three failures from three, now Valenti is campaigning against
peer-to-peer and the Internet.
Talking of outright theft, no discussion of monopoly rights is complete
without mentioning the record labels' habit of outright theft of ownership
from the artists who actually create music. It churns my stomach to see
thieves and con artists like the RIAA trying to take the moral high ground
with talk of "copying is theft".
Closer to home for the software industry, it is well recognised that
for software companies starting out, they get more benefit from
copyright infringement than they lose in revenue. Windows is the perfect,
if extreme, example: by turning a blind eye to piracy, Microsoft made sure
that anyone who wanted Windows could get it. That in turn meant that
programmers entering the workforce were already programming for Windows,
that businesses were demanding software that run under Windows, that
hardware manufacturers were supporting Windows.
Even today, Microsoft has a dilemma in China and South East Asia -- they
have a monopoly on Windows, but revenue is low because piracy rates are
extraordinarily high. But they don't dare get too strict on stamping out
piracy, because the last thing they want is to drive the billions of
actual or potential computer users of Asia to Linux -- Microsoft wants
hardware suppliers to support Windows first and Linux not at all or at
least as just an afterthought, not the other way around. Microsoft needs
software companies and consultants and programmers to work in the Windows
space, not Linux.
This means that, paradoxically, companies that work in the Linux space
actually want Microsoft to stamp down harder on piracy than Microsoft
wants to. We want more Ernie Balls:
http://www.osv.org.au/index.cgi?tid=91
As Microsoft knows, piracy is effectively giving your product away for
free. Can you think of any reason why you would want to give your product
away for free? Promotions, network effects, "the first sample is free",
driving your competitors out of business, try before you buy, software
which is paid for by advertising... there are many reasons why companies
might not just turn a blind eye to piracy but welcome it. The mistake is
to only think of piracy as lost revenue.
--
Steven.
Alex Martelli
> In a competitive marketplace, why would I choose to buy DRMed software if
> there is a non-DRMed equivalent with the same functionality and equivalent
> cost?
The only explanation I can think of is, their marketing must be
AWEsome!-)
Alex
The Eternal Squire
>copyright. There is no way to make a living from playing solitaire either
>-- should the government pass a law giving a legal monopoly on playing red
>queen on a black king to my granny, so that everyone playing that move
>has to pay her ten cents? That would make her old age so much more
>comfortable. If you object to my proposal, I can ask "But without it, how
>could one possibly make a living playing solitaire?"
Reductio de absurdum counterargument.
>If their "one software idea of a lifetime" is as pointless, useless and
>just *bad* as the average would-be "Great American Novel", then copyright
>or no copyright nobody will want their poxy code. Sourceforge is full of
>software projects, 90% of which go nowhere.
Thomas Edison (I think it was him) once said it took 999 failures to
make 1 success. That makes SourceForge 10 times more successful.
>The world is filled with
>millions of wanna-be poets, writers and creators whose sum total
>contribution to the artistic wealth of the world is negative.
>I'm not just using hyperbole. By poisoning the well with their garbage,
>they just make it that little bit harder for genuinely talented artists to
>be heard.
Whose opinion? Yours, or the market's?
>Despite this, people keep trying to write the Great American Novel.
>Creative artists will create, even if they would be economically better
>off washing dishes at Greasy Joe's Diner for a buck an hour. Michaelangelo
>didn't stop painting because he had no copyright protection.
And so the only valid income for a creative type is psychic income?
>The natural state of things is not copyright. "No copyright" is not
>punishing the author any more than "no flying unicorns" is punishing
>little girls with a fantasy for flying through the sky on the back of a
>horned horse. It is just the way things are.
Nature can be cruel. Do we dare drink unpasteurized milk because
natural is always good? For millenia slavery and serfdom were
considered "natural", but it caused endless human misery. And what
about plumbing and flush toilets? Those are not natural means to
convey eliminated wastes, but having just that in a society increases
the life expectancy of all its members by at least 10%.
The purpose of humanity is to NOT accept the way the things are... but
to apply compassion in all situations which if unaided cause great pain
and suffering.
>Copyright is a gift granted by the government, not the natural state of
>the world. When kings and emperors and presidents give commercial and
>economic gifts, like monopolies, they rarely are for the benefit of the
>majority.
Last I knew, we had government by, for, and of the people. We give
these gifts to ourselves, our officials serve at our pleasure. I
believe we decided to choose to give ourselves the gift of copyright
because that way a creator can be rewarded for his efforts rather than
his hiers.
>Lots of ideas have no legal monopoly. There is no legal monopoly on (say)
>good gardening skills, or the specific way of mixing the batter to make
>extra light and fluffy bread.
Reductio de absurdum counterargument again.
>Why should some ideas be privileged over others?
This is a corallary of the idea that people have the right to pursue
happiness... which could basically mean either increased convience of
life, longer lifespan, or greater joy within. Any idea which
increases happiness in a society as a whole is more worthwhile than an
idea which does not. And the market decides which is which.
>Lack of copyright doesn't need to be defended, as it is the natural state
>of the world.
And again, is everything about nature always good? God made us just a
little less than the angels, so that we could apply our sense of
compassion to natural situations that are bound to cause misery.
Copyright produces less misery, IMHO, than it causes.
>But my point is that there is a serious lack of evidence one way or the other
Billions of dollars supporting the lives of hundred of thousands of
people is pretty strong evidence that we are doing something right.
>and what
>evidence there is suggests strongly that over-strong copyright laws (like
>we have now) are bad for *everyone*, and that weaker copyright (as in the
>early 20th century) would be better.
And here is the crux of the debate. If good, how strong should it be?
Strong enough so that the creator pay his rent and his food and put his
children through college. No so strong that a new creator can't derive
a worthwhile new work from the old.
>In any case, piracy is demonstrably *not* bad for everyone. The entire US
>movie industry would not exist if not for patent infringement: the baby
>industry was being choked out of existence by the high royalties and
>licence fees demanded by the holders of Thomas Edison's patents, until
>they fled to California where enforcement was lax.
But that's apples versus oranges, patent is far different from
copyright.
> It churns my stomach to see
>thieves and con artists like the RIAA trying to take the moral high ground
>with talk of "copying is theft".
Copying is theft of opportunity for the creator to be rewarded for his
efforts. The RIAA serves an important role in attempting to introduce
this idea as part of our social norms and courtesies.
>The mistake is only think of piracy as lost revenue.
Piracy occurs when the taking occurs without the consent of the
creator. Derivation and reverse engineering are not piracy, and has
been shown as such in court. Admittedly there is a very thin line.
And open source is not piracy, as the consent is given.
Mike Meyer
>>the world. When kings and emperors and presidents give commercial and
>>economic gifts, like monopolies, they rarely are for the benefit of the
>>majority.
> Last I knew, we had government by, for, and of the people.
As far as I know, only one country ever claimed to have that, so your
"we" only applies to citizens of that country, and not to everyone who
may be reading the letter - and the status of the person you quoted
but did not attribute is unclear.
Further, recent evidence is that this is no longer true in that
country, assuming it ever was.
>>and what
>>evidence there is suggests strongly that over-strong copyright laws (like
>>we have now) are bad for *everyone*, and that weaker copyright (as in the
>>early 20th century) would be better.
> And here is the crux of the debate. If good, how strong should it be?
> Strong enough so that the creator pay his rent and his food and put his
> children through college. No so strong that a new creator can't derive
> a worthwhile new work from the old.
Neither of your two stated goals are being met by the current
copyright system. One of them is simply absurd as stated - presumably
because your statement is incomplete. Copyright by itself does not pay
the rent, put food on the table or put people through college. It's
strong enough to be do that *if* the public values what you create
enough and *if* you work hard enough at marketing it and *if* you
produce enough. Those are some mighty big ifs.
On the other hand, we're liable to never see creative work derived
from any Disney property newer than the Mouse, with certain narrow
exceptions. It seems that the government "by, for and of the people"
has reliably extended the lifetime of copyrights - retroactively, even
- every time the Mouse is about to slip into the public domain. Maybe
"the people" you're talking about above are "the rich corporations
with the congresscritters in their pockets." But that's hardly "the
majority".
>> It churns my stomach to see
>>thieves and con artists like the RIAA trying to take the moral high ground
>>with talk of "copying is theft".
> Copying is theft of opportunity for the creator to be rewarded for his
> efforts. The RIAA serves an important role in attempting to introduce
> this idea as part of our social norms and courtesies.
You apparently think that taking the opportunity for the creator to be
rewarded for their efforts is ok if you deride other people who do
that very thing. So what's the difference between the RIAA and a
pirate who publicly points out that what the RIAA is up to?
The Eternal Squire
>"we" only applies to citizens of that country, and not to everyone who
>may be reading the letter - and the status of the person you quoted
>but did not attribute is unclear.
It applies to not only the US, which explicitly has "We The People" in
our
Constitution, but to all other countries who model on republican
systems: Japan, Germany, France, South Korea, Taiwan, and more.
>Further, recent evidence is that this is no longer true in that
>country, assuming it ever was.
Wow, how Machiaviellian.
>Copyright by itself does not pay
>the rent, put food on the table or put people through college. It's
>strong enough to be do that *if* the public values what you create
>enough and *if* you work hard enough at marketing it and *if* you
>produce enough. Those are some mighty big ifs.
Yes, profitable innovation is 1 percent inspiration plus 99 percent
persperation.
>Maybe "the people" you're talking about above are "the rich corporations
>with the congresscritters in their pockets." But that's hardly "the
>majority".
It sometimes works that way, unfortunately. But at least we can vote
the
bastards out when we hear of such things.
>You apparently think that taking the opportunity for the creator to be
>rewarded for their efforts is ok if you deride other people who do
>that very thing.
And in what way is piracy a form of creation?
>So what's the difference between the RIAA and a
>pirate who publicly points out that what the RIAA is up to?
The difference is that the RIAA does not copy software without the
copyright holder's consent.
Erik Max Francis
> Further, recent evidence is that this is no longer true in that
> country, assuming it ever was.
Oh, please. Take the political crap elsewhere.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
There is no fate that cannot be surmounted by scorn.
-- Albert Camus
Mike Meyer
>>country, assuming it ever was.
> Wow, how Machiaviellian.
Just an observation on the state of the US. It's been a long while
since the people running the country did so for the people.
>>Copyright by itself does not pay
>>the rent, put food on the table or put people through college. It's
>>strong enough to be do that *if* the public values what you create
>>enough and *if* you work hard enough at marketing it and *if* you
>>produce enough. Those are some mighty big ifs.
> Yes, profitable innovation is 1 percent inspiration plus 99 percent
> persperation.
The critical thing is that copyright isn't a vital part of the
formula. Lots of people make a good living creating intellectual
property without needing copyright on said property to provide the
income.
The whole claim that copyright benefits the creator is a
misdirection. Look at the number of creators who make a living off of
sale of copyrighted materials vs the number of people between the
creator and the consumer making a living off their work. Tell me who
owns the big, fancy offices - the creators, or the middlemen. Tell me
who's lobbying congress to create laws that protect and extend
copyright. Finally, notice the difference between what you pay for a
mass-market work - dollars - and what the creator gets - pennies, and
tell me who gets the difference. Yes, copyright benefits the creator,
but the primary beneficiaries are the people who arrange to put hard
media in the hands of the public - the publishers.
During the bulk of the twentieth century, this arrangement was
reasonable - the middlemen were putting up the money, and taking all
the financial risks. In some cases, they even took on the risk for the
creator themselves, paying the creator an advance against royalties,
so that if the product failed in the market, the creator got paid, and
they took the hit for it.
Given all that, the *real* question isn't "How will the creator get
paid?", it's "How will the creator get published?" The last few
decades have given us a *lot* of answers to that: put it on their web
site, which can be had for free; put it in a podcat; blog it; put it
in a torrent; and so on. How they make money off of it after that is
still being explored, but people are doing it. Yes, the creator
doesn't sell as many copies this way. On the other hand, they get a
much larger percentage of the price of the product.
Publishers are in danger of becoming irrelevant. That's why they're
making all the noise, and doing everything they can to limit the
publics rights. They're distracting people from the real issue - their
bottom line - by claiming it's "for the good of the creator", while
they try and make sure their business model - the one where they get
the bulk of the profits - stays in place. *These* are the people whose
side you are arguing, not the creator.
>>Maybe "the people" you're talking about above are "the rich corporations
>>with the congresscritters in their pockets." But that's hardly "the
>>majority".
> It sometimes works that way, unfortunately. But at least we can vote
> the
> bastards out when we hear of such things.
It's been working that way regulary since the 1920s, and the same
bastards are still running the country.
>>You apparently think that taking the opportunity for the creator to be
>>rewarded for their efforts is ok if you deride other people who do
>>that very thing.
> And in what way is piracy a form of creation?
That's a complete non-sequitor.
>>So what's the difference between the RIAA and a
>>pirate who publicly points out that what the RIAA is up to?
> The difference is that the RIAA does not copy software without the
> copyright holder's consent.
Actually, they do. More accurately, the companies that form the RIAA
do. That's the point.
Mike Meyer
> Mike Meyer wrote:
>> Further, recent evidence is that this is no longer true in that
>> country, assuming it ever was.
> Oh, please. Take the political crap elsewhere.
It's got as much right to be here as the copyright crap. And I'm
trying to keep it to the minimum required to refute the political crap
I'm answering.
Steven D'Aprano
>>Perhaps there is no way to make a living from writing novels without
>>copyright. [snip] I can ask "But without it, how
>>could one possibly make a living playing solitaire?"
>
> Reductio de absurdum counterargument.
You say that as if it is a bad thing.
[snip]
> Thomas Edison (I think it was him) once said it took 999 failures to
> make 1 success. That makes SourceForge 10 times more successful.
Argument by platitude is it?
>>The world is filled with
>>millions of wanna-be poets, writers and creators whose sum total
>>contribution to the artistic wealth of the world is negative.
>
>>I'm not just using hyperbole. By poisoning the well with their garbage,
>>they just make it that little bit harder for genuinely talented artists to
>>be heard.
>
> Whose opinion? Yours, or the market's?
It isn't a matter of opinion, it is a matter of objective fact. Ask any
publisher: all the promotion in the world won't increase the number of
book sales in total, but merely shift sales from some other books to the
ones you are promoting.
Believe me, publishers have been trying to influence the market to buy
more books, and if there is a way, they don't know it. The Harry Potter
fad is exceptional, and the publishers don't know what triggered it any
more than anyone else. (It certainly isn't the writing, which is only
moderately good, or the plot, which is terribly unoriginal.)
Walk into any book shop -- there are thousands of books. I just spent a
wonderful, but frustrating, afternoon yesterday shopping for books at six
different shops. I ended up with three books in my bag and a sinking
feeling that there are thousands of titles that I never even glanced at,
let alone made a rational decision whether or not to buy. I never even
walked through the history section, and I love history books.
With tens of thousands of new titles coming our every year, I can't even
notice all the new books, let alone the back catalog or out of print
books. Not read or buy -- merely notice.
>>Despite this, people keep trying to write the Great American Novel.
>>Creative artists will create, even if they would be economically better
>>off washing dishes at Greasy Joe's Diner for a buck an hour. Michaelangelo
>>didn't stop painting because he had no copyright protection.
>
> And so the only valid income for a creative type is psychic income?
Do you think Michaelangelo survived on psychic income? Or Shakespeare, or
Bacon, or Ovid?
>>The natural state of things is not copyright. "No copyright" is not
>>punishing the author any more than "no flying unicorns" is punishing
>>little girls with a fantasy for flying through the sky on the back of a
>>horned horse. It is just the way things are.
>
> Nature can be cruel. Do we dare drink unpasteurized milk because
> natural is always good?
I've drunk unpasteurized milk. It is lovely. There is nothing wrong with
unpasteurized milk, if it is fresh. Keeping it fresh is the hard part.
> For millenia slavery and serfdom were
> considered "natural", but it caused endless human misery. And what
> about plumbing and flush toilets? Those are not natural means to
> convey eliminated wastes, but having just that in a society increases
> the life expectancy of all its members by at least 10%.
It is irrelevant that natural things can be bad -- firstly, you have to
demonstrate that the alternative is better, and secondly you accused me of
"punishing" writers. Punishment doesn't come into it.
But please, if you can demonstrate that some level of copyright and/or
patent protection is good, I'm all ears. I already have my opinion, as I'm
sure you do, and if you read my earlier post carefully instead of jumping
to conclusions you will probably be able to work out what that is.
> The purpose of humanity is to NOT accept the way the things are... but
> to apply compassion in all situations which if unaided cause great pain
> and suffering.
Exactly, which I why I'm doing my best to have the excessively strong
so-called "intellectual property" laws rolled back. I may never succeed,
but at least I'm trying to prevent abominations like the lawyer who has
applied for a patent on storylines.
>>Copyright is a gift granted by the government, not the natural state of
>>the world. When kings and emperors and presidents give commercial and
>>economic gifts, like monopolies, they rarely are for the benefit of the
>>majority.
>
> Last I knew, we had government by, for, and of the people.
And a wonderful fairy tale that is too.
> We give
> these gifts to ourselves, our officials serve at our pleasure. I
> believe we decided to choose to give ourselves the gift of copyright
> because that way a creator can be rewarded for his efforts rather than
> his hiers.
Yeah, right, that's why the Sony Bono Act extended copyright to 90 years
for corporations. You think Walt Disney is still alive to enjoy the riches
generated by Mickey Mouse?
Perhaps you should tell that to musicians, who were robbed of copyright
protection by an underhanded trick committed by a glorified clerk Mitch
Glazier, who later got a job for the RIAA:
http://www.cdbaby.net/articles/courtney_love.html
Yeah, government by, for, and of the people. It is to laugh.
Did you know that when copyright was first introduced in the United
States, you had to register to get 14 years protection, and then could
re-register for another 14 years if you wished? Registration was
essentially free of cost except for time. Only TWO PERCENT of books
published at the time were protected by copyright, the authors and
publishers making the decision that registering for copyright wasn't even
worth their time, and of those that did bother to register once, less than
one percent bothered to re-register 14 years later.
The market spoke: something like two out of a thousand authors felt that
28 years of monopoly protection was worth perhaps a day filling out a
couple of forms. The result was a wonderful vibrant public domain for
publishers and authors and other creators to work from.
Today, the merest scribble on a napkin is automatically protected by
copyright for 90+ years, and the public domain for authors to build on is
impoverished. In the twenty years since the Sony Bono Act was enacted,
more than one million patents will expire and not one copyright.
When you replied to my post, and your software automatically copied my
text into your reply, you were infringing my copyright -- as I have
infringed yours. The chances of me collecting damages from you are
essentially zero, but you were breaking the law. Laws which make ordinary
behaviour criminal or civil offences are not good laws, even if they
aren't enforced: they encourage disrespect for laws.
>>Lots of ideas have no legal monopoly. There is no legal monopoly on
>>(say) good gardening skills, or the specific way of mixing the batter to
>>make extra light and fluffy bread.
>
> Reductio de absurdum counterargument again.
No, it comes to the very heart of the matter. Why are some ideas given
monopoly protection and not others? Why shouldn't cooking, which is an art
form, be given legally enforced monopoly protection? When you go to a
restaurant and see a dish on the menu, why shouldn't the restaurant be
permitted to sue you if you steal their intellectual property? They
worked hard to invent that recipe, why should anybody be allowed to just
duplicate it?
>>Why should some ideas be privileged over others?
>
> This is a corallary of the idea that people have the right to pursue
> happiness... which could basically mean either increased convience of
> life, longer lifespan, or greater joy within. Any idea which increases
> happiness in a society as a whole is more worthwhile than an idea which
> does not. And the market decides which is which.
Oh dear, a market-worshiper. "The Almighty Market Shall Provide".
>>Lack of copyright doesn't need to be defended, as it is the natural
>>state of the world.
>
> And again, is everything about nature always good? God made us just a
> little less than the angels, so that we could apply our sense of
> compassion to natural situations that are bound to cause misery.
> Copyright produces less misery, IMHO, than it causes.
Where is your evidence for this? Economic analysis of the Sony Bono Act
was that it would add an average of just pennies of extra income to
the average copyright owner over an entire lifetime, while costing
publishers and readers hundreds of dollars in lost opportunities.
>>But my point is that there is a serious lack of evidence one way or the
>>other
>
> Billions of dollars supporting the lives of hundred of thousands of
> people is pretty strong evidence that we are doing something right.
What billions of dollars? What hundreds of thousands of people? The
average writer does not make a living from his or her books -- they are
lucky to make minimum wage. The average advance for a first novel is
$2000. It might take an author a year's work to get the book in a state
that they will be offered a contract, and another six months of extra work
before it is ready to be published. Something like 90% of books never get
any royalties beyond that first advance, and they never get offered a
second contract. You do the maths.
>> It churns my stomach to see
>>thieves and con artists like the RIAA trying to take the moral high
>>ground with talk of "copying is theft".
>
> Copying is theft of opportunity for the creator to be rewarded for his
> efforts. The RIAA serves an important role in attempting to introduce
> this idea as part of our social norms and courtesies.
The RIAA are the biggest thieves and pirates out there. Their concern for
artists is *negative* -- they will, and have, deliberately attempted to
impoverish artists out of spite or an attempt to control the market, even
if it costs them money in the short term. I'm married to a musician who
had a long career in California, I know what I'm talking about. Or ask
George Michael what he thinks of the RIAA and the labels.
Or read this:
http://www.negativland.com/albini.html
--
Steven.
Robert Kern
> Erik Max Francis <m...@alcyone.com> writes:
>
>>Mike Meyer wrote:
>>
>>>Further, recent evidence is that this is no longer true in that
>>>country, assuming it ever was.
>>
>>Oh, please. Take the political crap elsewhere.
>
> It's got as much right to be here as the copyright crap. And I'm
> trying to keep it to the minimum required to refute the political crap
> I'm answering.
Off-topic responses are just as off-topic as the off-topic posts they
are responding to. Take 'em off-list. Use http://conversate.org/ for a
relatively convenient way to do so.
--
Robert Kern
rk...@ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Ben Sizer
> > I have considered distributing my program as open source but with
> > encrypted data. Unfortunately anyone can just read the source to
> > determine the decryption method and password. Maybe I could put that
> > into an extension module, but that just moves the weak link along the
> > chain.
>
> This isn't a Python problem, it's a problem with what you're doing. Try
> Alex's solution, and put the data on a network server that goes
> through whatever authentication you want it to.
To be fair, I don't think I have accused Python of having a problem,
just mentioned that this is an area where Python is less appropriate
than other languages which have a significant degree of obfuscation as
a side-effect of their use.
I already explained elsewhere that putting the data on the network is
not always appropriate. I know people love web services and the like
these days, but they are not the answer to everything. Even in
situations where it is practical to keep all the data server-side, it
still just moves the problem rather than solving it, in that instead of
people copying the data they now copy the authentication for the data.
Anecdotal evidence from experiences with online registration for
Half-Life 2 and Windows XP would suggest that this method ends up
annoying more legitimate customers than the usual copy-protection does.
> It is? Is the Python disassembler so much advanced over the state of
> the art of binary disassemblers, then? Or maybe it's the Python
> decompilers that are so advanced?
Decompyle (http://www.crazy-compilers.com/decompyle/ ) claims to be
pretty advanced. I don't know if you can download it any more to test
this claim though.
> As far as I can tell, the only real
> difference between Python bytecodes and x86 (for instance) binaries is
> that Python bytecodes keep the variable names around so it can do
> run-timme lookups. That's not that big a difference.
It makes a lot of difference when you're hunting around for something
or trying to understand a bit of code. Python bytecode (or at least,
the output from dis) is also a lot more straightforward than x86 or 68K
assembly to decipher.
> > No, certainly not. But if you can mitigate your losses easily enough -
> > without infringing upon anyone else's rights, I must add - then why not
> > do so.
>
> Elsewhere in the thread, you said:
>
> > I'd just like to make it non-trivial to make or use additional copies.
>
> How do you do that without infringing my fair use rights?
Yes, I suppose my terminology there was wrong. The term I should
probably have used was 'distribute usable additional copies'. Generally
speaking I believe in the "like a book" interpretation of rights... you
should have the right to give it away, sell it to someone, lend it,
excerpt parts for review or criticism, but not to distribute additional
copies that essentially duplicate the original.
On the other hand though, what you term a 'fair use right' is not
necessarily viewed that way under law. The relevant part of the law (at
least in the US) says "it is not an infringement for the owner of a
copy of a computer program to make or authorize the making of another
copy or adaptation of that computer program provided [...] that such
new copy or adaptation is for archival purposes only", which is quite
distinct, legally speaking, from saying "you have the right to make a
copy or adaptation for archival purposes".
However, this is drifting more into the legal area which I am less
interested in. Really I'd just like to be able to use Python for my
work and am interested in finding the best way of doing so.
--
Ben Sizer.
Mike Meyer
>> It is? Is the Python disassembler so much advanced over the state of
>> the art of binary disassemblers, then? Or maybe it's the Python
>> decompilers that are so advanced?
> Decompyle (http://www.crazy-compilers.com/decompyle/ ) claims to be
> pretty advanced. I don't know if you can download it any more to test
> this claim though.
No, it doesn't claim to be advanced. It claims to be good at what it
does. There's no comparison with other decompilers at all. In
particular, this doesn't give you any idea whether or not similar
products exist for x86 or 68k binaries. Your claim was that it's
easier to go from pyc files to code than from binaries to code. To
show that, you have to show not only that it's easy to go from pyc
files to code, but that it's hard to go from binary files to
code. I've dealt with some very powerfull disassemblers and
decompilers, but none of them worked on modern architectures.
>> As far as I can tell, the only real
>> difference between Python bytecodes and x86 (for instance) binaries is
>> that Python bytecodes keep the variable names around so it can do
>> run-timme lookups. That's not that big a difference.
> It makes a lot of difference when you're hunting around for something
> or trying to understand a bit of code. Python bytecode (or at least,
> the output from dis) is also a lot more straightforward than x86 or 68K
> assembly to decipher.
I'm not convinced of the former. I'll grant you half of the
latter. 68K machine language is fairly straightforward. On the other
hand, it's also seems to be irrelevant. What platform are you
developing for that's still based on the 68K?
>> > I'd just like to make it non-trivial to make or use additional copies.
>> How do you do that without infringing my fair use rights?
> Yes, I suppose my terminology there was wrong. The term I should
> probably have used was 'distribute usable additional copies'.
My question still stands, though - and unanswered.
> On the other hand though, what you term a 'fair use right' is not
> necessarily viewed that way under law. The relevant part of the law (at
> least in the US) says "it is not an infringement for the owner of a
> copy of a computer program to make or authorize the making of another
> copy or adaptation of that computer program provided [...] that such
> new copy or adaptation is for archival purposes only", which is quite
> distinct, legally speaking, from saying "you have the right to make a
> copy or adaptation for archival purposes".
I think this just makes explicit that those activies are indeed fair
use, which is what non-infringing copying is called, and that you're
playing semantic games to salve your conscience. But we can be
explicit if you want: How do you do that without requiring that your
software be given special consideration in the distaster recovery and
preparedness planning? You should be concerned about this, as that
special consideration is often "Return that POS".
Ben Sizer
> "Ben Sizer" <kyl...@gmail.com> writes:
> > Decompyle (http://www.crazy-compilers.com/decompyle/ ) claims to be
> > pretty advanced. I don't know if you can download it any more to test
> > this claim though.
>
> No, it doesn't claim to be advanced. It claims to be good at what it
> does. There's no comparison with other decompilers at all. In
> particular, this doesn't give you any idea whether or not similar
> products exist for x86 or 68k binaries.
That's irrelevant. We don't require a citable source to prove the
simple fact that x86 binaries do not by default contain symbol names
whereas Python .pyc and .pyo files do contain them. So any
decompilation of (for example) C++ code is going to lose all the
readable qualities, as well as missing any symbolic constants,
enumerations, templated classes and functions, macros, #includes,
inlined functions, typedefs, some distinctions between array indexing
and pointer arithmetic, which inner scope a simple data variable is
declared in, distinctions between functions/member functions declared
as not 'thiscall'/static member functions, const declarations, etc.
> I've dealt with some very powerfull disassemblers and
> decompilers, but none of them worked on modern architectures.
You can definitely extract something useful from them, but without
symbol names you're going to have to be working with a good debugger
and a decent knowledge of how to use it if you want to find anything
specific. Whereas Python could give you something pretty obvious such
as:
6 LOAD_FAST 0 (licensed)
9 JUMP_IF_FALSE 9 (to 21)
> > It makes a lot of difference when you're hunting around for something
> > or trying to understand a bit of code. Python bytecode (or at least,
> > the output from dis) is also a lot more straightforward than x86 or 68K
> > assembly to decipher.
>
> I'm not convinced of the former. I'll grant you half of the
> latter. 68K machine language is fairly straightforward. On the other
> hand, it's also seems to be irrelevant. What platform are you
> developing for that's still based on the 68K?
There are several embedded/portable devices based on 68K derivatives.
That's not really the point though. I chose 68K assembly as an example
as it's considered to be simpler than x86 assembly, yet it's still
significantly more complex and less readable than the output from
dis.dis()
> > The term I should
> > probably have used was 'distribute usable additional copies'.
>
> My question still stands, though - and unanswered.
I'm not really sure where we're going here. I have made the point that
I am not obliged to make my software copyable to facilitate your right
to copy it any more than any given newspaper is obliged to publish you
to facilitate your right to free speech. Therefore I find it hard to
see how anything is infringing upon a right here.
My interest lies in being able to use encrypted data (where 'data' can
also include parts of the code) so that the data can only be read by my
Python program, and specifically by a single instance of that program.
You would be able to make a backup copy (or 20), you could give the
whole lot to someone else, etc etc. I would just like to make it so
that you can't stick the data file on Bittorrent and have the entire
world playing with data that was only purchased once.
> But we can be
> explicit if you want: How do you do that without requiring that your
> software be given special consideration in the distaster recovery and
> preparedness planning?
I should state that I am not at all claiming a "one size fits all"
policy for software development. Firstly, from a personal point of view
I am talking about simple consumer entertainment software which is not
mission critical or anything like it. For more important software,
there will surely be different expectations and requirements. In my
case, providing a free download of any lost executables or data upon
presentation of a legitimate license key should be adequate.
--
Ben Sizer.
Mike Meyer
>> But we can be
>> explicit if you want: How do you do that without requiring that your
>> software be given special consideration in the distaster recovery and
>> preparedness planning?
> I should state that I am not at all claiming a "one size fits all"
> policy for software development. Firstly, from a personal point of view
> I am talking about simple consumer entertainment software which is not
> mission critical or anything like it. For more important software,
> there will surely be different expectations and requirements. In my
> case, providing a free download of any lost executables or data upon
> presentation of a legitimate license key should be adequate.
In other words, you don't do that at all. My special handling for such
things - and *especially* for entertainment software, where the media
gets handled by children - is "Return that POS." Worse yet, you play
semantic games so you can claim not to be violating fair use rights in
the process.
Bruno Desthuilliers
> Without copyright, how could one possibly earn a living writing a
> novel?
Without copyright, how could one possibly earn a living writing programs?-)
The Eternal Squire
>presentation of a legitimate license key should be adequate.
Excellent compromise!
The Eternal Squire
The Eternal Squire
lines of code) is about as large as a single person can write without
automation, hence it is of an effort comparable in scope and creativity
to a novel.
Chris Mellon
I don't know about you, but I own the copyright to almost nothing that
I have written and been paid for, and further, none of has it's
copyright exploited to make money for the entity that does own the
copyright.
Thats not to say that there wouldn't be massive fallout from the lack
of copyright, or that I support that extreme of a solution, but many,
many programs would still be written, and people would still be paid
to write them, even in the absence of copyright. In fact, a few
decades ago, it was legally uncertain whether software qualified for
an IP protection at all, and people still wrote, and were paid to
write, programs.
Erik Max Francis
> I don't know about you, but I own the copyright to almost nothing that
> I have written and been paid for, and further, none of has it's
> copyright exploited to make money for the entity that does own the
> copyright.
But they wouldn't have paid you if you didn't (implicitly) transfer the
copyright to them. So copyright is just as relevant whether it's a work
for hire or not.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
You could have another fate / You could be in another place
-- Anggun
Mike Meyer
>> I don't know about you, but I own the copyright to almost nothing that
>> I have written and been paid for, and further, none of has it's
>> copyright exploited to make money for the entity that does own the
>> copyright.
> But they wouldn't have paid you if you didn't (implicitly) transfer
> the copyright to them. So copyright is just as relevant whether it's
> a work for hire or not.
I'm in the same position as Chris, and I'll say that that's almost
certainly not true. For most of them, the copyright was
irrelevant. What mattered was the right to use the software. In fact,
some of the contracts I have had explictly did *not* transfer the
copyright, but only granted the right to use it.
I don't have figured postdating the introduction of shrinkwrap
software, but before then, copyright was irrelevant for the bulk of
software written. The majority was either public domain or classified.
Steven D'Aprano
I'm not sure if that is meant to be a rhetorical
question or not, but something of the order of 95% of
all software written is never distributed to others,
and so copyright or the lack of copyright is not an issue.
If software is for purely in-house use, you don't care
if you have copyright on it, because nobody can use
that software.
Very few professional (i.e. they get paid to program)
developers actually own the copyright on the programs
they write, and of those that do own the copyright,
even fewer make money directly from that copyright.
--
Steven.
Ben Sizer
> > case, providing a free download of any lost executables or data upon
> > presentation of a legitimate license key should be adequate.
>
> things - and *especially* for entertainment software, where the media
> gets handled by children - is "Return that POS."
That's funny, I could have sworn that a few messages above you
suggested I "Try Alex's solution, and put the data on a network server
that goes through whatever authentication you want it to."
Are you claiming therefore that it's more acceptable to you to have to
access the data remotely every time you use the software than once per
install?
> Worse yet, you play
> semantic games so you can claim not to be violating fair use rights in
> the process.
No, I am just pointing out that you are mixing up the concept of an
actual 'right' such as one embodied in a state's constitution, with an
implied 'right' that is just an exemption from committing an offence.
The term 'right' does not even appear in the relevant part of US
copyright law, except to state that it is a limitation on the copyright
holder's rights.
--
Ben Sizer.
Ed Jensen
> I'm not sure if that is meant to be a rhetorical
> question or not, but something of the order of 95% of
> all software written is never distributed to others,
> and so copyright or the lack of copyright is not an issue.
Can you cite your source(s) for this information?
petantik
Do developers, when writing code consider how protected their code will
be when considering what language they will write it in i.e ease of
use, speed of language, maintainability and 'obfuscatability' ?
Is the problem of protecting or otherwise encrypting portions of code a
showstopper for some companies/individuals when using bytecode
interpreted languages?
I'm asking coz i don't have any real world/industrial basis to better
understand the problem and factors involved when selling software - i'm
just a student
*********************************************************
petantik f00l
http://petantik.blogsome.com - A Lucid Look at Reality
Mike Meyer
> Mike Meyer wrote:
>> "Ben Sizer" <kyl...@gmail.com> writes:
>> > In my
>> > case, providing a free download of any lost executables or data upon
>> > presentation of a legitimate license key should be adequate.
>> My special handling for such
>> things - and *especially* for entertainment software, where the media
>> gets handled by children - is "Return that POS."
> That's funny, I could have sworn that a few messages above you
> suggested I "Try Alex's solution, and put the data on a network server
> that goes through whatever authentication you want it to."
> Are you claiming therefore that it's more acceptable to you to have to
> access the data remotely every time you use the software than once per
> install?
Alex's solution doesn't require special treatment for disaster
recovery and/or planning, and as such is a valid answer to the
question. It may be unacceptable for *other* reasons, but it beats
dictating a disaster recovery plan for your software to the end user
hands down on that basis.
>> Worse yet, you play
>> semantic games so you can claim not to be violating fair use rights in
>> the process.
> No, I am just pointing out that you are mixing up the concept of an
> actual 'right' such as one embodied in a state's constitution, with an
> implied 'right' that is just an exemption from committing an offence.
> The term 'right' does not even appear in the relevant part of US
> copyright law, except to state that it is a limitation on the copyright
> holder's rights.
You're still just playing semantic games. The common usage is "fair
use rights." If you mean "... without infringing on the end users
rights, except for fair use rights", then you should say that.
Steven D'Aprano
Not easily, but I will try.
If it helps, I will clarify what I was talking about -- in hindsight it is
a little unclear. Most software written (I think about 95%) is by
companies for in-house use only. Since it never gets distributed outside
of the company using it, copyright is of little additional value.
--
Steven.
The Eternal Squire
>understand the problem and factors involved when selling software - i'm
>just a student
A fair request. The teaching of legality and ethics of incorporating
other peoples' works into one's own should begin at 6th grade and be
repeated every year until the message is driven home.
The concept of intellectual property (patent, copyright, trade secret)
is an extension into the business world of issues regarding the proper
usage of ideas (e.g. scientific principles) as treated in high school
and college.
>Do developers, when writing code consider how protected their
>code will be when considering what language they will write it in
>i.e ease of use, speed of language, maintainability and
>'obfuscatability' ?
Typically not due to a few well-known principles: 1) Essentially an
optimized (not debug!) compilation from source code to machine language
is nearly as good as encryption for hindering reverse engineering of
the distributed code, 2) Network license servers residing on a
seperate machine in the network apart from the executing software have
become the method of choice for securing more valuable software, 3)
User support and service is not an increasingly large component of the
service provided by a software product, which can only be obtained
through possession of a legal copy, 4) The time-to-market and
obsolescense windows of software are continuing to decrease to the
point where the time required to get around security is more expensive
than the utility that software provides.
Of course, all generally sweeping rules are false including this one,
but those are the trends.
All that being said:
The greatest theft of sales opportunities resides in entertainment or
gaming software. Little can be done to stop it except through
repeated education at every grade level that copying without paying is
as bad as plagiarism and just as dangerous to one's career in school.
Ourselves and our children are lost generations with respect to ethics,
manners, and respect for authority, perhaps we can train our
grandchildren to behave more proprely.
Productivity software is less so, the market is usually flooded with
reverse engineered or lookalike competitors but brand name loyality
usually wins out. Electronic Design Automation (EDA) software is
rarely so, due to the huge need for customer support that is denied to
an unregistered user.
The Eternal Squire
3) User support and service is not an increasingly large component of
the
service provided by a software product, which can only be obtained
to
3) User support and service is an increasingly large component of the
service provided by a software product, which can only be obtained
Oops,
The Eternal Squire
Ben Finney
> The teaching of legality and ethics of incorporating other peoples'
> works into one's own should begin at 6th grade and be repeated every
> year until the message is driven home.
I disagree strongly.
The legality of copying, modifying and redistributing works should be
reformed until it matches a 6th grader's intuitions about sharing.
--
\ "I bought some powdered water, but I don't know what to add." |
`\ -- Steven Wright |
_o__) |
Ben Finney
Ben Finney
Utter poppycock. Who is to say that a particular entity holds an
exclusive "sales opportunity" to a particular individual? Are we to
protect the expectations of profit for some, at the expense of sharing
things with each other?
> Little can be done to stop it except through repeated education at
> every grade level that copying without paying is as bad as
> plagiarism and just as dangerous to one's career in school.
Wonderful double-think.
> Ourselves and our children are lost generations with respect to
> ethics, manners,
Ethics such as sharing, and helping one's neighbour?
> and respect for authority
When such "authority" demands that we enter unsigned contracts to
protect their profits, they lose our respect, yes.
> perhaps we can train our grandchildren to behave more proprely.
I certainly hope our grandchildren will live in an environment that
encourages helping each other, yes.
--
\ "We spend the first twelve months of our children's lives |
`\ teaching them to walk and talk and the next twelve years |
_o__) telling them to sit down and shut up." -- Phyllis Diller |
Ben Finney
The Eternal Squire
>reformed until it matches a 6th grader's intuitions about sharing.
A 6th grader also has intuitions regarding the ownership of an idea.
"It was MY idea!!!" "No, it's NOT!!!" "Is TOO!!!"
The Eternal Squire
The Eternal Squire
>exclusive "sales opportunity" to a particular individual? Are we to
>protect the expectations of profit for some, at the expense of sharing
>things with each other?
Utter horse manure. Anyone can profit from something so long as it
is thier own idea.
>> Ourselves and our children are lost generations with respect to
>> ethics, manners,
>Ethics such as sharing, and helping one's neighbour?
Giving away an illegal copy of software it not helping one's neighbor,
it is making that neighbor an accessory to copyright infringement,
a federal offense punishable not in excess of 10 years of $10K.
Such a nieghbor should ask: "with friends like that, who needs
enemies?"
>I certainly hope our grandchildren will live in an environment that
>encourages helping each other, yes.
Helping each other cheat on a test is not helping, it is hurting.
There
is no difference ethically between plagiarism, cheating, or
unauthorized
copying.
Steven D'Aprano
> The teaching of legality and ethics of incorporating
> other peoples' works into one's own should begin at 6th grade and be
> repeated every year until the message is driven home.
I think you have that completely backwards.
Sixth graders have an intuitive understanding of the economics and
morality of using "things" that adults these days rarely have.
Material things, objects, are scarce resources and cannot be taken with
impunity. If I take your black crayon, then you have one less black crayon.
Non-material things, ideas, are not scarce resources. If I take your idea
of writing programs in a high-level language like Python instead of using
machine code, you still have the idea and we are both better off.
> The concept of intellectual property (patent, copyright, trade secret)
> is an extension into the business world of issues regarding the proper
> usage of ideas (e.g. scientific principles) as treated in high school
> and college.
Nonsense. Patents, copyrights and trade secrets are completely and utterly
opposed to proper scientific principles. Alchemists and magicians tried to
monopolise their knowledge. Scientists share. The proliferation of patents
in the medical industry is *hurting*, not helping, medical research:
scientists are reluctant to publish knowledge, or are prohibited by their
employer, and the cost of doing basic research is sky-rocketing due to the
need to pay licence fees.
This is especially obscene when one realises that in the US 80% of the
scientific research that gets patented by private companies is paid for by
tax payer dollars. Your taxes pay for the science which then gets given on
a silver platter to some private company who collects monopoly rents on
that knowledge for 20 years. It is a nice scam if you can get away with
it, and the pharmaceutical companies have got away with it.
>>Do developers, when writing code consider how protected their
>>code will be when considering what language they will write it in
>>i.e ease of use, speed of language, maintainability and
>>'obfuscatability' ?
>
> Typically not due to a few well-known principles: 1) Essentially an
> optimized (not debug!) compilation from source code to machine language
> is nearly as good as encryption for hindering reverse engineering of
> the distributed code,
That is utterly wrong. Reverse engineering of even optimized code is
relatively easy. That is one of the big myths that plague the IT industry:
"if I don't release the source code, nobody will be able to work out how
my code works".
It just doesn't work that way. Just ask the people working on the WINE
project, who have a working, almost complete, bug-for-bug compatible
reverse-engineered Windows emulator, and they've done it in their spare
time.
Or ask the virus writers, who often find bugs and buffer over-flows and
other security holes in software before the guys with the source code find
them.
Reverse engineering object code is harder than reading source, but it is
still not a barrier to anyone serious about working out how your code
works.
[snip]
> The greatest theft of sales opportunities
Listen to yourself. "The greatest theft of SALES OPPORTUNITIES". What is
that supposed to mean? Not theft of goods, not even theft of ideas, but
the theft of an opportunity to make a sale?
"I might have been able to sell to that person, but now I can't, it's YOUR
FAULT... I'm going to sue!!!"
The greatest "theft" of sales opportunities is COMPETITION, not copying.
If every food store and restaurant in the country shut down except
McDonalds, then they would have all the sales opportunities anyone would
ever want. Every store that competes with them is "stealing" the
opportunity to make a sale.
We've already seen this way of thinking. Listen to Jamie Kellner, chairman
and CEO of Turner Broadcasting System:
"Any time you skip a commercial you're actually stealing the programming."
Listen to the arrogance: "I guess there's a certain amount of tolerance
for going to the bathroom." We need a permission slip from the television
stations to go to the toilet? Heaven forbid we turn the machine off,
that's theft of sales opportunities.
Perhaps somebody should remind these folks, we're not the customer. We're
the product they are selling: they sell our eyeballs to advertisers, who
give them money for the opportunity to be seen by us. If we choose to
skip the commercials, that's just too bad for Jamie Kellner's business
model.
> Ourselves
> and our children are lost generations with respect to ethics, manners,
> and respect for authority, perhaps we can train our grandchildren to
> behave more proprely.
There is too much respect for so-called "authority", not too little.
Respect for authority is just another way of saying "Don't think for
yourself, do as you're told."
--
Steven.
Steven D'Aprano
That's what happens when you try to teach 6th graders about intellectual
property: they revert back to two year old mentality.
--
Steven.
Ben Finney
And what should we teach those children?
"Now children, it can be an idea you *both* have, and you both get the
benefit. Learn to share."
Or, do we instead teach them:
"Excellent children! Keep on fighting over who owns ideas, and never
share them. That's the sort of society we want you to live in."
The more you try to teach them to stop sharing, the more we'll teach
them to share. Keep your propaganda about "sharing == evil" away from
children.
--
\ "Those are my principles. If you don't like them I have |
`\ others." -- Groucho Marx |
_o__) |
Ben Finney
Ben Finney
> >Ethics such as sharing, and helping one's neighbour?
>
> Giving away an illegal copy of software it not helping one's
> neighbor, it is making that neighbor an accessory to copyright
> infringement, a federal offense punishable not in excess of 10 years
> of $10K.
So the law is the guide to ethical behaviour? Sure you don't have that
reversed?
--
\ "Unix is an operating system, OS/2 is half an operating system, |
`\ Windows is a shell, and DOS is a boot partition virus." -- |
_o__) Peter H. Coffin |
Ben Finney
Mike Meyer
> A fair request. The teaching of legality and ethics of incorporating
> other peoples' works into one's own should begin at 6th grade and be
> repeated every year until the message is driven home.
Right. You want to teach potential programmers that they should make a
checking the standard libraries and network library repositories for
libraries that can, if incorporated into their work, would make
finishing the product at hand that much easire. You wannt to teadh
them that this is not long legal and ethical, but smart.
I assume that other professions have similar tools/etc. available.
The Eternal Squire
sales opportunites... these are called infringement upon sales
territories..
Alex Martelli
Hmmm, I thought the original "95%" (which I think I remember from
something ESR wrote, but can't pin down what) applied to a wider
category matching your former description: 95% of all software written
is never distributed to others, _either_ because it was never meant to
be, _or_ because the development project failed disastrously (after some
code got written but before it got deployed, i.e., distributed), as so
many projects in the SW industry do (at various stages of the
development process).
Alex
Alex Martelli
> Alex's solution doesn't require special treatment for disaster
> recovery and/or planning, and as such is a valid answer to the
I'm not sure I understand this. I would assume that any software (or,
for that matter, data) of any substantial importance, worthy of being
deployed on a server, does include disaster planning (and recovery
plans, in particular) as a routine part of server-side deployment
(regular backups with copies off-site, etc etc).
Of course, server side deployment DOES make it considerably easier to
enjoy such crucial services, compared with client side deployment; but I
had not addressed such issues at all in my original posts on this thread
(in terms of "IP protection", a "fat client" with data kept client-side
might be just as suitable as a "thin client" for server-side
deployment... but it would be just as vulnerable as a wholly client-side
deployment to issues of [lack of] disaster planning etc).
So, I may perhaps be misunderstanding what you're saying about "my
solution"...?
Alex
The Eternal Squire
language, so this is not an issue.
Mike Meyer
> Mike Meyer <m...@mired.org> wrote:
>> Alex's solution doesn't require special treatment for disaster
>> recovery and/or planning, and as such is a valid answer to the
> I'm not sure I understand this. I would assume that any software (or,
> for that matter, data) of any substantial importance, worthy of being
> deployed on a server, does include disaster planning (and recovery
> plans, in particular) as a routine part of server-side deployment
> (regular backups with copies off-site, etc etc).
To recap, I asked the question "how do provide software that is
protected but doesn't require special treatment in disaster recovery
and preparedness planning?" I didn't raise the issue of server
deployment in light of this, but had earlier pointed it out as a good
solution to the general issue of copy protection. This resulted in my
beinng asked if I prefered your solution to an alternative that
involved local storage.
Anything on your server doesn't require any special treatment in my
planning. I might want to check what you promise to provide and how
well you live up to those promises as part of evaluating your service,
but that's a different issue. So "Put the software on a server and let
them run it there" is a valid answer to my question.
> So, I may perhaps be misunderstanding what you're saying about "my
> solution"...?
I hope I clarified what I meant.
Steven D'Aprano
Is that supposed to impress me? There are plenty of
lousy laws on the books being enforced.
Oh yeah, that's right, they are the Authorities, and
the Authorities can do no wrong.
--
Steven.
Ben Sizer
> > Are you claiming therefore that it's more acceptable to you to have to
> > access the data remotely every time you use the software than once per
> > install?
>
> Alex's solution doesn't require special treatment for disaster
> recovery and/or planning, and as such is a valid answer to the
> question. It may be unacceptable for *other* reasons, but it beats
> dictating a disaster recovery plan for your software to the end user
> hands down on that basis.
Sorry, I just don't see this as being a significant difference that
makes 'access-always' acceptable and 'access rarely' unacceptable.
> > No, I am just pointing out that you are mixing up the concept of an
> > actual 'right' such as one embodied in a state's constitution, with an
> > implied 'right' that is just an exemption from committing an offence.
> > The term 'right' does not even appear in the relevant part of US
> > copyright law, except to state that it is a limitation on the copyright
> > holder's rights.
>
> You're still just playing semantic games. The common usage is "fair
> use rights." If you mean "... without infringing on the end users
> rights, except for fair use rights", then you should say that.
Call it what you like; still, I cannot be infringing on your right when
such a right does not exist to be infringed. If you want to term it a
'right', feel free, but that's not what you're granted under US law or
the Berne Convention. The 'common usage' here leads to a
misinterpretation of what you're entitled to. What is actually stated
is a limitation on the copyright holder's exclusive rights, which is a
very different matter.
--
Ben Sizer