How The Changing Legal Landscape Impacts Free And Open Source Software Development

There is a constellation of legal constructs that you may sometimes hear referred to as "intellectual property." That's a tricky term because it encourages one to think of these separate types of legal constructs as the same. They aren't the same. Free and open source software developers used to mainly concern themselves with licenses, license interactions and the resolution of license violations. In recent years, the scope of free and open source legal issues has expanded to include patents and (to a lesser degree) trademarks. Trademark issues rarely stop software from being distributed, so this article will discuss copyright licenses and software patents.

Let's start with licensing. Software licenses operate as a set of additional permissions and requirements on top of default copyright. Copyright was originally conceived to cover written works, like books. Copyright has expanded over time to include paintings, movies, songs, maps and performances. Human-readable source code is also copyrightable. Actually, in almost all jurisdictions a computer program is automatically covered by copyright upon creation. Legally speaking, using no software license is the same as default copyright.

Related Articles

The licenses that are considered to be free or open source all share a few characteristics. They allow people to study, share, improve and redistribute the code. Licenses span a wide spectrum. Some licenses allow the code to be used or re-used in any way at all, including in a proprietary software codebase. Other licenses require that modifications are distributed under the same or a compatible license ensuring that future changes are available to the the rest of the community. Both the Free Software Foundation and the Open Source Initiative maintain a list of licenses that meet their criteria for acceptable licenses.

A software license covers the actual text or code that has been written, but a patent could cover the function that is carried out by the code. That distinction may sound confusing. In fact, the line has become blurry as the scope of copyright law and the scope of patent law have both expanded over time. In fact, some licenses make mention of patents. Two prominent examples include the Apache License, version 2 and the General Public License, version 3. These two licenses, which otherwise allow any use of the covered software, prohibit the user from patenting the functions described in the code. The goal is to prevent the developer and their community from being sued for their own usage of the code they've written and released as free or open source software.

A patent is a limited monopoly granted for certain amount of time (20 years in many places) in exchange for full disclosure. Based on the description in the patent application, a person who is knowledgeable in that field should be able to recreate the invention. Patents used to be reserved for physical processes, new devices and sometimes a limited monopoly on a particular business opportunity. The scope of patentability has expanded in the last few decades and can now include software, as well as business methods and even certain medical procedures. The intent of patents is purportedly to encourage inventors to make investments and create new inventions that might have otherwise been too financially risky to complete. As soon as a patent expires the idea can be freely implemented by anyone.

Software patents are a controversial subject for a few reasons. First, the work and research that needs to be done to bring a software idea to fruition is often much lower than other areas where patents are granted. Second, the software field moves very quickly. One and two year product life-cycles are the norm. Twenty years is an eternity in software development. Third, many software patents are either overly broad or involve a very minor innovation that most developers would consider trivial. This leads directly to a problem with notice. It is nearly impossible for software developers to discern when they are infringing a patent. It is more common to assume that nearly everyone is infringing on some patent or other, nearly all the time. This leads to a situation where patent-holders can easily find developers to sue for patent infringement.

There are two different types of software patent suits. There are those between two practicing entities; where one company sues a competitor for infringing one of it's patents. Sometimes, that competitor will then respond with a counter-suit claiming that the first company is infringing on one if it's patents. And then there are suit where one company -- that does not sell anything or make anything -- sues a practicing entity for patent infringement. There are different risks associated with each type of legal action for the free and open source community.

Suits where the plaintiff doesn't make or sell any products are more commonly referred to as "Troll" suits. At one point in time, trolls or "patent assertion entities" primarily targeted large companies with deep pockets. These days, more small and medium sized companies are being sued. Colleen Chien says, "While normally it’s not a good idea to sue your customers, patent trolls, who don’t make anything and therefore don’t have customers, are increasingly targeting users and adopters, rather than makers of the technology: this tactic is used an estimated 40% of the time." (Source: Colleen V. Chien: Tailoring the Patent System to Work for Software and Technology Patents" on November 15, 2012) This creates a problem for free and open source projects when their customers are sued -- especially if the project is too small or cash-poor to step and defend their customers in court.

While some practicing entities sue for patent infringement in good faith, believing that they will be unable to recoup the costs of their research and development in the market, others have a more sinister motive: market manipulation. Because of software's extremely short time frame, an injunction stopping a disputed program from hitting the market for six months or a year can crush a small competitor. Even situations where both competitors survive the legal battle, do not produce a good result for software users. Suits are costly in terms of time, money and attention. All of which are resources that could otherwise be directed towards further software development -- plus the cost of lawsuits is eventually passed along to consumers.

Even more worrying, the line between practicing entities and non-practicing entities is blurring. Practicing entities have been bringing more suits, increasingly in areas where they don't have products. The other practicing entity, the defendant, has no grounds for a counter-suit when the plaintiff isn't active in the area that the allegedly infringed patent covers. Practicing entities are looking for ways to "monetize" their patent holdings. If their patent holdings are far afield from their products and services, then that company has a sort of "troll" wing. All of which is very troubling when you consider that, "The US Patent Office is granting 40,000 new software patents each year." (Source: A Generation of Software Patents, by James Bessen, 2011) Although the US is the most prolific, patents are also being issued in other countries.

There are certainly many worthy organizations like the Electronic Frontier Foundation are pursuing legislative reforms to address the troll problem. The legislative solutions that are being discussed may only end up providing guidance or punishment for full-blown court cases. If new laws can not stop the flow of threatening letters that smaller projects and companies can't afford to fight in court, then the problem will only be partly fixed. In the meantime, projects are so worried about getting "the letter," that certain areas of innovation are actually being avoided by small-to-midsize projects. Start-ups and small free and open source projects are where some of our most exciting new technologies get their start. If those places aren't safe for new ideas and approaches, then all our software fields will stagnate.

The free and open source software community is used to working together to solve common problems and the threat of patent aggression is no different. There are two primary methods by which the United States Patent and Trade Office (USPTO) invites the public to participate in the process of patent examination. The first is by submitting prior art, which can be done by anyone. The second is by creating defensive publications, which are filed by other inventors. For both methods, there are community resources to help make the process of participating easier.

The crux of most of the world's patent systems includes the idea that a patent can only be granted on something that is new or novel. In other words, you can not have a patent on an innovation or inventive step that is already being used by people in any given field. If patent examiners are unable to keep up with what is current, then they don't have grounds to deny non-novel ideas. In computer science this is a particular problem, both because innovation moves very fast and because there is no single place to look for news of new inventions. Even places where a lot of new ideas are logged, like public repositories, much of the code isn't documented in a way that describes what it actually does. For example, a complete search of Gitorious and GitHub wouldn't really help examiners ascertain the current state of the art – even if they had time to look at everything there.

Prior art is a legal term that means all public information that is available regarding a specific invention. If the information was available to the public before a patent application is recieved, then a patent is not supposed to be granted. However, the public is a pretty vast place these days, so in practice the prior art that gets considered is information that is documented and easily searchable by a patent examiner. Several initiatives have sprung up to crowdsource prior art for specific areas. Linux Defenders works specifically with the free and open source community while Ask Patents deals more generally with software patents.

When an inventor wants to document something innovative, without seeking a patent then they can create a defensive publication. The invention then enters the public domain and can not be patented by any other party. It also becomes part of the USPTO's prior art database, which helps block later patent applications on the same innovation. Many companies choose to use defensive publishing in conjunction with a patent or two, to augment their defense. Other projects that oppose patents may choose to use defensive publishing instead of patenting – if they file defensively on some invention, then no one can be granted a patent for it. Organizations like Linux Defenders are set up to specifically help the free and open source community write effective publications, although any person can add their ideas directly to IP.com.

Unfortunately, there is no silver bullet that will allow free and open source developers to completely ignore the changing legal landscape. There is also no magical jurisdiction that will keep trolls or anti-competitive plaintiffs from sending letters. Projects can choose to take certain precautions and participate in community efforts to ameliorate patent risk. Choose a modern software license that forbids users from patenting your work. Sign a mutual non-aggression pact, pledging that you and your colleagues won't sue each other. Create some defensive publications that keep predators from patenting your inventions. Participate in the creation of prior art to block obvious or overly broad patents in your field. Keep an eye out for reforms that will help stop trolls and other bad actors. The legal issues facing the free and open source community may be complex, but they aren't insurmountable – especially when we all work together.