In times of mass customization, cloud computing and XaaS (anything-as-a-service), software and related service vendors and customers are increasingly discussing about their rights. IT industry is transitioning into new business models, moving into un-charted territory and new rules need to be invented. While standard package software solutions are moving off-premise, IT vendors are investing heavily in R&D and trying to find ways to transform their services into products or provide solutions as services and finding ways to secure their competiveness in a future which is hard to navigate.
Protecting rights to intellectual property has been a routine discipline, but when business models and digitalization develops, the typical roles of licensor and licensee do not necessarily apply in the long term or are at least blurred. There is a very true possibility that both vendor and customer are trying to exaggerate and over-protect their rights, because neither party knows better – ‘just in case’ is the safest bet to avoid the hazard of vendor lock-in.
Vendor lock-in is as old as IT itself. It refers to a delivery technique which often contractually forms a permanent dependence on a vendor. Vendor lock-in creates barriers to market entry (possibly resulting in antitrust action against a monopoly or a vendor with exclusivity rights in a market) and substantial switching costs for the customer. In worst cases, customers are rendered incapable to transition to other vendors.
A vendor lock-in is in most cases a trap. They are woven into agreements in ways which are not necessarily visible to the naked eye and even when discussed in negotiations, they are undermined by the vendor to avoid suspicion. The lock is typically connected to source code and makes no reference to service quality. When the customer falls out of love with the vendor, the vendor-lock prevents divorce. In extreme cases, lock-in terms even identify by name a single competitor or competitors who are intended to be locked-out.
At this point, it is important to differentiate intellectual property rights (IPR) with the typical vendor lock-in. In IT, IPR refers to protection by copyright and or trade secrets. It is quite understandable that when a developer invests in a creation which generates competitive advantage over competitors that it wants to protect its investment from commercial exploitation.
Business ethics should guide vendors not to build loyalty programs with contractual anchors which use e.g. IPR to disguise vendor lock-in. Even if this were successful, the amount of bad-will and loss of brand value will surpass any long-term gain it might seemingly bring.
Lets look at the basics. Copyright law and IPR should protect the software developer from the situation that the customer or third party re-sells or otherwise infringes damage the developer’s business with regards to the unauthorized use and exploitation of the source code. When it means that no other vendor is allowed to further develop or upgrade the customer’s solution but the original developer itself, IPR becomes a questionable vendor lock-in.
In my opinion, ethical software IPR protection occurs when terms are transparent, discussed well in advance and protection covers the software solution, not the associated services. Furthermore, the motives need to be understood and certain principles should be appreciated by both licensee and licensor.
One of these principles is IPR’s connection to pricing. If the licensee wishes to purchase the IPR, this comes with an obvious and additional price – this is for the simple reason, that the if the vendor sells the user rights including IPR, the vendor terminates its opportunity to repeat-sales and needs to re-develop the solution from scratch. The latter often equals the development cost of a customer specific delivery. And if a vendor develops software as their primary business, it should not even be negotiable that the vendor should be obliged to hand over (even at a price) the core of their livelihood.
Another principle, or rather matter-of-fact, is that the value of source code usually expires over time. Code usually renders itself useless as the software develops. Protecting IPR forever again creates a vendor lock-in which is largely exaggerated.
Where there might be some ambiguity, is customer specific development where there should be more latitude to discuss e.g. shared rights or measures of protection where the customer retains rights to solutions which could be considered trade secrets or where competitive advantage is at risk if exposed to third parties.
It would be great to see that IT industry as whole would adopt a more open attitude and begin to provision ethics-as-a-service, free of charge and proactively. Not everything has to be open-source, but my claim is that 99% of the customers have no dark intention to damage their software developers’ livelihood by exploiting the software code with commercial gain in mind. If moral code of conduct and solid ethics are considered by someone as a cost, they may have a calculable payback time, but often the returns are long-lasting and they build trust. On the other hand, lack of thereof burns like gasoline – a quick puff and reputation goes up in smoke. The only thing that is left is long-term suspicion and lingering doubt poisons the entire industry.