[All consumer electronics, mobile and software companies have to in-source third party software – but the perils and complexities of managing that software are several, as the software moves through your organisation and out to the customer. Guest blogger Ã…se Stiller distills years of experience in software licensing in simple guidelines for managing 3rd party software]
Sourcing 3rd party software to be integrated in consumer electronics like mobile handsets is a complex affair. There are multiple challenges and threats, in a way similar to the multi-headed Lernaean Hydra, the mythical beast that Hercules fought in Greek mythology. But finding a Hercules to manage your mobile software issues is easier said than done – so is managing the challenges of complying with license terms that you have signed with third parties, as the software itself navigates through your organization.
The particular challenge I would like to draw your attention to in this article is the risk for unauthorized distribution or reuse of the third software.
It is easy to see the need to assess a potential supplier, but it is equally important to turn around and take good look at your own company’s ability to safely manage the responsibility, End-To-End
Whether you are developing a 2D game or a complete application framework putting together software products is not always as “Lego-like” an activity as we like to draw in block diagrams to management. In many cases bringing in 3rd party source code is the only viable alternative, but you must be sure that everyone dealing with the code knows what they are doing.- and you can´t very well ask all engineers to study the contract. Pardon my French but it’s often hard to ask engineers to “RTFM” or to be precise “RTFC” (C for contract).
It´s is hard enough to get the right code, at the right price, in the right shape delivered at the right time but you must also get it with the right terms to fit well into your own development process, not to have to burden developers with unnecessary restrictions and contract details. Sourcing of software is and must be a team activity. Only a true Hercules can deal with all the Hydra-heads single handed.
Staying above the line of software commoditisation Developing an application, game, application framework or any piece of software for mobile phones means adding unique and sexy features to a whole lot of commodity, and checking that nobody else gets there first. What was cutting edge technology two years ago is now all taken for granted – users don’t want to pay for Bluetooth or FM radio these days and 5 mega pixel cameras is slowly becoming the norm. The value line of software is increasing up the stack with each month going by.
For software companies, as new technology ceases to be a marketing differentiator and turns into standardized commodities, it becomes appropriate to share the costs for maintenance and further enhancements with competitors and partners in the same business. The easiest way to find this economy of scales is of course through sourcing software from Independent Software Vendors (ISVs) or by using software which comes under an open source license (e.g. Eclipse IDE and WebKit browser core).
Another good reason to source software is of course to get access to specific technology that you cannot, or cannot afford, to develop in-house. Some things are simply best done by experts, like preparing Japanese puffer fish and developing e.g. telephony modules for mobile phones.
In mobile phones as well as all other complex consumer electronics you will find a lot of common functionality developed and maintained by external ISVs. The type of components vary from highly visible functions like Web-browsers to completely anonymous drivers, and only very few suppliers will get their logo in a prominent place. A mobile phone would have to be the size of a car to allow for “NN-inside” stickers for all externally developed software components.
There may be many links in the chain between the original developer of a software component and end-user. A lot of the sourced components themselves come with software developed by others than the supplier, like e.g. open source parsers and specific security solutions, and the further away from the original owner of the IP the harder to keep track. A good practice is to make sure that such components are declared well in advance before you sign an agreement to source software, specifically if there are inherited restrictions or obligations pushed on to you and your customers. Make sure that the sourced software doesn´t come with an undetected Hydra-head embedded in the license. If there is Open Source with obligations to disclose code to end-users this will affect you or your customer, or your customer’s customer.
The perilous journey of software through an organisation Regardless of the reason for sourcing 3rd party software it is important to truly understand how the sourced component will be used in the internal development process, and how the component will be integrated with existing product. For example, there may be a need to distribute code to sub-contractors or pilot users, customers, additional development sites etc, during the development process . Your license must meet these needs and allow for that – or you must plan for an alternative way to work.
Deviations from standard development process may add to the overall cost for the sourced component, and must be taken into the cost/benefit analysis. Naturally you must not panic but maintain a healthy balance between the added cost to eliminate a risk and the weighted cost for an actual breach.
If the sourced component is self contained and easy to replace your worries are less, even with a un-permissive license. However with a less modular and more realistic dependency you need to be more cautious about handling the code.
A good way to reach an understanding of all your needs for re-distribution of a sourced component is by identifying the End-To-End journey for the software through your company. You will then be able to anticipate what distribution rights must be catered for in the contract, and to prepare for a change in the process if you cannot win these rights in the license.
Another benefit of such practice is that you will gain a better understanding of how the third party product is to be integrated with you product. You can describe the level of integration and understand how that will impact your negotiation, or choice of license for Open Source software.
The natural place for an end-to-end flowchart and for the description of the integration is in a Risk Analysis for the sourced component. Such Risk analysis should also include the standard commercial risks, market risks, legal risks etc – but that is a different subject.
Plan for the software’s journey There is no single solution to how to safely manage third party code through your development process; any solution must be case specific. Naturally it depends on the size of your organization and of how many will have access to the code, but it also depends on the level of integration with the rest of the product.
Based on the End-To-End flowchart and the license for the software, you can provide a plan for the management of the third party code; you can identify an owner of the code in all stages of development, and if necessary specify a hand over process between development units, and eventually the hand over to your customers. You can define specific rules for the code and provide solutions before the issue becomes a problem.
As an extra bonus you may also find and be able to eliminate conflicts between licenses – e.g. an Open Source license forcing disclosure of code and another license prohibiting such disclosure. Another Hydra-head down.
Information is King A development process is only as waterproof for the in-sourced 3rd party software as the team members who are involved in this process. By identifying the different units that will be involved with the third party component, you will be able to locate who needs to be informed about the rights and obligations that come with the component. Knowledge about the restrictions for the component must be available for all those who actually access the code, all the time.
A good way to achieve this is to keep a simple database where you register the third party IP included in the product, and specify rules for how the code may be spread and used. Access to the information in the database must be granted to all those who come in contact with the code and therefore you may not want to add the contract as such to the database. Do not confuse this with a contracts database; that serves a different purpose.
Information in this database must be easy to find, easy to understand and interpret and it shall clearly explain what you must and must not do with the code. E.g. if you can only distribute to subcontractors or development sites that have been approved in the contract, these subcontractors and sites shall be listed in the database and if you can only distribute binaries to customers that must also be easy to detect for anyone who might need to release code to customers.
It is, of course, crucial that the information in the database is always correct and updated. Therefore someone must be identified as the owner for the information. The owner of the contract is my first choice since that is the person with the most to gain on this; the one who will be hit by the Hydra if something goes wrong or have a smooth and easy day at the office when all the questions are answered by the database.
Do’s and Don’t of software sourcing. When you accept the responsibility and liability that comes with signing a software license for source code – Open Source or closed Source, you must not let price and liability totally overshadow the rights to use and distribute. Do your homework and get a good understanding of the intended use of the code, before agreeing the license terms. Analyze the risk and avoid problems further down the road by planning the management of the software End-To-End and publish the restrictions for the code where it is easy to find and to update.
– Get the team to help define the contractual needs for the sourced software. My experience is that insufficient or unclear license rights too often blocks engineers from doing their job. If you can get the engineering teams to help you prepare the sourcing better by providing relevant input to how your company will use the sourced component, you stand a far better chance getting the contract right from start, and it will save you from panic changes to both contracts and project plans.
– Educate all on a need to know basis. My experience also tells me that engineers in general don’t love contracts, or rules restricting their creativity, but they do need to know the “Dos and Don´ts” with the third party code they handle. Just putting rules in a database is probably not sufficient; a verbal run-through of the rules is a good support for the information in the database, and an excellent way to test if the database works for its intended audience. You will probably also learn if the rules set up for the third party IP is too restrictive or too complicated.
– Talk to all stakeholders. Sourcing of software is teamwork involving every department in your company – save possibly for janitors. It takes a team to find and fight all the heads of the Hydra. In other words; to provide all the input for the risk analysis leading you to a good license agreement and a safe passage for the software through your development process, you need help from all the stakeholders. Open Source is no different from any other third party software in this respect.
– Ã…se Stiller
[Ã…se has lived through the pains of licensing software both from the selling and the buying side of the cooperation as part of UIQ and Teleca, and has survived to tell the tale and educate the rest of the industry.]