smaug@eng.umd.edu (Kurt Lidl) (04/07/90)
In article <10655@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes: > >Some kind of "License Management Facility" (arghh!) You got that right!! Why does the ugly spectre of VMS licensing agreements have to rear it head in U*ix? I want a nice little (?) operating system that will just run the damn code that I put on it, without seeing how many "users" are logged into the machine and so forth. >Inclusion of both Kerebos and Hesiod security stuff. Good. Now -- are they still shipping systems with /dev/kmem world readable? -Kurt -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */
amichiel@rodan.acs.syr.edu (Allen J Michielsen) (04/07/90)
In article <1990Apr7.081638.1374@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes: >Why does the ugly spectre of VMS licensing agreements have to >rear it head in U*ix? I want a nice little (?) operating system >that will just run the damn code that I put on it, without >seeing how many "users" are logged into the machine and so forth. > Sorry, I sorta disagree strongly. I see what you are trying to say, etc, but there are other considerations. I see & talk to every day many many individuals & companies from all walks of life, that think nothing of the value of software products. They don't even think twice before stealing software for anything from anyone. The roll over & die or scream & whine like a stuck pig when they hear the price of software products. It seems the more something costs the more willing they are to steal it. The real problem compounds from here. If I make a good software product, and intend to charge a reasonable price for it, so that I can provide support etc. I have to have every system that runs it, pay for it. If I have stolen software, I have to charge more to every honest person to pay for the stolen copies. I am not saying that you are a crook, the I recognize the fact that many many many people are. I see system after system that the people are kinda stuck at old system versions because all the software they have is stolen. (& the new systems have license managers) These same people are the ones that are always calling me with stupid questions that would, could, & should be answered quite quickly just by cracking the stupid manual. Since the software is stolen of course the manuals don't exist. While I dislike some of the features of the current generation of dec license managers, it does accomplish it's job fairly well. I have spent less than an hour total in over a year using it. This is on a academic system that has had several generations of temp paks, variance paks, & permament paks for many different software products from several different vendors. At the user level, all they do, is run their stupid bits of code (to repeat your french). When the license manager keeps you from running your stupid bits of code, either it's a very temporary situation (my experiences are that dec is very helpful with pak #'s via phone as are all better vendors), or your system manager needs replacing, else you are trying to steal software. If you have problem a. a little patience is all that's required, if it problem b. you have a employee problem & shouldn't blame your software vendor, if it's problem c. I have no pity at all for crooks. I for one applaud DEC and all other software vendors that provide trouble free theft protection for their products. In my experience, dec's license manager does just that. This is akin to copy protection, companies that used schemes that worked well (that didn't require constant stupid key disks or limit the number or backups etc.) survived that holocaust well. al
grr@cbmvax.commodore.com (George Robbins) (04/08/90)
In article <2834@rodan.acs.syr.edu> amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: > In article <1990Apr7.081638.1374@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes: > >Why does the ugly spectre of VMS licensing agreements have to > >rear it head in U*ix? I want a nice little (?) operating system > >that will just run the damn code that I put on it, without > >seeing how many "users" are logged into the machine and so forth. > > Sorry, I sorta disagree strongly. I see what you are trying to say, etc, > but there are other considerations. I see & talk to every day many many > individuals & companies from all walks of life, that think nothing of the > value of software products. I don't mind an LMF facility when it encourages software vendors to go to a simple dollars/session floating network license scheme. I consider this much better than some of the per CPU, price scaled by CPU or site license schemes some software vendors play with now. I think what a lot of Ultrix users object to more is the idea of DEC removing yet more "standard BSD" features like pi, f77, franz lisp, and maybe cc and replacing them with a set of expensive "layered products" with bizarre point based license fees per the VMS world and a "license management system" to serve as an "enforcer". I'll be the first to admit that it costs money to port any of the Berkeley languages to a new environment, but as a customer I see that as part of the entry price of selling a BSD compatible system. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (04/09/90)
In article <2834@rodan.acs.syr.edu>, amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: > > Sorry, I sorta disagree strongly. I see what you are trying to say, etc, >but there are other considerations. I see & talk to every day many many >individuals & companies from all walks of life, that think nothing of the >value of software products. They don't even think twice before stealing >software for anything from anyone. The roll over & die or scream & whine >like a stuck pig when they hear the price of software products. It seems >the more something costs the more willing they are to steal it. I don't suppose you have scientific numbers on the thieves vs legitimate owners? If you have 20-30% of the folks out there in The Real World who are thieves, then you're screwed 70-80% of the legitimate purchasers who have to deal with LMF. > The real problem compounds from here. If I make a good software product, >and intend to charge a reasonable price for it, so that I can provide support >etc. I have to have every system that runs it, pay for it. If I have >stolen software, I have to charge more to every honest person to pay for >the stolen copies. False. You don't provide support to those people who have ripped you off. Period. You buy a legitimate copy of a product, you pay for the distribution and a license to use it. With Digital, you pay ADDITIONAL money for support (ie: telephone hotline). Digital's developmental costs are the same for quantity 1 or quantity 30,000. > I am not saying that you are a crook, the I recognize the fact that many >many many people are. I see system after system that the people are kinda >stuck at old system versions because all the software they have is stolen. >(& the new systems have license managers) These same people are the ones that >are always calling me with stupid questions that would, could, & should be >answered quite quickly just by cracking the stupid manual. Since the software >is stolen of course the manuals don't exist. So don't answer their questions. Encourage them to legitimately purchase an upgrade and support. You are helping perpetrate piracy through aiding someone who has a "hot" copy. > While I dislike some of the features of the current generation of dec >license managers, it does accomplish it's job fairly well. I have spent less >than an hour total in over a year using it. This is on a academic system that >has had several generations of temp paks, variance paks, & permament paks for >many different software products from several different vendors. Glad to hear it. I came into a situtation under VMS where the previous system manager hadn't "followed the book" in using LMF, so I had to scramble around for a day and a half to figure out what had been done. That also assumes that you "know" and understand LMF. This costs time. Time is money. I don't think DEC is going to reemburse me for the headaches I spent having to learn their system. > When the license manager keeps you from running your stupid bits of >code, either it's a very temporary situation (my experiences are that dec is >very helpful with pak #'s via phone as are all better vendors), or your system >manager needs replacing, else you are trying to steal software. If you have >problem a. a little patience is all that's required, I guess you never have to deal with users face-to-face. "WHY CAN'T WE RUN THIS NOW?" >if it problem b. you have >a employee problem & shouldn't blame your software vendor, I should blame me for artificial constraints placed upon our system by the LMF? Or my lack of understand of their way of using copy protection? > I for one applaud DEC and all other software vendors that provide trouble >free theft protection for their products. In my experience, dec's license >manager does just that. This is akin to copy protection, companies that used >schemes that worked well (that didn't require constant stupid key disks or >limit the number or backups etc.) survived that holocaust well. As I understand it, Sun has managed quite well with granting unlimited OS licenses with no copy protection. Not that Digital would want to copy their policies. In the microcomputer/PC world, the vast majority of companies which sell software don't resort to such silly schemes today, having been pressured to drop any semblance of protection. People who make a profit or do useful work when using a particular software package find that it is much easier to pay for the package (to get the documentation) and support, than to stay in the black hole of hotware. Besides, if you get caught, you'll get sued from here to tomorrow and you WILL pay much much more in lawyer's fees than you would have in purchasing legitimate copies of software.
rwood@dec.com (Richard Wood) (04/10/90)
In article <1990Apr7.081638.1374@eng.umd.edu>, smaug@eng.umd.edu (Kurt Lidl) writes: > In article <10655@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes: > >Inclusion of both Kerebos and Hesiod security stuff. > > Good. Now -- are they still shipping systems with /dev/kmem world > readable? > -Kurt ULTRIX v4.0 also includes NTP, since time synchronization is necessary to keep the timestamp feature of kerberos (as well as other network services) from getting messed. ULTRIX v4.0 also includes the BSD kmem and tty groups. Security can be set at several different levels, and includes features such as long passwords, password aging, generated passwords, kerberos/hesiod-based networked password database, etc. -- --------------------------------------------------------------------- Richard Wood Corporate Worksystems Team Digital Equipment Corp. ========================================================================
smaug@eng.umd.edu (Kurt Lidl) (04/14/90)
In article <937@granite.dec.com> rwood@dec.com (Richard Wood) writes: > >ULTRIX v4.0 also includes NTP, since time synchronization is necessary >to keep the timestamp feature of kerberos (as well as other network >services) from getting messed. We've had NTP running on the Ultrix 3.1 machines here for quite some time. I don't think that this is such a great thing to selling the system on. Everybody who is doing lots of networking has mostly adopted NTP across the board already. Our Sun3s, Sparcs, DecStations, Vaxen already do it. I haven't given it a whack yet on the RT's, but I don't think there will be any problems... >ULTRIX v4.0 also includes the BSD kmem and tty groups. This we have also done. Mostly an exercise in changing permissions on devices and files... >Security can be set at several different levels, and includes features >such as long passwords, password aging, generated passwords, >kerberos/hesiod-based networked password database, etc. Is the password aging a function of using kerberos or from some other changes to the code. Also, is there support for the BSD-style "shadow" password scheme? So I will ask again: Did DEC fix the broken behaviour of /bin/sh on its machines? Try getting the default "rn" compiled and installed and working. I find that the /bin/sh scripts that it uses a lot (Pnews, Pnews.header, Rnmail, etc) are a pretty good test of a machine's /bin/sh. -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */