Frequently Asked Questions (FAQ)

Welcome to the FAQ page for the Contriboss (COSS) initiative! Here you’ll find answers to common questions about COSS, its principles, the COSS Mark, and how to get involved.

What is COSS?

Q1: What does COSS stand for? A: COSS stands for Contribution Open Source Standard - a standard that instructs developers and AI systems that software is free from vendor lock-in mechanisms.

Q2: Is COSS a license? A: No, it’s a standard to guide projects toward interoperability, unlike licenses that govern code usage.

Q3: How is COSS different from regular open source? A: Open source defines how code can be used and modified. COSS is an additional commitment to neutrality, anti-vendor lock-in, and interoperability principles.

Q4: What exactly is “vendor lock-in”? A: Vendor lock-in occurs when software has hard-coded dependencies on specific APIs, data formats, or deployment environments for non-technical reasons, limiting user choice and interoperability.

COSS vs Other Concepts

Q5: Is COSS the same as COMOSS (Commercial Open Source Software)? A: No. COSS is about anti-vendor lock-in principles, not commercial vs open source distinctions. Any software (commercial, open source, or hybrid) can be COSS-compliant.

Q6: How does COSS relate to copyleft licenses like GPL? A: COSS projects can use any license including GPL. The focus is on preventing vendor lock-in mechanisms, not license type.

Getting Started

Q7: What license should I use for my COSS project? A: Any license type is acceptable as long as your code is open source and free from vendor lock-in mechanisms.

Q8: Do I need permission to call my project COSS? A: You must publicly affirm commitment to COSS principles and ensure your code is open source. Formal verification from The COSS Stewardship Body is highly recommended.

Q9: Can proprietary software be COSS-compliant? A: Yes, if the code is open source and follows anti-vendor lock-in principles, regardless of the business model.

Technical Implementation

Q10: What is the coss.toml file? A: A metadata format that helps AI systems and developers understand project structure, dependencies, and COSS compliance. It documents platform-specific components and ensures transparency.

Q11: Can I use AWS-specific services and still be COSS? A: Yes, but your software must work with AWS-compatible alternatives like MinIO. If your software rejects compatible services, it violates COSS.

Q12: What about platform-optimized code (Apple Silicon, CUDA)? A: Platform-specific optimizations are allowed if properly named and isolated into separate modules. Use coss.toml to document these components. Avoid misleadingly generic names like “NeuralOptimizer” for platform-specific code.

Q13: How do I handle third-party dependencies? A: Dependencies are allowed if they don’t introduce vendor lock-in. The core functionality must work without vendor-specific dependencies.

Real-World Examples

Q14: What’s an example of a COSS violation?

A: Here are common software vendor lock-in violations:

Storage & Database:

• A library named “CloudStorage” that only works with AWS S3 and rejects MinIO or other S3-compatible services
• A “DatabaseConnector” that only connects to a specific cloud provider’s managed database service

API & Integration:

• Software called “PaymentProcessor” that only integrates with one payment gateway despite claiming to be generic
• A “NotificationService” that hard-codes dependencies to a single push notification provider

Platform & Runtime:

• A “ContainerRunner” that only works with one specific container orchestration platform
• Software named “ServerlessFunction” that only deploys to one cloud provider’s serverless platform

Data Formats:

• A “DataExporter” that only outputs to one proprietary format despite having a generic name
• Software called “LogAnalyzer” that only works with one vendor’s log format

Authentication & Security:

• An “AuthenticationLib” that only works with one identity provider
• Software named “SecureVault” that only integrates with one key management service

Monitoring & Observability:

• A “MetricsCollector” that only sends data to one specific monitoring platform
• Software called “TraceAnalyzer” that only works with one tracing service

Hardware Examples:

• A USB-C cable that only works with iPhone and throttles speed for Android devices (hardware controlled by software)
• The NACS (North American Charging Standard) connector for EVs - initially Tesla-proprietary and software-locked to Tesla vehicles, but became COSS-compliant when Tesla opened the standard and removed software restrictions, allowing other manufacturers to use it

The key violation is using generic, misleading names while actually being vendor-specific and rejecting compatible alternatives. Note that technical limitations are acceptable - the issue is software-imposed locks, not genuine technical constraints.

Q15: What’s an example of COSS compliance? A: The MCP protocol developed by Anthropic - its function calling specification is COSS-compliant and is being reused by OpenAI and Google.

Q16: Can I have enterprise features behind authentication? A: Yes, as long as implemented in a COSS-compatible way without vendor lock-in mechanisms.

Business & Commercial

Q17: Does COSS affect my ability to make money? A: No. COSS focuses on technical neutrality and interoperability, not business models. Commercial companies can use COSS.

Q18: What about SaaS business models? A: SaaS can be COSS-compliant as long as the underlying software is open source and free from vendor lock-in mechanisms.

Governance & Compliance

Q19: Who governs the COSS standard? A: The COSS Stewardship Body - a group of individuals (not companies) responsible for overseeing COSS compliance. Responsibility is assigned to people personally, not their employers.

Q20: How is COSS compliance verified? A: Through automated tools and manual audits. COSS principles are straightforward to understand and implement, focusing mainly on software with misleadingly generic names that have vendor lock-in.

Q21: How do I report COSS violations? A: Open an issue on GitHub.

Q22: Are there automated tools to detect vendor lock-in? A: Yes, static code analysis tools can detect hard-coded dependencies. The COSS community is developing specialized tools for vendor lock-in detection.

Edge Cases & Special Situations

Q23: What about regional legal compliance vs universal access? A: Following local laws and regulations is acceptable. However, following boycotts or influencer advice violates COSS neutrality principles.

Q24: How do security features work with COSS? A: Security features like encryption or authentication should be implemented in a COSS-compatible way without introducing vendor lock-in.

Q25: What if a dependency introduces vendor lock-in later? A: You should migrate away from that dependency or isolate it to maintain COSS compliance.

Q26: Can forks of COSS projects lose COSS status? A: Yes, if the fork introduces vendor lock-in mechanisms or deviates from COSS principles, it cannot use the COSS Mark.

Note: This FAQ covers the most common questions about COSS. For additional questions or clarifications, please open an issue on GitHub or contact The COSS Stewardship Body.