% fortune -ae paul murphy

Rx for Linux: Part 2 - SCO, Patents, and Money

Right now a person with a bright new programming idea and a full time job that doesn't involve commercializing bright new programming ideas for the employer faces a tough problem.

How tough it is depends on where the person is, because licensing and patent issues will affect his choices quite differently in different parts of the world - everything from the finders-keepers attitude state officials enjoy in Communist China to cronyism and a resurgent class of above the law families in Europe and Canada.

In the United States, where most of the world's innovation takes place, the combination of patent law abuse and the transition from fairness based license interpretation to legal interpretation are creating enormous barriers to individual action -thus favoring the big commercial players in ways almost exactly opposite to what was intended when the patent office was first created.

Imagine, for example, that you are an American or European with a great programming idea. Now what? Sink a couple of hundred thousand bucks you don't have into a patent search and application that may not produce a definitive answer? Quit your day job to ahead and do the work in the hope that the people who later come out of the woodwork to sue you on patent infringement can be greenmailed into writing a check to you instead of their lawyers? Release some early diagrams and thinking as a journal article both to get some feedback and to establish a primacy claim?

Suppose you did develop a prototype that worked, would you then release it under GPL or a BSD license in hopes of getting some smarter people to write production quality code for you? If so, what's in it for them -or you- when a big player, like IBM or Microsoft, uses your code to build a better marketed competitor and tells you to go ahead and sue them?

With barriers like these, why even try? The bottom line is that the patent system, worldwide, now works against innovation by individuals or small organizations - in fact I suspect you're down to choices:

  1. if you are willing to trade off low cost against high risk and have the contacts to get past the automated defences, trying to sell your idea to a couple of the biggest players you think likely to attack you after it succeeds, creates legal barriers that could stop them dead in their tracks if you later develop and release something that works; or,

  2. if you prefer low risk with high costs you could go and get a (usually low paying) job at a University or other public institution with the right kind of research support commitment and try to shelter your idea under their legal and innovation support umbrella.

So how do we fix this mess to bring greater freedom, and the potential for greater rewards, to the Linux coding community?

The long term answer is legal reform on patents and software licensing. In the United States the software industry has basically missed the boat on piggybacking its concerns onto medical liability reform, but the process obviously doesn't end there and other reform opportunities will arise. Once reformers succeed in the U.S., change will percolate from there to the rest of the world, but we can expect this to take from years to decades.

In the medium term Sun's openSolaris community offers a useful workaround. Develop your hot new product within its patent umbrella and you get both partial protection and a ready market. Look closely at their community development license and what you see is a mutual non aggression pact among signatories combined with the best of the BSD approach and what's left of the GPL when you strip out the political and economic agenda.

That's great, but there's a downside for the Linux community in that Sun's CDDL motivates developers to leave Linux for Solaris.

The answer for Linux, of course, is to copy it - use the OSDL or any other group willing to volunteer to create a similar license and patent umbrella for Linux, and look forward to eventually merging with the OpenSolaris community to support some kind of patent reform legislation, first in the United States and then elsewhere.

I don't believe there is a short term answer - but there is a palliative step that could be taken to reduce the rate at which we're sliding into licensing and patent nihilism: reverse the impact of the SCO/IBM precedent.

The numbers involved in the SCO lawsuit are huge - and their effect on the legal community could be likened to that of blood in shark infested waters or red meat placed in front of starving wolves. Such a comparison might be exaggerated, of course, but anyone familiar with billing presures in law firms will probably agree that most of the industry now salivates at the thought of either defending or pressing a software centered lawsuit.

Although most of the community disagrees with me on this, I think the basic SCO claim is a no brainer: strip away the absurdities perpretrated by lawyers using their client's money (and corporate goodwill) to go after their billion dollar contingency, and the basic claim is just that some IBM people allowed some contractually protected Unix system code to leak into the Linux development tree. Well duh, the issue here isn't whether it happened, but why IBM's senior people opted to fight rather than settle before the matter got so far out of hand.

There's a simple fix - one that would go a long way to taking the oomph out of the growth of the American software litigation business: a no fault settlement in which IBM pays SCOsource to to work with it on open sourcing all contractually covered Unix code - for everybody, including patents and any copyrights either party, including proxies like Novel, owns.

This is a fair trade: one that lets IBM retire honorably from the field without admitting fault, gets the lawyers out of the game, and lets SCO continue in business. Most importantly, however, it would remove much of the basis for the consequent litigation now threatening the Linux community regardless of who wins or loses in court.

Tomorrow: part three - licensing.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.