[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

990.0. "DECwindows and Software Licensing. " by NOHOPE::GALLOZZI () Wed Jun 21 1989 11:11

Subject:  Software Product Descriptions and client/server computing model.

Background:
-----------

Many Digital software products are being produced to work within the 
client/server model.  The general software license business rules pertaining 
to this area have not as yet been finalized.  The current general rules 
are that -a VMS based VAXserver system is shipped with a VMS File and
Application Server license which through terms and conditions has an
intent of allowing no interactive 'log ons'.  One current interpretation of
this intent is that VAXservers allow no interactive log ons, no screens being
driven by VAXservers [screens DEC/X window terminals being classified as
'users'].  The situation is essentially similiar for Ultrix based VAXservers.
The business policy for this area is currently under review.

Immediate Problem:
------------------

New applications such as DECwrite V1.0 and others wish to grant 
rights for use in a client/server model, and delineate them within
the product SPD.

Request:
--------

That for a short time period until a global policy can be agreed upon, no
software product explicitly specify support for the product's use as 'either
a client or server' upon a VAXserver of VAXstation.  All other references
to supported VAX/RISC cpus can and should be made. This ambiguity will 
accomplish at least two things:

     .  It will allow the creation of the SPD and shipment of the product to
            proceed.
     .  It will not preclude any policy options that Digital may wish to
            consider.

Should there be any questions, issue or comments please advise.

Carl Gallozzi
OS/Software Business Group

T.R	Title	User	Personal Name	Date	Lines
990.1		MU::PORTER	l'enregistrement electrique	`Wed Jun 21 1989 20:29`	8
	If this is the official mechanism for disseminating software business policy, it leaves rather a lot to be desired. Don't take it personally, but since I've never heard of you, I won't be taking any formal notice of this request until I hear it from someone like SQM.
990.2	Seems to me, this is just what notes are for: Informal early information	DECWIN::FISHER	Burns Fisher 381-1466, ZKO3-4/W23	`Thu Jun 29 1989 16:31`	11
	Don't get all hot-under-the-collar. Carl is for real. If I understand correctly, he is saying that we should expect some sort of official policy to be forthcoming, but to avoid a scramble when the policy comes, he is suggesting that we don't explicitly talk about VAXserver support in our products. Personally, I am happy to get this hint regardless of how I may feel about the policy. Thanks, Carl. Burns
990.3	Additional reasons	STAR::ROBERT		`Thu Jun 29 1989 16:52`	50
	There was another reason for Carl's note that wasn't explicitly called out. By making a representation in a non-VMS SPD about what can, or cannot be done under a particular VMS license we get a couple of problems: SPDs are part of legally binding "words" VMS Product management has to review every SPD to see what might be said about the VMS license. - greg Read on if you're curious about how we "got here". Background: Originally the license terms and conditions were fully defined in a single Ts and Cs document that covered all software. At some point these were modified to specify that additional Ts and Cs may appear in the pricebook and that these too form part of the legal words. This was done to allow the Ts and Cs to be changed/amended/expanded/liberalized/whatever more easily and frequently. With VMS V5.0 and DDSLA/LMF we introduced Activity Licensing (casually known as 'concurrent user licensing'). Since the exact definition of this must be specified by each product we add to the Ts and Cs a statement that additional Ts and Cs may appear in the SPD (sigh, licensing is _complicated_). Hence, SPDs now have another legal status, namely that they can form part of the Ts and Cs. SO: If product XXX's SPD states what is, or is not, allowed under one of the VMS license types (Workstation, Server, Concurrent User, General Capacity, other) then that can have legal implications --- so we have to be careful. Common sense: no SPD should really make any "definitional" comment about any other product, at least not without the sign-off of that product's product manager. We never memo'ized this because we never noticed the potential loop. - greg
990.4		MU::PORTER	l'enregistrement electrique	`Fri Jun 30 1989 10:21`	13
	Well, ok, maybe my wording was a little snappish. Sorry about that. What I meant was "please give me some background on who you are and why you're telling us this". Unfortunately, not all notes in notesfiles impart truthful information -- sometimes, uninformed answers masquerade as truth. Therefore, I wanted some clarification as to how "official" this might be. Since I've never heard of the "OS/Software Business Group", I wasn't inclined to do anything based on the note. If, for example, the note had been placed by someone in SQM, then I'd be happier to trust the source. It has nothing to do with the source itself, merely on my experience/knowledge of the source.
990.5		STAR::ROBERT		`Sat Jul 01 1989 09:19`	10
	The OS/Software Business Group is part of Bill Heffner's organization and worries about software licensing and pricing for all 32 bit software. They're the same people that did this work for him when he ran SSG which was VMS and Keating's products. Some of them, like Carl, are still here in ZK. Others moved with Heff to the Virginia road facility. The group is managed by Bob Dockser who reports to Heff. - greg
990.6		CSSE32::MERMELL	Window Pain	`Wed Jul 05 1989 11:37`	12
	re: .0 I've forwarded this note to appropriate people in CSSE and SQM to consider the issue. Note that the VMS V5.1 SPD states "To determine whether a specific DECwindows application runs distributed across different operating systems, refer to the application's product description." Because of the marketing messages of DECwindows support for ANY X-windows server, I believe we cannot afford any "ambiguity" in product SPD's regarding what servers they actually support! Hopefully this can be resolved before any more SPD's go out the door.