Re: spoofing the ethernet address (license managers)

[Michael.Wojcik () MERANT COM (Michael Wojcik)]

> From: Eric Sherrill [mailto:sherrill () ti com]
> Sent: Wednesday, March 29, 2000 10:19 AM
>
> I disagree with the assessment that it only helps honest people stay
honest,
> in large part because tying license managers to supposedly "unique"
> information like MAC addresses, can become a real pain for the sysadmin.

Administrative problems with licensing have nothing to do with whether
licensing is only effective for honest customers.  If licensing interferes
with administration, how does that make it harder to crack?  This is a
different issue entirely.

> Here are some examples.

Yes, yes, all of these have been debated ad nauseum in the forums I
mentioned (comp.security.unix, etc.).

We can, and do, issue temporary emergency licenses with a built-in
expiration date.  That's been enough for our customers so far; no one's ever
refused to purchase the product because of licensing, and many customers
have bought it because licensing enabled them to pay for just what they
needed.  It's a trade-off, and the market so far has justified it.

> 2. I lose my license server.

This has nothing to do with using MACs (or any other OS-provided system
identification; we just call whatever API the OS offers - I don't care if,
as on Unixware, it's just whatever's in a special file in /etc).  It's a
matter of a poorly designed client/server licensing mechanism.  The last
time I looked at FlexLM, though, it allowed backup servers.  (Our licensing
is all node-locked, so this is a moot point for me.)

> 4. I want to install a new machine, say solely for some temporary purpose,
> such as troubleshooting a problem.  Now I either have to have a spare
> license available on the license server, or I have to send information to
> the vendor and wait for them to issue an updated license file.  This can
> involve anything from a simple e-mail or two, to layers of corporate
> purchasing red tape (and weeks of waiting).

I want to drive a new car, say solely for some temporary purpose, such as
replacing mine while it's in the shop.  Now I have to fill out a bunch of
paperwork and pay some money.

> 5. Most license managers I have worked with are only "network-aware" in
the
> minimal sense that they seem to work in only a limited client-server
> paradigm - one server, many clients.  What would be more helpful:
>
>       a license manager that can discover and report (to the admin, not
the
> vendor) on authorized and unauthorized copies of licensed software running
> anywhere on your network (although this type of port-scan might also raise
> some network managers' eyebrows);

And it's trivial to defeat, and again it only works if the customers are
honest.

Hell, we have license auditing capability built into our stuff.  It logs
license-related events to a local file in a known location, and the system
administrator can do anything they want with it.  It's off by default and
has to be enabled by the system administrator.  I've never known anyone to
use it.

>       that can implement a shared pool of licenses among more than one
"server"
> machine (this would also help with 3. above);

When there's sufficient demand in the market for a feature like this, it'll
be developed.

>       that can automatically issue a limited number of "exceptions" within
> certain boundaries to help with variable peak loads (say you go over by
one
> or two seats for a few days on your quota, no problem; if you consistently
> abuse it, however, the vendor is notified).

People who want a margin for excessive use can pay for it.

Oh, I see your point.  There's an arguable value difference between licenses
you use all the time and licenses you only use in exceptional circumstances,
and it's possible that part of that value could be reclaimed by the
customer.  There's no reason for the vendor to do that, however, unless they
also get part of that value, in the form of increased sales, for example.
And I haven't seen any evidence that the market will sufficiently reward the
vendor for providing such a feature.  Particularly considering the
difficulties of design and implementation and the ample opportunities for
abuse.  (It might be implemented as "ablative" licenses, for example: you
have a pool of reusable licenses, and a pool of single-use licenses that
only get consumed when all the reusables are in use.  But that requires
persistent storage of the count of remaining single-use licenses, which is
going to be vulnerable to attack.  Rollback is particularly likely: I
snapshot the entire license server just after installation, and restore it
every time I use up my single-use licenses.)

Yes, software licensing has problems, and it poses difficulties for the
system administrator.  On the other hand, it offers a more flexible pricing
model and allows the vendor to retain a larger portion of due profit, which
funds maintenance and additional development.  If you don't feel you're
paying for maintenance and additional development, why are you buying the
product in the first place?  Use something open-sourced, or write your own.
Purchasing software is always a matter of the efficient application of
resources.  Customers who decide the penalties of software licensing
outweigh the combined benefits of licensing and of having that particular
software package at all apply their resources elsewhere.  That's how the
market works.

And the market can change.  The weight of opinion shifted against copy
protection for personal computer software.  It may shift against software
licensing.  Years ago I advocated dropping licensing for the base product
and making it Open Source, with an API for plugging in additional features,
then selling the features - some at flat rate, and some with usage-based
licensing.  Flexibility is what's important.

Michael Wojcik             michael.wojcik () merant com
MERANT
Department of English, Miami University