I hope you’re all aware of my book The Software IP Detective’s Handbook: Measurement, Comparison, and Infringement Detection. It’s the first book on Software Forensics, a field that I pioneered at Software Analysis and Forensic Engineering and Zeidman Consulting. Whereas Digital Forensics deals with bits and files, without any detailed knowledge of the meaning of the data, Software Forensics deals with analysis of software using detailed knowledge of its syntax and functionality to perform analysis to find stolen code and stolen trade secrets. The algorithms described in the book have been used in many court cases. The book also describes algorithms for measuring software evolution, particularly as it relates to IP changes.
If you are a teacher, this is a great time to incorporate the materials in the book into your courses on software development, intellectual property law, business management, and computer science. There’s something for everyone in the various chapters of the book. Your students and you will be at the forefront of an important and very new field of study.
If you’re interested, please contact me.
My book on software intellectual property, a labor of love (and hate) for the last two years, has just been published by Prentice-Hall. The book is intended for several different audiences including computer scientists, computer programmers, business managers, lawyers, engineering consultants, expert witnesses, and high-tech entrepreneurs. Some chapters give easy-to-understand explanations of intellectual property concepts including copyrights, patents, and trade secrets. Other chapters are highly mathematical treatments describing quantitative ways of comparing and measuring software and software IP. The first chapter of the book outlines which chapters are most important for the different audiences.
Overall the book covers the following topics:
- Key concepts of software intellectual property
- Comparing and correlating source code for signs of theft or infringement
- Uncovering signs of copying in object code when source code is inaccessible
- Tracking malware and third-party code in applications
- Using software clean rooms to avoid IP infringement
- Understanding IP issues associated with patents, open source, and DMCA
You can purchase your copy from Amazon.com here.
You can now run CodeMeasure to graph the growth of your software project development effort over multiple versions of the software. CodeMeasure uses the Changing Lines of Code (CLOC) method to calculate the growth. The graph that CodeMeasure produces illustrates various CLOC measurements. An example is shown below.
Now there is a caveat (we do need to make a profit after all). You can examine the graph and take a screen shot of it, but you can’t save the results to a spreadsheet without a paid license. The good news is that a license is only $500 for a 1-year unlimited license. You can download CodeMeasure here and purchase a license here. This way you get to try out CodeMeasure and see how the results can help you measure your software development effort.
Last month we announced CodeMeasure, our new standalone tool for measuring software growth. This month we announced the release of CodeSuite 4.0 that includes CodeCLOC for measuring how software evolves across versions of code. CodeCLOC uses the same algorithms that were implemented in CodeMeasure and that were developed for the landmark software transfer pricing case Symantec v. Commissioner of Internal Revenue.
You’re probably wondering what is the difference between CodeMeasure and CodeCLOC. CodeMeasure is a simple, inexpensive program for generating the CLOC measurement statistics for multiple versions of a program. CodeCLOC, intended for litigation, compares only two versions of code but produces a detailed database of results that can be further filtered and analyzed using CodeSuite or your own custom tools. The results from CodeCLOC can be presented in court and the CodeCLOC database can be presented to the opposing party for verification.
CodeSuite 4.0 also has a few other nice features including a revamped user interface. There’s also a new function to generate statistics from any CodeSuite database and the command line interface has been enhanced for integrating with other programs. CodeSuite 4.0 is available for download here and can be purchased on a term license or project basis. CodeCLOC is priced at $20 per megabyte. A one year term license for CodeSuite is $100,000.
SAFE has just introduced its latest product called CodeMeasure™ that can measure the growth of software. Unlike our other products, this one is intended for software developers (look for a litigation version coming soon to CodeSuite). The tool is based on the technique that Zeidman
Consulting developed for the case Symantec v. IRS that we call the Changing Lines of Code (CLOC) method of measuring software changes. It worked pretty well in the Symantec case to help calculate software transfer pricing, and saved Symantec over $500 million in taxes.
We have a whole new website about the product, designed for software developers, at CodeMeasure.com. Check it out and let me know what you think of the product and the website.
Forrester Consulting just put out a report that I found interesting. According to Forrester, chief information security officers (CISOs) face increasing demands from their business units, regulators, and business partners to safeguard their information assets. Security programs protect two types of data: secrets that confer long-term competitive advantage and custodial data assets that they are compelled to protect. Secrets include product plans, earnings forecasts, and trade secrets; custodial data includes customer, medical, and payment card information that becomes “toxic” when spilled or stolen. Forrester found that enterprises are overly focused on compliance and not focused enough on protecting their secrets. Forrester’s key findings are the following:
- Secrets comprise two-thirds of the value of firms’ information portfolios.
- Compliance, not security, drives security budgets.
- Firms focus on preventing accidents, but theft is where the money is.
- The more valuable a firm’s information, the more incidents it will have.
- CISOs do not know how effective their security controls actually are.
Download the report to report to get the details.
There are a lot of unanswered questions about source code, and we want to work with you to figure them out. We realize that currently accepted algorithms for analyzing, comparing, and measuring source code leave a lot to be desired in many cases. Also, there are a lot of techniques that have never been studied on large bodies of modern code. For example, measurement techniques developed in the 1970s were probably tested on assembly languages and older programming languages like BASIC, FORTRAN, and COBOL. Do they still hold on modern object oriented languages like Java and C#?
If you have a research idea relating to code analysis, and you can use the SAFE tools, let us know. Email Larry Melling, VP of Sales and Marketing with your ideas. If they pass our review process you’ll get free licenses to our tools, free support, and help getting your results published. This could be the beginning of a beautiful friendship.
My consulting company Zeidman Consulting worked on a large tax case last year. For reasons involving the labyrinthine regulations of the IRS, it was important to understand how much of the IP of a software program had changed from the time it was first developed ten years ago, through subsequent revisions, until the current version. In the current version, IP remaining from the first version was taxed at one rate while IP added subsequently was taxed at a different rate (this is a simplification based on my limited understanding of tax law). There was a lot of money at stake.
Previous methods of measuring code involve counting lines of code. However, that’s a very poor estimate. Consider an example where an entire function consisting of 10,000 lines of code is replaced with a more efficient function requiring only 9,000 lines of code. Simply counting lines would tell you that there was a net reduction of 1,000 lines of code, which could incorrectly be interpreted as a reduction in IP. We realized that we could use CodeDiff and FileCount to compare lines of code to find the number of lines of code that continue from one version to another, the number of lines of code that are changed, and the number of lines of code that are added. Plugging these values into a well-defined spreadsheet allow you to graph this measure of changing lines of code (“CLOC”) over time. The actual valuation of the initial version of the software is a complex process better left to financial analysts, but the CLOC method provides a great way to measure the changes in value.
You can read more about CLOC in the article by Nik Baer and me in Intellectual Property Today entitled Measuring Changes in Software IP including a measurement of the Mozilla Firefox open source project.