Similarly, issues such as bugs, vulnerabilities, or inefficiencies in open-source software are often addressed collectively by a community of collaborators. This collaborative approach allows companies to resolve problems efficiently while benefiting from innovation without the need to maintain large, in-house development teams.
Good thing happens when companies harness the power of community and synergy among developers. However, collaborations that involve the use or distribution of a creation often lead to conflicts over intellectual property (IP) rights. These conflicts typically arise between the initial developer and contributing developers, challenging the established status quo of IP ownership and raising important questions that warrant further inquiry.
Any real attempt to understand Open Source should start with defining “Closed Source”, otherwise known as proprietary software. In closed source, IP rights in the source codes are vested in the company, usually the rightsholder, giving them the sole authority to alter, inspect, or copy the source codes.
On the other hand, Open-Source Software is “opened” up to the public, and made freely available to other developers to be altered, inspected, learned, or copied, thereby enabling them to fix bugs, add new features, or tweak the program to make improvements.
It is this shared access that has pushed Open Source into the mainstream so much so that it has now become the generally accepted meaning of the word itself. Now, ‘Open Source’ has become synonymous with any project built on principles of open exchange, collaborative participation, rapid prototyping, transparency, and community-driven development.
The concept of Open Source can be distilled into the following core principles:
Access to source code: Source code, namely the underlying code behind the software, is made available to developers and end-users. This lets others view, study, and engage with the code directly.
Freedom to modify and distribute software: Users are not only allowed to use software but improve on the code or customize it and distribute their versions.
Contractually defined licensing terms: Open-source terms are set out in an Open Source License agreement, which defines users’ permissions (how they can modify and distribute the software), rights, and obligations.
Collaborative development: Some Open-Source licenses (e.g., Copyleft) require modified versions of the work to be shared under the same licensing terms to continue the cycle of continuous innovation.
Types of OSL (Open-Source Licenses)
Open-Source Licensing (OSL) varies in its application, with different interpretations tailored to specific use cases and industries. However, the modalities for licensing in Open Source can be broadly categorized into two:
- Permissive Licenses, and
- Restrictive or Reciprocal (Copyleft/Viral) Licenses.
Permissive licenses
Permissive licenses are so-called because they allow contributing developers to infuse open-sourced code into their proprietary or derivative solutions or integrate the same as part of their business operations without any obligation to disclose.
Such permission, however, is without prejudice to the contributing developer’s rights to enforce and protect their IP in the Open-Source software. Some common examples are:
MIT License: Extremely permissive and widely used, allowing almost unrestricted use as long as the original copyright notice is included. Expressly grants licensees the right to sub-license.
Apache License 2.0: Similar to MIT but includes explicit patent rights and requires preservation of license notices. It is commonly used in large projects like Android and Apache HTTP Server.
Berkeley Source Distribution (BSD): These include variations such as the 2-clause and 3-clause licenses, that allow for redistribution with minimal requirements, primarily retaining copyright notices. Although both BSD and MIT licenses are permissive, they differ in their scope. While MIT covers both software and its documentation files, the BSD license only covers the source code and binary form, without explicitly addressing documentation.
Unlicense: Essentially waives all copyright claims, allowing software to be freely used without restrictions.
Restrictive licences
These licenses, often referred to as Reciprocal/Copyleft/Viral licenses, require developers who modify or improve on Open-source code to use and distribute the derivative software under the same licensing terms as the original work.
The license has a “viral” effect, in that an original work licensed as ‘Open Source’ infects its derivatives and any further derivates therefrom, leaving them all open-sourced.
The most widely used copyleft license is the GNU General Public License (GPL), which requires software carrying GPL-licensed code to be released under the same license when distributed, thereby prohibiting sub-licensing using a different license.
It also precludes integrating its code into proprietary software that restricts user freedoms. While the GPL forbids a user from controlling downstream access in exchange for a fee, a user is not necessarily prevented from entering into an agreement with a downstream licensee to pay under a GPL. However, such a user risks suffering disrepute within the OS community as such practice is at odds with the Open-Source moral ethos.
Other examples include:
GNU Lesser General Public License (LGPL): A weaker form of copyleft that allows linking with proprietary software without requiring the entire work to be open-sourced.
GNU Affero General Public License (AGPL): Similar to GPL but includes provisions that require sharing of source code even when the software is accessed over a network.
Eclipse Public License (EPL): Allows for combinations of EPL and non-EPL code but requires that modifications to EPL code be shared under EPL terms.
Mozilla Public License (MPL): A more permissive copyleft license that allows integration with proprietary code as long as MPL-covered files remain separate.
IP dilemmas in Open Source
Intellectual property rights are, by their very nature, exclusive. They reside in the owner, and any use, distribution, or modification without authorized permission from the rightsholder may amount to an infringement. As Open-Source development is known to permit the use, alteration, and distribution of source codes, the fundamentals of IP are at odds with Open Source’s unrestricted access.
Although it may seem contradictory, OSL is fundamentally rooted in the IP rights of the original developer. Interestingly, third parties — including other contributors or users — can also maintain an action in infringement claims to enforce compliance with the license terms.
Such actions are often taken to safeguard the broader open-source community, particularly when a licensee violates the terms of an OSL in modifying or redistributing the open-source software. In summary, potential infringement issues can involve a single category of IP, such as copyrights, trademarks, and patents.
Copyright infringement issues
Compliance challenges often arise when a developer, as a licensee, accidentally breaches the copyrights of the original creator of a solution. This issue is particularly common because many licenses extend beyond the original work (i.e., the creation of the author, developer, or inventor) to also cover derivative works or “works based on the original work”. This broad scope increases the likelihood of unintentional copyright violations.
The GPL-2, a license crafted by U.S. lawyers primarily for a U.S. audience, provides clear guidelines to define the boundaries of this scope as follows: “work based on the Program” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.”
Permissive licenses allow users to use and distribute software with few restrictions, but copyright law still applies, as the original author retains specific rights protected under copyright. With the growing number of open-source projects rolled out yearly, (2023 alone produced about 3.9 million Open Source projects) this scenario, is commonplace. In addressing this, copyright holders use certain licenses that include a copyright notice that attributes the work to the original author or copyright holder as follows:
Some other versions of the MIT and BSD take it a step further, requiring the license holder to give the original author credit where the code is used in a commercial or promotional context. Once these terms are not followed, an action may lie in copyright infringement.
Patent infringement issues
Patent infringements are another concern in open-source software development. While the principle of shared innovation in open-source software often dispenses with the need for initial developers to file for patents, it is not uncommon for other developers who build on existing software to file patents for their derivative works.
In such cases, the original developer may inadvertently infringe on these newly filed patents. A potential solution to this issue is the concept of Open Patents, also known as the “Patent Commons” or “Patent Pledge.” This approach allows patent holders to pledge not to enforce all or part of their patent rights against individuals or communities, fostering collaboration and innovation.
IBM is credited with pioneering this practice (by listing 500 patents on its website to promote tech innovation in the information industry). More recently, companies like Google and Tesla have also embraced the Patent Pledge, dedicating patents to further innovation in their respective fields and contributing to the open-source community.
Trademark infringement issues
While patent and copyright laws often dominate discussions, trademark issues also play a significant role, particularly when developers overlook an important distinction: OSLs may grant rights to modify or distribute software under copyright law and, in some cases, patent law, but these licenses typically do not extend to trademark rights.
To obtain trademark rights, a licensee operating under an OSL would need a separate agreement explicitly granting those rights. This distinction underscores the importance of understanding the limitations of OSLs when it comes to trademarks.
The Neo 4j case provides a case in point. In casu, the court upheld Neo 4j’s motion to dismiss the argument that Neo 4j had granted a naked trademark license to the defendant, PureThink. The thrust of their defense was that Neo4j had ‘abandoned’ its trademark by failing to perform quality control on third-party modifications to its code, thereby granting the said license by conduct.
In its ruling, the court was quick to point out that the OSL granted to third parties were indeed copyright licenses — not trademark licenses. As such, under law, the defendant would still be precluded by ‘licensee estoppel’ to use the trademark rights, and use thereof would inevitably amount to an infringement.
IP ownership
Open-source development often highlights the challenge of tracing IP ownership, especially in large projects with multiple contributors. Determining “who owns what” can become a complex and elusive task. This issue was exemplified in a case involving Patrick McHardy, a developer who has faced widespread allegations of being a copyright profiteer within the open-source community.
In an application brought to preclude Geniatech from using Open Source in Satelite receivers, the court denied the same on the following grounds:
- He could not prove the true extent of his contribution to Linux Kernel; and
- He could not prove his copyright ownership of the derivative works, the infringement of which he sought to remedy.
Without any contribution agreement or IP assignment agreement, it’s impossible to measure the true extent of ownership in large projects. In Linux’s case, developer contributions are tracked only by looking at the number and size of commits. The tracking mechanisms (using a tool called Credit) report these commits at a granular level.
But a closer look at McHardy’s contributions reveals that out of approximately 125 source code files attributed to him, he indeed contributed to only one-third (⅓) of them, bringing his entire contributions in Linux Kernel’s code to 0.25%. Evidently, the extent of his IP rights in the Linux Kernel was — in this case — over-reported.
In large projects of this nature, it is common for IP rights to exist in both collective and individual capacities. All contributors jointly hold copyright in the overall work, while each developer retains individual copyright over their specific contributions. These rights coexist, creating a layered structure of ownership within the project.
It then follows that for Mr. McHardy to validly enforce his copyrights, he must have shown ownership of the copyrights to the Linux kernel as a joint author.
IP protection strategies in Open-Source Licensing
For organizations, the issue of licensing involves navigating two competing interests, namely: the economic value in commercial licensing and the community benefits in OSL.
The Proprietary Licensing Model tilts more towards the latter, as it offers a way to protect confidential information, make revenue by way of an initial fee paid to access the software, better control distribution by restricting licensees from inspecting the underlying source code or reverse-engineering the software.
The Open-Source Model occupies the opposing end of the Software licensing spectrum, which we have considered in detail.
Organizations may choose either approach or adopt a hybrid model, depending on their priorities. Ultimately, the goal of any innovation is to ensure that creators reap the rewards of their efforts. While Open-Source Licensing offers clear advantages, it is equally important to safeguard valuable IP rights that merit protection. Beyond understanding how OSLs operate, companies can consider the following strategies to protect their business-critical IP.
Patenting strategy
Organizations can adopt a hybrid approach by open-sourcing certain components of their software while protecting other commercially critical aspects through patents (yes, it’s possible to patent OSS)
Licenses like Apache 2.0 make this possible, as it grants licensees patent rights in the OSS code while allowing the organization to retain patent rights over the proprietary portions. Many companies have perfected this strategy, with Dropbox providing an excellent example. Dropbox open-sourced Lepton, its proprietary image compression technology capable of reducing JPEG sizes by an average of 22%.
While the vast storage savings achieved by Lepton added significant business value and justified keeping parts of the code proprietary and protected through patents, the company recognized greater benefits from open-sourcing the technology.
By using the Apache 2.0 license, Dropbox implemented a hybrid approach that would boost public access, and user adoption rates (as more web browsers incorporate the technology), and attract enhancements from collaborators. Meanwhile, the patent rights in the proprietary code will be retained by the company, thereby maintaining a competitive advantage.
Defensive custom agreements
Some licenses are silent on patent rights. In such a case, companies can include a Custom Patent License or a Termination clause enabling them (as patent holders) to terminate their license once a licensee asserts their patent rights against anyone using the OSS. This is called a “Patent Retaliation Clause” or “Patent Non-assertion Clause”.
Including such clauses prevent a licensee from creating or enforcing new patent rights in derivative source code. The downside to this, however, is that such a company might be precluded from enforcing any patent rights it holds in the OSS. As teams factor this into their decision-making prior to making the source code open-sourced, there are hardly any complications resulting from this.
Keeping of trade secrets
A company may elect to open source certain information and protect certain components — majorly information not codified within the OSS — as trade secrets by keeping them undisclosed.
Consider AI tools. An AI company may open up its machine learning libraries to an Open-Source community of AI developers. These libraries would usually contain generic algorithms and data processing aspects of their solution. However, proprietary algorithms, advanced model weights, and LLM database are made confidential to protect IP that is central to its value proposition.
Trade secret protection is particularly useful where the OSS is not likely to be easily reverse-engineered by competitors without having access to the source codes. Measures like avoiding unintentional disclosures, maintaining confidentiality (NDA) agreements, strict access controls, and cybersecurity will keep mission-critical information under wraps.
Clear contribution agreements and IP assignment clauses
In projects involving multiple collaborators, a contributor agreement sets forth the terms under which parties contribute to the project. IP assignment clauses document the extent of interest in IP of the contributing parties. This can be useful in safeguarding proprietary IP rights while benefiting from collaboration.
Guidelines are also instrumental in shaping the policy agenda and fostering transparency within the developer community. They should also set out the modalities for participating in projects, conflict resolution policy, and how decisions are made.
Wrap up
Companies understand all too well that balancing open-source principles with the protection of proprietary IP rights is essential. As license compliance and safeguarding proprietary assets become top priorities, organizations must seek legal counsel to proactively address potential risks. Deploying a robust IP strategy is equally critical to navigating the competing interests within the developer community and ensuring both innovation and asset protection are effectively managed.
