[comp.lang.c++] C++ 2.0 pricing *** CORRECTIONS ***

newsuser@lth.se (LTH network news server) (06/30/89)

Regarding my previous posting on AT&T's policy w.r.t. workstation networks:

===========================================================================
...
I would have preferred that you had asked me before you had actually
posted the message.
...
From reading your message I think you misinterpreted what I said to
you during our telephone conversation yesterday, and I would like to
take this opportunity to clarify the situation.

Where a File Server and several Workstations exist within a Network,
all CPUs on which the source code resides must designated under the
Source License.  If the source can be accessed from a Workstation but
is not transferred to the Workstation or stored in the Workstation's
memory ie. the Workstation is used as a dumb terminal, then the
Workstation does not have to be a designated CPU.  However, if the
source is transferred to the Workstation for any given time, that
Workstation must be a designated CPU under the License.

AT&T UNIX SOFTWARE
OPERATION EUROPE

Diane Leigh
LICENSING MANAGER
===========================================================================

I hope this information has clarified the situation.

Dag Michael Bruck
-- 
Department of Automatic Control		Internet:  dag@control.lth.se
Lund Institute of Technology
P. O. Box 118				Phone:	+46 46-108779
S-221 00 Lund, SWEDEN			Fax:    +46 46-138118

rfg@pink.ACA.MCC.COM (Ron Guilmette) (07/02/89)

In article <1989Jun30.074346.15350@lth.se> dag@Control.LTH.Se (Dag Bruck) writes:
>Regarding my previous posting on AT&T's policy w.r.t. workstation networks:
>
>===========================================================================
...
>Where a File Server and several Workstations exist within a Network,
>all CPUs on which the source code resides must designated under the
>Source License.  If the source can be accessed from a Workstation but
>is not transferred to the Workstation or stored in the Workstation's
>memory ie. the Workstation is used as a dumb terminal, then the
>Workstation does not have to be a designated CPU.  However, if the
>source is transferred to the Workstation for any given time, that
>Workstation must be a designated CPU under the License.
>
>AT&T UNIX SOFTWARE
>OPERATION EUROPE
>
>Diane Leigh
>LICENSING MANAGER
>===========================================================================
>
>I hope this information has clarified the situation.

Oh, sure!  It's clear as mud now.

Look, if I run "vi" or Emacs from my workstation, and I edit a piece
of Cfront 2.0, and if my workstation is *not* a "designated" CPU, then
will I be violating the AT&T license?  If I edit one of the source
files, then that file will (in general) be read into the "memory"
of my workstation, and I can't really claim that my workstation is
acting just as a "dumb terminal" because dumb terminals don't run
Emacs locally.

Based on the passage above, I have to assume that if I have a diskless
workstation on a local-network, then in order to edit (or "cat", or
anything else) on one of the Cfront source files without breaking my
license, I have to rlogin to the server first, and then do my editing
strictly using the server's CPU, with my workstation serving *only*
as an I/O device.

The implication of all this is that System Administrators of local
networks should be sure to place Cfront sources in a file system
which is restricted, and which can only be "mounted" (NFS or RFS)
by those "CPU's" on the net which are "designated" in the license
agreement.  If this means the "server" only, then the given file
system must be mountable on the server only.

Further, all "users" of the sources should be cautioned that any
(modified or pristine) copies of the source files must be stored
*only* on the particular file system from which they came.  Elsewise
there is leakage and this makes it possible that one or more source
files will come into contact with one or more "un-designated" (i.e.
rogue) CPU's thus making your organization vulnerable to legal proceedings.

Finally, note that if your license limits your set of "designated"
CPU's to your server only, and if lightning strikes your server
(quite common in these parts) and if Sun (or whoever) swaps out
your server's CPU board, then you must not use look at, touch, cat,
or do anything else to the Cfront sources until either (a) your
original server CPU board comes back from the depot or (b) you
obtain an official addendum to your license agreement from AT&T
sales & marketing which covers the new CPU (board).

Welcome to the 11th dimension.  If things don't always seem to make
sense to you here, believe me you are not alone.

I'd like to know if AT&T intends to hire special "main memory"
detectives or "file system mount" detectives to enforce their
Cfront licenses.

There are a lot of areas where I disagree strongly with
Richard Stallman and the Free Software Foundation, but one thing
we can agree on is that these kinds of silly licensing restrictions
result in nothing other than a big waste of resources.  Basically,
since it is next to impossible to enforce such things, all that
happens is that network System Administrators (just the more
paranoid ones) waste a lot of time and effort running around
creating disk partitions just to hold system X or system Y, and
making sure that only certain subsets of workstations can mount
the filesystems associated with those partitions.  They also waste
a lot of time telling users not to make copies of files (which they
may be responsible for modifying) in their own home directories.
The really paranoid ones waste even more time checking that their
users have not made any such illicit copies.

I agree completely that AT&T has a right to make money (and lot of it
if they can) from their Cfront product, however isn't it time that
this industry grew up and realized that site-licensing is the only
rational way to do licensing.

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.  Additionally,
site licensing can prevent a purchaser's SysAdmin's from doing a
Jeykel & Hide and turning into little dictators and unofficial
policemen working for the vendor and against the purchaser.


-- 
// Ron Guilmette  -  MCC  -  Experimental Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg

dave@ecrcvax.UUCP (Dave Morton) (07/05/89)

In article <264@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes:
>one thing
>we can agree on is that these kinds of silly licensing restrictions
>result in nothing other than a big waste of resources.  Basically,
>since it is next to impossible to enforce such things, all that
>happens is that network System Administrators (just the more
>paranoid ones) waste a lot of time and effort running around
>creating disk partitions just to hold system X or system Y, and
>making sure that only certain subsets of workstations can mount
>the filesystems associated with those partitions.  They also waste
>a lot of time telling users not to make copies of files (which they
>may be responsible for modifying) in their own home directories.
>The really paranoid ones waste even more time checking that their
>users have not made any such illicit copies.
Ah, nobody in their right mind bothers doing all this really. Still
the legal obligation exists. How many sys admins out there can
afford the time to carry through these silly measures. I'll
take my chances with the main memory police:-  Also, considering
the price of the upgrade one might as well consider just not using
C++ and just delete the old 1.2. At this prices who's gonna use
it anyway ?
>
>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.  Additionally,
>site licensing can prevent a purchaser's SysAdmin's from doing a
>Jeykel & Hide and turning into little dictators and unofficial
>policemen working for the vendor and against the purchaser.
Agreed 100%. Pity the lawyers who wrote all this junk into the
contracts dont know or understand the difficulties you
outlined. I think most admins hate the idea of playing secret
policeman especially for a vendor, the only assurance a vendor
has that people at a site dont steal software is the work
contract between the site and the user. If AT&T were honest
with themselves they'd admit that lots of sites have multiple
copies on different machines. As you say, it's almost impossible
to restrict or discover that joe user has a header file stashed
somewhere on his w/s. Mabye someone from AT&T could provide their
laywers with a "Noddy Guide to Sys. Admin at Large Sites".

Dave Morton, Sys Manager,
European Computer Industry Research Centre      Tel. + (49) 89-92699-139
Arabellastr 17, 8000 Muenchen 81. West Germany.
..!unido!ecrcvax!dave
dave@ecrcvax.uucp