FOSSA OSS Policy Best Practices Guide

🚧

Important Disclaimer

This guide reflects common patterns observed across FOSSA's customer base and incorporates insights gathered through our work with open-source compliance teams. It is intended to provide general best-practice guidance for configuring license compliance policies. It is not a substitute for legal advice, nor does it represent a legal opinion.

Organizations should apply these recommendations in alignment with their own internal policies, governance standards, and risk tolerance.

Overview of Available Policies

FOSSA provides three core license compliance policies designed for different distribution models:

1. Standard Bundle Distribution - General applications and software bundles
2. Website/Hosted - Server-side applications and SaaS products
3. Single Binary - Mobile apps, embedded systems, and compiled binaries

When to Apply Each Policy

Standard Bundle Distribution Policy

Apply to Projects When:

• Building desktop applications, CLI tools, or general software packages
• Distributing compiled binaries or installers to end users
• Creating software libraries or SDKs for redistribution
• Developing plugins or extensions for third-party applications

Best For:

• Traditional software products with standard distribution models
• Projects where you need moderate flexibility with copyleft licenses
• Applications where users install and run the software locally

Key Benefits:

• Allows most GPL licenses as "flagged" (requiring review but not blocked)
• Balances compliance requirements with development flexibility
• Good starting point for most commercial software projects

Website/Hosted Policy

Apply to Projects When:

• Building SaaS applications, web services, or APIs
• Developing backend services where code runs server-side only
• Creating websites or web applications accessed through browsers
• Building microservices or cloud-native applications

Best For:

• Any application where end users never receive the source code
• Server-side components of multi-tier applications
• Internal tools and services used within your organization

Key Benefits:

• Most permissive regarding GPL-family licenses (only blocks AGPL)
• Recognizes that server-side code doesn't trigger distribution requirements
• Allows maximum flexibility for backend development

Single Binary Policy

Apply to Projects When:

• Building mobile applications (iOS, Android)
• Developing embedded systems or IoT devices
• Creating statically-linked executable binaries
• Building firmware or system-level software

Best For:

• Applications where all dependencies are bundled into a single distributable
• Scenarios with strict license compliance requirements
• Products where source code disclosure would be problematic

Key Benefits:

• Strictest compliance approach for distributed software
• Minimizes copyleft license obligations
• Reduces legal risk for commercial products with tight IP requirements

Organizational Policy Application Strategy

For Organizations with Mixed Project Types

Recommended Approach:

1. Set Standard Bundle Distribution as the default org-wide policy for maximum development flexibility
2. Override at the project level for specific distribution scenarios:
   • Mobile apps → Single Binary Policy
   • Desktop software → Standard Bundle Distribution Policy
   • Embedded products → Single Binary Policy

For Specialized Organizations

SaaS/Web Companies:

• Use Website/Hosted policy organization-wide
• Only override for any mobile apps or desktop tools you distribute

Enterprise Software Vendors:

• Use Standard Bundle Distribution as default
• Override with Single Binary for mobile/embedded components
• Override with Website/Hosted for internal tools and services

Hardware/Embedded Companies:

• Use Single Binary policy as default
• Override with Website/Hosted for any cloud services or management portals

License-Specific Considerations

Key Differences to Understand

Special Attention Required

Always Review These License Categories:

• Licenses marked as "Flagged" require manual review but aren't blocked
• Uncategorized licenses (~23 per policy) need individual assessment
• Licenses with "DIRECT depth condition" are only approved as direct dependencies

Implementation Best Practices

Getting Started

1. Start with the most restrictive policy that fits your distribution model
2. Run initial scans to understand your current license landscape
3. Gradually relax restrictions only after understanding compliance implications

Policy Customization

1. Begin with a builtin policy rather than creating from scratch
2. Document any customizations and the business reasons behind them
3. Regular reviews of flagged licenses to ensure consistent decision-making

Team Coordination

1. Train development teams on the difference between approved, flagged, and denied
2. Establish clear escalation paths for flagged license decisions
3. Create organization-specific guidance for commonly encountered licenses

Migration Strategy

From No Policy to Builtin Policies

1. Start with Standard Bundle Distribution for initial friction
2. Run comprehensive scans across all projects
3. Address any denied licenses before enforcement
4. Gradually apply project-specific policies based on distribution model

Between Builtin Policies

1. Understand the license differences before switching
2. Test policy changes on representative projects first
3. Communicate changes to development teams in advance
4. Provide migration timeline for addressing newly-denied licenses

The key is matching your policy choice to your actual distribution model and risk tolerance, starting conservatively and adjusting based on your organization's specific needs and compliance requirements.