Open Source Software Defined.
OSS: The Historical Context
OSS in Business
- OSS in Industry and Consumer Electronics
- Response of Established Tech Companies to OSS
The OSS Licenses
Current OSS Legal Issues
OSS in the Courts
GLOSSARY
Significant Legal Cases in the US Involving Open Source Software
Governance of OSS in Organizations

Open Source Software Defined.

Open Source (OS) software represents an initiative to grant programmers greater liberties in adapting and utilizing computer applications that might typically be inhibited by exclusive source code involving considerable limitations on access and utilization. As an escalating number of corporations turn towards open source as a substitute, comprehending the benefits and drawbacks of invoking this style of software in the corporate milieu is paramount. Additionally, it is crucial to grasp the potential licenses applicable, such as the GNU General Public License and the GNU Lesser General Public License.

The purported benefits of OS include cost-effectiveness and the simplicity of customization. OS can typically be downloaded free of charge or at a minimal cost. A potential drawback, however, is the scant documentation and absence of technical assistance. However, supportive user communities and online resources offer help. Private enterprises have also begun to partake in the development and backing of OS.

OS operates on the principle of broad availability of the code, accessible to all. But the usage of OS is covered by OS licenses that ensure the OS code that gets developed is also accessible to others. Contrary to proprietary source code, OS is not safeguarded by patents, copyrights, or trade secrets.

Open source software (OSS) has become a significant aspect of the software industry in the last two decades, tracing its roots back to US academia in the early 1970s and gaining mainstream prominence in the 1990s. Today, OSS is nearly ubiquitous, and its influence and adoption continue to grow. OSS is defined by its licensing model, which grants users specific freedoms. There's a variety of OSS licenses, each differing in terms of clarity, length, and legal implications. The future of OSS looks bright, bolstered by several factors:

The Internet: OSS benefits from the ease of internet access, with modules available on sites like sourceforge.net and github.com. This aligns OSS with other internet-fueled software delivery methods, including virtualization, software-oriented architecture (SOA), software as a service (SaaS), and cloud computing. These methods have seen increased adoption in the 2010s, paralleling OSS’s growth.
Industry Evolution: The software industry is transitioning from traditional licensed software to remote, service-based computing. This generational shift further encourages the adoption of OSS.
Mobile Devices: The proliferation of smartphones and tablets, which challenge the primacy of desktops and laptops, has expanded the market for OSS. Operating systems like Android and Tizen, along with app store applications, represent new opportunities for OSS.
Internet of Things (IoT): IoT, which involves connecting physical devices with software and sensors, is a major technological advancement where OSS plays a crucial role. OSS is integral both in device firmware and in middleware platforms facilitating device communication.
Enterprise Use: Previously viewed as a commoditized version of proprietary software, OSS now underpins emerging software trends such as containerization, mobile, big data, and artificial intelligence. Major tech companies like Google and Microsoft contribute to OSS development. The Synopsys 2019 Open Source Security and Risk Analysis report found OSS in over 96% of surveyed codebases, accounting for more than 60% of the code in these codebases.
Quality and Competitive Advantage: OSS, often supported by robust communities, is generally perceived as higher quality than proprietary code. It accelerates market entry, frees resources for more valuable tasks, provides a competitive edge, encourages standardization, and aligns with the trend towards cloud- and service-based computing.
Overall, OSS's growing scope and appeal are driven by its adaptability to modern technological trends and its role in advancing industry standards.

OSS: The Historical Context

Origins of the OSS Movement

The Open Source Software (OSS) movement's roots lie in a cultural mindset prevalent in U.S. academia during the 1960s and 1970s and fully emerged around 1984 as a response to the limitations of the proprietary software model. This attitude was a response to the limitations imposed by intellectual property (IP) laws and was a reflection of the era's counter-culture. The movement particularly opposed the commercial use of UNIX, an operating system developed at Bell Laboratories by AT&T employees. This movement drew inspiration from the ideals of freedom, community, and voluntary cooperation established in 1776. A critical issue with proprietary software was that companies typically distributed only object code, not source code, making it impossible for users to modify the software. This meant that users were entirely reliant on the software company for updates, bug fixes, and were subject to the company's pricing.

Driven by a desire for autonomy and collaboration, the free software movement advocated for the public's right to freely study, modify, and share software. This philosophy was centered around empowering users to support themselves and their community through open collaboration. Richard Stallman, a prominent figure in the movement, emphasized that the term "free" in "free software" stands for freedom, not the absence of cost. He contrasted this with the proprietary software model, which, in his view, kept users dependent and disconnected due to its secretive nature. This movement laid the foundation for the modern open source software model, emphasizing transparency, user empowerment, and community-driven development.

The Free Software Foundation and the Four Freedoms

In 1985, Richard Stallman, formerly of MIT, founded the Free Software Foundation (FSF), a non-profit organization committed to developing and supporting "free software." The FSF's role included managing the GNU Project, holding copyrights for its software, and enforcing its licenses. The FSF defined "free software" by four essential freedoms: the freedom to run the software for any purpose, to study and modify the software through access to its source code, to redistribute copies, and to distribute improvements to the software.

GNU, the GPL, and Linux

Stallman initiated the GNU Project in 1983, aiming to create a free operating system as an alternative to UNIX. The project adopted the GNU General Public License (GPL). By 1992, all components except the operating system kernel were completed. The gap was filled when the GNU components were combined with a new kernel, Linux, resulting in the complete GNU/Linux operating system under the GPL.

The Open Source Initiative and the Open Source Definition

In the late 1990s, some OSS community members, led by Bruce Perens and Eric Raymond, perceived the strong anti-IP stance of Stallman and others as a barrier to OSS's broader acceptance. In response, they founded the Open Source Initiative (OSI) in 1998 to promote OSS based on practical benefits rather than ethical or philosophical reasons. The OSI manages the Open Source Definition (OSD), setting criteria for what constitutes open-source licensing. This includes reviewing and approving licenses that meet the OSD's ten criteria. The OSD acknowledges many types of licenses, each imposing different obligations, and the OSI's role is crucial in determining whether a software license qualifies as open source under these criteria.

Open Source Initiative (OSI) Definition The OSI has established a detailed definition of what constitutes an open source license. This definition is not met by merely licensing source code confidentially. Instead, the OSI outlines nine essential criteria for a license to be recognized as truly open source:

Free Redistribution: The license must allow free redistribution of the software as part of a larger software distribution.
Source Code Availability: The software must be available in source code form, ensuring accessibility and contrast with proprietary models.
Derived Works: The license must permit modifications and derived works under the same terms as the original software.
Integrity of Author's Source Code: Modification restrictions are permissible if they ensure the original source code remains unchanged for community visibility.
Non-Discrimination: The license must not discriminate against any person or group.
No Field of Use Restriction: It must not restrict the software's use in specific fields, such as only for educational purposes.
License Distribution: Rights attached to the program must apply to all recipients without the need for a separate license.
License Must Not Be Specific to a Product: The rights must not depend on the software being part of a particular software distribution.
License Must Not Restrict Other Software: There should be no restrictions on other software distributed alongside the open-source software.

Notably, OSI recognizes both the GNU GPL and the BSD License as valid open source licenses, despite their differing stances on open source principles.

Free Software Movement's Classification

The Free Software movement categorizes open source licenses with a focus on five key elements, aligning with but broader than OSI's criteria:

Freedom to Run the Program: This includes for any purpose.
Freedom to Access and Modify Source Code: Ensuring user autonomy in software use and improvement.
Freedom to Redistribute Copies: Encouraging sharing and collaboration.
Freedom to Release Modifications Publicly: Promoting communal development and improvement.
Copyleft Status: This element differentiates licenses by their ability to ensure perpetual freedom in software use and modification.

Open Source Defined.

Free redistribution. Software must be made available for redistribution without payment.

Source code. Software must be distributed with the source code or well-publicized access to it.

Derived works. License must allow modification of the software and distribution of resulting derived works.

Integrity of the author's source code. Distribution of "patch files" used to recreate the derived work (rather than full source code) must be permitted.

No discrimination against persons or groups. License terms must be the same for all licensees.

No discrimination against fields of endeavor. For example, limiting to non-commercial purposes is not permitted.

Distribution of license. Must be no need to execute extra licenses for redistributed software.

License must not be specific to a product. License rights must not depend on the software being distributed with other specified software.

License must not restrict other software. The license must not place restrictions on software distributed together with the licensed software.

License must be technology-neutral. The license terms must not vary according to the type of technology involved.

Contemporary Open Source Software Movement

The Open Source Software (OSS) movement has evolved with the support of key groups advocating for its compliant use, such as:

Software Freedom Law Center (SFLC): Led by Eben Moglen, a former General Counsel for the FSF, SFLC offers legal services to support and promote OSS.
Gpl-violations.org: This organization aims to raise awareness about the misuse of GPL-licensed software.
Regional FSF Affiliates: Groups like the Free Software Foundation Europe (FSFE) extend the FSF's reach globally.

OSS in Business

The widespread adoption of OSS is driven by a unique blend of factors. OSS projects often foster communities of developers dedicated to improving and maintaining the code, offering enhancements and fixes at no cost. Major OSS initiatives typically undergo thorough peer reviews, ensuring that their code matches or exceeds the quality of commercially produced software.

The ready availability of source code allows OSS to quickly adapt to new hardware platforms, ensuring its longevity beyond the lifespan of the original hardware. This contrasts with proprietary software, which may become obsolete if it's no longer financially viable to maintain it for outdated platforms.

In today's fast-paced competitive environment, where time-to-market is crucial, using pre-built OSS components for basic tasks can significantly reduce development time. This approach is evident across various sectors, notably in consumer electronics, as seen in the rise of the Android mobile operating system. OSS also impacts sectors like data management, healthcare, and financial services.

In developing countries, OSS can catalyze the growth of a local software industry. Governments in nations like Brazil, Russia, China, India, and South Africa are increasingly adopting OSS, facilitating local customization, integration, and support services.

OSS in Industry and Consumer Electronics

OSS is a cornerstone of innovation in many industries. It powers the world's top 500 supercomputers, a significant increase from just one in 1998. In consumer electronics, OSS stimulates market competition, evident in products like virtual reality headsets, HDMI streaming sticks, and broadband routers. For software developers, especially in startups, OSS reduces costs, accelerating product development and market entry.

Consumers benefit from OSS through free internet browsers, office suites, and audio editors, which eliminates the need to purchase software or rely on bundled software with hardware purchases.

Response of Established Tech Companies to OSS

Technology companies have varied in their response to the rise of OSS. Initially, software developers were more resistant compared to hardware vendors who could integrate OSS into their products. Recently, major IT companies have fully embraced OSS:

Open Invention Network (OIN): Formed by companies like IBM, NEC, Novell, Philips, Red Hat, and Sony, OIN protects OSS from patent infringement, offering free licenses to its members.
Rise of OSS-Based Companies: Companies like Red Hat have shown remarkable financial growth, leading to significant acquisitions like IBM's $34 billion purchase of Red Hat in 2019.
Microsoft's Transformation: Once an OSS opponent, Microsoft has dramatically shifted its stance, joining OIN with 60,000 patents and acquiring GitHub for $7.5 billion. It is now a leading contributor to GitHub.

Other OSS-focused firms like Canonical, Acquia, and EnterpriseDB are also thriving. Google's Android OS dominates the smartphone market, generating significant online advertising revenue.

In summary, OSS is increasingly central to both technological innovation and business strategy, with its impact felt across a wide range of industries and consumer markets.

The OSS Licenses

Plethora of OSS Licenses

In today's legal tech landscape, the variety of Open Source Software (OSS) licenses is vast, with hundreds in use that differ in length, clarity, purpose, and legal implications. These licenses range from the more demanding copyleft GPL to shorter licenses with fewer explicit terms. Broadly, OSS licenses fall into two categories:

Permissive OSS Licenses: These licenses typically require that any distribution of the original OSS adheres to the same terms as the original provision. Their key characteristic is compatibility with proprietary "closed source" software licenses. Permissive licenses allow licensees to modify, adapt, and integrate OSS code with proprietary code without imposing significant restrictions on these alterations or how the resulting derivative works are licensed.
Restrictive OSS Licenses (also known as "reciprocal," "hereditary," or copyleft licenses): These licenses extend beyond the scope of permissive licenses by imposing licensing conditions when OSS is modified, adapted, or combined with other software (proprietary or OSS) to create derivative works. The terms of restrictive licenses typically apply to both the original OSS and any derivatives, potentially affecting organizations that use restrictive OSS in conjunction with proprietary software. In such cases, there's a risk that the proprietary software might inadvertently become subject to the OSS license.

For those utilizing OSS in a business context, it is crucial to start by identifying the specific OSS and understanding the licensing terms under which it is provided. Assessing these terms is essential to determine if they carry any risks for your business operations. To aid in this process, some leading OSS service providers publish data on trends in OSS usage under common licenses. The following table, based on the latest data, illustrates these trends and helps in making informed decisions regarding OSS license selection and management.

| License | Permissive or Restrictive? | 2016 % | 2018 % | Change % | |--------------------------|--------------------------------|------------|------------|--------------| | MIT | Permissive | 25 | 26 | 1 | | Apache 2.0 | Permissive | 15 | 22 | 7 | | GPL 3.0 | Restrictive | 19 | 16 | -3 | | GPL 2.0 | Restrictive | 15 | 10 | -5 | | LGPL | Restrictive | 6 | 6 | 0 | | BSD 3 | Permissive | 6 | 5 | -1 | | Microsoft Public License | Permissive | 5 | 3 | -2 | | BSD 2 | Permissive | 3 | 2.2 | -1 | | Eclipse 1.0 | Restrictive | 1 | 1 | 0 | | Zlib | Restrictive | 1 | 1 | 0 |

This table provides an overview of various OSS licenses, categorizing them as either permissive or restrictive, and shows the percentage change in their usage between 2016 and 2018.

In the evolving landscape of Open Source Software (OSS), a significant trend has emerged, highlighting a shift in licensing preferences. Over the past decade, there has been a noticeable decline in the use of GPL licenses, known for their stringent "copyleft" terms originating from the Free Software Foundation (FSF). In 2010, GPL-licensed OSS constituted over half of all OSS applications. Fast forward to 2018, and the combined usage of GPL licenses has diminished to just 26%.

Contrastingly, the popularity of more lenient licenses, specifically Apache, BSD, and MIT, has surged. These permissive licenses represented a mere 14.44% of the OSS license share in 2010. By 2018, their collective usage skyrocketed to 55.2%, nearly quadrupling in eight years. This trend underscores a growing preference for permissive licenses in the OSS community.

The move from restrictive "copyleft" licenses to more permissive ones is particularly evident in high-profile OSS projects like Android. Developed by Google Inc., Android is a leading OSS operating system for mobile devices. As of May 2019, there were over two and a half billion monthly active Android devices. The Android project's choice of the Apache License 2.0 aligns with its philosophy of promoting openness and choice in the mobile world. The project's stance is that while they encourage open and modifiable devices, they do not want to impose this approach through restrictive licenses like LGPL, especially given the compliance challenges they present.

The current OSS licensing landscape is, therefore, a tale of two contrasting trends: the expansion of permissive licenses and the decline of restrictive ones. Though restrictive licenses like GPLv3 still account for a significant 16% of OSS usage, the trend towards permissive licensing is evident. As of 2015, the use of permissive OSS licenses surpassed that of restrictive ones, indicating a broader range of licensing options for OSS adopters.

This shift has significant implications for organizations formulating their IT strategies. The choice of OSS and its licensing regime should be a key consideration, influencing adoption and usage decisions.

Overview of Common OSS Licenses

The GNU General Public License (GPL)

The most widely recognized and employed Open Source (OS) license is the GNU General Public License (GPL). The GPL, authored by Richard Stallman and the FSF in 1989, is known for its "copyleft" provision, ensuring that freedoms granted by the GPL extend to derivative works. GPLv2 and GPLv3 are its notable versions, each with specific conditions.

The renowned OS operating system, Linux, is licensed under the GNU GPL. An end-user employing the OS under the GNU GPL for strict internal business operations without modifications may not encounter challenges with the internal usage of the untouched OS under the GNU GPL. Nevertheless, if modifications are made to the OS and used internally, risks regarding interoperability and access or utilization by subdivisions or external parties not classified as licensees under the GNU GPL license, may arise. Through an extensive evaluation of the GNU GPL license, a business can assess the pros and cons of invoking the OS under the GNU GPL license.

Lesser GPL (LGPL)

The LGPL, a less intrusive counterpart of the GPL, is often used for software libraries in proprietary programs, allowing them to link with non-GPL code under certain conditions.

For businesses aiming to license software to other entities while preserving some proprietary rights, the Lesser General Public License (LGPL) might be more suitable. It permits the licensee to amalgamate OS with proprietary software by creating links to the proprietary software, without mandating the proprietary software to be licensed under the LGPL. This provision allows the developer or business to maintain certain rights to the fundamental code in its proprietary software. The LGPL directly addresses the integration of libraries by computer applications and distinct considerations linked to the utilization of OS libraries are discussed within the license. When contemplating whether the work is based on a library or merely "uses" the library, it's crucial to consider thoroughly. Developers or businesses employing libraries that fall under the LGPL must determine whether they can comply with the LGPL requirements, such as granting any subsequent licensees the right to modify the code for internal use and reverse engineer to rectify bugs.

The following are copies of the GNU GPL and LGPL open source licenses:

gnu_license_v2.pdf

Apache License 2.0

The Apache License 2.0, preferred by Google's Android project, originates from the Apache Software Foundation and supports a range of OSS projects.

MIT License

The MIT License, from the Massachusetts Institute of Technology, is a succinct permissive license.

BSD License

The BSD licenses, originating from the Berkeley Software Distribution, are similar to the MIT license in their permissive nature.

Other OSS Licenses

As of September 2019, the OSI lists 96 approved licenses, encompassing both restrictive and permissive types. This variety reflects the diverse requirements and philosophies within the OSS community.

The OSS landscape is diverse and dynamic, with licensing choices reflecting broader trends in software development and usage. Understanding these trends and the nuances of different licenses is crucial for organizations and developers navigating the world of OSS.

Current OSS Legal Issues

Copyleft, "Contains," and GPL Version 2

GPLv2 Section 2(b)

Section 2(b) of GPLv2 remains the subject of debate and a source of confusion. It sits at the heart of the copyleft mechanism and reads as follows:

"2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work…provided that you also meet all of these conditions:

...b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this license (emphasis added)."

Clause 2(b) works essentially on the 'viral' principle by which the four freedoms (discovered in The Free Software Foundation and the Four Freedoms) are propagated. It specifies that if any distributed or published code is your "work" ("A") which "includes" or is "derived from" the Program (the code licensed under the GPL – "B"), it must also be licensed under the GPL. This means that your work (A) must be licensed under GPL. The challenge arises where your 'work' (A) is a software with a confidential code (due to security or competitive advantage purposes), and it could be argued to 'include' or be 'derived' from B, as adherence to GPL rules would require the source code's publication.

There are three significant points that exacerbate the tension within the context of GPLv2's clause 2(b)---two legal points, and one technical concern:

The initial legal problem emerges due to a stringent interpretation by OSS overseers of what constitutes a "derivative work" under US copyright law and how inclusion is defined under clause 2(b) to comply with copyleft.
The second legal issue is the existence of legal uncertainty. The GPLv2's publication is over two decades old, and seldom has case law addressed clause 2(b)'s meaning.
The technical issue arises from the inherently complex and detailed mechanisms by which A interacts may theoretically 'include' or be 'derived' from B, from a computer science perspective.

The ongoing debates regarding the limits of clause 2(b) and copyleft, both technical and legal, are far-reaching and unresolved. The following paragraphs provide a brief overview of the following:

The functionality of the operating system and software stack concerning a technical background.
Practical examples relating to clause 2(b) such as the functioning of Linux and Java.
Commonly applicable copyright principles associated with clause 2(b).
The application of clause 2(b), particularly regarding Linux and Java.
Additional relevant GPL points touching on the analysis.

The Operating System (OS) and the Software Stack.

To fully grasp the intricacies of the Section 2(b) debate in the context of software operation and compilation, a basic understanding of software architecture is essential. At the core of any computer system is its Operating System (OS), anchored by the kernel. The kernel acts as the authorized intermediary with direct hardware access and as a coordinator, ensuring various software components work harmoniously.

Visualizing this as a layered structure:

The Kernel: Positioned at the base, it interfaces directly with the hardware and manages core functions.
Operating System Components: Sitting above the kernel, this layer includes utilities aiding the kernel, drivers for hardware interaction, and interfaces like hooks and handles that establish rules for software-kernel interaction.
Libraries: These are repositories of pre-written code, facilitating common tasks for various programs. Libraries serve as intermediaries between the OS and applications.
Applications: At the top, these are user-oriented software performing specific tasks.

The kernel, in its authoritative role, manages critical resources like memory space, the processor, and hardware devices. Memory is split into 'kernel space' for the kernel and some utilities, and 'user space' for applications and libraries, with interfaces bridging the two. User space software accesses hardware indirectly via kernel space through system calls.

As the system's coordinator, the kernel efficiently allocates memory and processing resources, manages task prioritization, and controls output display.

Program Integration: Compilation and Linking

Software initially exists as source code – human-readable instructions in a programming language. To execute on a computer, this source code must be converted into executable code (binary or machine code). This transformation, known as compilation, is performed by a compiler. The compiler translates source code into object code and then links this compiled code to create an executable program.

Combining programs can be achieved through various methods:

Static Linking: Here, code, including library code, is permanently integrated into the executable. All relevant object code is copied verbatim, resulting in a larger executable.
Dynamic Linking: Rather than copying all object code, dynamic linking references separate code libraries during runtime, making executables smaller and more memory-efficient.
Plug-ins: These are software components that conform to specific interfaces, loaded by the kernel as needed to perform tasks like printing. Plug-ins, including loadable kernel modules (LKMs), optimize memory use.
System Calls: These are requests from applications to the kernel to perform tasks that the applications themselves are not permitted to execute directly.

Understanding these fundamental concepts is crucial for legal professionals navigating the technical aspects of software law, particularly in the context of open-source licensing and compliance.

Linux

Linux, serving as the kernel for the GNU/Linux Operating System, is licensed under GPLv2 and stands as one of the most significant products in the Open Source Software (OSS) arena. Its enhanced security, stability, and functionality have contributed to its growing usage. Each variant of Linux, often comprising tens of millions of lines of code, is known as a Linux distribution. These distributions are community-driven projects, with notable ones published by Canonical (Ubuntu Linux), Red Hat (Fedora Linux and Red Hat Linux), and OpenSUSE.

Originally designed for desktop computers, Linux has diversified into other areas, including servers and networking devices like firewalls and routers. Despite its modest desktop market share (about 1.5%), Linux dominates the server market, powering approximately 96.5% of the top one million web domains.

The operational mechanics of Linux have sparked discussions regarding the interpretation of GPLv2 section 2(b), particularly concerning the combination of code:

Linux combines utilities and libraries through static linking at compile and link time.
It utilizes dynamic linking for libraries during runtime.
Plug-ins, such as printer drivers (LKMs), are loaded and unloaded as needed.
Applications interact with the Linux kernel through system calls at runtime.

A central point of debate is whether executables created from these combinations are "contained in or derived from" GPL-licensed Linux code.

Scripting

Scripts, which are lists of commands in source code form executed by an interpreter, differ from standalone programs in that they often interact with other applications. While client-side scripting, executed by web browsers, typically modifies web page interfaces in real-time, server-side scripting runs on servers to generate customized web pages, often for interactive websites with extensive database queries.

Both client and server-side scripting contribute to creating dynamic web pages and can be used in tandem for enhanced web experiences.

Java: A Platform-Independent Staple in Software Development

The Java platform, developed by Sun Microsystems and predominantly licensed under GPLv2, is notable for its platform independence. Its core components include the Java programming language and the Java Virtual Machine (JVM). Java applets, which are examples of client-side scripts, dynamically link to Java class libraries during runtime and are executed within web browsers on client computers. Java extends to server technology with servlets and Java Server Pages (JSPs).

Java's feature of inheritance, where .jar files inherit functions from other classes, can pose GPLv2 copyleft issues when published under this license.

Javascript

JavaScript, only loosely related to Java, is another client-side scripting language used in web design. Its usage under GPLv2 can raise copyleft issues. An example of JavaScript in action involves steps where a user interacts with a retailer's website to receive special offers, highlighting two main issues under GPLv2:

The distribution of JavaScript in its source code form and its interpretation as "distribution" under GPLv2.
The possibility of server-side programs that communicate with GPLv2 JavaScript being considered to "contain" or be "derived from" GPLv2 code, thus potentially creating a "work based on" the GPL code.

These points underscore the complexity of GPLv2's application in various software contexts, leading to broader discussions on copyright and software licensing under GPLv2.

Navigating Copyright and the GPL in Software Development

In most jurisdictions, copyright laws have treated computer programs as literary works for several generations. This grants copyright holders exclusive rights to reproduce and create derivative works of their software, as highlighted by US copyright law, which heavily influences the language of GPLv2. To establish a copyright infringement claim in the realm of computer software, one must demonstrate ownership of the copyright, that exclusive rights have been infringed upon, and that such acts constitute infringement.

The GPL code, especially under GPLv2 Section 2(b), becomes a focal point in these discussions. Issues arise around how GPL code (like Linux, Java applets, and JavaScript) interacts with other software and whether these interactions infringe on the copyright holder's exclusive rights. Key considerations include:

Nature of Linking: Whether static or dynamic linking, or the use of plug-ins, leads to the creation of a derivative work.
System Calls: If an application makes system calls to the GPL code through an API, does it result in a work that "contains or is derived from" GPL code?
JavaScript and Web Browsers: The interaction between JavaScript in web browsers and server applications raises questions under GPLv2, particularly around the concept of distribution and derivation.

These scenarios lead to complex legal questions, such as:

Whether the copied material is copyrightable (is it merely a method of operation or an expression of an idea?).
If infringement occurs (is the amount copied substantial enough to constitute infringement?).
The creation of a derivative work (does the combination of GPL and non-GPL code result in a new work?).
Potential defenses, including fair use or implicit licensing.

GPLv2 Section 2(b) and Its Practical Implications

GPLv2 Section 2(b) adds complexity to these issues. It stipulates that any work "contains or is derived from" GPL code must be licensed under the same GPL terms. This section has caused significant debate over what constitutes "containing" or "deriving from" GPL code. Key points include:

Static Linking: Generally considered as creating a work that "contains or is derived from" GPL code.
Dynamic Linking and Plug-ins: More contentious, especially when proprietary drivers interact with Linux as LKMs.
System Calls: There is a broad consensus that system calls, particularly through an API, do not typically trigger GPL obligations.

The Free Software Foundation (FSF), along with industry professionals like Linus Torvalds, have varying interpretations of what constitutes combining code. The FSF emphasizes the nature and depth of communication between the software components in determining whether they form a combined work under GPL.

Interpreting GPLv2 Section 2(b) is challenging and has, in some cases, hindered the adoption of GPL software. Navigating this landscape requires a nuanced understanding of software interactions and the legal implications of combining GPL and non-GPL code. This complexity underscores the need for careful legal and technical analysis in software development and licensing.

The key obligations under the LGPL v3 are as follows:

Source Code Distribution: Provide the complete, corresponding source code of the LGPL library used, including any modifications, with your application or device. This can be done directly or via a written offer with instructions to obtain the source code. This is mandatory even if no modifications to the library were made. This ensures users have access to the original library code.
Library Modification and Facilitating Library Replacement: Users should be able to modify, relink, and replace the LGPL library with a different version if they choose. This includes permitting reverse engineering. Under LGPLv3, it’s explicitly required that users must be able to run the re-linked binary and sufficient installation information must be provided. This effectively prohibits the creation of closed, non-modifiable devices This is often achieved through dynamic linking, which clearly separates LGPL code from proprietary code.
- If you dynamically link the LGPL library, you can keep your application's source code proprietary. This is because dynamic linking typically constitutes a “work that uses the library.” However, with static linking, the application might not be considered just a “work that uses the library” and could be subject to the LGPL. To avoid this, it’s advisable to either dynamically link the LGPL library or release your application’s source code under the LGPL.
- But note, platforms like iOS and Android are known to pose challenges, as they typically don't allow users to replace libraries. The LGPL requires clear documentation of the process for substituting your version of the LGPL library with a user-compiled version. This requirement often makes LGPL impractical on such platforms.
Full Compliance Required for Distribution: If your application or device doesn’t fully comply with all LGPL requirements, its distribution is prohibited. This includes scenarios where patent licenses restrict the application’s distribution.
Non-negotiable Freedoms: The freedoms granted by the LGPL cannot be restricted or negotiated with recipients. This means that terms that limit LGPL rights cannot be imposed, including distribution channels like app stores that may have incompatible rules with LGPL.
Informing Users of Their Rights: Users must be notified of their rights under the LGPL. This involves providing them with a copy of the LGPL license text and displaying a prominent notice about the use of the LGPL library. Concealing the use of an LGPL library is not allowed.
DRM and LGPLv3: While the LGPL v3 does not prohibit DRM implementation, it stipulates that breaking DRM should not prevent free distribution of the software.
Patent Clauses in LGPL v3: Note, the LGPL v3 includes specific patent clauses to prevent enforcement of patent claims against other licensees of open-source libraries.

Understanding the Legal Nature of the GPL

A pivotal question in the legal tech world is whether the General Public License (GPL) is a mere license or a contract. This distinction has significant implications:

Enforceability: A contractual licensee can enforce terms against the licensor, unlike a bare licensee.
Implied Terms: Courts may imply non-express terms into a contractual license but not into a bare license.
Remedies for Breach: In the event of a GPL breach, if it's a contract, courts might grant specific performance, compelling a licensee to provide source code access.

The Free Software Foundation (FSF) views the GPL as a conditional bare copyright license, a stance supported by the Jacobsen v. Katzer decision (Federal Circuit 2008) before its settlement. However, some experts argue that the GPL begins as a unilateral contract, becoming bilateral when software is modified or distributed, as indicated by GPLv2 Section 5. The Artifex case further fueled this debate, especially regarding GPL as a contract.

If the GPL is merely a copyright license, US legal relief would be limited to copyright infringement remedies. Also, the lack of explicit governing law or jurisdiction clauses in GPLv2 adds complexity to international cases.

Tivoization and GPLv3’s Response

"Tivoization" refers to TiVo, Inc.'s practice of using Digital Rights Management (DRM) in its Linux kernel-based set-top boxes to prevent modifications. This method, while publishing the software, effectively locks modifications using DRM. GPLv3 addresses this in Section 6 by mandating that distributed software with consumer products must include necessary "installation information" for running modified software versions.

Patents and GPLv3

GPLv3 also addresses patent issues, aiming to protect OSS users from patent infringement claims. It prevents deals like the Microsoft-Novell agreement (2006), extending patent licenses granted by a patentee distributing GPL-licensed software to all software recipients.

Software as a Service (SaaS) and OSS Licensing

SaaS, where software is hosted and accessed via a web browser, raises questions about source code availability under OSS licenses. Except for the GNU Affero General Public License (AGPL), current OSS licenses don't typically consider SaaS hosting as redistribution. AGPL, a modification of GPL version 3, fills this gap by requiring source code availability if modified AGPL software is run on a server accessible to users. This effectively closes a loophole in the GPL that SaaS could exploit to bypass copyleft provisions.

OSS in the Courts

GLOSSARY

Application Programming Interface (API): An API, often referred to as "hooks and handles," is a set of protocols and tools for building software applications. It defines the methods and data formats that other software can use to communicate with an application or operating system. APIs are crucial for developing software that interacts with other software components, operating systems, or microservices, and are often made available even when the source code is proprietary.

Device Driver: A device driver is a specialized software component that allows a computer's operating system to interact with hardware devices. It acts as a translator, converting general input/output instructions into specific commands that the hardware device understands and can respond to.

Firmware: Firmware is a specific type of computer software that provides low-level control for a device's specific hardware. It can be embedded in flash ROMs or memory chips of the hardware and is crucial for basic device operations. Firmware can be updated to improve performance or add new features.

Kernel: The kernel is the core component of a computer's operating system, managing the system's resources and communication between hardware and software components. It allocates processing time and memory to programs, handles system calls from applications, and ensures security and efficiency in operations.

Linux: Developed by Linus Torvalds, Linux is a widely used open-source operating system kernel. Originating as a project to create a free alternative to MINIX (a UNIX-like system), it was released in 1991 and has since become the kernel for various operating systems, notably in GNU/Linux distributions.

Netfilter/Iptables: Netfilter/Iptables is an integral part of the Linux kernel, providing a framework for network packet filtering and manipulation. It is used in firewall solutions, network address translation, and packet logging and is crucial for network security and management in Linux-based systems.

Open Source Software (OSS): OSS refers to software with source code that anyone can inspect, modify, and enhance. OSS promotes collaborative development and distribution, allowing users to study, change, and distribute the software to anyone and for any purpose.

Copyleft: A method for making a program (or other work) free and requiring all modified and extended versions of the program to be free as well. Copyleft software licenses grant the right to freely distribute copies and modified versions of a work, requiring that the same rights be preserved in derivative works.

Source Code: The human-readable list of instructions that a programmer writes. When written in a high-level programming language, it needs to be processed by a compiler to convert it into machine code or an interpreter to be executed.

GPL (General Public License): A widely used free software license that guarantees end users the freedom to run, study, share, and modify the software. The GPL is a copyleft license, which means that derivative work must be open source as well.

These definitions provide a foundational understanding of key terms in the realm of open source software and its legal considerations.

Significant Legal Cases in the US Involving Open Source Software

The SCO-Linux Litigation Series

This series involved multiple lawsuits initiated by SCO Group against various GNU/Linux users, distributors, and Novell. It began after SCO claimed rights over UNIX, which had been initially developed by AT&T and later transferred to Novell. SCO's assertions led to legal disputes over copyright ownership and infringement claims against GNU/Linux distributors and users. A critical decision in 2007 by the US District Court for the District of Utah ruled that Novell retained UNIX copyrights, not SCO. Subsequent legal actions, including bankruptcy filings and appeals, have kept this litigation in flux, with some aspects still unresolved.

Jacobsen v. Katzer and Kamind Associates, Inc.

This case was crucial for the open source movement, challenging the legal standing of open source licenses. The US Court of Appeals for the Federal Circuit overturned a lower court ruling, establishing that breach of certain open source license conditions could lead to copyright infringement actions. This decision affirmed the enforceability of open source licenses in protecting the rights of software creators, culminating in a settlement agreement in 2010.

Artifex Software, Inc. v Hancom, Inc.

In this case, Artifex alleged that Hancom breached the AGPL license terms by not releasing the source code of its software, which incorporated Artifex's Ghostscript. Although settled out of court, the District Court's refusal to dismiss Artifex's claims reinforced the notion that open source license violations could constitute contractual breaches.

FSF v. Cisco Systems Inc.

This dispute arose when Cisco's subsidiary, Linksys, used a Linux distribution in its products without complying with GPL requirements. The Free Software Foundation (FSF) sought compliance from Cisco, eventually leading to a lawsuit and subsequent settlement in 2009. The settlement required Cisco to enhance its GPL compliance measures, including the appointment of a Free Software Director at Linksys and monetary contributions to the FSF.

Other Notable US Litigation

Despite the widespread use of GPL and other open source licenses, there has been a relatively low volume of litigation in the US. This may be attributed to the active roles of organizations like the FSF and the Software Freedom Law Center (SFLC) in promoting compliance outside the courtroom. For example, the SFLC initiated several lawsuits related to BusyBox software under GPLv2, most of which were settled out of court, emphasizing the preference for negotiated compliance in the open source community.

These cases collectively highlight key legal issues surrounding open source software, from copyright ownership disputes to the enforceability of open source licenses. They underscore the evolving nature of legal interpretations and enforcement mechanisms in the realm of open source software.

Legal Developments in Open Source Software: The German Perspective

GPL Enforcement in Germany by gpl-violations.org In Germany, significant strides in GPL enforcement have been led by gpl-violations.org, founded by Harald Welte. While many of these enforcement actions have been resolved informally, several key cases have made it to the German courts, demonstrating the legal weight of GPL licenses. Notable cases include:

Sitecom (2004): The Munich Regional Court confirmed an injunction against Sitecom for distributing OSS in violation of the GPL, specifically for using netfilter/iptables without providing the source code.
Fortinet (2005): Fortinet faced legal action for incorporating GPL software in its firewall and anti-virus products and attempting to conceal its usage. The Munich District Court issued a preliminary injunction, mandating GPL compliance.
D-Link (2006): D-Link was sued for selling devices with Linux kernels without adhering to GPL requirements, including source code disclosure. The Frankfurt court ruled in favor of gpl-violations.org, emphasizing the enforceability of GPL terms.
Skype (2007): Skype was found to have breached the GPL in distributing a VoIP handset with an embedded Linux kernel without accompanying source code. The Munich Regional Court's judgment was accepted by Skype, which withdrew its appeal.
Fantec (2013): In a case concerning incomplete source code provision for a Linux-based firmware media player, the Hamburg District Court ruled against Fantec, highlighting that companies cannot solely rely on supplier assurances for GPL compliance.

Other German GPL Cases

AVM v. Cybits (Date): In a dispute over modification of firmware in DSL routers, the court sided with Cybits, affirming the GPL’s provisions for modification and reproduction of the software.
VMware (2015-2018): Allegations of GPL violations in VMware’s ESXi product were brought by developer Christoph Hellwig, supported by the Software Freedom Conservancy. However, the Hamburg District Court and subsequent appeal favored VMware, citing insufficient evidence of specific code violations.

FSF’s Informal Interventions

The Free Software Foundation (FSF), akin to gpl-violations.org, typically engages in informal measures when addressing potential GPL license violations. These measures usually start with open-source software (OSS) advocates examining software or hardware for indications of GPL usage. Suspected violations are often publicized on blogs or online forums, sparking further analysis by the community.

This method of public disclosure can be effective in prompting GPL compliance. When necessary, the FSF or gpl-violations.org may initiate direct discussions with the alleged violators. While court action is rare, it remains a potential final step if informal resolutions fail. To date, there are no known UK legal cases initiated by the FSF for GPL enforcement.

FSF Europe’s Involvement with BT's Home Hub

A notable instance involving FSF Europe was its challenge to BT's Home Hub device. FSF Europe contended that BT distributed this network device, which used the Linux kernel, without providing the complete firmware source code. Despite BT's admission of using a GPL-covered Linux kernel and its subsequent release of parts of the source code, FSF Europe maintained that BT had not fully complied with GPL requirements. Specifically, FSF Europe argued that BT failed to provide essential components like the top-level Makefile and scripts for firmware image generation. Despite these claims, no further legal actions were pursued against BT.

Governance of OSS in Organizations

As OSS becomes more integrated into organizational operations, there's a growing focus on formal OSS governance and compliance strategies. This shift is in response to the ongoing legal ambiguities surrounding OSS's copyleft principles. Organizations are increasingly recognizing the need to find a balance between leveraging the freedoms and benefits of OSS and fulfilling the obligations imposed by OSS licenses. This balance is crucial for ensuring responsible and compliant use of OSS, particularly in a legal landscape where the intricacies of copyleft are yet to be fully resolved in court.

Documents Article