When a legal takedown request arrives, whether it’s about copyright,censorship, privacy, or something more vague, how a Free and Open SourceSoftware (FOSS) project responds can make all the difference.Handled well, a takedown request can be a manageable administrative step. Handled poorly, it can cause panic, disrupt infrastructure, or even put contributors at legal risk.As part of our legal resilience research, we spoke with a range of legal experts, software freedom advocates, and maintainers of mature FOSS infrastructure to understand how others manage these moments. In this article, we share what we learned, and how F-Droid is incorporating these lessons into its own approach.A Pattern EmergesDespite differences in jurisdiction, size, and mission, a few common themesfrom our research emerged when we asked how other projects handle takedownrequests:1. Don’t Be a Soft TargetLegal threats often follow the path of least resistance. FOSS projects thatpublish a formal takedown policy, require legal submissions through specificchannels, and insist on a valid legal basis are much less likely to receive,or comply with, vague or harassing demands.One FOSS organization, for example, requires all legal correspondence to be submitted by postal mail in the national language and citing local law. Most complaints evaporate once asked to comply.2. Creating a transparent and documented processSeveral digital rights organizations advised setting up structured responsesteps: Require submissions to a dedicated legal@ or abuse@ email. Insist on full documentation: legal basis, jurisdiction, evidence of theinfringement and identity of the complainant. Review for sufficiency, proportionality, and standing before acting.This creates proper documentation to process valid claims, while protecting projects from illegitimate or unfounded requests.3. Use Jurisdiction StrategicallyProjects based in civil law jurisdictions, particularly in Europe, are oftenbetter positioned to deflect legal demands from foreign entities. Severalorganizations emphasized that complying with vague or extrajudicialrequests, especially those originating outside your jurisdiction, canincrease risk unnecessarily. Instead, they recommended requiring a validlegal basis grounded in the project’s home country. Formal legal processes,such as court orders or official government channels, were seen as theappropriate threshold, not informal emails or unverifiable demands.Notification and Appeals: Fairness and TransparencyAll of the projects we consulted emphasized the importance of notifyingdevelopers whose apps are being targeted, informing them (if possible) ofthe seriousness of the claim, and the proposed strategy F-Droid is taking tohandle the claim. If a threat is deemed to be valid and a developer’s content is flagged fortakedown: The developer or maintainer is informed, unless prohibited by law (gagorders). A window for response (commonly 14 days) is offered, unless unfeasible dueto seriousness and time restraints of the request itself If the developer disputes the claim and provides supporting information(e.g. license, public domain status, fair use justification), the claim isreviewed. If the claim is upheld, the content is removed, but always with aninternal record and opportunity to appeal.This mirrors principles embedded in international norms (like the Manila Principles and GitHub’s DMCA takedown policy) and avoids overcompliance with weak or abusive claims.Transparency, Censorship, and What You Can (Legally) PublishTakedown requests occupy a complex space between legal enforcement andcensorship. While some are legitimate claims, like copyright violations orprivacy breaches, others are vague, politically motivated, or intended tosilence dissent. For FOSS projects that have a global user base, it’s notalways obvious how to respond. Complying too quickly can reinforcecensorship practices; resisting without process can lead to full websiteshut downs, domain names being takenaway(as in the US) or large and costly legalbattles.One strategy that helps balance this tension is radicaltransparency. Several projects we spoke with emphasized the importance ofdocumenting what actions were taken and why, not just for accountability,but as a form of resistance. A well-known example is GitHub’s DMCA takedownpolicy (as of July 2025), which mandates compliance with valid takedownrequests, but also posts each one publicly in their github/dmcarepository. The result: potential abusersknow their requests will face public scrutiny, which acts as a deterrent.However, not all jurisdictions allow this kind of transparency. In India,for example, we were informed that it is often illegal to disclose that youhave received a government request, even to the developer of the affectedapp. In contrast, in Russia, takedown requests can often be legallyposted, though by doing so you may beputting yourself at risk for retaliation, additional takedown requests andlegal troubles.With that in mind, some best practices for FOSS projects include: Publishing biannual transparency reports, even if redacted or aggregated. Maintaining an internal log of all takedown activity, with publicdisclosure where legally possible. Explaining the general reasons for content removals, who made the request,under what law, and what action was taken, unless legally prohibited. Being explicit about what cannot be shared, and why.Transparency won’t prevent all forms of censorship, but it can slow themdown, raise awareness, and provide a record that strengthens the broaderFOSS ecosystem.What We’re Doing at F-DroidF-Droid is revising its own takedown policy, informed by: Dutch law and EU regulations The structural support provided by The Commons Conservancy Practical lessons from long-standing FOSS organizationsOur draft process includes: Written takedown submission request to legal@f-droid.org including the required information.: Identify the specific material in question (e.g. app name) Include valid legal basis under applicable jurisdiction (e.g. copyright law, court order statutory basis) Indicate jurisdiction in which the legal basis is claimed to apply Include sufficient evidence of the alleged infringement (e.g. copyright certificate, ownership declaration) Clearly state that the complaintant is authorized to act on behalf of the rights holder Include full contact details and a verifiable identity (subject to exceptions, such as gag orders or whistleblower protection) Verification of jurisdiction and legal basis, including evidence Developer notification and appeal procedures Rejection of requests lacking documentation or legal authority may be rejected or ignored Biannual transparency reports and public tracking of takedown requestsWe’re also working to improve contributor education about potential exposurewhen contributing to F-Droid, document internal escalation paths, and ensureconsistent handling of international claims.Final ThoughtsTakedown requests are not going away in fact, they’re becoming more frequentand more complex. But FOSS projects don’t have to face them unprepared.By building processes, establishing clear jurisdiction, and protecting individuals through structure and policy, we can handle these challenges with the seriousness they deserve without letting them derail our mission.Legal DisclaimerThe content provided in this article is for informational purposes only anddoes not constitute legal advice. While we strive to provide accurate andup-to-date information, F-Droid makes no representations or warranties ofany kind, express or implied, about the completeness, accuracy, orsuitability of the information contained herein.F-Droid is not a law firm and does not offer legal services. Any relianceyou place on the information provided is strictly at your own risk. If youhave questions about legal obligations, rights, or compliance, we stronglyrecommend consulting a qualified legal professional familiar with yourjurisdiction.F-Droid and its contributors disclaim all liability for any loss or damagearising from the use or misuse of this content.