Proposed
ANU Software Register
Discussion Paper
This paper was prepared to promote further discussion to assist in the creation of a University Software register following a meeting on 11 Jan 2002 with Robin Erskine, Fay Gibbons, Nick Dal Molin, Sally Trotter and Don Graham
A major recommendation of the 2001 software audit carried out by the ANAO was for the University to have a common software register.
A second recommendation of the ANAO Audit was that of regular compliance checking. This would involve reviewing software loaded onto computers against licence details recorded in a software register. This ensures all software is licensed appropriately or any unlicensed software is removed.
At present each of the 40 to 50 business units on campus create their own record management system to record software purchases with varying degree of detail. Incomplete records of software licences has made it difficult for some areas to ensure they are fully licensed in accordance with University policy and Copyright Law. The responsibility rests with each area and their respective Dean or Director.
The risk to the University for non-compliance and the exposure to associated penalties needs to be minimised.
The creation of a common software register is seen as an essential component in minimising this risk.
Software registers currently range from photocopies of invoices/orders held in a binder on a shelf to complex management tools that track the issue of each item of software right down to each individual computer.
The right tool for the University is somewhere between the two. Ie a balance between providing useful and accessible information without creating an excessive administrative overhead to maintain.
At a minimum the software register should have the following attributes:
1) The software register should include all software purchased across the University.
2) Be easy to maintain.
3) Provide software information and reports on screen and through printouts or downloads.
4) Enable local areas access to read and update their own records.
5) Enable IIS to enter details of bulk software purchases made centrally on behalf of other areas to ensure licence details are reflected against each local area.
6) Provide a tool to local areas and to the University to confirm compliance with software licenses, copyright law and University policy.
The following table gives an example of some fields that may be useful in a “Software register”.
Software Details
|
Example
|
|
Software name |
Dreamweaver |
|
Software version |
4 |
|
Manufacturer |
Macromedia |
|
Licence expiry date |
Perpetual |
|
Licence type |
|
|
Concurrent
users |
1 |
|
Restrictions |
|
|
Upgrade from |
Ref# |
|
|
|
|
Cross reference to purchase details
and supporting documentation |
|
|
Supplier |
|
|
Order No |
ITS00000178 |
|
Invoice |
12345 |
|
Qty |
15 |
|
Unit Cost |
$145.00 |
|
Date purchased |
24/10/2001 |
|
|
|
Local Area Details
|
|
|
School/Dept/Division name |
Library |
|
Local area contact |
Xxxxx |
|
Local area account code |
R20510 5362 |
How do areas keep track of the software
loaded onto their computers?
The above fields while providing a useful record of the purchase do not provide a management tool to identify the specific computers using the licenses.
For areas that load a standard image on all their computers, keeping track of software in use will be reasonably straight forward. i.e., an area has 100 computers and 100 licences for Microsoft Office. Areas may also be using products such as Keyserver to limit concurrent users where licenses permit.
It is where software images vary from standard, due to the specialist needs of the users, this becomes more difficult to manage. An area may know they have 10 copies of Dreamweaver 4, but how do they keep track of which computers they have loaded it onto? Should the central software register record specific machine details or user name?
A linked table containing the issue details would resolve this and would only need to be used by areas for software outside of a standard image.
Software Issue Detail
|
|
Computer detail |
|
Computer serial number |
|
Computer location |
|
User name |
|
|
General Issues
The design or selection of a Software Register product will need to take into account the following:
1) The diversity of the computer environments across campus.
2) Devolved processing and responsibility.
3) The diversity of software products and their respective license agreements.
4) The provision of a useful management tool to aid in software copyright compliance. http://www.anu.edu.au/legal/copyright/software.html
Software purchased in the IIS (R29), CIS (R28) and STS (R57) ledger for 2001 came to approx. $1,100,000 for the year.
The above amount included software purchased through the IIS Business Office on behalf of local areas for 2001 ($500,000)
Software purchased by ANUSF $42,000 plus another $84,000 related to APAC.
CIS purchases of $257,000
STS (R57) purchases of $190,000.
Purchasing points:
Software can be purchased in a variety of ways including:
1) Bulk purchases coordinated by IIS – on receipt of requests from local areas.
2) Local area Business Office – purchase order, credit card or accounts payable for renewals.
3) Staff credit cards.
4) Software can also come as part of equipment purchases. (ie operating system)
5) Or may be brought in by staff in breach of license.
Computer related accounts in the ANU ledger are as follows however software can sometimes be found in other accounts:
1) 5362 - Software
2) 5111 – Computer equipment under $5,000 ea
3) 3111 – Computer equipment $5,000 ea or over.
4) 5363 – Computer consumables
1) Perpetual
2) Annual
3) Specified period or expiry date
4) Upgrade
5) Single user/Multi user
6) Concurrent
7) Site wide (limited user number)
8) Site wide (unlimited user numbers)
9) Etc.
Licence agreements vary greatly from product to product and determine conditions of use.
1) Platform specific
2) Restrictions on commercial purposes
3) Restrictions on transfer
4) Volume licence agreements
5) Etc
The following are some of the current volume purchase agreements:
1) Microsoft Select Agreement
2) Macromedia
3) Adobe
4) Mathematica
5) Dragon Naturally Speaking
Nick Dal Molin is currently in the process of looking further at the ESP system to assess if a software register is possible within the asset register system.
This paper provides only a limited view of the issues related to software management.
Whichever way we go, either with ESP or an off the shelf product, a working party would be needed to confirm user requirements and specifications, and to assess suitability of any proposed product or register system. The working party should include staff with local knowledge of existing software registers, together with the purchasing and business practices within various Schools, Faculties and Centres.
The software register is proposed in order to assist local areas manage existing responsibilities and to make the task of compliance with copyright and licensing requirements easier.
Prepared by: Don Graham, 5 Feb 2002