Negotiating Source Code License

Negotiating Source Code License

In my years selling enterprise software to multinationals, I have learned a lot about software licenses.  Although the current trend is more towards cloud subscription (used to be called ASP, SAS etc), there are still situations where source code licenses are used.  In this article, I would like to highlight a few points in a source code license arrangement.

Software License 101

Cloud software is easy to understand.  You as a customer, pay on a monthly or annual basis to use a software that resides on the vendor’s software.

In the more traditional model, where you “buy” a piece of software, install it in your computer and use it, you are actually just buying the right to use a copy of the software.  You have not bought the software IP in any ways.

The most common type of software license is called “perpetual license”, where the user gets the right to use the copy forever.   In the Enterprise Software (ERP) world, the software vendor usually charges an annual maintenance fee (20% of the license fee is quite common).  Customers who pay the maintenance fee will get software updates, as well as on-going technical support.  Invariably, the price of the software is proportional to the number of users.  I have also seen software price based on the size of the company (in terms of annual revenue).

It is partly because of the rather high annual maintenance fee that the Cloud model is becoming popular, even for large companies.

Source Code Licensing

In some situations, the vendor will pass the source code to the customer.  Usually this happens when customer also has strong in-house programming capability, and wants to be able to modify the software themselves.

And because the customer will have modified the software, maintenance cannot be done by the vendor.  There is no reason to collect on-going maintenance fee.

As a customer, or as a developer who has crafted a beautiful piece of code, when entering into such a contract to buy/sell source codes, there are several key points to consider:

  1. Notification of source code modification
    • This can become cumbersome.  Since the source code is sold “as is”, there really is no point to notify the vendor every time a change is made.  But this seems to be quite a standard clause.
  2. Transfer of source code to third parties
    • Rightfully, the vendor would not allow customer to pass on the codes to others.  You are only allowed to keep your codes for your own use.
    • However, there may be situation where customer would use outside party to maintain or update the codes.  You want to make sure that the contract language allows for such situations.
  3. Limitation on user count (indirect method)
    • In mainframe computer days, it was customary to specify the power grading of the computer used.  The idea is that, stronger computer could support more users, and the price for the software should be higher for implementations that supports more users.  Consent from vendor is needed before customer can move the software to a more powerful machine.  Translate: pay more before you upgrade the hardware.
    • Nowadays it would seem unrealistic to specify machine type or power grading.  Technology is changing too quickly.  For example, nobody could anticipate the advent of virtual machines.
    • An alternative is to price the source code according to number of end users or revenue generated by the source code.  This would require a mechanism to audit the usage.

Source code sales is inherently complicated.  Both sides should communicate clearly prior to committing.    I have successfully collected a rather large license fee, because customer changed to a bigger machine, and have outsourced maintenance of the code to a third party without our consent.  Legally, they have breached the original contract.  And their right to use the source code is void, meaning they need to shut down.  In the end, the customer had to pay us an additional license fee to rectify.  As the contract was signed many years ago, and not by the current person in charge, you can imagine my customer was not very happy to pay.

If you are a developer, you may want to make sure you have a way to benefit from your invention as your customer grows, in particular because of using your software.

It is not unreasonable to compare software with pharmaceutical IP – the inventor of a new drug gets income for every dose sold.  Of course it depends on your bargaining power: how essential and contributing the software is to your customer.

If you are a customer, you want to make sure you understand the contract terms clearly, and communicate the potential cost consequence internally.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s