Patents and open-source software licenses

A patent is a grant of rights to the patent holder (owner, applicant, inventor, assignee)¹ to exclude others from making, using, selling, or offering to sell, and/or importing the invention (distributing). The invention is defined in the claims of the patent. A patent is only enforceable (valid) within the territory of the – e.g., a U.S. patent is only enforceable in the USA, a German patent in Germany, et cetera.

An invention is “patentable” when the inventor demonstrates that (e.g., in the USA) the invention is new (novel), useful, and not obvious. In other jurisdictions the inventor must demonstrate that the invention includes an inventive step that solves a technical problem.

An inventor cannot get a patent for an idea. This is a common misconception. The inventor must demonstrate that the concept (idea) has been reduced to practice, or in other words, the inventor must document the invention’s credibility, enabling one of ordinary skill – without undue experimentation – to carry out (practice) the claimed invention. This does not mean that the inventor needs to create a working prototype, but it does mean that the invention must be sufficiently described in text and drawings, and (in the USA) the inventor must disclose the best mode of practicing the invention.

To understand how software fits into the classic model of patentability – this model is based on nineteenth century (industrial) model of inventions, which were largely improvements to physical apparatuses, new devices, or new (or improved) methods of manufacturing physical items – one has to relate software to the physical world. Simply, if one views software as a tool to accomplish a task, it is much easier to see the connection to the “old” patentability view promulgated in modern patent law. But, generally, if an inventor devises a novel, useful, non-obvious (or a solution to a technical problem with an inventive step) apparatus or method of making the same, then that invention may be “patentable”.

Thus, for software, an inventor does not have to provide reams of code demonstrating the execution of the program². But, the inventor needs to have more than a set of assertion of what the software will do. The inventor should clearly describe the technical problem being solved and how the software will function to solve this technical problem. Often, it is very helpful to put into context the inventive step of the software relative to the current (existing before your software code was developed) state of the art by expressly reciting the best teaching in the given field and explaining how your code improves over this, how your code solves a problem not addressed by the current art, or how your code better (more efficiently, faster, less-complicates) accomplishes the stated task, goal, or technical problem.

To reduce a software invention to practice (reduction to practice, or RTP) means that the solution is clear enough to implement by anyone that reads your patent application. This requirement does not mean the entire program be coded, debugged, and executed (that would certainly qualify), but it does mean that the software be outlined (logical diagrams, flow charts…) in sufficient detail so that any team of coders could write their-own code to implement the invention on a computer. It should show the relationship of the logical subroutines to one another, explain how data is compiled, stored, transferred, accessed, and searched, how the data is manipulated and the nexus to any physical devices including output devices (screens, speakers, printers, etc.), how information is inputted, manipulated, transformed, what the various software subroutines do, how they interact.

So, in the terms of software patents, the invention is the ability of the computer to solve a problem in a new way. A software patent is not limited to the unique expression of code – that is a software patent is not defined by the programming language and lines of code, but rather at a higher level, the function that the software performs and how the software solves the technical problem (not what it does, buy actually how it does it).

But, looking at the idea (paragraph A, above) – this disclosure is not sufficient to render the idea “patentable”. There is no description of how the software functions. But, the application for patent included 12 drawings consisting of logic flow diagrams illustrating the interaction of various components of the invention and 30 pages of text describing how the various logic components functioned. However, there was not a single line of code. But, a person of ordinary skill in the art could read the patent document and understand how to code this innovation. Thus, the basis of patentability was met.

The limit of the patent is based on the content of the claims.
1. A method of placing an order for an item comprising:

• under control of a client system,
• displaying information identifying the item; and
• in response to only a single action being performed, sending a request to order the item along with an identifier of a purchaser of the item to a server system;
• under control of a single-action ordering component of the server system,
• receiving the request;
• retrieving additional information previously stored for the purchaser identified by the identifier in the received request; and
• generating an order to purchase the requested item for the purchaser identified by the identifier in the received request using the retrieved additional information; and
• fulfilling the generated order to complete purchase of the item
• whereby the item is ordered without using a shopping cart ordering model.

As discussed, above, the scope of the patent is limited by the claim, but it is not restricted to a specific programming language. However, to implement the invention, the claim must be transformed into executable code.

However, to make the invention usable, it must be reduced to practice by coding, debugging, and running the software. This is implementation of the invention. This specific code can be subject to copyright protection. But, the patent rights are independent of the programming language used to implement the invention. Thus, the benefit to the patent is that it offers broader protection than the literal code, which is protected specifically by a copyright. In other words, it doesn’t matter if your competitor re-coded your invention in a different programming language than your software: It only matters if your competitor’s software includes the scope of the patent claim!

If you created your own programming language and coded the invention from scratch, you would have little worry of obtaining licenses. In reality, however, the implementation of the invention is going to use an accepted programming language and also likely to incorporate modules, routines, and other pre-developed constructs, which may be the intellectual property of a third party, and as such, subject to legal limitations on its use. The legal limitation on (or permission to use) these pre-existing constructs is called a license. The license may place certain obligations on you and you must accept those terms as a condition precedent to the use of those pre-developed constructs.

Of course, there may be prohibitions preventing you from using certain pre-developed constructs. The constructs may be the proprietary property of another, and no license to use was granted to you, for example.

We now come to a discussion about licensing software. As mentioned above, a patent grant is one type of intellectual property. Whereas a license is a contract involving (for example, a patent grant) the conditions of use of intellectual property.

A license agreement, as any contract, is freely entered by both parties. As such, and as long as a provision does not violate applicable law, the parties are free to contract to any condition. Thus, a Contributor to a Work, even if the Contributor is also a patent holder, comes to the license agreement and (in the terms of an open-source license) either accepts the terms or rejects them. In the case that the software-patent holder rejects the open source license terms, the patent holder is still able to code his invention, albeit without using any of the open source code and without benefit of other aspects of the open-source license.

However, if the patent holder accepts the license terms, the patent-holder is now bound by them. This, however does not prevent a Contributor from obtaining patent protection for its work because the patent right is independent of the license agreement. But, if the scope of the patent granted includes Work produced by a Contributor under the Apache 2.0 license agreement, then obligations and conditions must be met by the patent-holding Contributor, as discussed below.

First, the APACHE 2.0 license agreement makes no prohibition to obtaining a patent. However, Apache 2.0 does expressly require that Contributors grant a license to any patents touching upon the Work. Further, should you levy a patent infringement claim against another Contributor, you would lose any patent licenses you enjoy, which could result that your software is in violation of others’ patent rights.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

Using the open-source Apache 2.0 license agreement, you take some open source code and modify it in a new, unique, non-obvious way to create new functionality. This new software tool is represented by the large circle in the drawing. You realize, however, that part of this software tool is quite new and unique and, accordingly, you receive a patent grant for this (smaller circle). The patent grant, however, provides you rights that are much broader than the actual code that you created (overlap area surrounded by orange broken-line).

According to the license agreement you made under APACHE 2.0, you must freely provide your software code to any other open-source (APACHE 2.0) user. (The large circle, which contains your novel, non-obvious, literal code (orange broken line of smaller circle).

However, you have a valid, enforceable patent. This patent stands alone, independent of the APACHE 2.0 license agreement. Of course, as explained, the full patent rights at your disposal is modified according to the Apache 2.0 license agreement you previously entered into when taking the open-source code for your new software tool.

This patent still has some enforceability. For example, your competitor, not using open-source (Apache 2.0) software, codes its own software tool. But, a portion of the competitor’s tool contains the same functionality for which you received a patent grant (represented by the overlapping region between the small blue circle and the grey circle). This overlap is an infringement of your patent rights. And, as the competitor is not subject to your license agreements under Apache 2.0, you can assert your patent in this example.

In the example, above, here you must license your patented invention to your competitor because your competitor also used Apache 2.0 open-source software to code its tool. Because of the terms of use that you agreed to when using the Apache 2.0 open-source software, you are now obligated to grant the license for your competitor’s use.

You can hold a patent for innovative software at the same time as cooperating with an open-source software license, such as Apache 2.0. There remains value in the patent because the enforceable right remains outside the license agreement with Apache 2.0 – thus, a party that is not subject to the Apache 2.0 license agreement misappropriates your patented invention, the full force and effect of patent rights remains at your disposal.

¹ A patent must be granted to a real person (inventor), not a legal entity. The inventor is often an employee of the applicant (a company, legal entity, legal person but not a real person). In such cases the inventor assigns his or her right to the applicant (or assignee). Another term for assignee is owner or patent holder. 


² In fact, the literal code is subject to copyright protection. Registering the code with the appropriate office is not necessary for the right to exist, but to enforce the right, most (if not all) jurisdictions require registration. The copyright is actually a bundle of rights that includes the right of attribution, the right to create derivative works, the right to distribute the work, to copy it, among others.

³ See U.S. Patent No. 5,960,411 issued on 28-Sept-1999 titled “Method and System for Placing a Purchase Order via a Communications Network,” filed 12-Sept-1997 by Hartman et al. and assigned to Amazon.com, Inc.