Software Ownership: Who should ‘Own’ software licenses within an organisation?
Software license ownership is a common talking point within organisations. Who owns the license, or who has taken responsibility for ‘ownership’? It may be the case that nobody has been made responsible, or that there isn’t a dedicated and well communicated software license ‘owner’. So who should take ownerships of software and their licenses?
There are positives and negatives for the various options, and experience shows that it all depends on how the organisation is structured and run. Technically there is no wrong or right answer, but we will highlight the ‘recommended’ method of identifying ownership.
It is important to remember that no single person, department or organisation actually ‘owns’ any piece of software (apart from internally developed applications). Software publishers own all of the rights to the software; they are selling a license to use their product. However, it is important to assign ‘ownership’ of the software and software licenses within an organisation to ensure that all users, departments and senior staff members are aware of what software licenses they have, and where they should in theory be used. Assigning ownership is another key component towards being ‘audit ready’ and having a sophisticated ITAM estate.
Organisations may identify software license owners differently, based on how the organisation is structured and how it is run on a daily basis. It also depends on existing procurement and financial processes that are already in place, but the common ‘ownership’ areas are:
- The organisation as a whole
- Individual departments or cost centres
- Individuals (such as Software / License Champions)
In essence, it does not really matter where the ownership of the licenses lies, as what works for one organisation may not work for another. What is important is that clear responsibility and ownership for licenses is communicated and assigned so that users and the business knows where they stand and who to contact about the software or software license for a specific vendor.
The case for cost centre/department ownership
This is one of the most common options for organisations wishing to assign software license ownership. Organisations assign cost centres or departments as the owners responsible for certain software vendors. This is usually the department or cost centre with the biggest investment or most amounts of users of the software. The department or cost centre is then in charge of managing the licenses and ensuring compliancy, and also in charge of help with any software license additions or a renewal of the contract or software maintenance.
Departments or cost centres can get very protective over their licenses as the cost usually comes out of their individual budgets. Whilst this may be the case it is important to remember that the license is still the organisations license, it does not belong to the cost centre or department. The department or cost centres budget was given to them by the organisation anyway, so anything they purchase with that money is an asset to the organisation as a whole.
Having a department or cost centre as the owner of a specific vendors software licenses can result in under-used software, or other departments wasting money on licenses because the ownership department will not allow them any of their free licenses. This results in the organisation being over compliant, not using their licenses effectively and also over-spending on software unnecessarily.
However, there are positives to assigning ownership to a department or individual. The department or cost centre are responsible for the compliancy, procurement and overall management of the licenses which helps take some of the strain and pressure off of a SAM or ITAM team. This also allows a department or collection of users to become experts in licensing for that vendor, allowing them to provide support for the business and its users.
Pro’s and Con’s
|1. Assigns a department to manage licenses and finances, taking the pressure off the ITAM/SAM team||Can be protective over ‘their’ software licenses|
|2. Helps develop internal knowledge of software vendor and their licenses||Can result in over-spending and not using licenses effectively|
|3. Should be heavy users of the software, so know how to provide support to other users and the business||Can result in internal bickering if licenses are not ‘lent’ out to other departments|
The case for individual ownership
Out of the three options, this is the option that is used the least. Organisations may assign a specialist or heavy user of a certain piece of software to be the ‘Software/License Champion’. What that effectively means is that the user is responsible for managing any renewals for the license or maintenance, is the point of contact for any licensing issues around the software, and in some cases they may also be a part of the approval process for any new requests.
Assigning ownership to an individual is a risky option. There are a number of issues to consider. What happens when the software champion leaves? Do they take of their knowledge about the software and its licenses with them? There is also the risk that the software champion will make emotional decisions. This can range from rejecting license requests for users that they may not like, or not assigning licenses to users because they want to save their department money.
However, the software champion is only focusing on one vendor, and should be a heavy user of the software. That means that, whilst in the role of software champion, they should be an expert, both technically and licensing wise, which takes off a bit of the pressure and strain on the ITAM or SAM teams. This is also a big asset to the organisation, as through the software champion’s expertise they may be able to save money on their maintenance costs as they have the knowledge internally to support their users.
Pro’s and Con’s
|1. Expert knowledge and understanding of the software and licensing||Internal resource, if that person leaves the knowledge will leave with them|
|2. Only focuses on one vendor/application, minimal time taken out of their daily job||Can make emotional decisions and prevent certain users or departments from having a license|
|3. Knowledge can support other users and the business with the software and licenses||May not be financially savvy, negotiating a good deal on future agreements may be up to someone else|
|4. Internal knowledge and resource. Cheap!||May be resistant if the organisation wishes to remove or cut-back on the amount of installs for the application|
|5. Heavy user of the software, so is in a good position to assist the business with future renewals/license purchases||A lot of responsibility on one person. If they are absent from work, who can help with any questions or requests?|
The case for organisation ownership
At the end of the day, the organisation will own the license. Any software licenses purchased should be in the organisations name, or in the name of one of the entities within the organisation. To allow all users to use the software, and allow for greater flexibility, some organisations assign software license ownership to the organisation as a whole. The organisation pays for the software (event departmental budgets still come out of the organisations banks!), so they assign license ownership to the business. This means that all the licenses can be used by anyone (within the T&C’s) regardless of what department they are in.
Assigning ownership to the business takes out all of the arguments around who owns what software, and what department is using another departments software license. If there is a central pool and a central procurement method, then organisations can be flexible and more responsive with software license requests. This allows for better software asset management and will help the organisation manage their software licenses correctly and effectively via an ITAM or SAM team.
Personally, I would assign license ownership to the business so that a centralised ITAM or SAM team can manage all of the licenses and make the most out of the organisations investment. With no departmental restrictions (there may still be entity restrictions or regional restrictions) the ITAM or SAM team are free to try and utilise all of the available licenses and have a central pool for future requests and distribution.
Pro’s and Con’s
|1. More flexibility when allocating licenses||There still may be entity or regional restrictions to licenses|
|2. Can be managed centrally||Managed by one team to may not have individual expertise on all software vendors|
|3. Helps reduce SLA’s and waiting times for new software requests|
|4. Assists with being ‘audit ready’ and knowing compliancy|
|5. Allows the organisation to utilise existing/ software license before acquiring more licenses|
Top Tips for assigning ownership
We have arranged a number of top tips for assigning software license ownership within your organisation:
- Ensure ownership is clearly defined and understood
It is important to clearly set define who has ownership for what software licenses, and who the point of contact is for certain vendors. This can be done via an internal document on SharePoint, or via an ITAM/SAM solution.
- Ensure ownership is communicated throughout the business
Make sure end users know who to contact regarding any enquires about software or software licenses. Communicate the department/software champion/ITAM team’s name or contract details, and have the information stored somewhere that all users can access.
- Ensure the owner is capable and has the knowledge to manage software licenses (If assigned to a software champion)
If assigning ownership to a single person, it is important that they have the time, and knowledge to effectively manage the software and its licenses. They should be a heavy user and an expert in using the software, and have some understanding of how it is licensed.
- Ensure the department understands what licenses they have, and that they understand use rights (if assigned to a department)
Before handing ownership of licenses to a particular department or cost centre, it is important they understand exactly what licenses they have and can use. They also need to know what the terms and conditions of the license are and whether they are entitled to any internal charge back if another department wishes to use one of their licenses.
- No matter what, ensure that the ITAM/SAM/Licensing team are fully aware of all licenses purchased and owned by the organisation
Assigned ownership or not, the ITAM or SAM team still need to be told of any new software licenses or any existing ones to manage the organisations software assets effectively. All new license requests and purchases should still be done via the official channels.
If you have any questions about this article or would like to know more about software license ownership, then please get in touch with us. We love hearing your views and opinions on our content so have your voice heard!
The most interesting ownership structure I’ve seen centered around one individual in a company with about 90,000 PCs who developed (and exhaustively documented) a complex system that provided fine-grained control of licenses and regular harvesting of unused or retired software. It even included a tiered charge-back system in which business units who needed software such as SQL Server had multiple choices. If they wanted the latest product, they were charged nearly full price. If they wanted the previous version, they would pay less, all the way back to older versions that might be available for 10% the cost of a new license. This encouraged people to use older and already-paid-for licenses before purchasing new ones.
The guy who ran this system had enormous control, which was not always welcome. If he didn’t think you needed a product, you didn’t get an activation key for it. (And since he kept meticulous track of what was actually running, woe to those who tried to get around it.)
But, with something like 10,000 servers running at any given time, the company always knew exactly where it stood and it ran a lean, clean software infrastructure.