When a technology solution gets air under its wings and sale volumes rise, its provider may become the target of an alleged intellectual property infringement claim. In another context, where an ERP system is developed through an agile software development model, the customer may become disappointed by its functionalities, a delayed deployment day or an increased price tag – or in the worst case – all of the foregoing.
Further, when a corporation buys software licenses for its own internal use, the license audit may reveal an unpleasant surprise regarding unlicensed excess use of the software and the corporation may face a damage claim for the unauthorised users. Or, alternatively, when a company acquires software assets through a technology transaction, suddenly its use may be restricted by prior encumbrances not anticipated in connection with the acquisition. Finally, “out of the blue” a company may receive a claim from a private person regarding breach of privacy rights due to leaked data stored in the system the company was not even aware of.
What is the common denominator for these issues?
Know your code
The answer to the above question may be potential lack of understanding of the code base as well as rights and obligations pertaining to it. While in hindsight it may be easier to see what should have been done in order to avoid the hassle, the essence is to understand – already in the planning phase – the crucial elements of the matter as well as dependencies within them. What the crucial aspects are varies of course depending on the case: As to commercialisation of a technology solution, you must ensure adequate transfer of rights from employees or other inventors and creators under contract and law. As to agile development of a software system, you must understand which requirements get specified as features of the system and how the development model works, and track the progress in accordance with the contract. As to licensing of software for the organisation’s internal use, you must understand what licenses you need, for what purpose and how many. As to software assets in a technology transaction, there really is no short cut: you must do the due diligence and identify what intellectual property rights are relevant for the system, and who holds them. Finally, as to avoidance of privacy rights, the key is to understand – in a similar manner as to money flows – where the data comes from, where it is stored and where it is transferred. Simple, right?
Not quite, as the complexity comes from the vast amount of legal issues (yet) lacking a simple resolution.