Viral Licenses Explained: GPL, AGPL, and Copyleft

Understanding Viral Licenses

What Makes a License "Viral"?

A viral license "infects" derivative works with its terms. If you modify or extend viral-licensed code, your changes must typically be released under the same license.

Key Characteristics

• Reciprocal sharing: Modifications must be shared
• License persistence: Same license applies to derivatives
• Source disclosure: Source code must be made available
• No additional restrictions: Cannot add extra limitations

Major Viral Licenses

GPL (GNU General Public License)

GPLv2

• Released: 1991
• Used by: Linux kernel, Git, WordPress
• Key requirement: Source code for distributed binaries
• Trigger: Distribution of binary

# GPLv2 obligations triggered by:
- Distributing compiled binaries
- Selling products containing GPL code
- SaaS deployment (generally NOT triggered)

GPLv3

• Released: 2007
• Additional provisions: Patent protection, anti-tivoization
• Used by: GCC, GIMP, Bash
• Key difference: Prevents hardware restrictions

AGPL (Affero General Public License)

The "network copyleft" license:

• Trigger: Network use (including SaaS)
• Requirement: Provide source to network users
• Used by: MongoDB (formerly), Nextcloud, Mastodon

// AGPL Example - Must share source even for SaaS
if (userAccessesOverNetwork) {
    mustProvideSourceCode = true;
}

LGPL (Lesser General Public License)

The "library copyleft" license:

• Allows: Proprietary software to link to LGPL libraries
• Requires: Share modifications to library itself
• Used by: GTK, Qt (dual-licensed), glibc

Other Copyleft Licenses

How Viral Licenses Spread

Direct Inclusion

# Your proprietary file
import gpl_library  # Now your code may need to be GPL

def my_function():
    gpl_library.function()  # Using GPL code

Static Linking

// Compiling GPL code into your binary
#include "gpl_header.h"  // Creates derivative work

int main() {
    gpl_function();  // Your binary must be GPL
}

Modification

// Modifying GPL code
class MyClass extends GPLClass {  // Derivative work
    // Your additions must be GPL
}

The Derivative Work Boundary

What Constitutes a Derivative Work?

• Copy-pasting GPL code
• Modifying GPL source files
• Static linking to GPL libraries
• Subclassing GPL classes

• Dynamic linking (debated)
• Separate process communication
• Network API calls
• Data format compatibility

Gray Areas

# Uncertain scenarios

# 1. Plugin systems
def my_plugin():  # Is this derivative?
    return gpl_host.api_call()

# 2. Macro/Template expansion
GPL_MACRO(my_code)  # Expanded at compile time

# 3. Interpreted languages
eval(gpl_code + my_code)  # Combined at runtime

Working with Viral Licenses

Isolation Strategies

1. Process Separation

# Safe: Separate processes
./proprietary_app | ./gpl_tool

2. Network Services

# Safe: Network API
import requests
response = requests.get("http://gpl-service/api")

3. Clean Room Implementation

• Read specifications, not code
• Independent implementation
• No copy-paste
• Document development process

Compliance Strategies

For Businesses

1. Audit Dependencies

# Scan for viral licenses
license-scanner --fail-on GPL,AGPL,LGPL

1. Establish Boundaries

[Proprietary Core] <--> [API Layer] <--> [GPL Components]

1. Alternative Components

• Replace readline (GPL) with libedit (BSD)
• Use PostgreSQL (PostgreSQL) instead of MySQL (GPL)
• Choose OpenSSL (Apache 2.0) over GNU TLS (LGPL)

For Open Source Projects

1. Choose Compatible License

• GPL projects can use: GPL, LGPL, MIT, BSD, Apache
• AGPL projects need AGPL-compatible code
• Consider dual licensing for flexibility

1. Document License Rationale

## Why We Chose GPL

1. Ensure improvements benefit community
2. Prevent proprietary forks
3. Level playing field for competitors

Common Misconceptions

Myth 1: "GPL Prohibits Commercial Use"

Myth 2: "Using GPL Software Internally Requires Disclosure"

Myth 3: "GPL is Anti-Business"

Myth 4: "Dynamic Linking Avoids GPL"

Myth 5: "AGPL Affects All Network Software"

Real-World Implications

For Startups

Consideration: Fast development vs. license obligations
Strategy: Use GPL for non-core components
Risk: Acquisition complications
Mitigation: Clear license boundaries

For Enterprises

Consideration: Compliance across thousands of projects
Strategy: Automated scanning and approval workflows
Risk: Supply chain contamination
Mitigation: Vendor license requirements

For Developers

Consideration: Career and project impact
Strategy: Understand before contributing
Risk: Employer IP conflicts
Mitigation: Contribution agreements

license compatibility Matrix

Detection and Compliance Tools

Scanning Tools

# FOSSology - Comprehensive license scanning
fossology --repo /path/to/code

# Scancode - Detailed license detection
scancode --license --copyright /path/to/code

# REUSE - FSFE compliance tool
reuse lint

CI/CD Integration

# GitHub Actions example
- name: License Check
  uses: fossa/fossa-action@v2
  with:
    api-key: ${{ secrets.FOSSA_API_KEY }}
    fail-on: GPL-3.0,AGPL-3.0

Best Practices

1. Clear Documentation

## License

This project is licensed under GPL-3.0.
Commercial licensing available - contact sales@company.com

### Third-party licenses
- Component A: MIT
- Component B: Apache-2.0  
- Component C: GPL-3.0 (isolated in subprocess)

2. License Headers

# [SPDX](/tools/spdx-tools)-License-Identifier: GPL-3.0-or-later
# Copyright (C) 2024 Your Name

3. Contribution Guidelines

## Contributing

By contributing, you agree that your contributions will be licensed under GPL-3.0.

Future of Copyleft

Trends

• Declining new projects: Fewer choosing strong copyleft
• Permissive shift: Move toward MIT/Apache
• New models: Source-available, fair-code licenses
• Network copyleft: Growing importance with cloud

Evolving Landscape

• Courts beginning to rule on GPL interpretation
• New licenses addressing modern development
• Container/microservice architecture impacts
• AI/ML training data questions

Related Articles

• Latest SBOM Standards
• CycloneDX vs SPDX
• Supply Chain Security
• SBOM Automation Guide
• Complete SBOM Tooling Overview

Conclusion

Viral licenses serve important purposes in open source: ensuring freedom, preventing proprietary lock-in, and building collaborative communities. While they require careful consideration in commercial contexts, they're neither inherently good nor bad—they're tools with specific characteristics that may or may not align with your goals.

Understanding these licenses helps you:

• Make informed decisions
• Avoid legal issues
• Contribute effectively
• Build sustainable projects

Whether you choose to use, avoid, or embrace viral licenses, the key is understanding their implications and planning accordingly.