Legal disclaimer for publishing servers

[domdomegg]

We want people to be able to use the official registry data. This would likely include subregistries being able to scrape this data, who might have legal questions about the licensing of that data. Additionally there may be GDPR concerns about processing it, for personal publishers etc. (e.g. if I publish me.adamjones/airtable-mcp-server, and then some subregistry does some background check on that domain etc., that probably falls under personal data processing).

We should consult with some lawyers to check:

• what concerns are there actually here
• what do we need to put in place to mitigate them
  • e.g. maybe a clear privacy policy and terms of service for registry, that makes things clear to people what's going on, and legally clears contributions (e.g. maybe by publishing they agree that their server.json data is published into the public domain under CC0. And maybe we should put the whole database into the public domain via the PDDL?)

Privacy example from NPM: https://docs.npmjs.com/policies/privacy#npm-collects-package-data

[domdomegg]

@claude Are there any other legal, regulatory or similar questions we should be thinking about with registry? Read the docs and maybe GitHub issues to get a good understanding of what the project involves.

Please also take a first pass at guessing what a highly competent lawyer might say to these questions.

[claude]

Claude finished @domdomegg's task —— View job

---

Legal and Regulatory Analysis for MCP Registry

I've analyzed the MCP Registry project's legal and regulatory considerations. Here's what a competent lawyer would likely advise:

Analysis Summary

Project Understanding:

• Community-driven registry for Model Context Protocol servers with RESTful API
• Users publish server metadata including personal identifiers (e.g., "me.adamjones/airtable-mcp-server")
• Authentication via GitHub OAuth, with repository ownership verification
• Data flows to subregistries and third parties for security scanning/verification
• Currently MIT licensed software with no terms of service or privacy policy

Legal Analysis

Core Legal Concerns

1. Data Licensing & Intellectual Property

• Current gap: No explicit licensing for registry data itself (only software under MIT)
• Risk: Unclear rights for subregistries to scrape/redistribute data
• Recommendation: Implement CC0 or PDDL for registry data, Terms of Service clarifying data contributions

2. Privacy & GDPR Compliance

• Personal data processing: Names in server identifiers, GitHub profile data, repository associations
• Cross-border transfers: Registry accessible globally, subregistries may process data internationally
• Lawful basis needed: Consent or legitimate interest for processing personal data
• Individual rights: Access, rectification, erasure requests must be accommodated

3. Publisher Identity & Verification

• Issue "Publisher" data in official metaregistry #29 relevance: Publisher verification creates legal responsibility for accuracy
• Trust & liability: Registry becomes involved in identity assertions if implementing verification badges
• Defamation risk: False publisher claims could create liability

Additional Regulatory Considerations

4. Content Moderation & Platform Liability

• Section 230 (US): Registry likely qualifies as platform, but content moderation policies needed
• EU DSA: May trigger obligations as "hosting service" depending on EU user volume
• Harmful content: Need policies for malicious packages, impersonation, spam

5. Export Control & Security

• ITAR/EAR considerations: If servers include encryption or military applications
• Sanctions compliance: Blocking access from sanctioned entities/countries
• Security scanning partnerships (Issue Pingback from subregistries with extension data #292): Liability for security assessments

6. Terms of Service Requirements

• User agreements: Publishing requires acceptance of clear terms
• Dispute resolution: Mechanism for handling takedown requests, disputes
• Indemnification: Protection from user-generated content liability

7. International Compliance

• Data localization: Some jurisdictions require local data storage
• Right to be forgotten: GDPR deletion requirements
• Age restrictions: COPPA compliance if minors might use service

What Legal Counsel Would Likely Recommend

Immediate (Go-Live Blockers):

1. Privacy Policy - Essential for GDPR compliance and user transparency
2. Terms of Service - Governing data contributions, acceptable use, liability
3. Data licensing framework - CC0/PDDL for registry data contributions
4. Cookie/tracking disclosure - If using analytics or tracking

Medium-term:

1. Content moderation policies - Procedures for handling harmful content
2. DMCA agent registration - For copyright takedown requests
3. Data processing agreements - With subregistries and partners
4. Incident response plan - For data breaches, security issues

Ongoing:

1. Regular compliance audits - Especially as international usage grows
2. Legal monitoring - Evolving regulations (AI Act, DSA updates)
3. Insurance evaluation - Cyber liability, errors & omissions coverage

Comparison to NPM Approach

NPM's privacy policy provides a good model for:

• Clear data collection statements
• Processing purposes and legal basis
• User rights and contact information
• International transfer mechanisms

Key recommendation: Engage specialized technology counsel familiar with platform liability, data privacy, and open source licensing before launch.

---

Todo List Completed:

• Read project documentation and understand registry functionality
• Review GitHub issues for existing legal/regulatory discussions
• Identify additional legal concerns beyond those mentioned
• Analyze what competent legal counsel might advise
• Provide structured recommendations

[domdomegg]

I am not a lawyer, but some thoughts on Claude's analysis above

• 1. Data Licensing & Intellectual Property
  • agree with these concerns
• 2. Privacy & GDPR Compliance
  • agree with these concerns
  • individual rights: I'm actually not sure about this, maybe this is a problem? Could manage with manual request flow, although subregistries might still hold the package. Wonder how other services like GitHub do it where forks could contain data.
  • we do not currently have any analytics or tracking that collects PII, nor use any cookies or equivalent local storage technologies
• 3. Publisher Identity & Verification.
  • I think we have descoped "Publisher" data in official metaregistry #29 for go-live, so this is not a concern right now. We can revisit the legal implications if we do this in future I think.
• 4. Content Moderation & Platform Liability
  • Section 230: does not actually impose any requirements, it just gives immunity on some things
  • EU DSA: we're definitely too small for this
• 5. Export Control & Security
  • The registry will not hold the actual packages, just metadata about them. This would have a very low risk of someone somehow shoving export controlled secrets in.
  • Sanctions compliance: I'm actually not sure about this, maybe this is a problem?
  • Pingback: not being implemented for go-live, can revisit later
• 6. Terms of Service Requirements
  • section seems vague, not actually strictly needed?
• 7. International Compliance
  • Data localisation is not a concern AFAIK, given how mild the PII is
  • Right to be forgotten: see individual rights in section 2 above
  • COPPA compliance: Unlikely children under 13 use this service. Maybe future vibe coders could be a problem, but for now I think we should just ban them in the terms and their parents can submit on their behalf if they want to?

The general go-live blocker suggestions sound right, but we need to actually do them (except 4 because we have no cookies/tracking). Will get some lawyers on the case.

[domdomegg]

Some more ideas from Claude on the GDPR erasure and sanctions compliance points

Individual Rights (GDPR Data Deletion)

The MCP Registry faces the same fundamental challenge as GitHub and npm - the distributed nature of data makes complete erasure technically difficult:

1. Legitimate Interest Defense: Like GitHub, the registry could argue that maintaining provenance of contributions is a legitimate interest that overrides deletion requests for certain data (e.g., contributor attribution in published servers)

2. The Forking Problem:

   • GitHub explicitly states they cannot delete data from forks and must coordinate manually with fork owners
   • npm acknowledges they "can't make everyone who has downloaded published package data erase that data"
   • For MCP Registry with subregistries, this creates a cascading problem where data deletion from the main registry doesn't guarantee removal from subregistries

3. Practical Approach (following npm's model):

   • Accept that downloaded/scraped data cannot be retroactively deleted
   • Implement clear data retention policies upfront

4. Alternative: Manual Request Flow: This could work instead of option 3, but you'd need:

   • Clear process documentation
   • Response timeline commitments (GDPR requires 30 days)
   • Identity verification procedures (could be via existing auth, though this might pose problems if people have lost the domain)
   • Template responses for cases where deletion isn't possible

Sanctions Compliance

1. Industry Standard: PyPI explicitly prohibits use by SDNs and sanctioned entities in their ToS. This suggests it's a standard practice for US-based registries.

2. Practical Implementation Options:

   • Minimal approach (likely reasonable): Add ToS language prohibiting use by sanctioned entities (like PyPI)
   • Geographic blocking: Block access from comprehensively sanctioned countries (currently Cuba, Iran, North Korea, Syria, Crimea region)

3. Risk Factors for MCP Registry:

   • GitHub authentication provides some natural filtering (GitHub already does sanctions compliance)
   • Registry only hosts public minimal metadata pointing at trusted registries - even lower risk than npm/PyPI which host actual code

4. Recommended Approach:

   • Add clear ToS language about sanctions compliance
   • Consider geographic blocking if this becomes a problem/concern

Key References

GitHub's Approach

• Cannot delete data from all forks, requires manual coordination
• Maintains Git history under legitimate interest for IP provenance
• Reassigns repository network root when upstream deleted

npm's Approach

• Respects GDPR rights but cannot force deletion from downloaded copies
• Unpublish policy balances ecosystem stability with individual rights

PyPI's Approach

• Explicit OFAC compliance in Terms of Service, prohibits use by SDNs and sanctioned entities
• Has a pro-forma privacy policy that doesn't really address data deletion from packages