Say you’re a software developer and your customer wants to buy your app, do you know what you should be thinking about when selling software? Here are a few contract tips:
Can you legally sell your app?
Unless you have developed the code for the app from scratch and haven’t used any previous code of your own or any third party code, your app is likely to be a composite of code you’ve written in the past for other projects and which may even form part of your general toolkit.
You may also be using code from other developers which could be licensed under a variety of licenses, including open source licenses like GPL and BSD.
When you sell something, you generally transfer all the rights in the thing to the purchaser. You have to have the rights to transfer in the first place and if you don’t own all the rights in that thing you are selling, you can’t really sell it to someone else. If you attempt to do that, you’ll find yourself with a contract you are legally unable to comply with and that is a problem.
Tip 1: Check the rights you can transfer in a sale first.
Know what you are selling
This sounds pretty obvious but it’s a more complicated question that you may have thought. From your perspective you’re selling your app but what is that app, really? Are you selling the finished product alone or does your customer want the source code too?
Many software purchasers want the source code because they are concerned that if they don’t have the source code, they could find themselves in a pickle if the app breaks and they can’t reach you to fix it. It is basically a business continuity concern and the more your customer relies on the app to operate its business, the more important have access to the source code will be.
The challenges with selling the source code include disclosing your secret coding sauce that makes your code so valuable. Those trade secrets could give your customer or even a competing developer who encounters the code later an additional competitive edge over you. Another challenge is that selling your source code outright could have an impact on other projects which leverage elements of that source code because you will have far fewer rights to use that code once it is sold. This means you have to consider the impact on your obligations towards existing customers too.
Tip 2: Carefully consider precisely what you are selling and what the implications are of selling it to your customer.
Clearly define what you are selling
This also sounds obvious but it isn’t. In your mind you are selling an app but how would a person outside the deal be able to identify what you are selling, objectively? Is the app totally self-contained and in a box that can be easily identified? Chances are it may be a bit more complicated than that.
The reason why you need to be able to clearly define what you are selling is twofold: your contract needs to be clear on this and your customer’s expectations of what it will receive from you must correspond with your understanding of what you are selling.
How you define your app may depend on the nature of the app but here are a couple ideas:
- Include detailed and app-specific functional specifications;
- Depending on the app, possibly use a hash derived from the app’s code as a sort of fingerprint to identify it;
- When describing the software’s functionality, avoid generic descriptions that could apply just as easily to software you are not selling;
- Consider versioning your software and referencing specific versions being sold, if appropriate.
Tip 3: Define or describe the software being sold very clearly to avoid any confusion later.
Consider alternatives to an outright sale
A sale may not be appropriate because of its implications. Often a license agreement meet your customer’s requirements and help you avoid the problematic consequences of a sale so don’t be afraid to suggest that instead.
Licenses can be customised to suit most requirements and can, for example, be exclusive to the customer. The benefit of that sort of license is that the customer has the comfort of knowing you won’t make that software available to someone else and you retain enough rights to meet your other obligations.
If you go ahead with a sale and your customer insists on source code too, consider placing the source code in escrow with a trusted escrow agent with specified conditions which would trigger the source code’s release. Those conditions may include your business closing, you and your team failing to respond to requests for support for a period of time or some other set of conditions that would address your customer’s concerns.
If you sell your source code along with your app and you require elements of the source code to meet existing obligations to other customers or based on other licenses you agreed to, you may want to make sure you either withhold certain rights for yourself or license what you need back from your customer as part of the deal.
Tip 4: A sale may not be the best deal type and even if it is, this isn’t a one size, fits all approach. Customise the deal to suit everyone’s requirements.
Law is code too
Just because your sale agreement is a legal construct doesn’t mean similar rules you apply to your code don’t apply. Work with your lawyer or legal advisor to develop a contract that works properly and doesn’t leave you with bad dependencies and worse consequences.
Look at your contract as an app in its own right. Does the code make sense and does it function effectively given all the constraints and requirements?
Update (2014-06-10): Something else to bear in mind is the new VAT on digital goods sales. Developers who make more than R50 000 will have to register with SARS to pay VAT. It’s a pretty low revenue threshold.
Take a look at this article on MyBroadBand titled “Get ready for VAT on e-books, apps, digital music” for more information about how this affects you.