Marketplace Acceptable Use Policy

Effective date: 2026-06-24. Audience: marketplace creators.

This policy defines what is allowed and what is not allowed on the TryDirect marketplace. Reviewers reject submissions that violate these rules and cite the specific section in feedback. Creators should review this before submitting.

1. Hard prohibitions - never allowed

Templates in the following categories are rejected on sight and cannot be made compliant. Repeated submissions may result in creator account termination.

Illegal or harmful software

• Malware, ransomware, spyware, stalkerware, rootkits, RATs (remote access trojans).
• Botnets, command-and-control frameworks for unauthorised use, DDoS tools.
• Credential-stuffing tools, password brute-forcers, account-cracking tools.
• Phishing kits, fake-login templates, credential-harvesting frontends.
• Exploit kits and weaponised vulnerability scanners targeting third parties.
• Cryptojackers - software that mines cryptocurrency without consent.

Dual-use security tooling (pentesting frameworks, fuzzing tools, reverse engineering tools) is allowed if the template is clearly labelled for authorised security testing, includes a usage warning, and ships with safe defaults (no auto-exploitation, no scanning of arbitrary targets).

Illegal content distribution

• Child sexual abuse material (CSAM) - zero tolerance, reported to authorities.
• Content promoting terrorism, mass violence, or genocide.
• Content inciting violence against a person or group.
• Stolen credentials, leaked databases, doxing tools.
• Trademark infringement (e.g. fake brand storefronts).
• Templates that exist primarily to distribute pirated software, media, or game keys.

Fraud and financial crime

• Unlicensed financial services (lending, payment processing, crypto exchanges in jurisdictions that require licensing).
• Tools designed for tax evasion, money laundering, or sanctions evasion.
• Carding tools, fake-ID generators, synthetic identity tools.
• Multi-level marketing platforms that meet the FTC pyramid-scheme criteria.
• Templates that misrepresent TryDirect or another brand's identity.

Illegal marketplaces and listings

• Drug marketplaces (controlled substances).
• Weapons or ammunition sales platforms.
• Human trafficking, prostitution, escort booking platforms.
• Wildlife trafficking, endangered-species trade.
• Stolen-goods marketplaces.

2. Restricted - allowed only under specific conditions

The following categories are allowed but require explicit conditions. Reviewers verify each condition before approval.

Category	Allowed if...
Crypto mining software (consensual)	Template makes mining the explicit primary purpose, deploys only to the creator's or buyer's own infrastructure, and includes electricity-cost disclosure.
Email-sending platforms	Designed for transactional email or owned-list newsletters; not optimised for cold outreach or list scraping; complies with CAN-SPAM and GDPR consent requirements.
Web scrapers	Respects robots.txt by default, includes rate-limiting, prominently documents the legal obligation to honour target-site Terms of Service.
Proxy or VPN services	Not anonymising for illegal activity; logs disclosure clear; includes abuse-handling contact in template config.
Adult content platforms	Legal in the deployment jurisdiction; ships with strict age-verification (18+ wall) enabled by default; not targeting jurisdictions where pornography is illegal.
Gambling or poker platforms	Licensed-operator-only (template enforces licence-key validation); ships with self-exclusion and responsible-gambling tooling enabled.
Tobacco, alcohol, cannabis storefronts	Legal in the deployment jurisdiction; age-verification on by default; complies with local advertising rules.
AI agents with autonomous action capability	Documented permission model; ships with sane defaults (no auto-execution of shell commands, no auto-transfer of funds).
Forks of existing open-source projects	Original licence preserved and visible; creator has the right to redistribute (or the original licence permits it); template attributes the original maintainer in the long description.

3. Security and quality rules

Templates that compromise the security of the buyer's infrastructure are rejected. This is the most common rejection category in practice.

Embedded credentials

• No hardcoded passwords, API keys, secrets, tokens, certificates, or SSH keys in any file shipped with the template (compose files, env files, configs, volumes, scripts).
• Use environment variable interpolation (${VAR}) and document required variables in the template's long description.
• If a service needs a default password (for example, databases), the template must generate a random one at first boot, not ship with a known default.

Insecure defaults

• No --api.insecure=true or equivalent insecure-mode flags.
• No services bound to 0.0.0.0 when 127.0.0.1 or a private network is appropriate.
• No services without authentication when authentication is available.
• No outdated versions of services with known CVEs at submission time.
• No docker.sock mounts unless absolutely required, and only with docker-socket-proxy or equivalent least-privilege wrapper.
• No containers running as root unless the underlying service requires it and the template documents why.

Misleading metadata

• The listed services must match what is actually deployed (no bait-and-switch).
• The category and tags must reflect the actual purpose.
• The support URL must resolve to a real support channel.
• The pricing must match what the buyer is charged.
• The long description must not promise features the template does not deliver.

Outdated and unmaintained software

• Service versions must be supported upstream at submission time.
• Templates relying on end-of-life software (for example, Python 2, Node 12, PostgreSQL 11 and earlier, MySQL 5.7 and earlier) are rejected unless the unsupported software is the explicit subject of the template (such as a security training lab) and is clearly labelled as such.

Hidden network calls

• Templates must not phone home to the creator's infrastructure without the buyer's explicit knowledge.
• Any telemetry, license check, or update check call must be documented in the long description with the exact endpoints and data sent.
• Call-home patterns that would let the creator track buyer deployments, harvest data, or remotely disable a template are not allowed.

4. Required practices

Every published template must:

1. Deploy cleanly to a fresh server on at least one supported cloud provider.
2. Include a clear long description explaining purpose, required environment variables, and customisation points.
3. Include working SSL/TLS configuration when exposing services to the public internet (Let's Encrypt or equivalent, automated).
4. Document any expected ongoing costs (third-party API usage, model hosting, storage growth).
5. Include healthchecks for each long-running service.
6. Document the reset and uninstall procedure.

5. Content moderation and takedown

How we hear about violations

TryDirect responds to credible reports from:

• Buyers via the in-app report button or support@try.direct.
• Rightsholders for IP-infringement claims (see section 6).
• Law enforcement requests valid under applicable law.
• Independent security researchers via the responsible-disclosure policy.

Takedown process

When a violation is confirmed:

1. Template is delisted from /applications immediately.
2. Existing buyers are notified within 7 days.
3. Existing deployments continue to function. TryDirect does not remotely destroy buyer infrastructure.
4. Creator is notified with the specific violation cited.
5. Creator may appeal within 14 days via support@try.direct.
6. Earnings from sales prior to delisting are paid out per the standard schedule.

Repeated violations

• First violation: warning and delisting of the specific template.
• Second violation: 90-day publishing suspension.
• Third violation: permanent ban from publishing.
• Severe violations (CSAM, malware) result in immediate permanent ban without warning.

6. Intellectual property

Creator representation

By submitting a template, the creator represents that:

• They own the rights to all content in the template, or have permission to redistribute it.
• The template's use of open-source software complies with the relevant licences (MIT, Apache 2, GPL, AGPL, etc.) including attribution requirements.
• The template does not infringe any patent, trademark, or copyright.

DMCA / IP takedown

TryDirect honours valid DMCA-style takedown notices. Rightsholders may submit takedown requests to dmca@try.direct with:

• Identification of the copyrighted work claimed to be infringed.
• Identification of the specific template alleged to infringe.
• Contact information.
• Good-faith statement and statement under penalty of perjury.

Creators receive counter-notice rights consistent with DMCA Section 512(g).

AGPL and copyleft considerations

Templates incorporating AGPL software must:

• Clearly state the AGPL licensing in the long description.
• Make any modifications to AGPL components publicly available per AGPL Section 13.
• Not strip AGPL notices from the bundled software.

7. Geographic and legal compliance

• Creators are responsible for the legality of their template in jurisdictions where they market and sell it.
• TryDirect may geofence specific templates if required by applicable law (sanctions, export controls, age verification).
• Templates that violate US, EU, or other major-jurisdiction law are removed regardless of where the creator is based.

8. Changes to this policy

TryDirect may update this policy at any time. Material changes affecting already-listed templates are announced via email and in the creator dashboard at least 30 days before they take effect. Templates that become non-compliant due to a policy change are given the same 30-day window to either become compliant or be delisted.

Questions

Email support@try.direct for general questions, or dmca@try.direct for IP takedown notices. See the Marketplace Payout Terms for revenue share, payout schedule, and tax details.