Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

Tag Archives: Patent

Intellectual Property Ownership

Leave a comment Posted by on January 21, 2013

Whenever anyone involved in intellectual property starts a new job, particularly in software development, the employment contract usually includes a lengthy intellectual property agreement where the new hire assigns ownership of all intellectual property created over to the employer. Many new employees balk at this, concerned that the employer will claim any side projects they are working on and with recent court battles over software patents worth billions of dollars, for example, intellectual property ownership is a complex area worth exploring.

Employment contracts are usually “work for hire” contacts. Although the legal requirements and obligations vary from country to country, it usually means the employer owns any works created instead of the employee, in return for payment or salary. Few software developers dispute this. However, unlike authors and artists usually contracted for a specific work, developers are often contracted for all intellectual property created during their employment, irrespective of whether it is performed during working hours on work equipment.

Software developers are increasingly working on side projects like open source software or apps for mobile or tablet app stores. Many developers code in the spare time, whether it be tweaking the website for a friend’s business or experimenting with new libraries or languages. It is also increasingly common for students to bolster their resume this way or for software developers to teach themselves new languages or libraries.

This differs from traditional “working under the table” or “moonlighting” in that much of the work is not paid. The software developer may want to capitalize on the work in the future but usually just does not want others intruding or demanding ownership of the work, akin to a lawyer doing “pro bono” work. Software developers are also producing assets other than code. For example, software patents produced during software development can be more valuable than the code.

The barrier of entry for software development has never been lower. Thirty years ago, software development was difficult, usually performed on expensive, centralized computers and proprietary software. This is a far cry from today where one can create complex websites using free tools running on free operating systems hosted on commodity priced servers. Compare that to chemists, physicists or engineers that may require thousands or millions of dollars of equipment and dedicated teams of support staff to perform their research and yet more to monetize it.

Indeed, the problem with software patents and intellectual property ownership in software development is development only part of the cost. There is the marketing and sales required to turn products into revenue, for example, and the IT infrastructure, HR and accounting structures required to support all of this.

Patents are similar. Beyond software development, legal expertise to file patents is required along with the time and resources needed to find and deal with infringements. Patents are also often cross licensed, either earning additional revenue or allowing access to other organizations’ patents. Patents may also become more valuable over time as products they are used in become more widespread.

The word “ownership” also carries many mis- and preconceptions. If an employed software developer (“inventor”) wants to own all or part of his or her inventions, what does this mean? Does the inventor want royalties, like an actor may receive for a movie? Does the inventor want the option to use it in their own work, possibly for a job at a competitor? What about an open source project the inventor contributes to in his or her spare time? Does the inventor want the option to stop others using it, like competitors or those the inventor disagrees with? Will the developer help fund the sales, marketing and legal infrastructures required?

Even if those in software development can make a case for increased “ownership” of their products, it is not in employers’ interest to allow this. The creative process cannot be constrained to occur within work hours or on work equipment – many have  inspiration when asleep, exercising or in the shower – and increasingly flexible working arrangements further blur the distinction. Work for hire contracts are also well understood and widespread, making them lower risk.

Some would argue software development is like a painting selling and reselling for increasing amounts but the original painter seeing none of the profit.  However, a better analogy is performers selling music. Do they go through a record label where they get greater exposure and marketing but sacrifice income or do they produce the songs themselves and sell it through iTunes, where they can make a greater cut but a much reduced sales volume?

Many employers are also quite reasonable. If the idea is unrelated to current or likely projects and the employee is not going to make much money, pursuing it is not worth the expense. If the organization files patents, most reward developers with bonuses for doing so. Other employers take the opposite position and talking to the employer first before producing anything important is prudent.

It will be interesting to see what the future holds. Younger generations, those that have grown up with social networking, are used to sharing their lives on social media and regularly blur the lines between professional and social. With software development tools more accessible than ever and collaborative source code repositories like github gaining in popularity, will developers from younger generations look at coding the same way? While they may have different politics from their GNU and GPL espousing forefathers, will they see “social coding” or “social software development” as an obvious direction? If so, what compromises will be made?

Software Development , , ,

Of Patents and Putters

1 Comment Posted by on September 3, 2012

The recent victory of Apple over Samsung has brought the arguments for and against software patents to the forefront once again. With many of the big technology companies engaged in patent litigation, many ask whether patent law is a distraction that stifles competition. Many technical luminaries, blogs and articles are openly anti-patent so should software developers be actively filing patents in organizations willing do so?

Patents can be beneficial for the developer. Some companies offer financial rewards for filing patents and researching whether something is truly novel, required for filing a patent, may reveal other solutions and techniques. However, patents’ biggest benefit is demonstrable innovation. A filed patent has been reviewed by the organization’s internal process and the patent office. This is rarely perfect but far more review than many other achievements.

That said, filing patents can distract developers from working on products and can be expensive for the organization. Similarly, if a developer files patents on a product then moves to a different organization working on similar products, the developer must carefully avoid infringing those patents at the new organization.

Some, such as the Electronic Frontier Foundation (https://www.eff.org/patent), argue that filing software patents endorses or exacerbates the negatives of patents. Many prefer the open source movement ideals where information and software should be available to be extended and used by many. Much of modern computing builds on concepts and algorithms that, if originally patented, may have stalled or prevented much of what IT takes for granted.

However, is this being disingenuous? Could these concepts and algorithms have developed despite patents? Consider the case of VisiCalc, the first spreadsheet. It was not patented, allowing Lotus 1-2-3, Microsoft Excel and other competitors to copy, extend and eventually surpass it. If it had been patented, would Lotus, Microsoft and others created an even better solution to the original problem than a spreadsheet? (as per Russ Krajec’s blog post at http://www.krajec.com/blog/what-if-visicalc-was-patented)

There are many more arguments for or against patents. However, even if all the anti-software patent arguments were proved and pro-software patent arguments disproved, for example, there is still no guarantee the software patent system would be dismantled immediately or at all. Legal and political systems move slowly at best.

Indeed, the technical or ideological pro- and anti-software patent arguments are all academic. Organizations file patents to protect their intellectual property (IP) in a world where patent litigation is increasingly common and IP is becoming organizations’ greatest asset.  It is a strategic business decision.

If an organization chooses to file patents, a software developer refusing to file patents makes about as much sense as a golfer refusing to use a putter. The golfer may lobby for a rule change banning putters but, in the meantime, the golfer is only inflating his or her handicap. This is not a “two wrongs make a right” scenario. If the organization is successful, it will inspire copy cats and litigation from its competition. Depending on the industry and product, filing patents may be pragmatic.

Software developers often see themselves only as potential victims of software patents, the expense and difficulty of filing them and the misplaced assertion that developers do not producing anything novel fuelling circular logic. If the organization is willing to bear the costs of patent management, why not patent it? There are undoubtedly smarter people out there that can solve the problem more effectively if needed. The organization can always choose not to assert the patent over open source or use it defensively, too.

Some argue that nothing in software development is new and most work is merely reinvention but saying that modern software developers are all less capable, intelligent and imaginative than their forebears is clearly false. This is not to say that developers produce new things all the time. Similarly, while many patents are obvious in retrospect, it is also much easier to judge when their ramifications are in everyday use.

What developers can do is ensure filed patents cover only products the organization intends to produce. Much of the consternation around patents from developers revolves around “non-practicing entities” (NPEs or “trolls” as they are derogatorily known), where the focus is on licensing existing patents and not using them to produce products. Research NPEs are the exception, despite Ars Technica’s Fox News-worthy rant (http://arstechnica.com/tech-policy/2012/04/how-the-aussie-government-invented-wifi-and-sued-its-way-to-430-million/).

Irrespective of whether an organization chooses to file patents, developers should keep easily accessible evidence of design documents and design discussions, such as E-mails and written notes. Even if an organization chooses not to file patents or the organization is not building anything novel, the organization may still be the victim of a patent lawsuit and demonstrable prior art can refute or diminish a patent’s novelty.

Software developers are very good at arguing things on technical merits. Unfortunately, the software patent issue has never been a technical or even ideological issue. These are merely rationalizations. This is as economic and political issue, and most software developers are not economists or politicians. Some protection for inventions is required and patents are the current, imperfect implementation of this. Until we come up a better system, software developers are only hurting themselves by not using all the rules of the game to their advantage.

Software Development , , , ,

The Other Side of Software Architect Innovation

2 Comments Posted by on January 14, 2012
As stated previously in this blog, software architects must be innovators. They are responsible for creating a technical vision to apply new technologies to further the customers’ goals and/or reduce development costs and for high level designs. Many books, lectures, blogs and so on describe the process of innovation and are not repeated here but, when confronted with a problem, most developers and architects either work out their own solution or lazily Google something similar. However, software developers and architects, in particular, need not “reinvent the wheel”.
 
Ignoring structured learning, such as degrees and certificates, there are two ways architects can learn ways others do things. The first is to proactively listen for new information.Most software architects will already read favourite blogs or web sites, follow twitter luminaries, subscribe to magazines, read textbooks, attend conventions and so on. However, the key with information sources is efficiency – five sources providing predominantly relevant information is better than one hundred poor sources.
 
Aim for a mix of information sources, including some technical, some design, some industry commentary and some aggregators (those that provide interesting links to other sources that may only occasionally have relevant information). Review sources over time because the architect’s requirements, knowledge and expectations will change over time. Experiment with new things and plan to either remove “old favorites” or check them less often when they are no longer being consistently useful.
 
The second is to research topics when the need arises. Competitor’s products are good places to start but, unless this is a major feature, information is often sparse. Internet searches or dedicated development sites are useful but iterating synonyms is time-consuming.
 
Software architects often neglect academic texts or papers, which are particularly useful if the group is using more complex algorithms. Use Google Scholar or consider joining ACM or IEEE to access their academic paper repositories. Such papers may be dry or assume too much knowledge initially but persisting may reveal better approaches, establish common terminology and point out less explored areas suitable for potential patents or the architect’s own academic papers if he or she is so inclined.
 
Some would recommend looking at open source software. Assuming the product is chosen with care, open source software or other people’s code in general is a great source of information from obscure language features to new algorithms. However, the software architect must not copy any code verbatim or infringe patents or licenses.
 
If the problem is not solved or not solved sufficiently by prior art and the organization has a process in place, software architects should create and file patents. Arguments over whether software patents encourage or discourage innovation are irrelevant. As they say, “You cannot win the game from the sideline”. The IT industry is pursuing patents aggressively and companies that do not, such as Google with Android, now face legal challenges and hurdles. For the software architects, patents are one of the few peer-reviewed, universally available measures of creativity available. Many organizations also offer financial incentives for them, too.
 
Beyond the software architect’s products and patents, avenues for innovation include open source software, apps in app stores, writing a technical blog, conferences or academic papers. Approval may be required from the organization and social networking activity will need to comply with the organization’s policy but this can help the software architect’s personal brand and help find or precipitate conversations with like-minded individuals.
 
The single most important thing about innovation is to start. A software architect must be a technical leader but cannot lead without producing and cannot produce without starting. The first attempts may be unremarkable or unsuccessful but persistence will bear fruit.
Software Architecture , , , ,

%d bloggers like this: