[
Lists Home |
Date Index |
Thread Index
]
Sounds like the good oldeDaze of rolling back the
system clocks so the licenses would not expire *yet*.
DRM turns into a complex subject as I read more.
While not an XML topic per se, it is worth becoming
familiar with. Many react loudly against it, but
others realize that management is better than not
managing the situation. It seems to me that as
you observed, that should be flexible management.
When the Draconian parse debates were held, I
took the position that it was a 'hard' approach and
programmers would code around it. Turns out
they do, but now I find myself on the other
side wishing they wouldn't. Watching this
thread, it seems that like DRM, there are
cases with certain characteristics that make
it reasonable to clean up and others where
it isn't the best legal approach even if it
appears to be technically reasonable.
len
From: Bob Wyman [mailto:bob@wyman.us]
Claude L Bullard wrote:
> I find parallels between the 'soft' and 'hard'
> approaches to DRM and 'soft' and 'hard' approaches
> to accepting formed and valid content.
I had the distinct non-pleasure of being one of the first folk
to work in the DRM space back in the 80's at DEC. (I've got four of
the earliest patents in this area.) and can assure you that there are
many parallels between the debates... We were constantly debating
whether or not licensing facilities should be "soft" or "hard."...
One of my first experiences in this area came as a result of
our discovery that many users were running purloined copies of
ALL-IN-1 field test code. So, we decided to put expiration timers in
our field test products to turn them off 90 days after field testing
was schedule to end. Back in those days (probably about 1982) this was
a fairly radical thing to do. It had certainly never been done for a
DEC product before. Anyway, everything went smoothly until the day the
timers expired. Then, I had one of my worst days at Digital as reports
of broken systems came flowing in from all over the world... So, we
decided to go "softer" for the next field test and have the system
start to warn people about the expiring license starting on the day
that field test was over and we extended the time-out to 120 days.
Many customers told us that they appreciated the warnings and had
upgraded in time. Then, the timers expired and we were in the s**t
again. It seems some people had actually been seeing the warning for
120 days but had ignored it!!! This included people who worked at an
"unnamed" US government agency that sends rockets into space... They
were very upset that one of their rocket launch had to be delayed
while they upgraded their software and complained about the "millions"
of dollars of expense caused by the delay. (In the news, they mumbled
about bad winds on the launch pad...) Everyone agreed that we had the
right to do what we had, but, they were furious anyway.
The caution learned from these experiences ended up being
implemented in the VMS and ULTRIX license management facilities that
were based on my licensing architecture. Those system had very "hard"
technology for detecting bad or expired licenses, however, they also
allowed system managers to turn off license management enforcement in
"emergency" situations. Of course, many people just turned the stuff
off automatically. ... That was a nuisance, but then again, we never
delayed another rocket launch...
bob wyman
|
