Legal Issues in Open Source: Copyright and Patents

When you hear “open source,” the word “free” probably comes to mind. Free to use, free to look at the code, free to change things. But this freedom isn’t a state of lawless anarchy. In fact, it’s built on a surprisingly complex and clever legal foundation. The very laws that are typically used to restrict software are used in the open source world to keep it free. It sounds like a paradox, doesn’t it? This legal world is primarily ruled by two major forces: copyright and patents. Understanding them is the key to understanding how open source software can be both “free” and legally protected at the same time.

The foundation: how copyright protects software 🔗

At its core, any piece of software you write, from a simple “Hello, World!” script to a massive operating system, is a creative work. Just like a book, a song, or a painting, it is automatically protected by copyright the moment you create it. This is a crucial starting point. By default, copyright gives the author-in this case, the developer-exclusive rights. These are often summed up as “All Rights Reserved.”

What does this mean? It means that, by default, no one else can legally do these things without your permission:

• Copy your code
• Modify or adapt your code
• Distribute copies of your code (or your compiled program)

If you put your code on a public repository like GitHub without any license, you’re not automatically giving anyone these rights. You’re just showing them your code. Legally, they can’t do much with it. This default “all rights reserved” status is the baseline. To build an open source community, you have to actively give people permission to use your work. This is where licenses come in.

The clever twist: meet copyleft 🔗

If copyright is a legal tool to restrict use, copyleft is a brilliant legal hack that uses that same tool to ensure freedom. It’s not the opposite of copyright; it’s a specific way of *using* copyright. The concept was famously championed by Richard Stallman and the Free Software Foundation (FSF).

Here’s the core idea:
1. We start with copyright: The author still holds the copyright to their software.
2. We grant freedoms: The author uses a license to grant everyone the “four essential freedoms”: to run, study, share, and modify the software.
3. We add one condition: This is the magic part. The license states that if you modify the software and distribute your new, modified version (a “derivative work”), you must distribute your new version under the exact same license.

This ensures the freedoms are passed on. The code, and all future versions built upon it, remain free forever. It prevents someone from taking free code, adding a few features, and then making that new version proprietary and closed-source. Copyleft is a “share-alike” agreement. It’s like a community potluck rule: you can eat from any dish, but if you bring a dish that uses an ingredient from the community kitchen, you have to leave your whole new dish for everyone else to share too.

The most famous copyleft license: the GNU GPL 🔗

The most well-known and strongest example of copyleft is the GNU General Public License (GPL). When a piece of code is licensed under the GPL, any software that incorporates it must also be licensed under the GPL. This “reciprocal” nature is why some critics have called it a “viral” license, as it spreads its terms to the larger work.

This is a powerful tool for building a community commons. It guarantees that any contributions made to the project will remain part of that commons, and won’t be “taken private” by a corporation. Linux is the most famous example of a project built on the GPL, which is a major reason why it has remained a community-driven project for decades, even with massive corporate involvement.

A quick note: not all open source is copyleft 🔗

It’s important to know that copyleft is just one type of open source license. The other major category is permissive licenses, like the MIT License or the Apache License. These licenses also grant you the freedom to use, modify, and share the code. However, they do not have the “share-alike” requirement. You can take MIT-licensed code, build it into your own proprietary, closed-source product, and you don’t have to share your new source code. This offers more flexibility for businesses but less of a guarantee for the future freedom of the code itself.

Shifting gears: from the code to the idea with patents 🔗

We’ve established that copyright protects the written code (the expression of an idea). But what about the idea itself? This is where software patents enter the picture, and it’s where things get very controversial.

A patent doesn’t protect text. It protects an inventive process, method, or system. For example:

• Copyright: Protects the specific lines of code that make Amazon’s “1-Click” shopping button work.
• Patent: Protects the *idea* or *method* of purchasing an item with a single click on the internet, regardless of what code is used to make it happen.

You can see the problem. A developer in the open source community could, completely independently, write their own code for a one-click shopping cart, only to be sued for infringing on the patent for the *idea* of it. This creates a huge risk for open source developers, who are constantly building and improving upon existing ideas. How can you innovate if the very building blocks of software logic might be patented?

The big debate: the “technical effect” test 🔗

The core of the patent controversy is this: should software be patentable at all? Many legal systems, including India’s, have struggled with this. You can’t patent an abstract idea (like a mathematical formula) or a simple business method (like “paying employees on Fridays”). For a long time, many argued that software is just a set of mathematical instructions, an abstract idea.

To solve this, many jurisdictions, including the European Patent Office and increasingly the courts in India, have adopted the “technical effect” or “technical contribution” test.

The idea is that software itself isn’t patentable, but it *can* be if it produces a tangible “technical effect.” This means the software must solve a technical problem in a new, technical way, usually by making the computer or a machine it controls work better.

What counts as a technical effect? 🔗

This is the million-dollar question. It’s not just about running on a computer. Instead, it’s about improving the computer’s function. Examples of a technical effect might include:

• Software that makes a computer’s processor run more efficiently.
• A new algorithm that reduces the amount of memory needed to store a file.
• Software that controls a physical machine, like a car’s anti-lock braking system.
• A new method for encrypting data that is provably more secure.

In contrast, a patent for “a method of conducting an online auction” would likely be rejected as a pure business method. In India, this is specifically excluded under Section 3(k) of the Patents Act, which bars patents for “a mathematical or business method or a computer programme per se or algorithms.” The “per se” (by itself) part is key. Indian courts have interpreted this to mean that if a computer program has a genuine technical effect and isn’t *just* a program, it might be patentable.

When copyleft and patents collide 🔗

This is the final boss of open source legal issues. What happens if you use GPL (copyleft) code in your project, but your project also uses a method that you hold a patent for? Can you contribute your code to the community and then sue that same community for patent infringement?

The creators of open source licenses saw this trap. Modern licenses, like the GPL version 3 (GPLv3) and the Apache 2.0 license, include explicit patent clauses to prevent this.

Essentially, these licenses say that when you contribute your code to the project, you are also automatically granting all users of that code a free, royalty-free license to use any of your patents that are necessary to use that code. This is known as an “express patent grant.” It’s a defensive measure that ensures a contributor can’t use patents as a weapon against the very community they’re contributing to. It protects the users and keeps the ecosystem safe from this kind of “bait and switch” tactic.

In the end, the legal side of open source isn’t a barrier. It’s the sophisticated framework that enables this global collaboration to exist. It’s a clever use of 20th-century law to build a 21st-century digital commons, ensuring that “free” truly means free for everyone.

What do you think? Do you believe copyleft’s “share-alike” requirement helps or hinders innovation? And where do you think the line should be drawn for software patents?

References

1. https://opensource.guide/legal/
2. https://www.gnu.org/licenses/copyleft.html
3. https://patentpc.com/blog/the-role-of-technical-effect-in-patent-applications-for-software
4. https://spicyip.com/2024/08/dhc-and-3k-this-time-using-the-technical-effect-test.html
5. https://www.intepat.com/blog/patents-open-source-licenses