Files

master 6e687b523a fix tests. new product advisories enhancements

2026-01-25 19:11:36 +02:00

11 KiB

Raw Permalink Blame History

Plugin Developer FAQ

Document Version: 1.0.0 Last Updated: 2026-01-25

This FAQ addresses common questions from plugin developers working with the Stella Ops Community Plugin Grant. For the full legal terms, see LICENSE-ADDENDUM-COMMUNITY-PLUGIN-GRANT.md in the repository root.

General Questions

Q1: What constitutes a "Plugin" under the Community Plugin Grant?

A: A Plugin is a separately packaged extension that interfaces with Stella Ops using documented public plugin APIs or integration points. This includes:

Examples of Plugins:

Custom vulnerability connectors (e.g., integrating a proprietary vulnerability database)
CI/CD integrations (e.g., Jenkins, GitLab CI, Azure DevOps plugins)
Output formatters (e.g., custom report templates, dashboard integrations)
Notification connectors (e.g., Slack, Teams, PagerDuty integrations)
Scanner analyzers (e.g., language-specific dependency parsers)
Policy gates (e.g., custom compliance rules)

NOT Plugins (derivative works requiring BUSL-1.1 compliance):

Modifications to Stella Ops core source code
Forks that include modified Stella Ops components
Extensions that copy substantial portions of Stella Ops internals

Q2: Can I sell my plugin commercially?

A: Yes. You may develop and sell plugins commercially under license terms of your choosing (including proprietary terms), provided:

Your plugin does not include, copy, or modify Stella Ops source code; AND
You comply with the attribution requirements (see Q4).

Your commercial plugin license is entirely separate from the BUSL-1.1 license covering Stella Ops itself.

Q3: Do I need to open-source my plugin?

A: No. Plugins that interface with Stella Ops through public APIs do not need to be open-sourced. You may use any license you choose, including proprietary licenses.

Exception: If your plugin includes, copies, or modifies any portion of Stella Ops source code, it becomes a derivative work subject to BUSL-1.1.

Q4: What attribution is required when distributing a plugin?

A: When distributing a plugin, you should:

Acknowledge compatibility: State that your plugin is designed for use with Stella Ops (e.g., "Compatible with Stella Ops Suite")
Include license reference: If your plugin distribution includes any Stella Ops components (even configuration samples), include the LICENSE and NOTICE files
Link to source: Provide a link to the Stella Ops source repository (https://git.stella-ops.org)

Minimum attribution example:

This plugin is designed for use with Stella Ops Suite.
Stella Ops is licensed under BUSL-1.1. See https://git.stella-ops.org

Usage Limits

Q5: What counts as an "Environment"?

A: An Environment is a logically separated workspace within a Stella Ops installation. The free tier allows up to 3 Environments per installation.

Each of these counts as one Environment:

A "Development" environment for testing scans
A "Staging" environment for pre-production validation
A "Production" environment for live deployments
A tenant/workspace in a multi-tenant setup
A project or team workspace with isolated configuration

These do NOT count as separate Environments:

High-availability replicas of the same environment
Read replicas or cache nodes
Backup/disaster recovery instances (if not actively used)

Example scenarios:

Scenario	Environment Count
Single dev laptop installation	1
Dev + Staging + Prod for one team	3
Two separate teams, each with Dev + Prod	4 (requires commercial license)
MSP hosting 5 isolated customer instances	5 (requires commercial license)

Q6: What counts as a "Scan"?

A: A Scan is one completed execution of Stella Ops' vulnerability or artifact analysis pipeline that produces a new result. The free tier allows up to 999 Scans per calendar day.

Counts as a Scan:

First-time scan of a container image (new hash)
Re-scan of a modified image (hash changed)
SBOM generation for a new artifact
VEX statement generation for new findings

Does NOT count as a Scan:

Cache hits (retrieving previously scanned results)
Viewing existing scan reports
Policy evaluation on cached data
API queries for existing results

Deduplication: Stella Ops uses hash-based deduplication. Scanning the same artifact multiple times only counts as one Scan if the hash hasn't changed.

Q7: What happens if my users exceed the free limits?

A: If users of your plugin exceed the free tier limits (3 Environments or 999 Scans/day):

They need a commercial license - The user (not the plugin developer) is responsible for licensing compliance
Your plugin continues to work - There's no technical enforcement in the plugin itself
Quota enforcement is server-side - Stella Ops may introduce delays after limits are exceeded (see docs/legal/30_QUOTA_ENFORCEMENT_FLOW1.md)

As a plugin developer, you should:

Document the free tier limits in your plugin documentation
Recommend users contact stella-ops.org for commercial licensing if they exceed limits
Not build quota circumvention into your plugin

Bundling & Distribution

Q8: Can I bundle Stella Ops core with my plugin?

A: This depends on how you bundle:

Allowed (aggregation):

Shipping your plugin alongside Stella Ops as separate components
Docker Compose files that reference Stella Ops images
Helm charts that deploy Stella Ops as a dependency
Installation scripts that download Stella Ops separately

Requires BUSL-1.1 compliance (derivative work):

Embedding Stella Ops source code into your plugin
Modifying Stella Ops binaries and redistributing
Creating a single binary that includes Stella Ops components

Requires commercial license:

Bundling into a competing managed service offering
White-labeling Stella Ops functionality

Q9: Can I create a plugin that modifies Stella Ops behavior at runtime?

A: Yes, if the modification uses documented extension points:

Allowed:

Plugins that register custom handlers via plugin APIs
Extensions that add new endpoints or processing steps
Integrations that intercept and transform data via documented hooks

Not allowed without BUSL-1.1 derivative work compliance:

Runtime patching of Stella Ops binaries
Monkey-patching internal classes or methods
Replacing core components at runtime

The key distinction is whether you're using documented public APIs (allowed) vs. undocumented internal behavior (derivative work).

Commercial Considerations

Q10: Can my plugin be used with Stella Ops commercial/SaaS offerings?

A: Yes. Plugins designed for the Community Plugin Grant are compatible with commercial Stella Ops deployments. Commercial customers may use community plugins subject to their commercial license terms.

Q11: Do I need Licensor approval to publish a plugin?

A: No. You do not need approval from stella-ops.org to:

Develop plugins
Publish plugins (open source or commercial)
List plugins in third-party marketplaces

However, stella-ops.org may maintain an official plugin registry with quality/security standards for listed plugins.

Q12: Can MSPs provide plugins to their managed customers?

A: Yes, with these considerations:

Plugin distribution: MSPs can freely distribute plugins to customers
Stella Ops licensing: Each customer deployment must comply with BUSL-1.1:
- Within free tier limits; OR
- Covered by MSP's commercial license; OR
- Customer has their own commercial license

See docs/legal/SAAS_MSP_GUIDANCE.md for detailed MSP scenarios.

Edge Cases

Q13: Does the Community Plugin Grant apply to unofficial API integrations?

A: The grant specifically covers plugins using "documented public plugin APIs or integration points." For unofficial or undocumented APIs:

Using undocumented APIs is at your own risk (they may change without notice)
The Community Plugin Grant still applies if you're not modifying source code
Relying on internal implementation details may create a derivative work

Recommendation: Use documented APIs for stable, supported integration.

Q14: Can I fork Stella Ops and call it something else?

A: Forking is allowed under BUSL-1.1, but:

BUSL-1.1 applies to the fork - Production use requires compliance with the Additional Use Grant or a commercial license
Attribution required - You must preserve LICENSE, NOTICE, and copyright notices
No trademark use - You may not use Stella Ops trademarks for your fork
Change Date applies - After the Change Date (2030-01-20), the fork converts to Apache-2.0

Q15: What if my plugin becomes popular and used beyond free tier limits?

A: Success is good! If your plugin enables usage beyond free tier limits:

Users are responsible for licensing - Not you as the plugin developer
Consider partnership - Contact stella-ops.org about potential partnership or revenue sharing arrangements
Document clearly - Ensure your plugin documentation explains licensing requirements

Q16: Can I host a free scanning service for the community using my plugin?

A: The BUSL-1.1 restriction specifically targets "public multi-tenant paid hosting." Non-commercial, free-of-charge hosting for community benefit may be eligible for the Community Program.

Potentially eligible:

Free scanning for open source projects
Academic/educational free access
Non-profit services for other non-profits

Not eligible (requires commercial license):

"Free tier" that upsells to paid services
Free scanning bundled with paid consulting
Any scenario where the free service drives commercial revenue

Process: Apply to the Community Program at community@stella-ops.org. Approval is not automatic and is evaluated based on genuine community benefit.

See docs/legal/SAAS_MSP_GUIDANCE.md Section 4.3 for detailed guidance.

Getting Help

Technical questions about plugin development:

Documentation: docs/plugins/
Community forum: https://community.stella-ops.org

Licensing questions:

Email: legal@stella-ops.org
FAQ: This document and docs/legal/LEGAL_FAQ_QUOTA.md

Commercial licensing:

Email: sales@stella-ops.org
Website: https://stella-ops.org/pricing

11 KiB Raw Permalink Blame History