The article below appeared in the February 2009 issue of Technology Transfer Tactics. Click here to subscribe.

By Dr. Mahshad Koohgoli, CEO, and Dr. Sorin Cohn-Sfetcu
Protecode, Inc.
Ottowa, ON

Technology managers insist on efficiency through re-use of already written and proven software code — be it internally generated or acquired from 3rd parties — rather than rewriting every line of code from scratch for each project. Typically, many code files are already available internally, and even more can be downloaded from Open Source libraries or acquired from 3rd party developers at a fraction of the cost and time it would take to do it in-house. Code search on the Internet has become as easy as finding any other information.

Open Source code is particularly attractive because it has grown exponentially in functionality, richness and stability, while perceived to be available at no monetary cost. However, Open Source software is governed by a complex variety of license regulations and conditions for use which require expert interpretation.

Unfortunately, most technology transfer projects (and even fully finished products) suffer from a lack of proper record keeping, especially when it concerns the software aspects. In universities and large R&D organizations, this problem is exacerbated by the fact that technology development occurs over several generations of developers (some of them transient students) with little training in, or commitment to, proper Software IP Management (SIPM) and record keeping. Most record keeping, if done at all, is manual, time-consuming, prone to errors, and largely unappreciated.

While good software development practices have evolved over time to include systems for checking syntax, managing software versions, tracking software bugs, etc., certain standards and best practices common to structured hardware development have yet to be adopted for software development. These include:

• An approved vendor list that contains the approved components and licenses, including commercial terms, vendor history, version, pricing, etc., such that a developer may select components freely from the list without concern;
• Automatic notification in case attempts are made to use code with unapproved licenses or code modules that are governed by incompatible licenses;
• A Bill of Materials (BoM) that fully records the components ending up in the final product, with details to enable production, determine costs, comply with export rules, track vendor upgrades, and other post-design activities.

These advanced practices need to also be applied to software development processes in order to achieve proper SIPM, enable organizations to achieve more effective management of their software assets, and streamline the tech transfer and commercialization process.

Best practices defined

The critical factor driving the economic value of SIPM is the effort, and hence the time interval, required between the time when IP issues are detected and when they are fixed. The earlier in the process those external IP obligations are detected and managed, the less expensive it is to address and fix them. After-the-fact corrective measures result in wasted resources required to remove the offending code, identify a replacement 3rd party code (or worse, rewrite the code internally), and make changes to the Application Program Interfaces (API) in order to fit the new code in the software. The time required for these tasks can impact the commercialization value, and in extreme cases can scuttle a commercial engagement altogether.

The best approach is making the IP management an integral part of your TTO’s software development and Quality Assurance (QA) processes. Automatic tools which minimize requirements for training researchers on IP matters are preferable, as these automated tools should be easy to adopt and without disturbing the normal creative development process.

Policies and compliance

TTO managers should work with legal counsel to develop appropriate software IP policies and establish a process which ensures IP compliance and downstream safeguarding of IP rights, while enabling constructive use and adoption of Open Source or 3rd party software. A sound IP policy must result in an effective list of approved software vendors, together with acceptable external-content license attributes and IP licenses. The policy should specify:

• What is allowed and what is restricted;
• What to do if a piece of code with an unknown license is desired;
• What to do in case of unknown code;
• Potential distribution restrictions, including export rules (which software goes into which product sold into which country).

Setting up a software license policy is not trivial, and requires educated input from legal, business and technical perspectives. Ideally, your policy should be centrally defined, easy to enforce, and allow for tracking compliance as development proceeds. It is quite possible, particularly in larger organizations, that you may adopt different IP policies for different projects. Any automated solution deployed to manage software IP should therefore recognize multiple IP policies and manage each project accordingly.

Retrospective code mapping

The next step is for the TTO to establish a map of the existing (legacy) code in the institution and ensure that it complies with the IP policy. This can be done by engaging expert teams to perform an IP audit or by using automatic Enterprise IP Analyzer tools to perform the code mapping.

There are several such tools available in the market from companies like ours as well as BlackDuck, Palamida, and others. These are retrospective tools which establish the IP pedigree of existing code by analyzing the code and decomposing it into modules and matching against extensive databases of known software. If any of the code components violate the established IP policy, it is then necessary to: a) mark the code clearly in the organization repository; and b) in extreme cases, remove or otherwise correct the code attributes. This may be very expensive in the case of code written by previous generations of developers, particularly in the absence of good records.

Preventive steps

To prevent problems from arising in the first place, your TTO should work with research managers to embed the SIPM process as an intrinsic part of your organization’s IP development and QA processes. This can be done by using Development IP Assistant tools, which unobtrusively operate at each development workstation. These automatic tools detect and log each piece of code brought by the developer into the project in real time. The code pedigree is determined by a number of techniques (searching for its “signature” against a database of known code modules, identifying which URL it came from, identifiers within the code itself, etc.). The tools then record each piece of code in an overall project code map.

The automated SIPM tool must check the licensing obligations of the identified code against the IP Policy for that project and take appropriate action. Optionally, if the piece of code was not identifiable, or if it violated a policy, then the automatic tool allows the developer to provide comments, such as why the code was brought in, or where the code came from.

Properly integrating these tools, as well as IP Analyzer and IP Policy Admin tools, will result in a real-time, clean IP software development process with proper record keeping and an appropriate source code Bill of Materials for each project.

Automatic SIPM tools are now being adopted by both academia and industry, and their use is expected to accelerate in the face of enhanced demands for IP indemnification, Open Source enforcement of copyright infringement, and the need to reduce the costs and schedules of software-intensive technology development and commercialization.

Contact Koohgoli at 613-721-5936 or Koohgoli@protecode.com; contact Cohn-Sfetcu at 613-301-0066 or scohn@protecode.com.