The pros and cons of software subscriptions and perpetual licenses are informed primarily by the business considerations of both the vendor and the customer, but each carries different legal implications. Because this decision is typically determined by a vendor, I will first focus on the factors that tend to determine which model a business adopts and then look at a few key legal considerations pertaining to each model.
What’s your business? First and foremost, subscription pricing with ongoing periodic payments tied to term-specific access rights lends itself to a “software as a service” or SaaS model. On the other hand, a perpetual license, typically with a one-time upfront payment is most common with a commodity software product that is installed by the licensee and either used for its useful life or upgraded via an ongoing service plan.
With a SaaS model, the software is hosted by the vendor and the customer receives client-side access. The vendor is able to update its software and roll those updates out to its customer base almost instantly without requiring each customer to go through an upgrade migration. The customer may not even obtain or require a license to the software itself, but rather receives access to the service. In a SaaS model, the initial access costs less than a competitor’s software solution made available with a perpetual license and one-time payment.
If the service meets the customer’s needs during the initial subscription term, the customer is likely to continue renewing, often at increasingly higher annual fees depending on what is negotiated. The customer may feel locked in if the costs to migrate to an alternate solution are higher than the annual subscription fee for the current service, which is generally the case if the alternative is a perpetually licensed solution hosted by the customer. And of course, even if the current service is not perfect, the SaaS provider is presumably rolling out improvement continuously, and from a customer’s perspective the devil you know may be better than the devil you don’t. It is hard to see how perpetual rights to the service and/or a one-time payment will ever make sense in a subscription model, and I have never seen it.
At the other extreme is a software application that is installed by the end customer and used by that consumer indefinitely or until its useful lifespan runs out. These customers historically have expected, and vendors have provided, a perpetual license for a one time upfront payment. Minor updates are often included, but major upgrades are not. Vendors are thus able to obtain an initial upfront payment and then offer a service plan that includes updates and upgrades while the customer is paying for the service plan. Consumer applications such as Microsoft Word™ and Adobe Lightroom™ used to be available solely on a one-time license, but now both companies have moved to hybrid models involving both a license and a service with recurring payments.
There are plenty of B2B examples of perpetual licensing, such as highly customized accounting and royalty software hosted by the customer and software embedded in a customer’s digital products which are licensed without a set term, such as third party game engine software. Customers of such software require that all third-party code be licensed for perpetual end user use.
These models are very much in flux as traditional commodity software providers seek to shift to a hosted model and reap the benefits of recurring payments and access to data through cloud hosting. Adobe’s Creative Cloud is a good example of taking software applications and making them available to consumers through the cloud on a subscription basis. These two models can come into conflict in some instances, such as when a value added reseller (VAR) who generally offers its customers perpetual licenses wants to re-sell another company’s service.
Regardless of which licensing structure is utilized, the following outlines some of the key items that should be addressed along with approaches to addressing them.
As mentioned above, payments are typically recurring, whether monthly or annually, and service access is dependent on payment for the subscription period. This generally means a comparatively lower cost for customers to get up and running compared to a perpetual license. There may be payments tied to implementation and/or customization, but these options are generally more limited than customization of solutions hosted by a customer (or by third parties on behalf of the customer). Lower startup costs, ongoing support and a proven scalable solution are key selling points of a subscription service.
One issue that arises is how to address fees in subsequent years. On one hand, a customer does not want to be at the mercy of the vendor who may offer incentive pricing to get the customer “locked in” and raise the prices over time. On the other hand, a vendor will be reluctant to commit to holding prices fixed or capping increases beyond a limited time horizon.
Typically, payment is made as a one-time up-front payment. There is no rule about this, however, and a customer could of course try to negotiate staggered payments or payments tied to use metrics, but at some point the customer will have paid “in full” and be entitled to use the software indefinitely. It is more common on perpetually licensed solutions to have a separate services agreement to assist in customization and implementation. A benefit of a perpetual license is the customer knows the license cost and will not be at the mercy of a subscription service provider raising fees in subsequent periods (assuming the customer has the capability of maintaining the code base over time).
There are accounting and revenue recognition rules that could make one approach more favorable than the other to vendors and providers.
Most subscription solutions will have some client-configurable options as part of the service. Some will also offer a separate service to help get customers up and running and may offer some additional customization not already built into the system. However, for a true SaaS solution focused on scalability, the key selling point is not bespoke development and customization. Those companies who need something truly unique are more likely to find a higher level of customization available with a perpetual license and development services model. When SaaS providers do agree to implement certain features at the request of a customer, some customers expect a level of IP “ownership” in those customizations, but this is more appropriate in a perpetual license/custom development model. SaaS vendors typically resist this.
Software licensed on a perpetual basis is often, but not necessarily, hosted by the customer on its own servers and may require a higher level of customization and integration in order to interoperate with the customer’s other systems and meet the customer’s specific needs. Vendors and their authorized service providers can be engaged to customize and integrate the software as a separate service agreement. The level of customization at the direction of the customer varies, and so too does the allocation of IP ownership rights in the customization, but sometimes a customer requires a level of customization and control that can not be met by a SaaS provider.
Warranties are often hard fought, and appropriately so, whether the license is for a subscription or for perpetual rights. For a subscription service, it is generally expected that there will be some level of performance warranty that would apply throughout the subscription term. Vendors will typically seek to limit their obligations and their customers’ remedies to repairing the issue and failing that terminating the agreement, in some cases offering a pro-rata refund for the remaining term as the sole remedy in the event of such termination, or service credits if the agreement is not terminated.
A perpetual license rarely comes with a perpetual warranty! Generally, performance warranties will be limited to a period of time, such as 90 days. If the software doesn’t meet the warranty requirements the vendor will typically repair or replace the software, but failing that, will offer a refund, possibly the entire license fee. Beyond the warranty period, the customer is typically dependent on the terms of a secondary service agreement.
Upgrades and updates are typically included as part of the subscription fee. Indeed, most SaaS providers want (or need) to maintain a single instance of the server-side code base and have efficiency gains maintaining customers on the same version of code.
Usually, providers of software licensed on a perpetual basis will include a time limited warranty, as discussed above. They will rely on the customer paying to obtain an upgrade every few years (e.g., moving to a new version of Word) or paying for an ongoing service/support plan which could include providing access to the latest versions as long as the customer is an active support customer. Since software and hardware have a limited life span, the “perpetual” nature of a perpetual license is somewhat illusory and vendors will not support out of date versions beyond a certain point.
Because the customer’s sensitive data will likely be stored on the vendor’s system (or on the system of the vendor’s cloud provider, due diligence and contractual protections such as security warranties, security audit rights, third party security certifications, data breach requirements and cyber insurance are crucial.
Perpetually licensed software is usually hosted by the customer (either on its own servers or through its own third party providers), so the customer will presumably have more insight into and control over the security. This sense of greater security may be illusory as legacy systems may not be up to date to protect against the latest cyber threats.
All good things come to an end. When a customer utilizes a subscription service, it needs to consider upfront how will it will transition off of that service, even though it is unlikely to know what the replacement service will be or how far into the future the need will arise. Here, it is key to think through and negotiate contractual protections to ensure as smooth a transition to a future service as possible, such as the ability to easily export all key data in a useable form. Also, it SaaS providers may prevent access to data if the customer is in breach, giving the provider great leverage. Although some customers may ask for a source code escrow in the event the provider defaults or goes out of business, this rarely makes sense in a SaaS solution.
With a perpetual license, the same questions arise, as no software or system will be used “forever”. The protections needed here will depend on how and where the data is stored, and what internal capacity the customer has to access the data without support of the licensor. If the customer does not have access to source code, it may seek to have the provider put the source code in a third-party escrow account, along with documentation, so that the customer can access it in the event the vendor defaults or ceases to operate.
So which is better? The answer to this question should, I submit, be primarily driven by business, rather than legal, decisions. As I have shown, each option carries with it different contractual implications that need to be considered by both the vendor and the customer. Although there are a range of negotiation options to address different concerns within each model, they are not the same. Subscription models, with time-to-launch, pricing, and other benefits, will not appeal to all customers, and customers should not expect providers of subscription services to offer bespoke software development and implementation services for the customer.