Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
- Subject: Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
- From: Greg Hurrell <email@hidden>
- Date: Wed, 21 Apr 2004 00:24:20 +0200
El 20/04/2004, a las 23:33, Rams escribis:
From Macromedia's website
Who will be required to activate their products?
Activation is included in our MX 2004 products and Contribute 2.
Customers who purchase retail, ESD, or boxed products or receive
original equipment manufacturer (OEM) versions of Contribute must
activate the software. However, if you've obtained the software
through a Macromedia volume-licensing program such as the Macromedia
Volume License Program (MVLP), you won't need to activate. Products
obtained through a DevNet Subscription may be required to activate
even when purchased through a volume agreement.
I read: You are only purchasing one copy.
I haven't read the license, but no doubt you're correct. No doubt the
license says something along the lines of, you are licensing one copy,
and have permission to install it on a single machine. Sounds perfectly
fair to me.
You are not really an important customer to us. We realize Product
Activation (PA) is a hassle. That is why we will not be asking our
important customers to deal with it. You will deal with our PA and
any snafus that will result from it.
I don't read any of that stuff. What I read is, "PA is not intended to
inconvenience honest users. It is not an accusation that you, our
customer, is a criminal. What it *is* is an effective piracy prevention
mechanism which prevents would-be software pirates from using a
single-user, single-machine license on multiple machines".
No doubt the reason that activation isn't required for the MVLP
programs is because, by their very nature, these programs are intended
to allow mass installation on a large number of machines. Macromedia's
Product Activation is designed to tackle a different problem (the
illegal use of single-user, single-machine licenses on multiple
machines) and so doesn't apply here.
There's nothing in there about "more important", "less important", or
"not important" customers. I am sure that Macromedia sees every
customer as important. I certainly do in my own shareware business. I
sell my software cheaply (as cheaply as five bucks a pop). Every single
sale is important, because the only way I can hope to continue to work
fulltime on shareware is if I keep those tiny little sales coming in in
sufficient quantities to pay the rent. There's no doubt that Macromedia
sees it the same way. Every sale adds up.
PA will write to track zero of your drive. PA will leave you open to
root privilege escalation until we get around to fixing it. We are
not responsible for any damages or lost time PA may cause you.
I have no idea about the technical details of Macromedia's PA. If what
you say is true and their system tampers with your file system and
opens a security hole, then it certainly qualifies as an example of
"badly designed, poorly implemented PA. I don't endorse that any more
than I endorse badly designed, poorly implemented software of any kind.
A well designed, well implemented PA system should be completely
transparent in the sense that there should be full disclosure of how
the system works and why. The system shouldn't hide data anywhere on
your computer, nor tamper with the filesystem. The system shouldn't
compromise the end users' privacy. The eSellerate PA scheme is a good
example of a well thought out system that fulfills these requirements.
This should not concern you because it does not concern us. Again,
you are not a very important customer. You are only purchasing a
single copy. If that bothers you, go somewhere else.
I don't see any statements about lack of concern or lack of importance.
What I do see is a system designed to thwart casual software piracy. I
would phrase it like this. "This is our intellectual property. We have
product activation to prevent license abuse. If you object to the
system and choose to exercise your right to shop elsewhere then we must
regretfully allow you to do so because the cold hard reality of the
business is that casual software piracy hurts our business badly and we
are compelled to deploy countermeasures."
Call me a crack pot, but I went somewhere else.
I am not going to call you a crack pot, but you yourself have admitted
that you've ended up purchasing a product that wasn't your first
choice.
Just imagine if every piece of software on your machine required PA.
One drive failure would require several days of waiting on customer
service, who values your call but doesn't mind making you wait an hour
and a half before getting around to answering it.
Completely incorrect. Good PA doesn't make honest users jump through
hoops. Good PA has reasonable tolerances inbuilt which permit a degree
of hardware reconfiguration without requiring reactivation. Good PA is
so transparent to the end user that it is no more complicated than
entering your serial number (which you have to do anyway) and clicking
a button (which you have to do anyway).
I completely agree with you that the kind of Bad PA you're using in
your examples is unacceptable. I wouldn't stand for it either, just
like I wouldn't bother to purchase any software that was shabbily and
thoughtlessly designed.
I won't pay hard earned money for mistreatment just because some
developer thinks a 'casual pirate' on P2P is going to go out and buy
their software rather than simply choose from the multitude of other
similar applications available for 'free' in the same place. Remember
developers, you have to convert at least as many pirates as you loose
already paying customers due to PA.
There is zero doubt in my mind that the number of lost customers is
negligible (ie. close to zero), and the number of
casual-piracy-to-purchase conversions is significant. I am not so daft
that I would go through the rigamarole of developing the system without
first being sure that the overall effect on sales would be positive and
significant.
Have you researched this, or are you simply making a calculated
gamble? A bird in the hand...
My own experience indicates that if you implement PA well, only a
miniscule number of users will decide against your product because of
it. (Implement it badly, as you've illustrated above, and the number
increases.)
You'd see the same if you sold a shareware product but didn't require
serial numbers. The day you introduced serial numbers you'd see your
sales rate shoot up 1000%. (ie. from 1 purchase per 1000 downloads, to
1 purchase per 100 downloads). Forcing users to enter serial numbers is
a burden. It's an inconvenience. But do you see people running around
saying, "I'm being accused of being a criminal! I'm being told that I
am not important!" No, you don't see any of those things. People are
used to serial numbers, and they'll get used to product activation too;
and especially so if the activation is handled in an elegant,
trouble-free, and fair manner, which is what I am arguing for.
If you follow eSellerate's experience (see the emails by Josh), you'll
see they've only had one complaint. Note that developers who use
eSellerate's engine boast some of the highest download-to-registration
ratios in the industry (as high as 10%). Something is evidently
working well here.
Ok, I've said my peace. Now if you will all excuse me, I'm off to
purchase a Photoshop Plugin from a vendor whose business will lose at
least one customer if Adobe chooses to use PA on the Mac. :-/
Fair enough. Free country and all. Free market.
In the mean time, I'll continue working on improving my copy protection
technology, improving my products, and making a living doing what I
enjoy.
Cheers
Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.