By Adam Atlas
Attorney at Law
Opportunities abound to automate numerous processes and migrate various pieces of business operations to cloud services. In plain English, much of what businesses do is now being uploaded to the cloud through an ever-growing selection of apps, platforms and systems.
While programmers are in high demand, they need direction from business visionaries who see an untapped opportunity for data storage and processing for a specific niche of merchants or other users. Under the right conditions, new apps and platforms often become the subject of licensing, partnership or other acquisitions that help the developers draw value from their hard work in creating the product.
The Green Sheet proposed the idea of a series of three columns that focus on this part of the payments industry, viewed from a legal perspective. This first article in the series focuses on the ground level. What can a developer do—right at the starting blocks—from a legal perspective to add value to their project?
Ironically, some of the most important and far-reaching legal work in payment application or platform development is done at a project's outset. The following are all legal themes that should be addressed—or at least discussed—at a project's inception.
This helps with selling the IP at a later date. It also helps to insulate the ISO business on the one hand, and the IP development business on the other hand from the liabilities of the other.
Once upon a time, developers created products and licensed them for a fee. That legacy assumption is not necessarily the best for the model you are building. Freemium licensing, open source licensing or other forms of deploying a new product might—in the bigger scheme of things—be preferable to a classic model of building and licensing.
The key takeaway here is that developers in the payments space should be open minded and ready to smash their original assumptions concerning pricing and revenue. Failure to keep an open mind on this topic may result in turning down what appears to be a bad deal—but is actually a foot-in-the-door for a much larger opportunity. Also, the pace of change in blockchain and other payments-related technologies may likely favor survival of the flexible.
Assigning intellectual property rights after a product has been created is a disaster. All persons involved in the development of a payments product should sign suitably drafted employment or independent contractor agreements that each include intellectual property rights assignments.
These contracts are the legal building blocks of the product that will be created. Without them, the asset for licensing or sale is wobbly.
Developers may be tempted to pinch code from a previous project to save time. Don’t. If the finished product contains code that was copied without permission, that defect could haunt the product forever and even result in its destruction. If a finished product becomes the subject of an IP-violation claim by the person whose code was copied without permission—even if the developer wins the case—the claim could waste time, attract negative publicity and also shake the confidence of investors and clients.
Nothing is better than owning all the code to your product. Clients, partners and investors will all want to see this and will reward the developer accordingly. Ensuring that the code has not been copied requires effort on the part of the company carrying out the work. It also requires a degree of trust in the individual programmers.
Not everything is patentable, but for a novel new product, it’s worth running patent searches with an IP lawyer to see if there is room to file a potentially winning patent application.
Don’t wait until the product is publicized. Indeed, novel ideas and the search for patentability of those ideas must be done with the utmost confidentiality, otherwise the developer risks losing the patent rights altogether.
If it turns out the product is not patentable, that’s not the end of the world; there are plenty of unpatented technologies that have been immensely rewarding for their creators.
When a child builds a sand castle on the beach, that castle is the whole world for them at that time. When building a product in payments, be prepared for the product—in an instant—to occupy the whole beach or all beaches. Instruct programmers to build with an eye toward growth and flexibility. Cloud hosting services like AWS are built to accommodate this kind of thinking.
And flexibility should pertain not only to size, but also to features and functionality. Some licensees, buyers and investors will see a particular utility in your product that you might not have seen yourself. Be prepared for your groaner feature to be another person’s valuable treat.
The points listed above each have a legal component, but they speak to a greater aim: the goal of owning something unique to sell. 
In publishing The Green Sheet, neither the author nor the publisher is engaged in rendering legal, accounting or other professional services. If legal advice or other expert assistance is required, the services of a competent professional should be sought. For further information on this article, please contact Adam Atlas, Attorney at Law via email at atlas@adamatlas.com or by phone at 514-842-0886.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
