I very much appreciate all of the comments that I have received, both
publicly and privately. In that regard, let me answer just a few of the
comments here.

Mark Wonsil wrote:

> Another system I have seen lately is a license server.  This system takes a
>  registration key (a base) and then calculates a hash based on several
>  identifying characteristics of the PC.  This hash is sent to a server to
see
>  if the license is valid.

That's exactly what we're planning on doing, but only for the demo period and
for the initial registration. If we were to require a license check for every
legal copy, every time the application was run, we would have to insure that
our license server was always up and that the internet would never fail.
While we can insure the first aspect to some degree (we're planning on
putting in UPS'es everywhere and installing an auto-on micro-turbine
generator or a natural-gas fuel cell to backup the UPS'es), we have no
control over the internet, either locally to us or near the customer.

This is the reason that properly profiling the user's PC is so important. A
simple license file can be locally checked to determine the validity of copy,
without having to dial back to AICS each time the program is to be run.


John Korb wrote:

> In addition to the points previously made, how do you plan to handle "site
>  licensing", or do you expect there to be need or demand for site licensing?
>
>  As others have mentioned, people swap out hard drives.  In two years I had
>  three hard drives in my (company provided) laptop.  I have five PCs (some
>  running Windows, some running Linux) in my office.  Three of those (two
>  Windows, one Linux) have had hard drives changed - not because the hard
>  drives failed, but because a new, faster controller and a faster drive
>  extend the life of the machine by making it "faster"

The enabling "license" will actually be a ten-letter string, something like
"EWKIDCSTYA". When that string is first entered into the application's
registration window, the profile of the computer will be transmitted back to
AICS. The licensing string will have a copy count associated with it -- and
one copy will be deducted from whatever that current value is. In return, a
"license.txt" file will be placed on the user's computer.

I wrote about this methodology a few months ago on this list and I've
included the relevant portion of one those postings below. The intention is
to make it just as easy for a large corporation to buy a thousand copies as
it is for one person to buy a single copy.


Gavin wrote:

> Whether people value your application enough to put up with whatever
>  copy protection mechanism you inflict on them is a different issue.
>  It's generally more acceptable on high-priced software that runs on a
>  small number of systems than it is on cheap software that needs to be
>  installed on every user's workstation.

I agree with Gavin that "easy" is everything. Indeed, we want to make the
process transparent.

I've enclosed the text of the previous posting below. The primary difference
between current thinking and that then is a lessened reliance on the MAC
address of the NIC card.

Wirt Atmar


======================================

THE LICENSING METHOD WE'VE CHOSEN TO EMPLOY:
(comments welcome)

The method of licensing we've chosen to employ was designed around these
concerns:

     o That it would provide an easy try-before-buy methodology, but one that
protects our interests as well in that it doesn't allow for easy mechanism to
invoke unlimited trials.

     o That it would be as easy for a corporation to purchase 5000 copies as
it is for an individual to purchase a single copy

     o That it would provide an easy, reliable, completely automated
mechanism of purchase, 24 hours a day, seven days a week.

     o That it would suppress the piracy of a legitimately purchased copy to
the greatest extent possible. The HPSUSAN number on MPE boxes has been very
successful in that regard. The MAC address on a PC's NIC card is the closest
similar number in a PC, absent a unique identifier in the CPU chip itself
(which as Jeff notes, was a contentious issue a few years back).

=================================

The mechanism works as follows: The trial user downloads a copy of the
software. When it is first run, the program will notice that there exists no
"license.txt" file resident in the executable's folder on the user's PC, thus
the copy must be a trial copy. It will then automatically telnet back to AICS
Research and transmit the PC's lowest slot NIC MAC address that exists for a
real (hardware) adapter. This MAC information will be stored in an HP3000
IMAGE database, along with a count of 1. At this point, that's all the
information we will have concerning the user.

Each time the user then reruns the trial version, the same procedure recurs.
The NIC MAC address is transmitted back to the AICS. If it already exists in
the database, as it would now, the count is incremented until the maximum
number of trials is exhausted. At that point the user would either have to
purchase the software or run through the trial limits on another PC (or
change out his NIC card).

If the user opts to register the software, a form will come up inside the
software itself (there is no need to resort to a web page). If the user
wishes to purchase the software on a credit card, he enters the number of
copies he wishes to purchase, the credit card number, and his email address.
All of this information is encrypted and transmitted to AICS, where this
material is not only automatically charged to his credit card, but also
stored in the database at AICS, along with the number of copies purchased.

If the organization wishes to purchase a fair number of copies and prefers to
arrange that purchase through a purchase order, basically the same process
occurs: a PO is sent by letter, by fax or by email, and the licensing
material is returned by email or by phone.

The licensing mechanism we're adopting is a "meal card" plan. If you purchase
one copy, a dozen or 5000 copies, you are sent a 10-letter number, something
like MSKFIESCSR, that you will use to license your copies of the software
internally. It will be your responsibility to safeguard the licensing number.

The next time the user runs an unlicensed version of the software, he will
have the opportunity to type in the licensing number. At that time, the
program will telnet back to AICS, transmit the licensing number and the MAC
address of the PC, deduct one from the count of copies purchased, and create
a license.txt file on the user's PC. From that point on, now due to the
presence of the license file, the PC will never again have to talk AICS.

There are some caveats to this. When a user purchases "one" copy, we will
actually multiply that number by 3, allowing him to place a copy of the
software on three PCs. We're doing this primarily to allow the user to
upgrade his machine (and thus change out the NIC card) two times, but he
could place the software on three different machines immediately if he wished
to do so.

All of these rules will be published, so if the user wanted to maintain his
licensed copies indefinitely, he could migrate his NIC cards, but as a
practical matter, I don't think most people will do that. Similarly, some NIC
card MAC addresses are changeable, thus some "leakage" (a polite word for
piracy) could occur, but so few cards allow this that we don't consider it a
great problem.

However, to the users' advantage, we are not planning on charging for
updates. Rather we intend on having the software publicly available, just as
we do now with QCTerm. The QCTerm distribution process has worked amazingly
well, distributing approx. 50,000 copies completely invisibly to our
day-to-day operations. Using the same model, users can continuously upgrade
to new copies without ever having to contact us.

Similarly, we're planning on offering student versions of some of the
software, where we'll only charge $10 for a year's usage. Under this
licensing agreement, a 10-letter licensing number will be issued, as above,
but every usage of the software will telnet back to AICS and check the
validity of the date.

Other than hacking into the AICS server, which will of course be an HP3000
running IMAGE, the user won't have any way to manipulate the dates himself or
forge a fake licensing file. On the other hand, doing licensing this way
means that we won't have to hide a licensing file anywhere on the users'
machine, trojan horse-like. And it will provide the user some protection. If
his hard drive should crash and he loses everything, with our products at
least, all he would have to do is download a new copy off of the web. The
first time that he runs the software, it would telnet back to AICS, at which
time the software would recognize that this machine was already licensed and
rebuild a new license.txt file on his PC, and he would be immediately back up
and running, without having to call customer support and explaining his
problem.

If anyone has any comments or complaints about this procedure, I would
appreciate hearing them.

======================================

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *