Patents and Open Source: Understanding the Risks and Available Solutions

Favorite

Why Patents Licenses Matter: The Benefits of Explicitness

Although most people think of Open Source licenses as primarily creatures of copyright law, patent considerations also come into play any time one is choosing to license software (or any other technology or content) under an Open Source license.

One of the first articulations of the need to consider patents as part of Open Source licensing was in the preamble of GPL-2.0, written in 1991:

[A]ny free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all.

Although GPLv2 expressed at least part of the concerns that patents presented to Open Source licensing, it also engendered years-long debates about the language used in that license addressing patents, and the extent to which it obligated licensors to grant rights to their patents.

Later-developed Open Source licenses took care to include an “express” (i.e, explicitly written) patent license, of relatively well-defined scope, in an effort to make clearer to licensors what patent rights they were granting, and to licensees what patent rights they were receiving. One example is the Apache-2.0, written in 2004, which included – in Section 3 – both an express patent license grant, as well as a “defensive termination” clause: 

If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the [licensed] Work or a Contribution incorporated within the [licensed] Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that licensed Work shall terminate as of the date such litigation is filed.

In this way, the licensee was given a direct assurance that they received a patent license to the software they received under the Apache-2.0 Open Source license, as well as a warning that if the licensee were to take certain aggressive patent actions against that software, they would lose the benefit of that license. This formulation attempted to effect a form of mutual patent peace between the parties licensing and/or using the Open Source software. GPL-3.0 also adopted an explicit patent grant in Section 11 when it was issued in 2007.

The Risks of Implicitness, and of Disclaimer

Many of the earliest Open Source licenses – including some of the most popular so-called non-copyleft (or ”permissive”) licenses – did not address patents in any explicit way. As a result, there have been debates about the extent to which licenses such as BSD-3-Clause or MIT confer any patent rights at all. For BSD-3-Clause, opposing positions have been presented: that no patent rights are conferred, or that that license implicitly grants patent rights. A similar debate has been had for MIT: it contains no patent license, or includes an implicit patent license. Although this debate has not ever been resolved in court, there may continue to be a risk that a licensor will advance a “no patent license” argument for licenses without an explicit patent grant, leaving licensees to rely upon arguments that a grant exists implicitly – a legal analysis that can be heavily fact-dependent and may vary from jurisdiction to jurisdiction.

Even more risky are licenses that attempt to disclaim the granting of any patent rights at all. The OSI confronted this issue upon submission of the Creative Commons Zero (CC0) license for OSI approval in 2012. Although that license has much to recommend it – it is perhaps the best example of a comprehensive effort to dedicate content to the public domain – one portion of that license raised concerns:

4. Limitations and Disclaimers.

a. No trademark or patent rights held by Affirmer are waived, abandoned,     surrendered,licensed or otherwise affected by this document.

A full disclaimer of any patent rights was thought to potentially run afoul of at least OSD 7, which states that an OSI-approved license “must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.”  Subsequent OSI license approval submissions with similar comprehensive patent license disclaimers have been similarly rejected.

Why Licenses Are Not a Complete Solution

Although well-crafted explicit patent license grants in Open Source licenses (with or without defensive termination provisions) go a long way to reducing the risks of patent infringement claims against anything using an OSI-approved license, they are not a complete solution. That is because there are many patent holders who either do not participate in Open Source development or licensing at all, or who may participate in Open Source projects but may hold patents relevant to projects to which they do not participate. In those circumstances, any patent license grants in the Open Source license governing a project would not apply to their patents.

Nevertheless, the situations in which patent holders who have no patent license obligations to a particular project have made assertions against that project are relatively rare. There are several reasons for this. First, many patent-holding entities who participate in Open Source development projects understand that if they engage in patent assertions against other projects in which they do not participate, they could harm their community standing and make all Open Source projects less receptive to their participation. Additionally, many patent holders tend to view Open Source code as essentially “free as in beer” (i.e., not licensed for any monetary gain), and thus not an attractive target for patent assertions which are often made to collect substantial royalties or other damage awards.

Despite the low incidence of patent assertions against Open Source projects, and the disincentives many patent holders see against making them, such patent assertions are not unheard of. In such circumstances, there are a variety of entities and mechanisms available to address the risks the assertions present to the Open Source community.

For example, the Open Invention Network (OIN) — a consortium that includes thousands of members — operates the world’s largest patent non-aggression network. Members agree not to assert patents against core Open Source technologies – what OIN calls the “Linux System Definition,” although it encompasses much more than just the Linux kernel or the components of a Linux system. Because the many thousands of members pledge to not assert their patent rights against that defined list of Open Source technologies, a huge number of potential patent assertions are taken off the table.

Similarly, Unified Patents, OIN and the Linux Foundation have joined together to create an “Open Source Zone” around which they can use prior-art submissions and other administrative mechanisms within patent offices around the world in an effort to invalidate or narrow patents before they become threats against Open Source projects. Other, non-Unified Patent efforts have also been successful in eliminating patent assertion risks against both Open Source software and hardware.

Thus, although no Open Source alone can prevent patent litigation or other patent assertions, community structure and various organizations and initiatives can make patent aggression against Open Source commercially unattractive and potentially a threat to the ability to further assert the patent itself.

The Continued Viability of Software Patents as a Risk 

For a time, many Open Source software developers felt that software patents were something that the law did not allow, or should not allow.

The dispute about whether software patents should exist came to a head in Europe in 2002 upon introduction of the “Proposal for a Directive of the European Parliament and of the Council on the patentability of computer-implemented inventions” (CII). Many prominent Open Source supporters and developers opposed this initiative, ultimately unsuccessfully.

In the United States, there was a belief among many Open Source developers that software patents did not exist or were not valid until the 2014 U.S. Supreme Court decision in Alice v. CLS Bank. This belief was not correct – in fact, the U.S. had been issuing software patents since the 1960s – but nevertheless the Alice decision provided the sort of clarity about the boundaries around which patent protection for software was available in the U.S., much in the way the CII did in Europe. These standards appear to be firmly entrenched in both jurisdictions, meaning software patents will continue to be a risk that Open Source projects – as well as non-Open Source software – will need to address through the various mechanisms described above.

Practical Risk Management

So what should developers and companies actually do?

1. Know your licenses. Licenses with explicit patent grants (e.g., Apache 2.0, GPLv3) for distributed projects may mitigate the risks that contributors later argue that they never granted a license to their patents.
2. Join a defensive network. Membership in OIN or Unified Patents may provide companies or projects meaningful protection if and when patent assertions emerge.
3. Use open governance. Projects under recognized foundations (e.g., Linux Foundation, Apache Software Foundation) benefit from institutional defense mechanisms and may have industry backing to help collectively oppose patent assertions.
4. Keep records. Document where your code came from and under what license. It’s your first line of defense in any dispute. Records of when code was first made publicly available (such as through public versioning systems like GitHub) may also be useful in establishing prior art status that could be used in challenging patents.
5. Stay informed and reach out. Keep abreast of patent developments and patent assertions; there are many members of the community – including lawyers versed in both patent law and Open Source licensing – who may be able to help.

The Bottom Line

Patents in Open Source are often a manageable legal risk. The biggest risk isn’t infringement claims; it is not reaching out to available resources.

The Open Source community has spent two decades building the scaffolding to make patent threats rare and containable. Developers who understand that landscape can focus on what they do best: innovating in the open, confident that the legal ground beneath them is far more stable than any patent myths suggest.

Click Here to View Original Source (opensource.org)