Articles

Given that it is an IEEE publication where this advice appears, one can admittedly permit a bias towards a United States perspective, but many aspects of the article are either confused or misleading.

We start with the notion that the supposedly patentable cut-and-paste feature was probably written in a specification somewhere, which may have been true at the time of its introduction (1974 or 1975, if one trusts Wikipedia even to a small degree [1]), but it seems unlikely that such user interface developments would be specified "up front" in most cases, and it would arguably be even less likely today. Moreover, one must acknowledge that cut-and-paste was merely an established real-world concept that was "transferred" to a computer user interface paradigm. I know that the author of the article only wished to provide an example, but when he writes that "suppose someone else has already invented the cut-and-paste function", I doubt that he means people doing manuscript editing work, despite those very people being responsible for the underlying idea. Indeed, the article serves to remind the reader of the poisonous state of the US "intellectual property" arena: that by merely tagging refinements ("and ­improvements thereof", as he puts it) to existing practices, an idea is suddenly monopolised. And there are numerous examples of such trivial patents, so the author only serves, perhaps inadvertently, to remind the reader of these disgraceful practices.

The author takes many an opportunity to discredit or to downplay the importance of copyright, writing that "the notion of copyright protection for the code is limited, because it doesn’t apply to code taken from the public domain", which is like saying that trousers are flawed items of clothing because fish cannot be made to wear them. He spends no time exploring why this might be (the nature of the public domain) or qualifications to this blanket statement (derived works and whether the public domain is even a valid concept in some jurisdictions). Nor does he dwell on the factual details when stating that copyrighted "code doesn’t have to be inventive, new, or unobvious", ignoring that the code does have to be original (or contain original components if it is a derived work).

One starts to wonder about the author's agenda, even before the biographical information scrolls into view. For copyrighted code he writes that "technically, it doesn’t even have to work". Yet, he writes the following: "Patents, in sharp contrast, are designed to protect functionality, usually not by covering specific lines of code but rather by covering a software “engine” that takes certain inputs, manipulates them, and provides certain outputs." Such vagueness is presumably not clarified by "a flow chart showing how the various subroutines, modules, and algorithms interact", nor by the rest of the average patent application. Suddenly, it seems that the vague, potentially unreproducible expressions of functionality represented by patents are preferable to concrete, reproducible expressions of functionality represented by copyrighted works.

One is left with an impression of the author's tenuous grasp on software development in the real world, perhaps seen through clichés that may originally had some roots there, but which are increasingly detached. In the authors mind, designers - the ones responsible for the flowcharts - are apparently responsible for the big ideas, whilst programmers merely write the code. Since there is an increasingly prevalent perception, in a business environment that favours offshoring, that programmers (or coders) are freely interchangeable, the author panders to the view that the work of the replaceable masses should not be regarded too highly and it should instead be the work of the supposedly visionary architects and designers which should demand increased protection.

Yes, the author has an agenda: to take a field of endeavour with working, well-established mechanisms for the protection of the output of that field's practitioners (copyright), and to introduce instruments (patents) which merely serve to obstruct the work of those practitioners and to introduce a proliferation of monopoly fiefdoms, potentially ruled only by those with enough money and legal resources both to resist and to practise the extortion which software patents seem to encourage. Concrete objects such as actual program code whose misappropriation is typically obvious and detectable are seemingly not favoured for protection, whereas vague processes encoded in patents appear to be favoured because they provide a plausible basis for intimidating people who appear to be undertaking similar activities.

As a software developer, I wonder how those sharing the author's mindset would feel if those of us actually doing the work in the software industry were determined to start imposing unwanted obstacles and regulations on their fields of endeavour. How would the author of this article feel if my colleagues and I were able to expose him and his colleagues to legal intimidation so that suddenly a previously unknown entity could impose sanctions on him and his business without warning and without any indication that he or others were doing anything inappropriate in the normal proceedings of business?

It certainly is possible to become "patent savvy": recognise that patents with any connection to software whatsoever are expensive, unethical and unnecessary instruments whose very existence have virtually no justification. And observe that when one group of individuals seeks to interfere with another group, resulting in no apparent benefit for the latter, the motivation is almost certainly the greed of the former. The patent business apparently needs more land to cultivate. Do not let it destroy valuable, well-functioning ecosystems in its desire to inflate its own importance and the already abundant wealth of its members.

[1] http://en.wikipedia.org/wiki/Cut_and_paste