Conference 7.286::digital

    They think by changing the name, they can fool the masses.
    
    :-)
    
    Q

As Digital's representative to the effort that created the License Service API (LS API),
let me state as clearly as I can that the LS API is a very different animal than the
product we are building to replace LMF 1.*.

The LS API is an industry standard describing calls you would put in a piece of software
you want to license.  It is NOT a product, just a standard for one small part of a
software licensing system/product.

The "replacement for LMF 1.*" is a set of products being built by Digital to provide a
next generation software licensing product for the licensing of software.  Amoung other
things, it includes an extended version of the LS API to be used by software developers
to license their products.

Now, I am sure you are wondering "Why does Digital need to extend the LS API, particularly
since we were one of the driving forces behind the LS API?"  The answer is that in a
standards process you many times make compromises to push the process forward and get
a standard agreed upon and announced.  These compromises, in the case of the LS API,
were centered around a set of extensibility calls (they were dropped because we were
in a stalemate) and a challenge mechanism for authentication between client software
and licenses (we don't like it for many technical reasons).

I hope I have answered any question you may have had on this topic.

================================================================================
Note 1960.2                   Information on LSAPI?                       2 of 2
CREATV::GIBIAN "Marc S. Gibian"                      22 lines  23-JUN-1992 13:52
                     -< WRONG!   They are not the same!!! >-
--------------------------------------------------------------------------------

As Digital's representative to the effort that created the License Service API
(LS API), let me state as clearly as I can that the LS API is a very different
animal than the product we are building to replace LMF 1.*.

The LS API is an industry standard describing calls you would put in a piece of
software you want to license.  It is NOT a product, just a standard for one
small part of a software licensing system/product.

The "replacement for LMF 1.*" is a set of products being built by Digital to
provide a next generation software licensing product for the licensing of
software.  Amoung other things, it includes an extended version of the LS API
to be used by software developers to license their products.

Now, I am sure you are wondering "Why does Digital need to extend the LS API,
particularly since we were one of the driving forces behind the LS API?"  The
answer is that in a standards process you many times make compromises to push
the process forward and get a standard agreed upon and announced.  These
compromises, in the case of the LS API, were centered around a set of
extensibility calls (they were dropped because we were in a stalemate) and a
challenge mechanism for authentication between client software and licenses (we
don't like it for many technical reasons).

I hope I have answered any question you may have had on this topic.

    It seems to me that this attitude that we must 
    always extend standards that we had a hand in
    setting is faulty.  These actions weaken the
    acceptance and ultimate effectiveness of the
    standard.  If we feel that strongly about the
    matter, we should work through the amending
    process to the standards, rather than adopting
    extensions to them.

        Re: .4

        This attitude that we must never implement beyond existing
        standards is faulty.  Standards should be based on previous
        implementations to be sure that they are reasonable to
        implement.  If Digital doesn't extend the standards then:

          o  Digital will have no concrete experiences to use to support
             arguments in standards meetings.

          o  The companies that extend the standards will be in
             leadership positions and Digital will always be a follower.

        					B.J.

    Of course if people got their act together and did LMF 2.x several
    years ago when it was ready to be done, we might even be further ahead,
    But Nooooo... we had to wait for the standard to appear and then
    finally try to extend it.
    
    I am not impressed!
    
    Tom
    

As Digital's representative to the LS API standards effort, I
feel compelled to answer the extension question in .4, .5 .6
(sorry it has taken so long, too much other traffic in this conference)

Before going into the actual subject, I do want to voice my
disgust with the attitude in .6.  If you are familiar with
the development effort on the product replacing LMF v1.* and
have these concerns, then please contact our product management.
Otherwise, you are in no position to judge the appropriate-ness
of our work, nor the positioning of our product against our
competition and the LS API standard, and should refrain from
knocking the efforts of a dedicated group that understands
just how urgent it is to complete and ship this product.  The
only complaint I have, as one of the first technical people
on this team, is that the company has not been able to support
this effort with all the resources needed to ship sooner than
our current schedule.

In summary, don't complain unless you know what it is that
you are complaining about!

One to the standard and extensions issue...

<WARNING: for internal consumption only!>

Digital's position was to include extensibility in the LS API
standard.  This was based both on the problems mapping our
next generation licensing product's features into the standard
LS API, as well as the belief that software licensing technology
is rather young and will be evolving relatively quickly in the
next few years.  We wanted a LS API that could grow with these
changes.

Unfortunately, standards are not simply exercises in documenting
technology.  They are totally political activities which if you
are lucky produce standards that actually work when you go to
implement them.  In the case of the LS API, Digital withdrew
its objections to the extensibility features in exchange for
other things we wanted in the standard, and in recognition
that the group was deadlocked on the extensibility topic.  It
was more important to crank out a standard than to maintain
the deadlock, and likely kill the LS API standard.

So, now we have a flawed standard which is going to serve as
the main client software API.  The only way for us to offer
a full set of features to the customers of our next generation
licensing product is to produce an extended LS API that is
a proper superset of the standard LS API.  This will be
source code compatible for software coded against the base
LS API, yet allows use of all of our product's more sophisticated
features that are not supported in the standard.  Any other
approach would reduce the competitive positioning of our
product, and thus result in less sales and profit.  The
bottom line, then, is this is the only reasonable way to
do what we need to do...

-Marc