Empirical Evidence of Why Software Patents Are Bad (or Good) – Part 1

I’ve written plenty about patents in the past, including a provocative post titled Abolish Software PatentsI was having a conversation with John Funk, a partner in Evergreen Innovation Partners, at the end of last year after a catch up lunch.  We got into a serious conversation about the fact that so much of the software patent good vs. bad rhetoric seems like it’s more about opinions, anecdotal experience, and agendas – rather than a comprehensive review of the facts.  So – we decided to take it up a level and see where the conversation went.

Now – John and I have some interesting history around this.  We have been colleagues (I was an investor in Exactis (fka Mercury Mail / Infobeat – his first company), adversaries (Infobeat sued a company I co-founded – Email Publishing – for patent infringement – which was eventually settled for $1 and a cross-licensing agreement between Exactis and MessageMedia (the company that acquired Email Publishing)), and once again friends and colleagues (I’m an investor in John’s latest company, Evergreen IP.)  While we’ve both struggled personally with an emotionally charged issue, we’ve ended up friends. 

Interestingly, given the wide range of experiences we’ve each had around software patents, we have pretty similar views.  So – John fired off a long email to me which I’ve edited and broken up into several posts with the following premise: What if we attempted to craft a social policy hypothesis that would defend the existence of software patents, and then we went about creating an experiment that would attempt to disprove that hypothesis?  Hmm – social science – disproving a null hypothesis – how academic!

Let’s begin with this: Patents in general, and software patents in particular, are a government conferred monopoly that rewards the public disclosure of a software method or program. The rationale for patents is anchored in (1) public disclosure accelerates innovation because future invention rests on prior patent disclosures (e.g., innovation is a chain that builds on prior building blocks), and (2) conferring a patent monopoly will encourage innovation that otherwise would not occur due to perceived risk/return (e.g., in absence of patents, competitors will trounce new entrants by rapidly copying; therefore monopoly is needed to be able to raise capital and take the risks).

More coming in part 2 – same bat time, same bat blog.

  • sigma

    I’m not happy with software patents and would be pleased to see them go away.

    For (1), accelerates innovation, is mostly nonsense. The solid foundations of innovation in software come from the research universities. Building on what is in the research libraries is much better than building on what is in the patent office.

    For (2), a patent monopoly will encourage innovation, is again mostly nonsense. In software, mostly can get decently good protection of ‘secret sauce’ just by use of trade secrets — i.e., just don’t tell anyone.

    The patent system depends on a lot of use of the legal system, and that is clumsy, slow, expensive, and unpredictable.

    ‘Innovation’ is mostly in small companies, and patents are mostly for big companies with deep pockets for lawyers. For small companies, software patents have little upside but a big downside from big companies wanting to license their portfolios.

  • Dave Jilk

    Trade secrets are notoriously difficult to protect and enforce in software. Anything a software engineer can understand well enough to keep it inside his/her head is not realistically protectable. As for innovation being mostly in small companies, that’s just not correct. Although “per capita” innovation is perhaps higher in small firms, large companies innovate constantly. Heard of Intel?

    The patent software system is indeed a mess, but it’s important to address all the issues if one is going to propose change.

  • Dave Jilk

    Are you going to fix the spelling of “empirical” in the title? It detracts from credibility…

  • sigma

    I can’t “address all the issues” and was responding just to software patents.

    I can’t give solid legal advice, or any legal advice. But, I’ve been around advanced, original software for a long time, have seen a lot, and have some opinions; since I have some advanced, original software, I need some opinions!


    “Trade secrets are notoriously difficult to protect and enforce in software. Anything a software engineer can understand well enough to keep it inside his/her head is not realistically protectable.”

    yes, it’s a problem. What great software idea cannot be understood well enough for someone to keep it inside their head? After all, someone had to dream up the idea, in their head, to begin with! Indeed, mostly advanced, original ideas are the work of just one person.

    If some technique is important for US national security and its great properties are broadly described, then, sure, the National Academy of Sciences (NAS) can put together a team and reinvent the ideas quickly. Such a team will be well informed on what’s known, where the fundamental unsolved problems are, what might be doable now, and how to proceed. For really outrunning the NAS on something important for US national security, f’get about it.

    Otherwise, for anything very advanced and original in ‘software’, the chances of the information technology business community reinventing the ideas at all quickly are from slim to none. In ideas in software, the business community is to the NAS like the junior high hoopsers are to the LA Lakers. So, a small company with some advanced, original work will have plenty of time to build a good customer list, brand name, and company and exit before anyone else in business will reinvent the idea and mount any significant competition in the market.

    About a competitor, too often the big company will say, it is a tiny company and we can forget about it, it is a medium sized company and responding to it would hurt our bird in the hand, or it is a big company and too big to beat. Do we have to name names from IT history? Telecom history?

    Again, for a small company, if have a good idea, then, first-cut, just don’t tell anyone. So, a founder-CEO may be the only one who knows. Inside the company, keep it locked up. For people who see the ‘recipe’ for the ‘secret sauce’, have non-compete agreements, etc. For the customers, have license agreements that forbid reverse engineering the code. Also maybe have some ‘code obfuscation’. Some Windows media security functionality may help. Or, just keep the code on in-house servers and never ship it to customers.

    So, company A comes up with advanced, new, powerful software idea X and uses it in their business. Two cases: Case (1), company A might get a patent on idea X. Then company B can get a copy of the patent and use the idea. Company A, then, has to discover that company B is infringing on the patent and bring successful legal action. Since idea X is buried in software, maybe on a server in-house to company B, could be nearly impossible for company A to discover that company B is using the idea. Case (2), company A might just keep idea X secret — not tell anyone — and try to rely on the legal status of ‘trade secrets’. Then company B might reinvent the idea, patent it, and sue company A for infringement. Then company B would face the difficult problem of discovering that company A was using the idea and infringing and pursuing successful legal action. But, with (2) company A could lose rights to idea X even though they were using the idea before company B reinvented it. But, in case (2), if idea X is advanced and tricky and buried in software where it is not easy to see, then company A might feel that the chances of company B reinventing the idea, getting a patent, detecting the company A is using the idea, and successfully suing company A soon are small.

    So, to compare, with (1) company A basically gives the idea away and pretty well guarantees that small companies all around the world could infringe on the patent and get away with it, while with (2) company A has a good chance of being the only company using the idea for some years, enough for the business goals of company A.

    With (1), company A actually might not much mind that some small company on the other side of the world uses idea X in some way that does not affect the business of company A. A really serious case would be in case (2) when company A gets to be really big and a competitor patents idea X and sues company A. So, if company A gets big, then they might want to patent idea X, let people on the other side of the world use it without charge, but protect themselves against any big companies that are major competitors. So, if it looks like a major competitor is using idea X, then company A would sue. At least the lawyers would do well.

    So, really, I believe that company A would be better off without software patents: When company A is small, then it would not have to worry about being sued by big companies with large patent portfolios. When company A is big, then it does not have to either give the idea away and try to stop infringement (a bad option) or worry about some big competitor getting a patent on idea X and keeping company A from using what it invented first and has been using as a trade secret (a bad option).

    Or, software patents say to company A, to protect your idea, first tell the world and, then, when you are big, get into big legal fights with big competitors. There’s a lot in this for the lawyers; I don’t see much in this for company A.

    More generally, it seems to me that enforcing a software patent presents some really severe problems, at least practical, maybe fundamental: One explanation is from one of my favorite sayings, “Software doesn’t mean anything”. E.g., what does a = bc mean? Clearly it doesn’t mean anything. Sure, we believe that we know what F = ma means, but, without making some assumptions about mnemonic identifier names, it doesn’t mean more than a = bc, which doesn’t mean anything. F = ma has meaning when it is in a text on freshman physics discussing Newton’s second law of motion and where it is made clear that F is force, m is mass, and a is acceleration. NOW F = ma means something. So, the meaning depends on the English (or other natural language) language text surrounding F = ma. Without the surrounding English, really F = ma is meaningless.

    Or, take the source code for a program, remove all the comments, change all the identifier names to have no mnemonic content, get rid of the pretty printing that might suggest what parts of the code do, and call the result ‘software’. No supporting papers of mathematics, references to the literature, program logic documentation, or software design documents; just the code. Now, what does it mean? Tough to say. I just give up and say that it doesn’t mean anything.

    So, any ‘meaning’ in software is heavily dependent on writing in English in design documents, program logic documentation, comments in the source code, mnemonic identifier names, reports of test cases, end user documentation, etc. In particular, my view is that some a = b*c in source code needs English language writing entirely analogous to what in a physics book surrounds F = ma. Just the ‘software’ without the English doesn’t mean anything.

    Here is some more: Suppose I invent nifty algorithm X and patent it. I know that the algorithm works because of some mathematics I derived; otherwise, except for the source code comments and/or mnemonic identifier name spelling, just looking at the source code, it is not the least bit clear what the algorithm is intended to do or why it works. E.g., look at the code for the fast Fourier transform and its bit-reversed permutation. Or W. Cunningham’s anti-cycling rule in network flows (how the heck to know it’s solves cycling?) or the D. Bertsekas polynomial network flow algorithm (how the heck to know it’s polynomial?). Heck, some months ago, I used the implicit function theorem and multi-dimensional Newton iteration to write some software to find the stiffness of arbitrary space frames. The only way I can follow the logic in the software is to start with about 10 pages of careful mathematics in TeX and then source code comments tied closely to the mathematics. Without the mathematics, comments, and mnemonic variable names, the code would look like total gibberish — for me, and I WROTE the code. Once did some work with non-linear duality theory to solve a large integer program — 40,013 constraints and 600,000 variables. It worked great! But, without the mathematics, comments, and mnemonic names, the code would be just gibberish. Some of the algorithms in cryptography are still more obscure.

    Now, suppose I patent my algorithm X. Someone reads my patent and uses my algorithm. I sue. They had over their code, without any English language or mnemonic identifier names. What is to be done with their code? Super tough challenge. Seems to me that showing that they used my algorithm X would be next to hopeless. Since the only way they learned about my algorithm X was from my patent application, looks like my patent had me give away the idea with no hope of enforcement.


    “Although ‘per capita’ innovation is perhaps higher in small firms, large companies innovate constantly. Heard of Intel?”

    I’ve had too much experience in large companies: Usually their approach to innovation is to work really hard and successfully, even ‘innovatively’, to make sure no such horrible thing ever happens! The full list of reasons is long, and good descriptions are common. A simple reason is that, for nearly everyone in the company, ‘innovation’ has too little upside and a lot of downside. Another reason is that nearly always the people are hired to do existing jobs, already formulated, and nearly no one with any authority wants to bet any part of their career on any of the risk of innovation. If someone innovates, then the people above can see lose-lose: If it fails, then they were partly responsible for the wasted effort. If it succeeds, then the responsible executive might get promoted over them. Commonly only the CEO can really push innovation, and mostly big company CEOs are generalists and not technology visionaries who want to bet their careers on new ideas they do not understand.

    Once I saw a good system: Research had their own budget and worked only on projects they selected, often by first asking operating divisions “where does it hurt?”. When research found a solution, they would present to an operating division. If the division went ahead, then the financial gain would be measured and Research would get half the gain for three years and then none of the gain. Projects in Research commonly lasted from one month to one year. Only about one project in 10 got implemented. With these rules, Research returned three times what they spent. The company would want to double the budget of Research, and Research would decline to take the money!

    In big companies, ‘research’ with Ph.D.s is usually done close to academic norms (easier to manage that way — just count peer-reviewed papers), is pursued heavily for ‘publicity’, and otherwise has become mostly just an effort to build patent portfolios; mostly connections with the product line are not wanted.

    Intel is nearly forced to innovate since a five year old processor can be sold for only about $10. The only way Intel can keep selling processors for 10 or 100 times that much is to keep making Moore’s law true. Still, people who held their breath waiting for Intel to do VLIW regretted it; last I heard, 24 way VLIW will give 9:1 speedup on general purpose code and more on special purpose code. I have to respect someone for the progress to 45 nm, still without use of the electron beam on the north side of I-84, but maybe Applied Materials gets more credit than Intel. Intel’s success with 64 bit addressing has been disappointing. Looks like maybe AMD did better.

    Also, of course, Intel’s innovations are not really in ‘software’ — although I believe that they should be, that is, should be able to get a factor of several by changing hardware to make the software both easier to write and faster. For one hint, have 256 byte addresses — hash and cache — and let the software identifiers be essentially the addresses themselves and, thus, get rid of all the address calculation which takes up a big fraction of the cycles now. AVL trees, extensible hashing, Cartesian trees, sparse matrices — all handled as special cases! I.e., no one ever really wanted all those darned sequential addresses; so, get rid of them! Can’t patent that now!

    Where has any big company ever created a new idea in software, got a patent on it, used the idea in a software product, had someone use that idea in their software, and then successfully defended their patent? Can anyone name two significant cases?

  • I strongly feel that software should be able to be patented and that strong patents help to minimize patent infringement and improve patent enforcement. I believe software creators should be able to make money on their creations just like anyone else in this country!

    • I also believe that software creators should be able to make money on their creations.  I just don’t think software patents (which I don’t believe are a valid construct anyway) have anything to do with this.