The idea is to license MetaCard usage based on time, either usage
time, or calendar time. While this has been done before, we now have
a new and better way to implement it: using the WWW. The problem with
old "30 day" evaluation technology is that it's too easy for people to
cheat. They just turn back the clocks on their systems. We've done
it, we've seen our customers and potential customers do it (for the
purposes of keeping a time-limited beta release operational), and have
seen postings and received email messages from people whose clocks are
running suspiciously slow ;-)
So, the first idea would just be to have the software check the time
on an Internet site. This solves part of the problem, since it's no
longer so easy to cheat. But it still has disadvantages, the most
notable of which is that you would have to continually reissue
licenses for each new time interval, and that there is no way to
really measure usage (unless you set up your own time servers that
record source IP addresses, a solution which has its own problems).
But what if instead of controlling the time, you control access using
HTTP to serve up license keys? That way, all you have to do is
control whats on the server. For example, the keys could all be saved
in one file, and the software would look through it to find the one
it's looking for (e.g., based on the name/organization used for
current MetaCard licensing). The application could also ask a CGI
script to check the license, or just try to get a document using the
key as the URL.
To maintain the licenses, all the licensor would have to do is make
sure the correct files were available. When the time expires, remove
the file (or entry in a file), and the software stops working. Usage
based licensing could be achieved by merely forcing a download every
hour, say, and then counting the number of "hits" of a document. Once
the limit is reached, the key file would be removed. One potential
wrinkle is the impact of having server-caches (on firewalls for
example), as this would defeat the system if the caches aren't flushed
often.
Granted this system would only work if the workstation running the
application was able to get documents via HTTP, but this is quickly
becoming a standard configuration. Another potential problem, that if
the license server goes down that the user is dead in the water, is
not really a problem because ISPs that maintain HTTP servers are
ubiquitous and it is very inexpensive to add new files on them,
allowing a very redundant system to be set up.
It seems to me that this architecture is vastly superior to
conventional license managers, as it requires no node-locking, no
system administrator intervention, no massive licensing fees, no
single-point-of-failure architecture, and very few potential
inter-application conflicts. It doesn't directly offer the equivalent
of "floating licenses", but these could be replaced either by
usage-based licenses (and would be more convenient since users would
never be locked out like they can be with conventional floating
licenses), or by CGI scripts that track concurrent usage (e.g. the
application calls log in/log out CGI routines).
What do you think? Would it be useful to be able to license MetaCard
for, say, $100 a month? What about being able to license it for, say,
$8 an hour? Anyone know if this system has already been implemented
by someone?
I'm looking forward to hearing your comments about these ideas.
Regards,
Scott
-- *********************************************************************** * Scott Raney (raney@metacard.com) Internet Meltdown Day approaches * * http://www.metacard.com Prepare thyself * ***********************************************************************