holbrook@apollo.COM (Alan R. Holbrook) (11/22/88)
In a recent posting, Dave Funk of the University of Iowa had the following comments about Apollo's Network License Server. Dave has some concerns and some misconceptions about NLS. > Now if you are having a hard time swallowing that one, try this on > for size; At SR10.2 Apollo is talking about putting NLS (Network License Server) > locks in its software. NLS is, among other things, a system for electronic enforcement of software license agreements, the legal documents that control how many copies of a software product may be made or used by a customer. It is also a valuable tool for system administrators to use to understand and control the use of software in the network. Properly used, it saves both time and money. NLS is a product our customers have requested. It's also one that we believe in, and so naturally we will use it to license some of our own software. Contrary to Dave's statement that SR10.2 time is also NLS time for Apollo, when we'll license our software has not yet been decided. > ...................... This will, along with increasing your network > traffic & CPU load, Concurrent access licensing adds about 400 milliseconds of elapsed time to the application. The license server itself requires about 300 blocks of disk space. The memory requirements for the license server are directly proportional to the number of licenses supported by the server. If that's more time and memory than you can spare, note that Apollo will continue to offer conventional node-locked licensing, for which no license server or NCS runtime support is required. Nodelocked licenses can also coexist with the concurrent-access licenses that are administered by the license server. > .................., require you to purchase a license for each product for > each node that you want to run it on. Dave has confused these two types of licenses--you can either purchase "a license for each product for each node" (nodelocked type) or "increase your network traffic" (concurrent-access type)--you are not forced to deal with both unless you choose to. > The first pass will be "advisory" locking only, it will tell you "naughty" if > you run an unlicensed product or too many copies of a licensed product. > Now your guess is as good as mine as to how long they leave it at the "advisory" level. Advisory locking is in fact one implementation of NLS we are currently examining. Because NLS is a new idea, we think advisory locking is an important educational step in the direction of our ultimate goal--an active, rather than advisory, enforcement policy. If we choose to implement advisory locking, the length of time we use this method will be determined in part by our customers. > NLS is an interesting system but we've been having a hard time with it. > It took us 3 months (and lots of phone calls) to get NLS licenses ("hooks") > out of Apollo that would work with the software that they sent us. (Thats 3 > months after we paid for them, and they arn't cheap). The University of Iowa had a problem getting NLS licenses from us. We apologized to them for the inconvenience. Nevertheless, readers of this news group should keep in mind that the University ordered the NLS product presumably because they intend to use NLS to lock their OWN software. The difficulties Dave has had have NOTHING to do with NLS locks on Apollo software since we don't have any locked software for sale yet. > The NLS licenses are node locked to the server node that you designate. If you want > to replace your server node, you have to get a whole new set of "hooks" and "keys" > issued. Imagine ALL your licensed software held hostage by a few server nodes. Concurrent-access licenses are in fact locked to the servers you choose. To ensure high availability, we recommend running multiple servers and distributing licenses among them. Everyone we've talked to thinks server-administration of licenses is an advantage--you can run a software product from any node on the network--you needn't move to the node to which the product is nodelocked. Furthermore, you don't need as many concurrent-access licenses as nodelocked licenses to accommodate the same number of users. > Hopefully Apollo can get some of these rough spots worked out before SR10.2. Apollo realizes the scope of what we intend to do with Network Licensing. Dave, and anyone else contemplating buying software from Apollo, can rest assured that we have no intention of consciously introducing "rough spots" into our base. Are Dave's objections to NLS shared by the University of Iowa? Since the university has ordered NLS, it must be at least considering doing precisely what Dave finds objectionable--licensing its software under NLS. Alan Holbrook Program Manager Distributed Computing
dennis@gandalf.nosc.mil (Dennis Cottel) (11/22/88)
[In article <3fccff2d.bf13@apollo.COM> holbrook@apollo.COM (Alan R. Holbrook) addresses Dave Funk's NLS comments.] In general, we are in favor of the NLS scheme and have long been bothering vendors to implement something like it. Having Apollo do it once, right, will be a big help for all the people who have to install and maintain vendor applications software. However, Alan says: >Concurrent access licensing adds about 400 milliseconds of elapsed time >to the application. An extra half second per application may not be bad for a large monolithic applications program like Mentor or somebody's CASE tool environment, but it's going to be an entirely different thing if, for example, every compiler invocation takes an extra half second! Alan also says: >Concurrent-access licenses are in fact locked to the servers you >choose. To ensure high availability, we recommend running multiple >servers and distributing licenses among them. Suppose you split all your licenses in two parts onto two servers, and then one server gets seriously sick and won't be available for a week or two. (It can take us that long to write a repair order!) That means you are stuck with half your software for that time. Not pretty. What provision has Apollo made for alleviating this scenario? What is the argument for locking the license servers to particular nodes? Thanks to Alan for addressing the previous questions. Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@NOSC.MIL sdcsvax!noscvax!dennis
krowitz@RICHTER.MIT.EDU (David Krowitz) (11/22/88)
Actually, I would have a problem with the NLS license server being node locked. I run a fairly small (by Apollo's standard) network of about 25 Apollos. We do a *lot* of development work over a wide range of products. Many of these we would only want 1 or 2 concurrent licenses which makes it a little unfeasible to distribute the licenses over more than one NLS server. What if the server goes down? I don't want to lose access to all of my software tools (FTN, CC, PAS, GMR, 3D GMR, etc) just because a single node went down! If the registry can be made immune to a single node failure, why can't the license server? It is just as important to have access to the software as it is to be able to login. If I can login but can't access the software, why bother logging in? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
timv@IMAX.ENG.UIOWA.EDU (Tim VanFosson) (11/24/88)
In response to Alan Holbrook's recent posting (in response to that of Dave Funk). >>>The University of Iowa had a problem getting NLS licenses from us. We apologized >>>to them for the inconvenience. Nevertheless, readers of this news group should keep >>>in mind that the University ordered the NLS product presumably because they intend >>>to use NLS to lock their OWN software. The difficulties Dave has had have NOTHING to >>>do with NLS locks on Apollo software since we don't have any locked software for >>>sale yet. >>> As I understand the situation the University contracted with Apollo to provide the *keys* to use in unlocking a software product that we were considering purchasing. The reason being that the per-node pricing was somewhat beyond the realm of the ridiculous. I have never heard that the University was considering marketing any software based upon NLS. As one, and perhaps the only, group on campus that would be in a position to do so, I think that I would have heard about it if it were so. >>> >>>Are Dave's objections to NLS shared by the University of Iowa? Since the university >>>has ordered NLS, it must be at least considering doing precisely what Dave finds >>>objectionable--licensing its software under NLS. >>> >>> Alan Holbrook >>> Program Manager >>> Distributed Computing >>> Dave, I think, has raised some valid concerns about NLS, which have been echoed in other notes. The issue of increased overhead is very important if Apollo intends to incoporate NLS into its utility programs and compilers, especially in an environment where cost concerns would preclude the possibility of obtaining node-locked software for small, frequently- used applications. So, the answer to your question - in light of our real use of NLS - is yes, at least for this member of the University community. --- Timothy VanFosson Internet : timv@imax.eng.uiowa.edu Systems Analyst US Mail : CAD-Research University of Iowa 1405 Engineering Building Phone : (319) 335 - 5728 Iowa City, Iowa 52242 My opinions, as well as my mistakes, are my own.
frank@CAEN.ENGIN.UMICH.EDU (Randy Frank) (11/26/88)
I think that while Apollo's NLS is an excellent technical idea, their marketing strategy in for the birds. In particular, having talked with several third party software companies about thier plans for using NLS, virtually all have said that Apollo's royalty scheme is unacceptable. As I understand it, Apollo isn;t just charging for the software, but is actually charging for each key purchased. If Apollo's goal is to get some of its technology adopted by the wider community (a la Sun and NFS or MIT/DEC and X windows) Apollo had better start coming up with marketing plans that don;t turn off the rest of the community. At least one other company (Frame Technologies) decided to implement their own license server at least based in part on Apollo's idiotic licensing of NLS (this based on info told me be a friend at Frame). The point is that NLS is an interesting although not totally novel idea. It isn;t that hard to independently come up with other implementations of a license server. The industry will be a lot better off is a SINGLE license server becomes the de-facto standard. However, Apollo's current marketing scheme guarantees that this won;t be Apollo's implementation. Apollo needs to understand that it stands to gain a lot more from having its implementation of the license server idea become the standard as opposed to the potentially minor revenue stream that is MIGHT get from, in my opinion, a stupid royalty scheme. Apollo: charge a REASONABLE on-time license fee to software houses and forget about this nonsense of charging for keys. REASONABLE: substantially less than it would cost a software house to implement on their own a replacement for NLS. You'll be doing yourself and the industry a favor, and this might even contribute to improving your image within the industry as a side effect. Randy Frank