Principle 3: Optional Dependencies & Ecosystem Compatibility
“Adapters, connectors, or plugins within a COSS-branded Project that connect to third-party libraries (including proprietary or copyleft code) are permitted only if: i. the core functionality of the COSS-branded Project builds and functions without them, and ii. the third-party license is respected and clearly documented. Bundling such third-party code with the core is prohibited unless its license terms: (a) do not conflict with the user’s rights to the core Project’s code under its underlying MIT License (or other permissive license approved by the Stewardship Body), (b) do not prevent the core Project from functioning as intended, and (c) allow the core Project’s code to be distributed under its own permissive license.”
Rationale: Why Managing Dependencies Carefully Matters
This principle addresses how Contriboss (COSS) branded projects should interact with external software, particularly when those dependencies might have different licensing terms or could introduce aspects of vendor lock-in if not handled carefully. The goal is to maintain the core project’s neutrality, functionality, and adherence to permissive licensing, while still allowing for rich integrations.
Key reasons for this principle include:
- Preserving Core Neutrality and Functionality: The essential features of a COSS-branded project should not be contingent on proprietary or restrictively licensed third-party software. Users must be able to use the core project effectively without being forced into other ecosystems.
- Maintaining Licensing Integrity: COSS projects recommend the MIT License (or similar permissive licenses) for their core code. This principle ensures that integrating or bundling third-party code doesn’t inadvertently impose more restrictive licensing terms on the core COSS project or its users in a way that contradicts the COSS philosophy.
- Clarity and Transparency for Users: Users need to clearly understand which parts of a software offering are core to the COSS-branded project (and thus adhere to COSS principles and permissive licensing) and which are optional integrations with potentially different terms.
- Facilitating Modularity and Choice: By treating significant external integrations as optional plugins or adapters, users retain the choice of whether or not to use them, and the core project remains lean and focused.
- Preventing “Trojan Horse” Scenarios: This principle helps prevent situations where a seemingly open COSS project becomes effectively dependent on, or a mere wrapper for, a proprietary or vendor-locked service due to tightly coupled, non-optional dependencies.
What This Principle Means in Practice for COSS-Branded Projects
- Core Functionality Must Be Independent: The primary, defining features of the COSS-branded project must be usable even if no optional third-party adapters, connectors, or plugins are installed or enabled.
- Clear Demarcation of Optional Components: Any components that integrate with third-party libraries or services (especially proprietary or copyleft ones) should be clearly identifiable as optional add-ons, plugins, or connectors.
- Respect for Third-Party Licenses: If an optional component uses or links to a third-party library, the license of that third-party library must be fully respected. This includes any obligations regarding distribution, attribution, or source code availability for that specific component. This should be clearly documented for users of the optional component.
Careful Bundling
-
Prohibition on Incompatible Bundling: Directly bundling code (i.e., including its source or binaries directly within the core project’s distribution in a way that makes it non-optional) from a third-party library is prohibited if that library’s license would impose obligations on the core COSS project that conflict with its permissive nature or the COSS principles (e.g., a GPL library bundled into an MIT core project in a way that forces the whole to become GPL).
-
Conditions for Permitted Bundling: If third-party code is bundled with the core (perhaps for convenience, e.g., a permissively licensed utility library), its license must be compatible as defined: it must not restrict the user’s rights to the core COSS code, prevent the core from working, or prevent the core from being distributed under its own MIT (or similar) license.
-
Documentation of Dependencies: All significant dependencies, especially optional ones that connect to external services or libraries with different licenses, should be clearly documented, along with their licenses and how they extend the core functionality.
Examples
- Compliant (Optional Plugin): A COSS-branded data visualization tool (MIT licensed) offers an optional plugin that allows users to connect to “VendorA’s Proprietary Analytics Service.” The plugin itself might contain VendorA’s client library (under VendorA’s license). The core visualization tool functions perfectly without this plugin. The plugin’s use and its licensing implications are clearly documented.
- Non-Compliant (Core Dependency on Proprietary Library): The same data visualization tool requires VendorA’s proprietary library to be installed for even basic charting features to work. This violates sub-principle (i).
- Compliant (Bundling Compatible Library): A COSS-branded web framework (MIT licensed) bundles a small, MIT-licensed JavaScript utility library within its core distribution for a common task like date formatting. This is acceptable as the licenses are compatible and it doesn’t change the nature of the core framework.
- Non-Compliant (Incompatible Bundling): A COSS-branded command-line tool (MIT licensed) directly incorporates and bundles a GPL-licensed library for a core function in such a way that distributing the tool would require the entire tool to be GPL-licensed. This would violate the condition that the bundling must allow the core project’s code to be distributed under its own permissive license. An optional, dynamically linked plugin would be a better approach here.
Ensuring Ecosystem Health and User Freedom
This principle helps COSS-branded projects maintain their integrity and commitment to openness, even as they provide rich integrations with the wider software ecosystem. It ensures that users always have a functional, neutral core and clear choices about engaging with third-party dependencies.