[54] in Layered Athena
Proposed 3partysw policy for Layered Athena
daemon@ATHENA.MIT.EDU (nschmidt@MIT.EDU)
Thu Feb 3 14:15:25 1994
From: nschmidt@MIT.EDU
To: layered-athena@MIT.EDU
Date: Thu, 03 Feb 94 14:14:28 EST
Here is the text of the proposal referred to by Bruce Lewis in his message
of this morning:
Background:
----------
Licenses for software that is currently on Athena fall into the
following three categories:
1. MIT site licensed
2. Athena only site licensed
3. Limited number of concurrent licenses (i.e. license
managed)
I have defined category (2) to include those cases where the license
says "only on Athena" in any form ("computers dedicated to Project
Athena", "connected to the Project Athena network", "administered by
Project Athena", etc). In some cases, a broader definition of
"Athena" would retain the spirit of the law as well as the letter of
the law if we were to go toward Layered Athena. We can speak with the
vendors in question to see if they would allow a broader definition of
Athena to include the entire MIT distributed computing environment.
In other cases, such a broader interpretation of what is Athena would
patently violate the spirit of the license.
The following are the major third party software packages, broken into
these three categories:
Maple 1
Motif 1
Numerical Recipes 1
Xess 1
Matlab 2
SPlus 2
LUCID Common Lisp 2
AT&T Cfront 2
Sabre (CodeCenter) 2
AutoCAD 3 (enforced)
SAS 3 (not enforced)
Tecplot 3
Frame 3
------------------------------------------
Proposal:
--------
1. We will provide access to all software in category (1) for
workstations in the MIT domain that take Layered Athena.
2. We will not provide access to software in category (2) or category
(3) for general workstations that take Layered Athena, but we will
provide groups of owners of these workstations with information and/or
assistance on puchasing and setting up their own floating licenses for
software in category (3). In some cases may be able to take advantage
of our large pool of licenses in order to get volume price breaks.
3. Workstations that would be given access to software in categories (2)
and (3) would be:
- workstations purchased with ACS funds (including all public
workstations and workstations given by us to departments)
- workstations that will be purchased by departments at the
MCC, provided that the third party software that will be
used on these workstations will be used in conjunction with MIT
subjects. (ACS will be charged with giving such approval).
- workstatations that were purchased at the MCC and Athenized
prior to Layered Athena. (i.e. a grandfather clause)
4. This system will be enforced by a combination of Jeff's bit and a
DCNS-built wrapper.
Rationale for this proposal:
---------------------------
1. We are unable to guage what 'fraction' of a floating license a
non-educational (i.e. research) workstation will use up. Most
research use will probably involve intensive use of one or two
products, tying up a license for a long period of time and thus
effectively removing it from the educational pool.
2. We would have to be able to add licenses to the pool as research
users drain those licenses that were purchased for educational
purposes. Thus, we need to be able to recover this money in a dynamic
way.
3. Two ways of collecting the money would be
- by charging individual customers something in between what
their actual use costs us and what they would pay to acquire their
most frequently used product.
- by getting money out of the indirect cost pool
The problem with method (1) is knowing how much to charge and the
administrative costs of yearly billing. The problem with method (2)
is that we need to continually up the amount of indirect pool funds we
receive as the number of our users increases.
Counter-arguments that can be made:
---------------------------------
1. The institute as a whole would benefit by both economies of scale and
by utilitzationof 'unused cycles' if researchers could share in the
pool of licenses purchased by ACS, adding their funding if their
participation requires us to purchase additional licenses.
2. This could be a source of revenue for IS.
3. This would be value-added to the MITnet resource and would entice
people to bring Layered Athena to their workstations.
----------------------------------------------
Note: Provision of 3rd party applications was not part of the original
rationale for Layered Athena. In the opportunity evaluation, the
following were the benefits that were stated:
>We believe there are a number of benefits derived from doing a Layered
>Athena project:
>
>First, it will help us complete new platform ports easier.
>
>Second, it will allow us to deal better with a source-code free world
>for client platforms (although not necessarily for servers).
>
>Third, it will allow us to expand the use of Athena into departmental
>clusters and labs that do not want to give up their local control.
>
>Fourth, it will lessen the amount of time our support people spend with
>each special workstation configuration (although this may prompt more
>specials that result in an ultimate increase in support load).
>
>Finally, it will also make it easier for us to export Athena services
>outside of MIT, increasing our profile in industry.
None dealt with distribution of commercially licensed software applications.
