Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!mcnc!thorin!jason!tuck From: tuck@jason.cs.unc.edu (Russ Tuck) Newsgroups: comp.lang.c++ Subject: Re: C++ 2.0 pricing and licensing policy Message-ID: <8723@thorin.cs.unc.edu> Date: 5 Jul 89 15:57:27 GMT References: <1989Jun30.074346.15350@lth.se> <264@pink.ACA.MCC.COM> Sender: news@thorin.cs.unc.edu Reply-To: tuck@jason.UUCP (Russ Tuck) Organization: University Of North Carolina, Chapel Hill Lines: 61 In article <264@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes: >From the vendors point of view, site licensing is just about the only >thing that can be enforced. From the purchaser's point of view, it >is the only way a big corporation can hope to be assured that they >will not be sued by the vendor because some bozo accidently made an >illicit copy of 1 tiny file into his home directory. If everyone at a site uses a program, site licensing is certainly the way to go. But if a few users at a large site need a program, it's often a poor solution. Either the users pay way too much (essentially paying for the right of many people to use it who won't use it), or they don't buy it (because they can't afford or justify the huge cost). This assumes a large price for a site license at a large site. If site licenses are affordable even for small groups at large sites, then the seller may be losing lots of potential revenue at large sites where everyone uses the software. A practical alternative (already used by a few applications) is to pay per simultaneous user (not per CPU, or per potential user). You pay for the right to use up to N copies at a time, and have a license server with N "keys" (maybe encrypted numbers obtained from the vendor at license purchase). When run, the application gets a key from the server, or exits if no keys are available. This lets license fees reflect the actual use (and presumably value) of the program. A few users at a large site can buy a few copies (keys) at an affordable price and use it on whichever machines are convenient. If the program becomes popular with other users, so all the keys are frequently in use, they can buy more keys or negotiate a site license as appropriate. To justify posting this to Comp.lang.c++, I'll add my application of these ideas to C++ 2.0. My site has a large pool (>100) of workstations, a larger pool of grad students, faculty, and staff. A growing subset of the people use C++. Most grad students (and some faculty and staff) do their work on workstations in semi-public labs -- this means they work on many different machines, often a different one every time. Though the $300/cpu educational license for C++ 2.0 may seem small compared to the $10K commercial price, for our 100+ machines it means $30K+ to license them all. Even though maybe 25% of the users use C++, we can't just license 25% of the machines. (There'd be a 75% chance that the machine that's free when I enter the lab doesn't have C++, so I can't do any work.) I think AT&T is hurting themselves and C++ by pricing it so high. Instead of everyone migrating quickly to 2.0, the new well-documented and supported standard language, many users will be forced to continue using 1.2 or to use GNU's g++. Since g++ has some of its own unique features, this means 3 different languages in use. This language fragmentation will slow C++'s adoption by users, software and hardware vendors, book publishers, ... It's the same kind of fragmentation that continues to plague UNIX. I think AT&T is shooting themselves (oh, well) and C++ (ouch!) in the foot. They would be wise to license C++ 2.0 very reasonably and get it widely adopted and firmly established. If they're patient, they'd even get larger profits by eventually raising prices modestly in a much larger market. --- Russ Tuck internet: tuck@cs.unc.edu Computer Science Dept., Sitterson Hall csnet: tuck@unc University of North Carolina uucp: ...!mcnc!unc!tuck Chapel Hill, NC 27599-3175, USA Phone: (919) 962-1755 or 962-1932