Blink a LED? Then live your life in fear of lawyers and software patents.

Time permitting I participate in the Open Source board layout software project PCB. A recent exchange in the patch tracker brought to light just how scared developers have become of lawyers. Why must we live in fear of these leaches on society?

At issue is one of the developers put a lot of effort in to a enhancement that would 'blink' the difference between two revision of the board layout, to make the changes stand out. To which I raised the potential issue of a user having Photosensitive Epilepsy. This is where certain light patterns can induce seizures in people prone to this problem (it is also being looked at as a 'non-lethal' weapon by the military; watch the movie Looker someday). The end result is that Bert, the developer, decided 'blinking' was unsafe because of the potential for lawyers to appear. How many times have you blinked a LED in that widget you are developing? Now you too can live your life in fear of lawyers. I'll let Bert explain his case, taken from the patch tracker:

Hi Bob,

Thanks for the warning.

The default delay value is 50, which means 50 centi-seconds, which equals to toggling every 0.5 seconds, which gives 2 Hz.
On my laptop it takes even longer than 0.5 seconds for the default value to toggle (twice a second).

The above UK site mentions:
[quote]
  Most people with photosensitive epilepsy are sensitive to 16-25 Hz. Some people may be sensitive to rates as low as 3 Hz and as high as 60 Hz.
[quote]

Nevertheless the user can still inflict some damage upon him/herself by changing the delay parameter, or tuning/modifying the software, their computer, or whatever.

My gut feeling (legal adviser) says it's better to withdraw any patch for any blinking whatsoever, due to the way the US legal system regarding injuries and lawsuits functions.

Bear in mind that the upstream pcb repository resides on US soil.
3 Hz is just to close to 2 Hz for me to feel comfortable.

Put in other words: risk = probability * effect --> I take zero chance and rather have no effect.

This leads us to the issue of software patents and patent trolls. Lindsay Blakely, on the staff at Inc.com, recently wrote the piece How Much It Costs to Fight a Patent Troll, describing what happens to us 'little guys' that don't have teams of leaches, sorry, lawyers, on staff.

See also The Private and Social Costs of Patent Trolls by James E. Bessen, Jennifer Ford, and Michael J. Meurer of Boston University School of Law.

I've been making my case against software patents for years with the example of R++, a mathematical process (that is not patentable), that would allow us to have far safer systems. What is R++ ?:

R++ is ''rules in C++''. R++ is an extension to C++ that bridges the gap between object-oriented programming and data-driven (rule-based) programming. Programs written in R++ have all the facilities of C++ plus a new programming construct: a rule. A rule is like an ''IF-THEN'' statement, but it sits apart from the procedural code and is triggered automatically upon changes to the data that it monitors. In effect, rules monitor object memory and react when their ''IF'' clause becomes true.

What are rules useful for?

• Applications can use rules to help maintain model integrity by enforcing invariants and detecting constraint violations in the model.
• Applications that monitor a physical system (such as a telephone switching system) can use rules to detect and react to critical states.
• Applications that are primarily reactive (such as an elevator controller) can use rules to express state transitions.
• Applications that apply engineering guidelines (such as in equipment configuration) or business policies (such as in loan analysis) can use rules to apply the guidelines/policies when each situation arises.
• As a software engineering aid, rules can be used as a kind of non-procedural exception mechanism for detecting and handling illegal states.

The problem is that through mega mergers, sellouts, and buyouts, no one can actually figure out who owns what. Lucent has a patent on the technology in R++ but AT&T owns the production version of the software. Commercial use of R++ is a bit more tricky. Neither Bell Labs Research nor AT&T Labs Research are in the business of distributing research generated software for commercial use. I was able to get a principal at Lucent on board with open-sourcing R++. However any contact at all with AT&T got a me a referral to the legal department voice mail. Despite repeated attempts at email and phone messages, I've never been contacted by anyone from AT&T. Is it any wonder they are so hated by most (cell-)phone users?

There is a Federal Register notice, Request for Comments and Notice of Roundtable Events for Partnership for Enhancement of Quality of Software-Related Patents, that the US Patent Office would like to form a partnership with the software community to figure out how to 'enhance' the quality of software patents. To that end, they are looking for comments and there will be two roundtble events sponsored by the USPTO, one in Silicon Valley, Tuesday, February 12th, and one in New York, Wednesday, February 27th. If you plan on attending you must register by Feb 4th. The USPTO plans to make the roundtable events available via Web cast. Web cast information will be available on the USPTO's Internet Web site before the events. Grok Law has more on the issue, and a copy of the relevant Federal Register pages may be found at IP Watchdog.

Leave a comment if you think you can make it to one of these events, and give us a first hand report, please.

Software Quality and Software Costs by Capers Jones

"An occupation where failures and disasters are the top cost drivers is not a true engineering discipline.  To become a true engineering discipline, software engineering needs better quality control, better quality measures, and better economic analysis than current norms." - Capers Jones in ASQ/SQP June 2011.

This month's (June/2011) issue of the American Society for Quality's Software Quality Journal, has a 'Must Read' article, "Software Quality and Software Costs" by Capers Jones where he explores the application of two metrics frameworks - software cost of quality and software defect containment. Both to model and manage the cost and quality consequences of poor requirements and spending time on debugging, instead of not putting the bugs in the first place.


Some ASQ/SQP articles are member only, and a few are available with a free registration.  Some articles such as the one we are discussing here are made available as PDF's under 'Open Access'.  The system may ask you to register with a name and email address, then you may be directed to a page saying you must purchase the article.  However if you click the link again, the article should open due to it being an Open Access article.


Jone's metrics are based on the International Function Point Users Group (IFPUG).  Using Function Points allows for measuring defects across different languages, and in requirement documents where measurements of "Lines of Code" are useless.


To summarize: The Bad, and alas the typical development process today:

• Either inadequate estimation or the arbitrary rejection of accurate estimates by clients who then imposed unachievable schedules; [Clients refusal to listen to accurate estimates on development time, usually being driven by an unmovable trade show deadline].
• Inadequate status tracking by management that concealed problems until too late to recover.
• Poor change control combined with creeping requirements in excess of 1 percent growth per calendar month; [The Creeping Feature Creature is a powerful task master, as late addition requirements contain more bugs].
• Poor quality control.
• Testing alone is not very efficient in finding bugs.  Less that 35% effective.

The good, that is proper project planing and management (Always make a case from the point of the bottom line to get the attention of the Bean Counters):

• The high-quality project schedules will be shorter by about 15 percent.
• Software Quality and Software Costs in defect removal efficiency will cost about 20 percent less to develop than identical projects with poor quality.
• Cumulative Total Cost of Ownership of high-quality applications from the start of the first release through five years of maintenance and enhancement will be about 30 percent lower than identical projects with poor quality.
• Annual maintenance costs will be lower by about 40 percent.
• For large applications, high quality levels will minimize the chances of failure.
• High-quality applications tend to have quicker testing schedules and hence quicker overall schedules.
• The economic value of excellent quality is directly proportional to application size. The larger the software application, the more valuable quality becomes.

"No true engineering discipline should have defect repairs and canceled projects as the two top cost drivers.  For software engineering to become a true engineering discipline, quality control will have to be much better than it is in 2011."

Just because we can, does that mean we should?

Some inventions like Voice Mail and the iPad Steering Wheel Mount, really should never have been invented.

One site claims this is the patent of the Steering Wheel Mount, however that time line does not fit.

Just because we can make dangerous and destructive products, does that mean that we should? Having been run off the road by a Texting-Teen, problems like these are all to real.

My personal view of Apple's products is more along the lines of this patent: GB1151321. If I'm going to fork out Big Bucks for a product, I'm going to use it anyway that I see fit, but Apple says I can only run their "Approved Apps". No thanks, I'll wait for something Open Source based.