After 12 years in this industry I really wish I could claim that the problems we saw at new customers this year were different from those we've seen for the past years...but unfortunately that's really not the case.
First, there was the customer that contacted us after experiencing a BSA audit having paid out hundreds of thousands of dollars in fees and consulting dollars (lawyers, experts, etc). We assisted them in determining what they needed to purchase but they still wouldn't invest the small amount of money to put in an appropriate Software Asset Management (SAM) program (tracking software, processes, policies and product use rights education) or even consider outsourcing this issue.
Second, the customer who wanted some help negotiating a new volume licensing agreement. Unfortunately, when they had implemented their SQL Server 2005 environment with redundancy they failed to consult with an expert on product use rights (PUR's) so ended up implementing a solution requiring them to have duplicate SQL Server Enterprise processor licenses...a very expensive solution that could have been avoided with a quick phone call or e-mail.
Third, there was the customer who wanted our help in performing their Microsoft true-up. They had discussed their server virtualization project with their reseller in connection with their VMWare needs...but the reseller never asked about their actual server licenses. The 20 Windows Server Enterprise licenses they needed to purchase came as a complete surprise.
The list goes on...
The lesson to learn here is this: In Software Asset Management, spending a little money by having an expert on retainer can easily save ten-fold on your investment. Stop relying on internal staff who do not have the time or the resources to know the current PUR's on all your products, and don't take the word of anyone (including publishers, resellers or consultants) unless they back it up with publisher documentation.
I hope your 2008 is full of the positive rewards of an effective SAM program!
Friday, December 28, 2007
Thursday, October 25, 2007
Software Asset Management – A Regulatory/Industry Compliance Perspective
Software Asset Management (SAM) not only makes good business sense (lowers cost of software ownership, is integral to good security and enhances the productivity of technology workers) but it is also a key component in most of the regulatory and industry compliance requirements facing businesses today.
OK, I stretch on a few like HIPAA and Gramm-Leach-Bliley (GLB)…you can technically comply with these without SAM as long as you have hardware asset management, but still – you need to know where your computer assets are, who has access to them and be able to restrict what data can be loaded onto them.
But for Sarbanes Oxley (SOX) and the Payment Card Industry (PCI) Standards, it goes beyond that to actual SAM.
For SOX, there is a COBIT™ control objective which loosely states “Ensure that only appropriate software is installed in the environment”. Well, if you take that apart (which your auditors do…) then “appropriate” would mean (a) that you know what is appropriate and what is not, (b) that you have this documented somewhere, and (c) that it is licensed correctly. Additionally, to prove that you comply you need to be able to show what is installed in your environment and prove that you have a process that is documented and followed for periodically checking this information.
For PCI, you need to maintain a vulnerability program which has two requirements: (1) use and regularly update anti-virus software and (2) develop and maintain secure systems and applications. Both of these requirements come with a list of required items but basically it comes down to being able to ensure that every system has the most up-to-date virus protection and the latest approved security patches for all applications running on those systems. How do you ensure this information if you (a) don’t know what’s installed and where, and (b) don’t have a way of verifying what patch level it is at?
SAM makes good business sense, and it is required by many of the major regulatory/industry compliance requirements…so why are so many companies still avoiding it? Why the piecemeal approach that I see so often in the business place? Why do CIO’s and CFO’s eyes roll back in their heads when you mention SAM? I realize IT staffs are frequently overloaded and often do not have the necessary current information to maintain a SAM program – but isn’t that why we outsource?
Would love your insights…
OK, I stretch on a few like HIPAA and Gramm-Leach-Bliley (GLB)…you can technically comply with these without SAM as long as you have hardware asset management, but still – you need to know where your computer assets are, who has access to them and be able to restrict what data can be loaded onto them.
But for Sarbanes Oxley (SOX) and the Payment Card Industry (PCI) Standards, it goes beyond that to actual SAM.
For SOX, there is a COBIT™ control objective which loosely states “Ensure that only appropriate software is installed in the environment”. Well, if you take that apart (which your auditors do…) then “appropriate” would mean (a) that you know what is appropriate and what is not, (b) that you have this documented somewhere, and (c) that it is licensed correctly. Additionally, to prove that you comply you need to be able to show what is installed in your environment and prove that you have a process that is documented and followed for periodically checking this information.
For PCI, you need to maintain a vulnerability program which has two requirements: (1) use and regularly update anti-virus software and (2) develop and maintain secure systems and applications. Both of these requirements come with a list of required items but basically it comes down to being able to ensure that every system has the most up-to-date virus protection and the latest approved security patches for all applications running on those systems. How do you ensure this information if you (a) don’t know what’s installed and where, and (b) don’t have a way of verifying what patch level it is at?
SAM makes good business sense, and it is required by many of the major regulatory/industry compliance requirements…so why are so many companies still avoiding it? Why the piecemeal approach that I see so often in the business place? Why do CIO’s and CFO’s eyes roll back in their heads when you mention SAM? I realize IT staffs are frequently overloaded and often do not have the necessary current information to maintain a SAM program – but isn’t that why we outsource?
Would love your insights…
Thursday, September 13, 2007
Common Ways a Company Becomes Non-Compliant
Over the years I've worked with a number of companies and what has become obvious to me is that - it is rare that a company knowingly pirates software.
So, how do so many companies become non-compliant on their software agreements?
1) Lack of proper processes (and adherence to those processes) for software acquisition, deployment and retirement.
2) Lack of a good asset inventory tool that will accurately and easily report on what is installed.
3) Lack of records of what is owned.
4) Misconception or lack of knowledge of product use rights.
5) Misconception or lack of knowledge of volume licensing agreement rights.
Of all of these, I find the last two to be the most universal and it's a combination of misconception and lack of knowledge. Of the two I find misconception the most dangerous...because the company thinks that they're doing things right so they never ask for help.
How do the misconceptions happen? Generally, through outdated knowledge or guesswork.
Some things to be aware of:
1) Different use rights exist for different versions as well as different forms of acquisition.
For example, Microsoft 2007 software (Office, Server, Operating System) acquired OEM normally does not allow for downgrade; however, if acquired through Open, Select or Enterprise it normally does allow for downgrade. This was not always the case, in the past it had been allowed...was it allowed when you did it? Reference - http://download.microsoft.com/download/d/2/3/d23b9533-169d-4996-b198-7b9d3fe15611/downgrade_chart.doc). How were you planning to handle those OEM Office 2007 that are coming in the door? Were you going to downgrade those to 2003 until you're ready to upgrade?
2) Test and Development servers need to comply with product use rights same as Production.
3) Your Developers may have the "Professional" version of the software for development purposes but not be licensed for those for business use - be careful what's being installed on their production machines.
4) Vendors selling you a solution dependent upon another companies technology may not always provide you with full/accurate information about the licensing requirements...do your homework.
5) Client Access Licenses - in general if you're using the resources of a server, you need some form of client license for each user/device. Watch this carefully, it's the most common problem we find.
Just to name a few...
So, how do you keep up and still do your job? Frankly, you don't. You bring in professionals to educate you and provide you with documentation from the publisher supporting that education (do not rely on anything else...if a problem comes up, you're the one holding the bag) which you retain in a centralized location until those licenses (and their future upgrades) are no longer in use.
Questions? Comments? Would love to see them...
So, how do so many companies become non-compliant on their software agreements?
1) Lack of proper processes (and adherence to those processes) for software acquisition, deployment and retirement.
2) Lack of a good asset inventory tool that will accurately and easily report on what is installed.
3) Lack of records of what is owned.
4) Misconception or lack of knowledge of product use rights.
5) Misconception or lack of knowledge of volume licensing agreement rights.
Of all of these, I find the last two to be the most universal and it's a combination of misconception and lack of knowledge. Of the two I find misconception the most dangerous...because the company thinks that they're doing things right so they never ask for help.
How do the misconceptions happen? Generally, through outdated knowledge or guesswork.
Some things to be aware of:
1) Different use rights exist for different versions as well as different forms of acquisition.
For example, Microsoft 2007 software (Office, Server, Operating System) acquired OEM normally does not allow for downgrade; however, if acquired through Open, Select or Enterprise it normally does allow for downgrade. This was not always the case, in the past it had been allowed...was it allowed when you did it? Reference - http://download.microsoft.com/download/d/2/3/d23b9533-169d-4996-b198-7b9d3fe15611/downgrade_chart.doc). How were you planning to handle those OEM Office 2007 that are coming in the door? Were you going to downgrade those to 2003 until you're ready to upgrade?
2) Test and Development servers need to comply with product use rights same as Production.
3) Your Developers may have the "Professional" version of the software for development purposes but not be licensed for those for business use - be careful what's being installed on their production machines.
4) Vendors selling you a solution dependent upon another companies technology may not always provide you with full/accurate information about the licensing requirements...do your homework.
5) Client Access Licenses - in general if you're using the resources of a server, you need some form of client license for each user/device. Watch this carefully, it's the most common problem we find.
Just to name a few...
So, how do you keep up and still do your job? Frankly, you don't. You bring in professionals to educate you and provide you with documentation from the publisher supporting that education (do not rely on anything else...if a problem comes up, you're the one holding the bag) which you retain in a centralized location until those licenses (and their future upgrades) are no longer in use.
Questions? Comments? Would love to see them...
Tuesday, July 31, 2007
Software Asset Management – Luxury or Necessity?
I was speaking with a friend to day who asked me the question…is what you do a necessity or a luxury? I immediately responded that SAM is a necessity – but at the same time it made me really think about his question and about why he was asking it.
He’s a mortgage broker – and if you’ve watched the news at all, you know that there is a lot of pain going on in that industry. However; there is a lot of pain going on in a lot of industries right now, which is why he asked the question. If you think about it, while SAM is always important and there are always significant business reasons to do it – when things are tough financially and operationally it makes it even more important.
You can look at the figures all over and you will constantly see evidence that SAM saves companies around 30% on software costs in year one and about 10% on an annual basis. When you factor in the soft dollar savings on increased operational efficiency the savings go up dramatically. I know these numbers to be true based upon the results our clients have seen.
You could make the argument that while SAM is important, companies don’t need to hire consultants to do it for them so the hiring of a firm such as ours could be considered a luxury. True, companies can do it themselves…but unless you’re going to invest the time, money and energy to train someone within your organization to become a SAM expert – you will probably expend a fair amount of personnel time and then turn around and hire a professional when you don’t get the results you’re expecting.
Implementing a SAM program frequently involves a lot of esoteric knowledge – knowledge that is not necessary for ongoing maintenance but is necessary to provide the accurate evaluation of the current license and process status. Hire a professional to set up your program – let them put their expertise to work for you and train your staff on what it will take to maintain the program going forward.
So, unless you’re not going to buy software – SAM becomes even more important to you in lean times as it saves you considerable money, and hiring a professional to set up your program allows you to leverage their historical knowledge and expertise while at the same time ensuring that your staff only has to learn the pertinent information to maintain your program.
Has your company established a SAM program? Did you do it yourself or hire a professional? What was the outcome?
He’s a mortgage broker – and if you’ve watched the news at all, you know that there is a lot of pain going on in that industry. However; there is a lot of pain going on in a lot of industries right now, which is why he asked the question. If you think about it, while SAM is always important and there are always significant business reasons to do it – when things are tough financially and operationally it makes it even more important.
You can look at the figures all over and you will constantly see evidence that SAM saves companies around 30% on software costs in year one and about 10% on an annual basis. When you factor in the soft dollar savings on increased operational efficiency the savings go up dramatically. I know these numbers to be true based upon the results our clients have seen.
You could make the argument that while SAM is important, companies don’t need to hire consultants to do it for them so the hiring of a firm such as ours could be considered a luxury. True, companies can do it themselves…but unless you’re going to invest the time, money and energy to train someone within your organization to become a SAM expert – you will probably expend a fair amount of personnel time and then turn around and hire a professional when you don’t get the results you’re expecting.
Implementing a SAM program frequently involves a lot of esoteric knowledge – knowledge that is not necessary for ongoing maintenance but is necessary to provide the accurate evaluation of the current license and process status. Hire a professional to set up your program – let them put their expertise to work for you and train your staff on what it will take to maintain the program going forward.
So, unless you’re not going to buy software – SAM becomes even more important to you in lean times as it saves you considerable money, and hiring a professional to set up your program allows you to leverage their historical knowledge and expertise while at the same time ensuring that your staff only has to learn the pertinent information to maintain your program.
Has your company established a SAM program? Did you do it yourself or hire a professional? What was the outcome?
Thursday, June 21, 2007
What's an acceptable "out of compliance" number?
I was privy to an interesting conversation a few weeks ago...the topic was "What level of non-compliance is acceptable?". Basically the basis for the discussion was that being illegal on some licenses was to be expected but at what level does it become an issue.
Before jumping into all sorts of morality issues, I'll stop myself and instead put this in the context of...assuming it will cost me money to prove every single license, is there a point at which I can say "under this amount is not worth the cost"?
Now, morally I don't feel there is a number greater than zero that can be acceptable. If you can't prove licensing for a single product, you owe it to yourself and the publisher who invested their time and resources into its creation to buy the product (and then keep better records).
Getting off my moral high horse I will point out that running even a single copy of software that you can't prove licensing for is a risk to you and your organization. As with any risk to your organization, your organizations risk assessment framework should address this topic for you. But remember - you can't manage what you don't know and you can't apply a risk assessment if you don't have the details!
What are your thoughts?
Before jumping into all sorts of morality issues, I'll stop myself and instead put this in the context of...assuming it will cost me money to prove every single license, is there a point at which I can say "under this amount is not worth the cost"?
Now, morally I don't feel there is a number greater than zero that can be acceptable. If you can't prove licensing for a single product, you owe it to yourself and the publisher who invested their time and resources into its creation to buy the product (and then keep better records).
Getting off my moral high horse I will point out that running even a single copy of software that you can't prove licensing for is a risk to you and your organization. As with any risk to your organization, your organizations risk assessment framework should address this topic for you. But remember - you can't manage what you don't know and you can't apply a risk assessment if you don't have the details!
What are your thoughts?
Sunday, May 20, 2007
Is the business world ready for embedded controls in software?
I was at the SAM Summit last week (www.samsummit07.com - check it out for future years as I was very pleased with the dialog's started) and the topic of embedded controls came up (think Adobe's License Manager or Microsoft's Vista for example) in a small group session I was leading.
The question we were dealing with is "what did we think was the future or embedded controls and would the user community rebel". My group was a nice blend of 3 reps from end-user companies, 2 tool reps, 1 publisher rep and myself (a SAM services rep). Quite frankly, with this blend we didn't answer the question...but we had some great dialog.
From the industry side (tools & publisher) came the steadfast belief that these controls are here to stay and are necessary. From the end-user side came a lot of uncertainty and concern...but frankly none of them had even tested the controls yet to know if their concerns were founded.
Now, don't take me wrong...I am not envious of any company facing enterprise-wide rollout of software with embedded controls - I've lived in the IT world too long to think it's going to go smoothly. However; until we at least test it - it's pure speculation! I know some of my readers have to have tested (and some potentially deployed) software with embedded controls. What's your reaction? What has experience shown you?
Are embedded controls bad for the end-user community or can they do their job and simplify our SAM headaches? Who should have control over who the control reports to (publisher or internal SAM)? Give us your thoughts and experience.
The question we were dealing with is "what did we think was the future or embedded controls and would the user community rebel". My group was a nice blend of 3 reps from end-user companies, 2 tool reps, 1 publisher rep and myself (a SAM services rep). Quite frankly, with this blend we didn't answer the question...but we had some great dialog.
From the industry side (tools & publisher) came the steadfast belief that these controls are here to stay and are necessary. From the end-user side came a lot of uncertainty and concern...but frankly none of them had even tested the controls yet to know if their concerns were founded.
Now, don't take me wrong...I am not envious of any company facing enterprise-wide rollout of software with embedded controls - I've lived in the IT world too long to think it's going to go smoothly. However; until we at least test it - it's pure speculation! I know some of my readers have to have tested (and some potentially deployed) software with embedded controls. What's your reaction? What has experience shown you?
Are embedded controls bad for the end-user community or can they do their job and simplify our SAM headaches? Who should have control over who the control reports to (publisher or internal SAM)? Give us your thoughts and experience.
Monday, April 09, 2007
Startups and Small Companies Exempt from Buying Software?
I was at a CFO conference last month and had an interesting discussion with another attendee over lunch one day.
This attendee (we'll call him Jeb) is the CFO of a small firm in California. This is not his first time at being a CFO and is an intelligent, articulate gentleman who endorses an entrepreneurial spirit within his company.
The conversation started out the usual way with him asking what my firm does (Software Asset Management-SAM) and then asking a variety of questions about how SAM benefits companies. The conversation then turned towards compliance and he shared that a former company had been audited by the Business Software Alliance (BSA) right before he had gone to work for them and had been fined due to inappropriate use of software licenses. He described some of the financial and operational pain the company had experienced as a result of not being properly licensed.
Finally, the conversation turned to the financial impact of outfitting an organization with software licenses. Being a business owner myself, I could definitely commiserate with Jeb over the costs to properly outfit an organization. However; I was amazed to hear him share his viewpoint that start ups and small businesses shouldn't be expected to license every computer.
Frankly, I was blown away. Here was an intelligent, financial professional stating that companies should be allowed to break the law, steal intellectual property, and essentially mis-state their financial earnings (when you realize that they wouldn't be including a major cost to doing business...buying software).
Desperately trying to stay off of my soap box, I raised these issues with Jeb. I tried every logical argument to try to have him understand how integrally unethical his viewpoint is...I hope I at least gave him something to think about. Unfortunately, he's not alone in his viewpoint...can someone please explain to me how you can morally or ethically justify software piracy?
Weeks later and it still amazes me...
This attendee (we'll call him Jeb) is the CFO of a small firm in California. This is not his first time at being a CFO and is an intelligent, articulate gentleman who endorses an entrepreneurial spirit within his company.
The conversation started out the usual way with him asking what my firm does (Software Asset Management-SAM) and then asking a variety of questions about how SAM benefits companies. The conversation then turned towards compliance and he shared that a former company had been audited by the Business Software Alliance (BSA) right before he had gone to work for them and had been fined due to inappropriate use of software licenses. He described some of the financial and operational pain the company had experienced as a result of not being properly licensed.
Finally, the conversation turned to the financial impact of outfitting an organization with software licenses. Being a business owner myself, I could definitely commiserate with Jeb over the costs to properly outfit an organization. However; I was amazed to hear him share his viewpoint that start ups and small businesses shouldn't be expected to license every computer.
Frankly, I was blown away. Here was an intelligent, financial professional stating that companies should be allowed to break the law, steal intellectual property, and essentially mis-state their financial earnings (when you realize that they wouldn't be including a major cost to doing business...buying software).
Desperately trying to stay off of my soap box, I raised these issues with Jeb. I tried every logical argument to try to have him understand how integrally unethical his viewpoint is...I hope I at least gave him something to think about. Unfortunately, he's not alone in his viewpoint...can someone please explain to me how you can morally or ethically justify software piracy?
Weeks later and it still amazes me...
Tuesday, March 27, 2007
Software Asset Management - Past, Present and Future
While enjoying a nice bottle of wine with a friend and fellow Software Asset Management consultant last week the topic of the future came up (which I think is probably pretty common when alcohol is involved), the future of Software Asset Management.
Well, we couldn't really discuss the future without rehashing the past and disecting the current.
History of Software Asset Management: SAM has been very cyclical in its popularity over the years. In the mid to late 1980’s when desktop computers were gaining in popularity within business there was a constant eye on the cost of such technology. Volume agreements and product use rights were very different from today with the minimum entry point for a volume discount being much higher and use rights flexibility such as concurrent usage being more current. Also during this time we saw the formation of the industry watch dogs (the Software Publishers Association and the Business Software Alliance) to educate and “police” organizations in regard to copyright infringement on software. In the early 1990’s there was a strong concern for the potential fees associated with being audited on improperly licensed software causing companies to implement SAM programs. The mid-1990’s saw a dramatic shift in volume license programs and product use rights creating a need for education on these changes and their impacts on organizations. The late-1990’s saw organizations moving away from a focus on SAM as publishers and industry watchdogs became more concerned about potential litigation. While there was some increase in attention due to the concerns around the Year 2000 problem, the cost cutting requirements of the early 2000’s had the effect of eliminating many internal controls as organizations cut positions. Now, in the mid-2000’s we see an increased focus on internal controls with the various regulatory requirements, an increased aversion to risk and an increase in industry audits.
SAM Present Day: As I mentioned, we're now seeing an increased focus on internal controls and increased regulation. This is resulting in a renewed interest in SAM. For some companies that threw out their programs in the 90's with all the other cuts - that means starting from scratch. For others, it's just a brush-up to become current with new product use rights, new licensing programs and better tool options. Unfortunately for a few, it means continuing to stick their head in the sand and hope that they don't have to deal with it.
Future of Software Asset Management: OK, so I don't really have a crystal ball. I'm actually going to raise more questions than I answer...
Many that I talk to think that we will be facing more regulations and therefore SAM will continue to grow. Personally, I don't think business will continue to support that model...how regulated can private industry become (and how much money can companies spend on regulation compliance versus increasing profits) before it rebels?
Others feel that Software as a Service (SaaS) will remove a lot of the licensing demands on companies making it a pay for service commodity. While I think we've already seen an increase in SaaS (or ASP for the old school), I also think there are basic desktop applications that are going to remain being exactly that...desktop applications (OK, not sure betting against Google is a smart move...but I also don't really think they expect to win big business). Mind you, I've predicted for the past 10 years that software licensing would move to a "lease" model...but this isn't the way I expect to see us get there.
So, what does this mean for SAM? Personally, I think it means that SAM will be an ongoing part of business and just like it has for the past many years the true adoption of it will be more a basis of the maturity of an organization rather than an indication of the industry.
What do you think?
Well, we couldn't really discuss the future without rehashing the past and disecting the current.
History of Software Asset Management: SAM has been very cyclical in its popularity over the years. In the mid to late 1980’s when desktop computers were gaining in popularity within business there was a constant eye on the cost of such technology. Volume agreements and product use rights were very different from today with the minimum entry point for a volume discount being much higher and use rights flexibility such as concurrent usage being more current. Also during this time we saw the formation of the industry watch dogs (the Software Publishers Association and the Business Software Alliance) to educate and “police” organizations in regard to copyright infringement on software. In the early 1990’s there was a strong concern for the potential fees associated with being audited on improperly licensed software causing companies to implement SAM programs. The mid-1990’s saw a dramatic shift in volume license programs and product use rights creating a need for education on these changes and their impacts on organizations. The late-1990’s saw organizations moving away from a focus on SAM as publishers and industry watchdogs became more concerned about potential litigation. While there was some increase in attention due to the concerns around the Year 2000 problem, the cost cutting requirements of the early 2000’s had the effect of eliminating many internal controls as organizations cut positions. Now, in the mid-2000’s we see an increased focus on internal controls with the various regulatory requirements, an increased aversion to risk and an increase in industry audits.
SAM Present Day: As I mentioned, we're now seeing an increased focus on internal controls and increased regulation. This is resulting in a renewed interest in SAM. For some companies that threw out their programs in the 90's with all the other cuts - that means starting from scratch. For others, it's just a brush-up to become current with new product use rights, new licensing programs and better tool options. Unfortunately for a few, it means continuing to stick their head in the sand and hope that they don't have to deal with it.
Future of Software Asset Management: OK, so I don't really have a crystal ball. I'm actually going to raise more questions than I answer...
Many that I talk to think that we will be facing more regulations and therefore SAM will continue to grow. Personally, I don't think business will continue to support that model...how regulated can private industry become (and how much money can companies spend on regulation compliance versus increasing profits) before it rebels?
Others feel that Software as a Service (SaaS) will remove a lot of the licensing demands on companies making it a pay for service commodity. While I think we've already seen an increase in SaaS (or ASP for the old school), I also think there are basic desktop applications that are going to remain being exactly that...desktop applications (OK, not sure betting against Google is a smart move...but I also don't really think they expect to win big business). Mind you, I've predicted for the past 10 years that software licensing would move to a "lease" model...but this isn't the way I expect to see us get there.
So, what does this mean for SAM? Personally, I think it means that SAM will be an ongoing part of business and just like it has for the past many years the true adoption of it will be more a basis of the maturity of an organization rather than an indication of the industry.
What do you think?
Tuesday, January 09, 2007
Mergers & Aquisitions - the importance of software licensing
I got a call the other day from a former co-worker. It appears that her new company had recently spun off from it's parent and in preparing for their software upgrade they got an ugly surprise...their former parent had never bought the software they contractually "transfered" to my friend's company. About $400,000 worth of software needed to be bought.
Knowing for sure about software licensing during Mergers and Acquisitions or any other type of change of control activity is extremely important.
Divestitures
When a company splits off from a parent company there is a lot to be figured out, including who gets the software.
If the company has only purchased OEM software then the software rights transfer with the machine – however; documentation is key. The onus of ownership remains with the company using the software.
If the company purchased retail software, will this be transferred to the new company? If so, physical transfer of the licensing agreements and records needs to occur as well. It would also be wise for the new company to insist on financial records showing the initial purchase.
If the company purchased under volume agreements (non-contractual), then the publisher needs to be notified of the transfer (transfer fees may be involved) and appropriate documentation needs to be retained by both companies.
If the company purchased software through a contractual agreement then there are additional considerations. Is the contractual agreement also covering any of the former parent’s software as well? In most cases it would be. Does the contract allow for separation or transfer of licenses? Is there a license transfer fee or notifications? Will either company still be of appropriate size to qualify for the contract?
Acquisitions
The last thing a company wants to do is acquire someone else’s software licensing nightmares. Ensuring that you receive full documentation of what you are paying for when you acquire the company and its software assets is key.
Additionally, a company that is acquiring another company generally has its own software assets already under various forms of contracts (or through acquisition a company might finally be of a size to qualify for a contractual volume agreement). Maintaining separate agreements or being able to wrap multiple agreements together is one of the items to be considered. Additionally, some contracts have language in them requiring a company to wrap acquisitions into an existing contract. It is important that a company be aware of any such requirements upfront so there are no costly surprises.
Knowing for sure about software licensing during Mergers and Acquisitions or any other type of change of control activity is extremely important.
Divestitures
When a company splits off from a parent company there is a lot to be figured out, including who gets the software.
If the company has only purchased OEM software then the software rights transfer with the machine – however; documentation is key. The onus of ownership remains with the company using the software.
If the company purchased retail software, will this be transferred to the new company? If so, physical transfer of the licensing agreements and records needs to occur as well. It would also be wise for the new company to insist on financial records showing the initial purchase.
If the company purchased under volume agreements (non-contractual), then the publisher needs to be notified of the transfer (transfer fees may be involved) and appropriate documentation needs to be retained by both companies.
If the company purchased software through a contractual agreement then there are additional considerations. Is the contractual agreement also covering any of the former parent’s software as well? In most cases it would be. Does the contract allow for separation or transfer of licenses? Is there a license transfer fee or notifications? Will either company still be of appropriate size to qualify for the contract?
Acquisitions
The last thing a company wants to do is acquire someone else’s software licensing nightmares. Ensuring that you receive full documentation of what you are paying for when you acquire the company and its software assets is key.
Additionally, a company that is acquiring another company generally has its own software assets already under various forms of contracts (or through acquisition a company might finally be of a size to qualify for a contractual volume agreement). Maintaining separate agreements or being able to wrap multiple agreements together is one of the items to be considered. Additionally, some contracts have language in them requiring a company to wrap acquisitions into an existing contract. It is important that a company be aware of any such requirements upfront so there are no costly surprises.
It's also important to know your rights. It's not unusual for software publishers to limit what rights can be transfered when a company is bought or sold.
If you need to know more, contact us through our website at www.cynthiafarren.com
Subscribe to:
Posts (Atom)