Consider the following hypothetical (the names contained in which are entirely fictional):
Arthur Jones, Worldwide VP of Sales for eOS Corporation, a small start-up vendor of embedded operating systems, has worked hard for nearly six months to convince the world's largest manufacturer of microcontrollers, IMC, Inc., to adopt the company's flagship eOS product in all of IMC's high volume products. The commercial terms have been agreed upon and a letter of intent has been signed. The next step is to successfully complete IMC's supplier quality audit, required by IMC's procurement division. IMC's auditing engineers will visit eOS's development center in Bangladesh to observe the software development and QA processes and ensure IMC's stringent best practices are followed. As Arthur reviews the agenda for the upcoming audit, Arthur notices for the first time that IMC auditors will be inquiring as to eOS's "policies, procedures and processes for ensuring the integrity of the company's intellectual property, minimizing the risk of contamination and adverse third party legal claims, and maximizing the legal protection afforded to the company's products." Suffering a sudden attack of the sweats, Arthur phones his company's lawyer and asks him to "draft something up quick …!"
Software companies are frequently the subject of stringent supplier quality audits prior to being selected by their customers. Oftentimes software supplier selection criteria for major OEMs includes successful completion of an onsite inspection in which a team of software or process engineers inspect the supplier's software development and quality assurance processes, such as adherence to the software capability maturity model (CMM), extreme programming methodologies, ISO, or the like. Frequently suppliers are questioned as to their compliance with information security standards or practices, such as ISO 17799.
With increasing frequency, these companies are now demanding to include within these audits a review of the developer's internal intellectual property rights policies. Proliferation of infringement lawsuits, the ever-increasing costs associated with litigating or settling such claims, heightened prevalence of open source licensing regimes, and peer-to-peer distribution mechanisms, among other factors, have all contributed to a heightened awareness of and sensitivity to the legal risks associated with software development, and a concomitant heightened level of scrutiny for software suppliers.
Of particular importance are external source code intake policies, clean room development procedures, and technology use and confidentiality policies. It is now expected that software companies have well-documented and consistently applied policies which ensure adequate protection and optimal management of IP assets, insulate against the risks of contamination, particularly in the area of open source software, and impose discipline in the manner in which software engineers license in or introduce external code into the companies' products. These IPR reviews can oftentimes rise to level of scrutiny normally reserved for M&A due diligence.
Failure to have these policies and processes established, documented, and fully implemented early in a software company's growth cycle can prove to be a significant impediment to satisfying these quality audits, and could as a result foreclose significant business opportunities. OEMs would not look favorably upon a software company's reactive and post hoc establishment of such policies as a result of the OEM's auditing conditions.
Such policies should at a minimum consist of the following:
Arthur Jones, Worldwide VP of Sales for eOS Corporation, a small start-up vendor of embedded operating systems, has worked hard for nearly six months to convince the world's largest manufacturer of microcontrollers, IMC, Inc., to adopt the company's flagship eOS product in all of IMC's high volume products. The commercial terms have been agreed upon and a letter of intent has been signed. The next step is to successfully complete IMC's supplier quality audit, required by IMC's procurement division. IMC's auditing engineers will visit eOS's development center in Bangladesh to observe the software development and QA processes and ensure IMC's stringent best practices are followed. As Arthur reviews the agenda for the upcoming audit, Arthur notices for the first time that IMC auditors will be inquiring as to eOS's "policies, procedures and processes for ensuring the integrity of the company's intellectual property, minimizing the risk of contamination and adverse third party legal claims, and maximizing the legal protection afforded to the company's products." Suffering a sudden attack of the sweats, Arthur phones his company's lawyer and asks him to "draft something up quick …!"
Software companies are frequently the subject of stringent supplier quality audits prior to being selected by their customers. Oftentimes software supplier selection criteria for major OEMs includes successful completion of an onsite inspection in which a team of software or process engineers inspect the supplier's software development and quality assurance processes, such as adherence to the software capability maturity model (CMM), extreme programming methodologies, ISO, or the like. Frequently suppliers are questioned as to their compliance with information security standards or practices, such as ISO 17799.
With increasing frequency, these companies are now demanding to include within these audits a review of the developer's internal intellectual property rights policies. Proliferation of infringement lawsuits, the ever-increasing costs associated with litigating or settling such claims, heightened prevalence of open source licensing regimes, and peer-to-peer distribution mechanisms, among other factors, have all contributed to a heightened awareness of and sensitivity to the legal risks associated with software development, and a concomitant heightened level of scrutiny for software suppliers.
Of particular importance are external source code intake policies, clean room development procedures, and technology use and confidentiality policies. It is now expected that software companies have well-documented and consistently applied policies which ensure adequate protection and optimal management of IP assets, insulate against the risks of contamination, particularly in the area of open source software, and impose discipline in the manner in which software engineers license in or introduce external code into the companies' products. These IPR reviews can oftentimes rise to level of scrutiny normally reserved for M&A due diligence.
Failure to have these policies and processes established, documented, and fully implemented early in a software company's growth cycle can prove to be a significant impediment to satisfying these quality audits, and could as a result foreclose significant business opportunities. OEMs would not look favorably upon a software company's reactive and post hoc establishment of such policies as a result of the OEM's auditing conditions.
Such policies should at a minimum consist of the following:
- external source code introduction and management policy: procedures to avoid or minimize the risk of external source code being introduced into the software company's products without authorization or in violation of licensing terms, which include a process for legal review of licensing terms and inbound licensing "playbooks" or guidelines;
- clean room development procedures: a formalized and systematic process description, consisting of clear and precise rules regarding staff segregation, network management, access logs, management audits, etc.;
- technology use and confidentiality policies: best practices and rules regarding use of company technology and IP assets and protection of company confidential information and trade secrets; and
- IP asset management policies: systems for tracking, clearing, identifying and protecting the company's patent, trade secret and copyright assets.
Posts
No comments:
Post a Comment