Open-Source Software and Patents – What’s the Deal?

You are developing an innovative technical solution. Part of it is implemented in software. You want to use Open-Source Software (OSS), or you want to publish some of your code as OSS. AND you want to patent your ideas.

Can you do that? Are there any issues with this approach?

Good questions. Let’s have a closer look.

(If you are not interested in the gory details, you may cheat and skip to the end of this article, to the section “Conclusions”, where you can find a summary and recommendations.)

It’s… complicated

The topic of patents and OSS raises a lot of questions. In practice, the ones I hear most often are these:

1.?You cannot patent software anyway! So, where’s the problem?

2. Are patents compatible with using OSS?

The present article concentrates on the second question. But for completeness, let me briefly address the first one: can you patent an idea that’s implemented in software?

The short answer is yes: you can patent it, provided it is “technical” enough. If the software solves a technical problem or implements a technical process, it may be patentable. (Note: I am concentrating on European practice here, but things are not that different elsewhere.) Here are some examples of potentially patentable ideas:

• Your code controls a ?machine, such as a robot, more efficiently.
• Your code uses less power than conventional solutions, making it better for running on a portable device.
• Your code implements an innovative method for processing sensor data to measure the state of a real-world system.

I won’t go into detail here. (I have vague plans to write more about the topic of patentability of computer-implemented inventions some other day.) For the time being, have a look at this summary provided by the @European Patent Office: See reference [13].

Now, let’s review the second question. Are patents compatible with using OSS?

Patents and OSS — What’s the Deal?

There are numerous OSS licenses out there. Some contain clauses applying to patent rights, while others come with such broad language that they might apply to patents, too.

For example, here’s a section from the preamble of the GPL 3 license (links to all the licenses cited here can be found at the end of the article).

Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.

In its detailed terms and conditions, GPL 3 limits how patents can be applied against GPL 3 software.

And GPL 3 is not the only OSS license that includes such clauses.

To keep things simple, I wanted to limit this article to the most popular OSS licenses and their interactions with patenting. I have therefore dug up some numbers (see [10]), and I was surprised to find that a handful of players dominate the market:

In the following, I’ll look at the patent-related clauses of these “big six”.

The OSS Patent Clauses

When it comes to patent clauses, the “big six” can be divided into two groups. The first group (Apache 2, GPL 3, GPL 2, and LGPL) contains explicit patent clauses. The second group (MIT and BSD 3) is silent on the topic. We look at the two groups separately.

The Licenses with Patent Clauses

GPL 3 and LGPL have the same patent clauses because LGPL is based on GPL 3 and does not change the patent-related language. They both include explicit patent licenses. And so does Apache 2. In simplified terms, they all request the following:

• If you publish software under the GPL 3, LPGL, or Apache 2 license, and
• your contribution to the work is covered by a patent you control,
• you grant a free patent license to anyone using the software.

Okay. But what if you use LGPL, GPL 3, or Apache 2 code in your patented product but do not publish the modified code under any of these licenses?

In that case, things differ a bit between GPL 3, LPGL, and Apache 2:

• If you take GPL 3 code and incorporate it into your own code (at the source level or by static or dynamic linking), you “modify” the GPL code in the sense of the GPL 3 license. If you “convey” such modified code to a third party, you must place your code under GPL 3 and make the source available. Hence, you will have to grant a license for your relevant patents.
• LGPL provides some exceptions to this. For example, you may dynamically link to an LGPL library without placing your own code under GPL, provided you follow some rules, e.g., by making the LGPL library end-user replaceable. Hence, if you are careful, you can dynamically link to an LGPL library from your code without having to grant every user of your software a license to the patents embodied by your code.
• Apache 2 allows you to distribute your code under your own license terms. Hence, you don’t have to out-license your patent rights. However, if you do distribute your code under the Apache 2 license, you will grant patent licenses.

GPL 2 mentions patents, but it does not contain an explicit patent license granted by the work's author. However, section 2a) obliges the person publishing work under GPL 2 to “cause” any work that they distribute or publish “to be licensed as a whole at no charge to all third parties”.

It may be argued that this general license includes patent rights, too. This is up to courts to decide, and the interpretation of the license may differ between jurisdictions. For example, gnu.org finds in its FAQ that “in many countries, distributing software under GPLv2 provides recipients with an implicit patent license to exercise their rights under the GPL” [1]. See also [2a] for a legal review, which discusses pertinent U.S. court decisions and concludes that the case law still needs to provide clear guidance. For more details, see [2b], which gives an in-depth review and also looks at European law aspects as well as the interesting question of "exhaustion" of the patent rights.

Hence, GPL 2 may or may not imply a patent license, and the situation may differ between countries.

The Licenses Without Patent Clauses

So, what about MIT and BSD 3? They do not mention patents. However, both provide a broad, general license of the work. MIT, for example:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software.

The wording does not restrict the license to a specific IP right, such as to copyright or to patents only. As for GPL 2, therefore, many authors argue that if you distribute your code under MIT or BSD 3, you also (implicitly) grant a patent license, see, e.g., [3] and [4].

However, in contrast to GPL 2, the permissive MIT and BSD 3 allow you to distribute modified code under any license of your choosing. Hence, if you implement your ideas in computer software that uses OSS code under MIT or BSD, you don’t need to publish your code under that license (thereby potentially granting patent licenses to third parties). Rather, you can keep the resulting code proprietary. Or you can use a license that does not grant patent rights (see below).

OSS-ing For Patentees

As follows from the above, if you distribute your code under any of these six common OSS licenses, there are basically two scenarios, from a patent-point-of-view

(A) You use an OSS license with an explicit patent license grant (GPL 3, LGPL, or Apache 2). In that case, it’s clear that you grant a patent license to anyone using the software.

(B) You use an OSS license that does not mention patents (GPL 2, MIT, or BSD 3). In that case, it can still be argued that you implicitly grant a patent license to anyone using the code because, under these licenses, you allow third parties to use the software substantially without restrictions. The courts yet have to decide on this question, and courts in different countries may come to different conclusions.

Hence, if you have a patent used by your software, both options are risky. If you want to stay in charge of who may use your patent, you should neither go for (A) nor (B). Instead, you must keep your software proprietary, or you must use a license that explicitly excludes patent grants, such as the BSD-3-clause-clear. That, however, may not be an option if the original software is under a non-permissive license.

Another point to consider: Some organizations (such as some universities) allow staff to publish their code under OSS licenses. This is a good thing, I think, because it helps the community to profit from (often publicly funded) research work. However, an organization that is also into patenting should consider this:

• As shown above, under Apache 2, GPL, and LPGL, you grant users of your code an explicit patent license. Under most other OSS licenses, you may grant an implicit patent license. So, if the code implementing your employees’ inventions is licensed under any of these OSS licenses and if you file patent applications, the patents may not be enforceable against users of the code.
• Releasing code under an OSS license includes publishing the code. Such a publication generates “prior art” against any patents you may later try to file.

Hence, such organizations should have a clear policy regarding when and how software should be open-sourced.

OSS Rocks, and It Can Coexist with Patents

Don’t get me wrong: Even if this text warns patentees of the dangers of OSS licenses, I very much support the concept of open-source software. OSS has allowed the creation of new technologies, breaking up monopolies (or duopolies), and establishing novel business models. It eases development pain and can encourage thriving development communities around products.

And, as shown above, OSS and patents can coexist.

For example, @NVIDIA, a company holding thousands of patents, has published a lot of software around its hardware products, some of it under OSS licenses [5]. Other parts of the company’s software are, however, distributed under proprietary licenses, see, e.g. [6].

@Intel, a holder of even more patents, has also contributed to OSS, and it has intensified these efforts recently [7], maybe because of the stiff competition it faces in its hardware business.

Not only big international companies are active patent filers and open-source members. There are also Swiss companies that have patents while also contributing to the OSS community, thereby encouraging the use of their products, solutions, and services. Examples: Axpo Group , dormakaba , On , SBB CFF FFS , Sensirion , u-blox (retrieved by comparing some of the companies at the Swiss OSS Benchmark [8] against the Espacenet database [9]).

As you see, OSS can be used in combination with patents. Smart folks have found that it can make sense.

On a general note: If you are a business and decide to publish some code as OSS, use a policy and license that is compatible with your long-term business model. If your OSS project gains momentum, stay committed and don’t pull the rug from under the community’s feet [11], [12]. A sudden change to a more restrictive license might turn your allies into enemies.

And don’t forget: honor the license the OSS comes with.

Conclusions

Here is a summary of some patent aspects of the “big six” OSS licenses that I have discussed above:

And these are the takeaways:

1.? You can use OSS and patents at the same time. The two are not inherently incompatible. Their combination can give you an advantage.

2.? However, if you have a piece of code that is covered by a patent you are planning to file or have filed, some precautions are in order:

a. Do not combine (at the source level or by linking) this code with third-party softwarethat comes under a non-permissive license, such as GPL 2 or GPL 3. These licenses will force you to publish your own code, if you distribute it, under their terms, and these terms grant licenses for your patents explicitly or (probably) at least implicitly.

b.?To be on the safe side, the same applies to combining your code with LGPL codeunless you are sure you can comply with the library-linking exceptions it comes with.

c.?Combining your code with software distributed under the permissive licenses of MIT, BSD, or Apache v2 is fine because they do not force you to open-source your own code

3. If you want to open-source your own code, keep in mind that the common six OSS licenses either explicitly grant a license for your pertinent patents, or, at least, you run a substantial risk that you implicitly grant such a patent license. If open-sourcing code containing ideas you may want to patent, use an OSS license that explicitly excludes patent licenses (such as BDS-3-clause-clear). And remember: open-sourcing software publishes the ideas therein, which may make it harder or impossible to patent these or similar ideas after the open-sourcing.

4. Comply with the license of any code you use and stay committed to your open-source engagement. Do the right thing!

Note: These conclusions only cover the six most common licenses discussed here. And they only look at the patent-related issues you should consider in your OSS strategy — this is not a complete OSS strategy.

What are your opinions on this topic?

If you have questions, don't hesitate to contact us at E. Blum & Co. AG , or message me directly

References and Links

References

[1] gnu.org, Frequently Asked Questions about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.html#v2OrLaterPatentLicense

[2a] Anna Haapanen , Free and Open Source Software & the Mystery of Software Patent Licenses, International Free and Open Source Software Law Review, 7(1), pp 19 – 28, https://dx.doi.org/10.5033/ifosslr.v7i1.107, 2015

[2b] Anna Haapanen , Free and Open Source Software Licensing, and the Mystery of Licensor's Patents, https://helda.helsinki.fi/server/api/core/bitstreams/c28a4c43-daee-4abc-bc50-d4c7b4cecdc2/content

[3] Scott K Peterson, Why so little love for the patent grant in the MIT License? https://opensource.com/article/18/3/patent-grant-mit-license, 2018

[4] Rowan Wilson @Rowan Wilson, Free And Open Source Software And Your Patents, https://oss-watch.ac.uk/resources/fossandpatents, 2008

[5] Thorsten Leemhuis, Nvidia prefers open source Linux kernel drivers from now on, https://www.heise.de/en/news/Nvidia-prefers-open-source-Linux-kernel-drivers-from-now-on-9805037.html , 2024

[6] Tobias Mann, Nvidia's subscription software empire is taking shape, https://www.theregister.com/2024/08/06/nvidia_software_empire/

[7] @Dan Meyer, AI a big driver of Intel’s open-source efforts, https://www.sdxcentral.com/articles/interview/ai-a-big-driver-of-intels-open-source-efforts/2024/09/

[8] The Swiss OSS Benchmark: https://www.ossbenchmark.ch/institutions

[9] Espacenet: https://worldwide.espacenet.com

[10] statista, Most popular open source licenses worldwide in 2021, https://www.statista.com/statistics/1245643/worldwide-leading-open-source-licenses/

[11] James Governor , Open Source Foundations Considered Helpful, https://redmonk.com/jgovernor/2024/09/13/open-source-foundations-considered-helpful/

[12] Sid Sijbrandij , Open Charter gives open source users predictability amidst the licensing change trend, https://opencoreventures.com/blog/2024-05-open-charter-gives-open-source-users-predictability-admist-licensing-change-trend/

[13] @European Patent Office, Digital Techologies, https://www.epo.org/en/news-events/in-focus/ict

The OSS Licenses

Apache 2: https://www.apache.org/licenses/LICENSE-2.0

BSD-3-clause: https://opensource.org/license/bsd-3-clause

BSD-3-clause-clear: https://spdx.org/licenses/BSD-3-Clause-Clear.html

GPL 2: https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

GPL 3: https://www.gnu.org/licenses/gpl-3.0.de.html

LGPL 3: https://www.gnu.org/licenses/lgpl-3.0.html

MIT: https://mit-license.org

?

(Banner artwork generated by a combination of lazy AI and hard, manual labor)