Software distribution, or software reselling, is a vibrant market. It allows developers of clever and innovative software to tap into potentially vast networks of customers without having to invest in their own marketing machine or start a distribution network from scratch; it allows resellers to upsell new products to an existing network of clients and make a profit without having to set up their own R&D operation. However, for all its vibrancy, it is surprising how often the legal structures – and implications – of “reselling” are misunderstood or simply overlooked.

In layman’s terms, people understand the concept of “selling” or “reselling” software: licence fees are paid, and access to software is granted. However what this means in legal terms is far more complex. There are different legal models for “reselling” software, and getting the legal terms right – whichever model you are using – will be crucial for protecting IP and revenue stream. Using the correct approach and avoiding some of the common pitfalls could also be very important in ensuring that you don’t fall foul of competition law. In this article we highlight some of the common key issues and suggest some solutions.

Licensing structure – who does the end user contract with?

The layman’s model of “money is paid and access is granted” overlooks one of the key questions: who is actually granting the licence? The answer to this question determines the structure of the reselling contract, the risks under that contract, and the set of pitfalls which need to be considered and avoided.

So, is the distributor licensing the software to the customer in its own name? Or does it “license” the software to the customer on the developer’s paper?

Agency

If the software is licensed in the developer’s name on the developer’s paper, this is almost certainly agency and the IP model is actually quite simple – the licence is granted directly from the developer to the customer, on contractual terms set by the developer, and the reseller is simply acting as an agent who facilitates that sale and licence.

Nonetheless, there are still numerous issues and risks that need to be considered. For instance, are there any territorial restrictions on the agency? Are there market or sector restrictions? What level of exclusivity is being granted, if any? Is the developer reserving its rights to sell the software to the market directly? What controls are there around how sales are reported and commission calculated? Are there other agreements – whether agency agreements or otherwise – in place that this agreement would breach? What controls are there over what the agent can say about the software’s functionality and capabilities? And if the developer is not happy with the level of sales, what rights are there to terminate and go elsewhere?

These issues should all be considered at the outset of the relationship and drafted carefully into the contract, as they could have significant implications on the developer’s ability to exploit the value in the software outside this particular agency relationship.

Distribution

If, however, the software is licensed in the reseller’s own name, this is not agency but distribution. Resellers may often want to use their own paper and to license software in their own name so that, amongst other things, they can enhance and maintain their own brand, and protect the integrity of their own client relationships. However, reselling in this distribution model entails a number of considerations that are often overlooked.

Firstly, under the distribution model the reseller is in fact granting a sub-licence to the software, but this fact is often swept up into a very broad licence “to distribute, use and resell” the software, and/or ignored completely. What are the terms of the licence to the reseller itself? What should the reseller be allowed to do with the software? The principal right should be to grant sub-licences to its customers, and to carry out demos and testing as part of the reseller’s sales effort. The risk with a very broad licence is that (a) it does not mean much – if anything – in licensing terms, making it far more difficult for the developer to enforce their intellectual property rights in the software, and (b) there is potential for over-deployment of the software by the reseller – for instance within the reseller’s own business – without the full value of the software making its way back to the developer. The extent of these risks will obviously depend on the context of the relationship, but they should at least be considered as part of the contracting process.

Secondly, under this model the developer has no direct contractual link with the customer. In some respects this lack of contractual link with the end customer might appear to a developer to be something of a blessing, as it means that the reseller acts as a contractual buffer between the developer and the end customer in terms of breaches and liability. However, this is little comfort if the reseller has rights under the distribution contract to sue the developer for the losses that the reseller suffers at the hands of the end customers, and the reseller’s downstream contract gives the end customer unduly broad leeway to bring claims against the reseller for failures in the software.

The key here is that the contract between the reseller and the end customer is not just a contractual buffer, it is also a crucial method for controlling the use of the developer’s main asset – its IP in the software – and for restricting the developer’s ultimate liability for failings in those assets. As such, it may be very sensible to stipulate in the reseller agreement certain terms that have to apply in each sub-licence: without this stipulation, the developer is essentially trusting the reseller to put sensible terms in place with the end customers without any guarantees, and this could be quite a big risk. For instance, what is the scope of the licence that is granted to end users? Does the developer have a direct right of enforcement and/or termination against end customers? To what extent is the end customer’s liability restricted or uncapped for misuse of the IP? Are there sufficient express terms to prevent hacking, reverse engineering, and use of the software for illegal purposes? Is the end customer aware of any minimum hardware requirements? Is it clear to the end customer that the IP belongs to the developer, but that the customer’s recourse for breaches is primarily with the reseller? These are just some of the issues, and more sophisticated resellers will have these terms in their contracts anyway, but there is certainly no harm in ensuring that they are included in all the contracts that underpin the usage of the developer’s all-important IP assets in the wider world.

Pricing and competition law

The parameters around what the parties are allowed to do with pricing is another area where the two models differ.

Under an agency model, the developer is free to determine the price at which the software is to be sold to end customers (whether on a general basis or in relation to specific customers), and the reseller is paid a commission – often calculated on a percentage basis – for each licence sold.

Under a distribution model, there is a temptation for a developer to try to retain this freedom, but to do so may well be in breach of competition law. Reselling under the “distribution” model would count as a “vertical agreement” for the purposes of competition law, which amongst other things places a prohibition on “resale price maintenance”, i.e. where a manufacturer (= the developer) dictates the price at which the retailer (= the reseller) is to sell the product (= the software licence) on to the end customer, either on a general basis or in relation to particular customers. There are in fact some exceptions to this prohibition, but they are few and narrow, and the consequences of breaching the prohibition can be quite severe. To avoid this pitfall, the contract – and all the pricing negotiations – should be structured purely as between the developer and the reseller: in other words, the developer gets a fee of £X per sub-licence from the reseller, but what the reseller charges to the end customer per licence is entirely the reseller’s business.

Pricing and metrics

One of the most potentially costly issues to a developer in any distribution-style agreement sits on the boundary between the commercial and the legal: the metrics and drafting around what is being charged for the “resale” of the software. The key here is to be extremely clear in the concepts of what it is a developer is selling to the reseller, and what the reseller is selling on to the end customer, before the negotiations start on price.

An example: developer and reseller start negotiations and in principle agree a price of “£100 per licence”. Whilst appearing simple enough, this can open up more questions than it answers. Licence for what? Is the software to be charged out on a per-end-user basis, per instance, per server, per customer, or something else? If per customer, and one customer can have more than one end user – perhaps hundreds or even thousands of end users – how will the developer obtain the full value of its assets? If per server, how does this take account of virtualisation at the end customer level? If charging is based on usage levels, at what point is one licence “used up” such that the end customer has to pay extra, and what are mechanics of making that happen?

It is crucial that the drafting in this area is tight and unambiguous, but the drafting can flow easily if the thinking behind it is clear and comprehensive. The risk for a developer is always that it may in some circumstances be in a reseller’s interests to bundle the developer’s product in with other products that make higher margin so as to make those other products more attractive to clients, and if the commercials are not drafted – or thought through – with those risks in mind, then there is a real danger that the developer’s most valuable IP assets could be used as a marketing tool for the reseller, rather than creating a solid stream of revenue for the developer. Revenue sharing models are particularly prone to this risk, and minimum fees from reseller to distributor are always worth considering.

Software support

Contracts using the distribution model should be very clear about which party is to provide support for the software, and how such support is to be paid for. Often support is split between first, second and third lines, but the parties should also consider whether the support is to be white labelled as being provided by the reseller. Developers should consider asking that service levels or other standards apply to the parts of the support to be provided by the reseller, not least to help protect the reputation of the software in the marketplace. More importantly from a commercial perspective, the contract with the reseller should set out in precise terms the circumstances in which the developer will be entitled to charge extra for additional support. This is largely a question of defining scope: what is included within the support service to be provided as part of the licence, and what is therefore to be counted as “extra support” for which extra fees can be levied to the reseller.

Marketing support

Developers may often be asked to provide support and demonstrations in the context of the reseller’s marketing efforts. Again, the issue here is really one of defining scope, but to sign up to an obligation to “provide reasonable support” without defining scope or expressly setting up a mechanism for charging for these “professional services” could be very costly to the developer if, for instance, the reseller persistently asks for assistance in selling to clients in far-flung locations but the developer has no way of charging for its time and costs incurred in helping out.

Conversely, consideration should be given to the level to which the reseller is to market the software, under both distribution and agency models. This will be particularly pertinent where exclusivity is granted to the reseller, as the exclusivity narrows the other channels through which the developer can sell its assets: if the sales operation is not good enough, the developer might have nowhere else to go, so a termination right might be the best option.

Conclusion

The ease with which software can be disseminated and accessed, together with the fact that it is nowadays rarely an item in a box on a warehouse shelf, means that extra care has to be taken when making arrangements for selling it en masse. Getting the arrangements right, in a way that protects both parties’ commercial interests and fully recognises the intangible nature of the product changing hands, will always be in the interests of both parties in the long term; but to achieve this goal, detailed attention, and thought, will always be required.

• Share this blog

• Twitter
• Facebook
• Linkedin