hide python code !

Paul Boddie paul at boddie.org.uk
Tue Aug 15 13:24:52 EDT 2006


Ben Sizer wrote:
> Paul Boddie wrote:
> > Successful software businesses are not merely founded on the process of
> > having ideas and implementing them - they might also need to be
> > effective at delivering those ideas and going through the whole process
> > again and again. Writing a neat utility for Windows is not by itself
> > the foundation of a successful business - other factors are critical,
> > whether they be continuous improvements, service, support, or a number
> > of other things.
>
> Yes, but this was never about 'successful software businesses' as such.

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

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

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

> > So, if we decide to ignore people waving pieces of paper around which
> > make some claim to an idea or some way of solving some problem, instead
> > investigating the actual code, others have pointed out already that if
> > you provide just a binary and there exist people who want to know what
> > you've done, those people will find it out whether you make it easy for
> > them or not.
>
> Yes, in much the same way that there is no point ever locking your
> doors or installing burglar alarms, as a determined thief will
> eventually steal your belongings.

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

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

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

> > Now, if we sidestep the issue of decompiling binaries and
> > cast the affected work as some kind of service, the question can now be
> > expressed as whether you should expect to be rewarded forever for
> > providing such a service.
>
> But what is 'forever'? Is it a single service for one customer that
> persists forever? Or is it a service that will be invoked many times by
> different customers forever? Since these are completely different
> scenarios, the answer is "it depends".

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

[...]

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

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

[Cliff Richard's day at work]

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

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

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

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

Paul




More information about the Python-list mailing list