## 1. Open Source and Repository Requirements Macro Deck plugins must be open source and hosted in a public GitHub repository. - The repository must be publicly accessible. Private repositories are not accepted. - The project must be released under an OSI-approved open source license, such as MIT, Apache-2.0, or GPL. - The repository must contain a valid license file. - The repository's README must include the "Open in the Macro Deck Store" badge linking to the package's store listing (see Section 10). - The source code published in the repository must correspond to the plugin being distributed through the store. - Developers must have the right to publish and distribute all code included in their plugin. These requirements allow users to inspect plugins, understand what they install, and contribute to their development. ## 2. Dependencies and Third-Party Code Plugins must not include precompiled third-party libraries or dependencies. - Third-party dependencies must be referenced through publicly available NuGet packages. - Precompiled third-party DLLs and other compiled third-party assemblies must not be bundled with plugins. - Dependencies must come from publicly accessible and legitimate package sources. - Developers are responsible for ensuring that their dependencies comply with their respective licenses. - Bundling code from another project without complying with its license is not permitted. The goal is to make dependencies transparent, reproducible, and easier to audit. ## 3. Intellectual Property and Content Licensing All content distributed through the Macro Deck Store must be legally usable and distributable by the publisher. This includes, but is not limited to: - Icons and other graphics - Images, photographs, and illustrations - Fonts - Sounds and music - Code and third-party libraries - Other assets included in a plugin or package You must have the necessary rights or licenses for all third-party content. Do not distribute copyrighted material unless you have permission or a license that allows its redistribution. If a license requires attribution, notices, or other conditions, these must be followed. When appropriate, include the relevant license information in the repository or package. The use of third-party trademarks, including brand names and logos, is also subject to the branding requirements in Section 5. Descriptive use of a trademark to identify compatibility does not necessarily require a separate license, but it does not automatically authorize the use of every associated logo or other copyrighted asset. ## 4. Security and Malicious Software The distribution of malicious or harmful software through the Macro Deck Store is strictly prohibited. This includes: - Malware, ransomware, spyware, and other malicious software - Code designed to steal credentials, tokens, or personal data - Software that intentionally damages systems or files - Hidden backdoors or unauthorized remote access - Code that secretly performs actions unrelated to the plugin's stated purpose - Packages that contain malicious or compromised dependencies Plugins must clearly communicate what they do and should not perform actions that users would reasonably consider unexpected or unrelated to their purpose. Macro Deck may review submitted packages for security issues, but store approval does not guarantee that a plugin is completely free of vulnerabilities or malicious code. ## 5. Naming and Branding Plugins and other packages must use their own identity and must not present themselves as official Macro Deck products or as official products of third-party companies or services they integrate with. ### Package IDs and Namespaces Package IDs, namespaces, and other technical identifiers must not use `Macro Deck` or `MacroDeck` as their own namespace or publisher identity. They must also not use a third-party company or service's namespace or publisher identity in a way that could make users believe the plugin is officially developed or maintained by that company. **Not allowed:** * `app.macro-deck.myawesome-plugin` * `MacroDeck.MyAwesomePlugin` * `com.steelseries.sonar` **Preferred:** * `com.authorname.myawesome-plugin` * `AuthorName.MyAwesomePlugin` * `com.authorname.steelseries-sonar` Package IDs and namespaces should identify the developer or their project rather than Macro Deck or the third-party company or service. ### Plugin and Package Names Plugin and package names must not suggest that they are developed, maintained, or officially endorsed by Macro Deck or by a third-party company or service. Using a third-party brand or product name to clearly describe what a plugin integrates with is allowed, as long as the name does not imply an official relationship. **Allowed:** * `SteelSeries Sonar Plugin` * `Spotify Plugin` * `Discord Integration` **Not allowed:** * `Official SteelSeries Sonar Plugin` * `SteelSeries Sonar by SteelSeries` * `Macro Deck Official Spotify Plugin` **Also acceptable:** * `SteelSeries Sonar Plugin for Macro Deck` * `Spotify Integration for Macro Deck` The important distinction is whether the name clearly describes the plugin's purpose without falsely implying that it is developed, maintained, or officially endorsed by the referenced company or service. ### Macro Deck Branding and Assets Third-party packages must not use Macro Deck's official branding, logos, icons, or other official assets in a way that suggests the package is developed, maintained, or endorsed by Macro Deck. Do not use the Macro Deck logo as the primary logo or identity of a third-party plugin. Macro Deck branding may be used to clearly describe compatibility with Macro Deck, as long as it does not create the impression of an official affiliation or endorsement. ### Third-Party Branding Plugins may use third-party brand and product names to identify the services, applications, or devices they integrate with, provided the use is accurate and complies with applicable law. Official third-party logos may be used as package icons or other identifying assets only where the specific use is permitted by applicable law and the brand owner’s relevant trademark or branding policies. Describing compatibility with a product does not, by itself, grant permission to reproduce its logo. Third-party branding must not misleadingly suggest that a package is officially developed, maintained, certified, sponsored, or endorsed by the brand owner. Developers must follow applicable restrictions on logo appearance, modifications, and attribution. Developers are responsible for verifying that their use of third-party branding is lawful. Macro Deck may request evidence of permitted use, require alternative branding, or reject or remove branding that raises reasonable legal or impersonation concerns. Written authorization is not a universal submission requirement, but may be necessary for particular uses. ## 6. Quality and Functionality Plugins published to the Macro Deck Store must meet a reasonable level of quality, reliability, and maintainability. Publishing a plugin means taking responsibility for its functionality. The Macro Deck Store is not intended for experimental, unverified, or automatically generated plugins that the publisher cannot properly test or maintain. ### Testing Requirements Developers may only publish plugins whose core functionality they are able to test themselves without relying on users or other third parties to perform the testing for them. This means that developers must have access to the software, service, hardware, account, environment, or other resources reasonably required to verify the plugin's advertised functionality. Before publishing a plugin or an update, developers must: - Test the plugin themselves in a representative environment. - Verify that its core advertised functionality works as intended. - Test relevant configuration, authentication, connection, and error scenarios where applicable. - Verify that actions, variables, widgets, and other functionality exposed by the plugin behave as documented. - Ensure that failures are handled reasonably and do not leave Macro Deck or the integrated service in an unexpected state. - Re-test affected functionality after significant changes to the plugin or its dependencies. Using users as the primary testing method for functionality that the developer cannot test themselves is not acceptable. Community testing and feedback are encouraged, but they supplement the developer's own testing rather than replace it. ### Maintainability Developers must be reasonably capable of maintaining and troubleshooting the plugins they publish. A plugin should not be published when the developer has no practical way to reproduce issues, verify fixes, or determine whether its core functionality continues to work. If continued testing becomes impossible, for example because the developer permanently loses access to required hardware or services, the developer should make reasonable efforts to restore their ability to test the plugin or clearly communicate its maintenance status. ### Implementation Quality Plugins must be implemented with reasonable care and must not consist of unreviewed generated code or other functionality that the publisher does not understand well enough to maintain. Developers are responsible for all code they publish regardless of whether it was written manually, generated with AI, adapted from examples, or contributed by another person. The use of AI-assisted development is permitted, but it does not reduce the developer's responsibility to understand, review, test, debug, and maintain the resulting code. Plugins may be rejected or removed when their implementation shows substantial quality problems, including but not limited to: - Functionality that has clearly not been adequately tested. - Repeated or easily reproducible failures in core functionality. - Excessive or unnecessary resource usage. - Unhandled errors that regularly disrupt plugin or Macro Deck functionality. - Unnecessary dependencies or components unrelated to the plugin's purpose. - Generated or copied code that the publisher is unable to explain, troubleshoot, or maintain. - Large amounts of unfinished, placeholder, dead, or otherwise unused functionality in a published release. ### Scope and Completeness Published plugins should provide a coherent and reasonably complete implementation of their stated purpose. Plugins should not be published merely because a minimal implementation technically works. Actions, variables, widgets, settings, and other features should provide meaningful functionality for the integration they represent. Experimental or incomplete functionality must not be presented as stable or complete. Known significant limitations should be documented in the store listing or repository where users can reasonably discover them before installation. Publishing multiple packages does not reduce the quality requirements for any individual package. Every package is reviewed and expected to meet these guidelines independently. ### User Experience Plugin functionality exposed to users should follow Macro Deck conventions where reasonably possible. Names, descriptions, configuration fields, error messages, actions, variables, and other user-facing elements should be understandable without requiring users to inspect the source code. Configuration should provide appropriate validation and should give useful feedback when required information is missing or invalid. Technical errors should not be exposed to users without context when a clearer and actionable message can reasonably be provided. ### Store Review and Quality Enforcement Macro Deck does not guarantee a complete functional review of every plugin before publication. Store approval does not transfer responsibility for testing or quality from the publisher to Macro Deck. Macro Deck may request changes, reject a submission, temporarily remove a plugin, or require additional testing when there are reasonable concerns about its quality, reliability, or maintainability. This may include situations where a plugin: - Does not provide its advertised functionality. - Consistently fails to work for users. - Appears to have been published without adequate testing. - Cannot reasonably be tested or supported by its publisher. - Causes data loss or other destructive behavior. - Causes serious or repeated system problems. - Has significant issues that the creator does not address after being notified. A temporary removal may be used to protect users while an issue is investigated or until the creator responds and takes reasonable action. ## 7. Legal Compliance You must comply with all applicable laws and regulations when publishing content to the store. The following content is not permitted: - Software that facilitates illegal activities - Content that infringes intellectual property rights - Content that violates applicable privacy or data protection laws - Content intended to bypass security measures or gain unauthorized access - Content that violates the rights of others Macro Deck does not provide legal advice. Developers are responsible for ensuring that their own content is lawful. ## 8. Privacy and Data Handling Plugins that collect, process, or transmit user data must be transparent about their behavior. - Do not collect personal data unless it is necessary for the plugin's stated functionality. - Do not transmit data to external services without a legitimate purpose. - Clearly disclose relevant data collection and external network communication in the plugin's documentation. - Do not collect credentials, tokens, or other sensitive information without a legitimate and clearly communicated purpose. - Follow applicable privacy and data protection requirements. Plugins should request only the access and permissions they actually need. ## 9. AI Features and AI-Generated Content Packages that use artificial intelligence, or that contain content created with it, must say so openly. Declare in your package manifest and in the Creator Portal whether your package: - Lets users interact with an AI system, for example a chatbot, voice assistant, or conversational agent - Generates images, audio, video, or text with AI while it runs - Contains assets that were created or substantially changed with AI, such as icons, images, sounds, or texts The Macro Deck Store shows this declaration on the package's store listing. When your package uses AI: - Users must be clearly told when they are interacting with an AI system, unless this is already obvious from the context. - Content your package generates with AI must keep any machine-readable marking the AI service provides. Do not remove watermarks, provenance metadata (such as C2PA), or similar markers. - Realistic AI-generated or AI-modified images, audio, or video that show real people, places, objects, or events (deepfakes) must be clearly labelled as artificially generated. Content that depicts real people without their consent is not permitted. - Disclose which external AI services your package uses and what data it sends to them (see Privacy and Data Handling). An inaccurate or missing declaration counts as misleading store information. These requirements do not replace your own legal obligations. Depending on what your package does, laws such as the EU AI Act (Regulation (EU) 2024/1689) may apply to you as the provider or deployer of an AI system. Macro Deck does not provide legal advice. ## 10. Store Information and Presentation Store listings must accurately and clearly represent the package they provide. - The package name, description, screenshots, icons, and other metadata must not be misleading. - Store information should make it reasonably clear what the package does without requiring users to inspect the source repository. - Developers should provide clear installation and usage instructions. - Known limitations, required services, and important configuration steps should be documented. - Packages should not be submitted solely to distribute unrelated files or promote unrelated services. - Do not impersonate Macro Deck, its developers, or other projects. ### Icons and Visual Identity Every package must provide an appropriate and intentional visual identity. The primary package icon must have a clear and recognizable connection to the package, its functionality, or the service, application, protocol, or platform it integrates with. Generic artwork must not be used merely to fill the icon requirement when it does not meaningfully represent the package. - Icons must be intentionally chosen or designed for the package they represent. - Generic symbols, stock-style graphics, or abstract artwork should only be used when they have a meaningful connection to the package's purpose. - An icon should allow users to reasonably associate it with the package when they encounter it elsewhere in the Macro Deck UI. - Packages integrating with a specific product or service should use visual language that makes the integration reasonably recognizable, while respecting applicable trademark and branding policies. - AI-generated artwork must not be used as a substitute for an appropriate package identity when the resulting asset has no meaningful connection to the package. - Icons must not contain irrelevant decorative elements that make their purpose harder to recognize. - Icons must remain recognizable at the sizes used throughout the Macro Deck Store and Macro Deck UI. - Icons should not contain unnecessary text or details that become unreadable at smaller sizes. - Different packages from the same publisher should remain reasonably distinguishable from each other. - Icons must comply with the branding and intellectual property requirements described in these guidelines. - Third-party brand names and logos may be used to identify an integration where permitted under Section 5 (Third-Party Branding), including applicable law and brand-owner policies. Compatibility alone does not authorize logo use. The icon does not need to explain every feature of the package, but it must provide a recognizable identity and must not appear unrelated to the package. Macro Deck may reject an icon or request its replacement when it appears generic, unrelated, misleading, excessively low quality, or otherwise fails to provide an appropriate visual representation of the package. ### Screenshots and Visual Presentation Screenshots must help users understand what the package actually provides. Packages with functionality that can reasonably be demonstrated visually should include screenshots showing representative functionality in actual use. This includes, for example: - Widgets. - Custom UI elements. - Visual status information. - Controls or integrations whose functionality can be demonstrated within Macro Deck. - Configuration interfaces where they help explain how the package is used. Screenshots must: - Show functionality that is actually available in the published version. - Represent the current version of the package reasonably accurately. - Focus on meaningful functionality rather than decorative or unrelated content. - Be readable and presented at a reasonable quality. - Avoid excessive empty space, irrelevant desktop content, debug information, or other elements that distract from the functionality being demonstrated. - Not use mockups, generated images, or concept artwork in a way that could be mistaken for actual plugin functionality. - Remain reasonably representative after significant UI or functionality changes. Screenshots should demonstrate different meaningful aspects of the package where possible instead of showing multiple nearly identical views. For packages without directly visible functionality, screenshots may instead show relevant configuration, available actions, or another meaningful example of how the package is used. Screenshots are not required where they would provide no meaningful information about the package. ### Store Description Quality Store listings must contain enough information for users to understand what they are installing and what they can expect from the package. Descriptions should clearly state: - What the package integrates with or provides. - Its main functionality. - Important prerequisites, such as required software, hardware, accounts, or external services. - Significant limitations users should know about. - Any unusual setup requirements. Descriptions consisting primarily of generic promotional language, automatically generated filler text, or statements that do not meaningfully describe the package may be rejected. The package name, description, screenshots, icons, and other metadata must accurately represent the package and must not be misleading. Store assets and descriptions are considered part of the package and are subject to the same quality expectations as its code. ### README Badge The README of the package's public repository must include the "Open in the Macro Deck Store" badge, so users who find the repository can easily reach the store listing. - Get the badge code from the Creator Portal under **General Information → README badge**. It already contains the correct link to your package's store listing. - The badge must link to the store listing of the package itself, using its own package ID. It must not link to another package or to an unrelated page. - The badge must be placed in the README where it is easy to see, for example near the top. - The badge image must not be modified, recolored, or distorted. Use the provided image URLs and keep the provided height. - You can choose the variant that fits your README: dark, light, or one that adapts automatically to the viewer's color scheme. The Creator Portal provides the following variants (replace `com.authorname.my-plugin` with your package ID; the portal fills this in for you): **Dark badge** ```html Open in the Macro Deck Store ``` **Light badge** ```html Open in the Macro Deck Store ``` **Adaptive badge (switches between light and dark automatically)** ```html Open in the Macro Deck Store ``` Using the badge to link to the store listing is compatibility information and does not imply that the package is an official Macro Deck product (see Section 5). Macro Deck may request changes to icons, screenshots, descriptions, or other store metadata when a listing is incomplete, unclear, misleading, low quality, or does not reasonably represent the package. Macro Deck may reject new submissions or updates until requested changes to the store listing have been addressed. ## 11. Updates and Maintenance Developers are responsible for maintaining their published packages. Maintenance does not require continuously adding new features, but publishers must remain reasonably capable of verifying compatibility, investigating significant problems, and providing fixes when necessary. - Updates must continue to comply with these guidelines. - Security issues should be addressed within a reasonable timeframe. - Breaking changes should be documented where relevant. - Developers should avoid publishing updates that unnecessarily break existing installations or configurations. - Developers should review their plugin when significant changes to Macro Deck, a required dependency, or an integrated third-party service may affect its functionality. - Publishers must be able to reproduce and investigate significant issues affecting the plugin's core functionality. - Users must not be treated as the primary means of verifying whether a fix or release works. - If a plugin is no longer maintained, the developer should clearly communicate this through the repository and, where supported, the store listing. A plugin may be considered unmaintained when significant compatibility, security, or functional issues remain unresolved and the publisher is unable or unwilling to investigate them within a reasonable timeframe. Macro Deck may take action on packages that pose security, compatibility, quality, or other significant risks, including older versions that remain available in the store. ## 12. Reporting Issues If you discover a package that violates these guidelines, contains malicious code, infringes copyright, or otherwise poses a risk, please report it to the Macro Deck team. When reporting an issue, include the package name, a description of the problem, and any relevant evidence or links. Reports may be reviewed and investigated. Macro Deck may contact the publisher for clarification or remediation. ## 13. Enforcement Macro Deck reserves the right to take action against content or accounts that violate these guidelines. Depending on the situation, this may include: - Rejecting a package submission - Removing a published package or specific version - Temporarily restricting a package - Requiring changes before a package can be republished - Suspending or permanently disabling a publisher account - Removing an entire publisher account and its published content Macro Deck reserves the right to remove any package from the store or suspend or terminate an account at its discretion if these guidelines are violated or if content poses a security, legal, or other significant risk. Macro Deck may also take action when necessary to protect users, the store, or the Macro Deck project, even if a situation is not explicitly described in these guidelines. ## 14. Changes to These Guidelines These guidelines may be updated over time to address new security concerns, technical requirements, or changes to the Macro Deck Store. Publishers are responsible for complying with the current version of the guidelines. Where appropriate, Macro Deck may communicate significant changes to existing publishers.