🚀 go-pugleaf

In article <1992Oct6.144040.5288@news.dfrf.nasa.gov> todd@fred.dfrf.nasa.gov (Todd Vernon) writes:
>I am an independent software developer, and I am readying a product
>for market.  Like many developers in my position, money is a premium... 
>
>							...has anyone had
>any experience with first release products that were initially node 
>locked and then later floating licenses were available.  Did the 
>companys provide an trade in policy, to make the deal seem a little
>sweeter to big accounts ?
>

We have a lot of experience with three major CAD vendors, including
Mentor, Cadence, and Meta Software, over several years. All have offered
100% value trade in of node locked to floating licenses, although they
always protest first that they are not in the business of taking back products.
It is not unusual to charge a nominal fee if the trade is even.

Some vendors have allowed us to purchase floating licenses before they 
were available, promising meanwhile to provide lots of node-locked 
temporary keys. This can leave a real mess if the vendor can't deliver,
and this happened where it took >2 years for a vendor to deliver a 
version with floating licenses that could pass our QA tests on items unrelated
to the license manager. In the meantime, both I and the vendor grew many gray 
hairs keeping the temporary keys from running out every few months.



-- 
+-----------------------------------------------------------------------------+
| John Hayden,  SPD Div. CAD Manager       Internet: John-a.Hayden@Analog.Com |
| Analog Devices Inc, 3 Technology Way, Norwood, MA 02062 |   617-461-3862    |
+-----------------------------------------------------------------------------+

We are developing our own license server here at MIT which will likely
be available soon.  We will be sure to announce it here when we are 
ready to release the code.
					-Mark

I am a big proponent of license management mechanisms which allow for tailoring
of policies.  I don't know of any public domain license managers.  But as a
user of some products which incorporate such managers in a large scale
environment, I would like to say that the proliferation of different types of
license managers (different interfaces, don't work together, don't log data
consistently, don't support similar policies the same way, etc.) is making life
quite difficult for me.  Whenever I get the opportunity I push, not only for
reasonable, flexible policies, but for consistency across the implementations.

Please at least keep it in the back of your mind when implementing such things
in your applications.  Some of us care almost as much about how it's done as
about the fact that it's done at all.

Quoting royalty@bcstec.ca.boeing.com (Chuck Royalty) from comp.software.licensing:
|I am a big proponent of license management mechanisms which allow for tailoring
|of policies.  I don't know of any public domain license managers.  But as a
|user of some products which incorporate such managers in a large scale
|environment, I would like to say that the proliferation of different types of
|license managers (different interfaces, don't work together, don't log data
|consistently, don't support similar policies the same way, etc.) is making life
|quite difficult for me.  Whenever I get the opportunity I push, not only for
|reasonable, flexible policies, but for consistency across the implementations.

Is there a "standard" for licence managers, something describing a formal
specification of the protocol, the way keys are represented, how the client
communicates with the licence manager daemon, etc...? I don't think there is,
given the variety of licence managers offered by companies.

I've heard the MIT is working on a licence manager, which I hope will be made
publicly available and become a 'de facto' standard. If every company which is
in need for a licence manager but cannot afford the ones provided by dedicated
companies start developing their own, soon there will be lots of "licence
manager daemons" running on a single network node, all with different
configuration schemes, with different logging convention, as Chuck Royalty
pointed out.

What we need is a good GNU or PD licence manager implementation. If it is to
be used by many software, great care must be taken to ensure that the
authentication protocol between a given application and the shared licence
manager is safe and that nobody can issue keys for another application,
even by running a "fake" licence manager with some hooks to dump the traffic
with a particular client.

I don't know if that is possible, given the fact that most companies which
sell licence managers recommend you to keep the source they provide well
protected and away from the man in the street (for security reasons, of course).
-- 
Raphael Manfredi <ram@eiffel.com>
Interactive Software Engineering Inc.
270 Storke Road, Suite #7                      / Tel +1 (805) 685-1006 \
Goleta, California 93117, USA                  \ Fax +1 (805) 685-6869 /

deram@eiffel.com (Raphael Manfredi) writes....

> I've heard the MIT is working on a licence manager, which I hope will be made
> publicly available and become a 'defacto' standard. If every company which is
> in need for a licence manager but cannot afford the ones provided by
dedicated
> companies start developing their own, soon there will be lots of
"licence
> manager daemons" running on a single network node, all with different
> configuration schemes, with different logging convention, as Chuck
Royalty
> pointed out.

I agree, however I am left no choice.  A worse problem is small independent
developers don't want to write for the platform because there is no
way to protect there investment.   

Todd

In article <138@eiffel.eiffel.com> ram@eiffel.com (Raphael Manfredi) writes:
>Is there a "standard" for licence managers, something describing a formal
>specification of the protocol, the way keys are represented, how the client
>communicates with the licence manager daemon, etc...? I don't think there is,
>given the variety of licence managers offered by companies.

And I'm cynical enough to believe there isn't likely to be any standard, at
least for a while.  The market at present seems to consist of a several
license manager developers, each pushing his own proprietary product;
they don't want standards because their only competitive advantage is
in being different from all the rest.  Seems to me this isn't likely to
change unless some Really Big Player (e.g. Microsoft or IBM) adopts
a license manager protocol and makes it more affordable for software
developers (and end users) than any of the competing alternatives.
>
>I've heard the MIT is working on a licence manager, which I hope will be made
>publicly available and become a 'de facto' standard. If every company which is
>in need for a licence manager but cannot afford the ones provided by dedicated
>companies start developing their own, soon there will be lots of "licence
>manager daemons" running on a single network node, all with different
>configuration schemes, with different logging convention, as Chuck Royalty
>pointed out.
>
Yeah, but I wonder if the market has run so far ahead of MIT/gnu/etc.
that there won't be any momentum to whatever they do come up with.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

In article <1b1to1INN9nj@darkstar.UCSC.EDU>, haynes@cats.ucsc.edu (Jim Haynes) writes:
|> 
|> In article <138@eiffel.eiffel.com> ram@eiffel.com (Raphael Manfredi) writes:
|> >Is there a "standard" for licence managers, something describing a formal
|> >specification of the protocol, the way keys are represented, how the client
|> >communicates with the licence manager daemon, etc...? I don't think there is,
|> >given the variety of licence managers offered by companies.
|> 
|> And I'm cynical enough to believe there isn't likely to be any standard, at
|> least for a while.  The market at present seems to consist of a several
|> license manager developers, each pushing his own proprietary product;
|> they don't want standards because their only competitive advantage is
|> in being different from all the rest.  Seems to me this isn't likely to
|> change unless some Really Big Player (e.g. Microsoft or IBM) adopts
|> a license manager protocol and makes it more affordable for software
|> developers (and end users) than any of the competing alternatives.

Well, if you believe that OSF is a standards company, then through the
Distributed Management Environment (DME), a standard license management
system will soon be available.  This is the same license management
system that has been selected by Unix International (UI) and an ever
growing number of large OEM's like: IBM, Silicon Graphics, Intergraph, 
and Hewlett-Packard.  Other large companies will soon be announcing plans 
to use this same license management system.  This technology is available
now.

The license management system used by all of the above is NetLS, the product
developed and marketed by HP/Gradient Technologies.  A number of years back
a group called the Network Computing Forum (NCF) came up with a specification
of what a "standard" license management system should look like.  The NCF
license manager spec is what the 1.1 version of the NetLS product was based
on.  The NetLS 2.0 product contains many improvements on this specification,
but still maintains an NCF compatability library for anyone who is interested
in maintaining a standard. 

Regards,

Mary
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Mary Bennett                                250 Apollo Drive
    OSSD/Distributed Object Computing Program   Chelmsford, MA  01824
    Mail Stop chd-02-co                         Telnet: 436-4266
    mob@apollo.hp.com                           mary_bennett@hpj600.hp.com
    (508) 436-4266                              FAX: (508) 256-3941
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> ram@eiffel.com (Raphael Manfredi) writes:

   What we need is a good GNU [...] licence manager implementation.

May I nominate this as the Oxymoron of the Year? :-)
May I quote you in my .signature?
-- 
Jon W{tte, h+@nada.kth.se, Sweden, Phone +46-8-107069

"From now on, I think I'll re-label the EQ on the
 desk as Fizz and Wobble, rather than HF and LF."