Legal

The legal posture of the project. What's defended, what's disclaimed, what's licensed how, and what jurisdictions matter.

This document is descriptive of strategy, not legal advice. The authoritative documents are in flighthelp/governance/. Specific legal questions are routed to retained counsel (general counsel on retainer; jurisdiction-specific counsel ad hoc).

Entity structure

  • Primary entity: EU foundation (Stichting in NL, or equivalent in DE/IE depending on incorporation decision). Holds IP, trademarks, contracts, bank accounts.
  • Secondary entity: US 501(c)(3) public charity, established once US donor pipeline justifies the legal cost.
  • Optional future entities: Brazil-based foundation for ANAC 400 work, possibly an India entity for DGCA work. Created only if local presence becomes operationally necessary.

The structure prioritizes the EU entity because:

  • The largest body of passenger-rights law is EU-originated (EC 261 and its successors)
  • The most contributors will be EU residents
  • EU non-profit law provides strong protections against commercial conversion
  • The Brussels Effect makes EU-grounded legal positioning useful globally

Intellectual property

All IP created by employees and contractors is assigned to the foundation under a Contributor License Agreement (CLA) signed at onboarding. The CLA covers code, schemas, written documentation, and translations.

For external community contributors:

  • Code contributions: covered by the inbound license terms of the relevant repo (MIT, AGPL, or CC-BY as applicable), which permit the project to use, modify, and relicense (within the constraints of the existing license).
  • Data contributions: covered by CC-BY 4.0 by default; the contribution form explicitly notes this.
  • Translations: covered by CC-BY 4.0.
  • Photos uploaded to the contributor app: licensed to the project under CC-BY-SA 4.0 with attribution to the contributor's display name.

This is the standard open-source-foundation IP arrangement. It is well-tested and reasonably contributor-friendly.

Trademark

The wordmark "flighthelp" and the associated logo are registered:

  • Class 9 (downloadable software)
  • Class 35 (advertising and business; specifically for the information service)
  • Class 38 (telecommunications; for the API service)
  • Class 42 (technology services; for the website and tools)

Initial registration in the EU (EUIPO), the UK, the US, Brazil, India, Australia. Additional jurisdictions added as the project's operational footprint expands.

Nominative fair use

The project uses airline names, logos, and policies in a nominative-fair-use posture: to identify the airline being discussed, not to imply endorsement, partnership, or affiliation. This is well-established for descriptive use of trademarks in journalism, comparison, and consumer-information contexts.

Specific practices:

  • Airlines are named in their official trademarked form ("Lufthansa," not "LH Airlines")
  • Airline logos are displayed in low resolution and only when needed for identification (e.g., on airline pages); the project's site avoids using airline logos as design elements
  • Disclaimers on airline pages clarify that flighthelp is not affiliated with the airline
  • Airline content is presented in a layout visually distinct from the airline's own marketing

These practices have been litigated favorably for similar consumer-information sites (Consumer Reports, Wirecutter, AirHelp's free-information pages, FlyerTalk).

Defending the mark

If a third party uses "flighthelp" in a way that creates consumer confusion (a copycat site, a phishing scheme, a competing service using the name), the foundation enforces through cease-and-desist followed by legal action when needed. Trademark enforcement is necessary to maintain the mark; failing to enforce risks genericization and loss.

The foundation does not enforce against:

  • Use of the name in journalism, criticism, or commentary
  • Use by other open-source or non-profit projects that don't create confusion
  • Use as part of fair criticism of the project

Data licensing

CC-BY 4.0 on the dataset

The dataset is the project's most-shared asset. CC-BY 4.0 is the right license because:

  • It permits commercial use (which the mission requires; the data must be usable by everyone)
  • It requires attribution (which preserves credit to the contributors and the project)
  • It's well-understood by lawyers worldwide
  • It does not allow downstream re-licensing under a stricter license

When commercial consumers integrate the data, they must:

  • Credit "flighthelp.net" or "the flighthelp dataset" in user-visible locations where attribution is reasonable
  • Link to the original source where practical
  • Not misrepresent the data as their own

If a consumer attempts to relicense or sub-license the data restrictively, the foundation enforces the CC-BY terms. The enforcement is typically a notice, then a formal request, then public disclosure if the consumer doesn't correct.

CC-BY-SA 4.0 on photos

User-contributed photos (gate sizers, lounge interiors, terminal layouts) are under CC-BY-SA 4.0 (Share-Alike). This means downstream uses must also be licensed CC-BY-SA. This is stricter than CC-BY on the dataset because photos are individual creative works with stronger moral-rights interests.

MIT on the engine, schemas, and scrapers

Maximum permissiveness. Anyone can integrate without contagion. This is correct for infrastructure layers; the project's mission is served by their universal adoption, not by their copyleft propagation.

AGPL on the reference website

The reference site is the only part of the project under copyleft. AGPL ensures that if anyone forks the site to run their own service, their improvements come back to the project (or remain open).

This protects against a parasitic fork: someone takes the codebase, runs a competing service with the project's own technology, and contributes nothing back. AGPL doesn't fully prevent this but raises the cost significantly.

The AGPL choice does mean that companies cannot run a proprietary internal fork without legal complications, but that's intentional. Companies that want to integrate flighthelp use the API; the source code is for the open community.

GDPR / CCPA / data protection

The project collects relatively little personal data, by design.

Visitor data (consumer site)

Cookie-free. No tracking pixels. The only client-side persistence is localStorage for language preference and theme. No personal data is collected from anonymous visitors. The privacy policy is correspondingly short.

Contributor data

The data inventory:

  • Email address (for authentication)
  • Display name
  • Self-reported home airport, languages, airlines flown, airports visited
  • Submission history
  • Verification history
  • Earned badges
  • Optional verified credentials (e.g., cabin crew status)
  • Optional public profile

Lawful basis: contract (the contributor signs up to provide a service to the public; their data is processed to enable that participation).

Contributors can:

  • Export all their personal data (Article 15 GDPR / equivalent)
  • Correct any personal data (Article 16)
  • Delete their account and personal data (Article 17), with the caveat that their contributions remain in the public dataset (attributed to "Former Contributor")
  • Object to processing (Article 21) — typically results in account deletion
  • Withdraw consent (Article 7) — typically results in account deletion

The data-portability export is automated through the contributor app. Account deletion is also automated. Correction goes through a simple support flow.

Photo handling

Photos uploaded to the contributor app:

  • EXIF data stripped on upload (no GPS metadata, no device metadata)
  • Faces auto-blurred if detected
  • Stored with timestamp and airport-level location only (not exact GPS)
  • Subject to CC-BY-SA 4.0 licensing as described above

Photos containing identifiable individuals are rejected at moderation unless those individuals' faces are blurred or the photo is of the contributor themselves.

Data residency

Personal data is stored within the EU (for the EU foundation) and within the US (for the US 501(c)(3), if separate). The choice is driven by GDPR data-residency requirements and donor expectations.

Backups are encrypted at rest and in transit.

Breach response

In the event of a data breach:

  • Discovery: detected through monitoring or external report
  • Containment: within 4 hours, the breach is closed
  • Assessment: within 24 hours, the scope is understood
  • Notification: regulators notified within 72 hours where required (GDPR Article 33)
  • User notification: affected users notified directly within 72 hours of confirmation
  • Public disclosure: status page and blog post within 5 days
  • Post-mortem: published within 30 days

The project does not minimize, delay, or obfuscate breach disclosure. The reputational damage from a delayed disclosure exceeds the damage from a prompt one.

Disclaimers

Every page on the consumer site includes the standard disclaimer in a small, visible footer:

Information on flighthelp is provided for general guidance and reflects community-verified data and the project's interpretation of regulations. It is not legal advice. For complex situations, consult a qualified lawyer. flighthelp is a non-profit and is not affiliated with any airline.

The rules engine output includes a stronger disclaimer in the API response:

This determination is informational. It is not legal advice. The engine evaluates against the inputs provided; the user is responsible for the accuracy of those inputs. For high-value or complex claims, consult a qualified lawyer.

These disclaimers are not boilerplate; they reflect the project's actual posture. The engine is a useful shortcut, not a substitute for legal counsel. The data is community-verified, not authoritative.

Liability

Limitation of liability

The terms of service for API users limit the project's liability to:

  • For free-tier users: zero (consistent with no fee paid)
  • For commercial users: the lesser of (a) 12 months of fees paid, or (b) $50,000, except in cases of gross negligence or willful misconduct

This is the standard infrastructure-as-a-service limitation and is necessary to make the API insurable.

E&O insurance

The foundation carries Errors & Omissions insurance once the operational scale justifies the cost (typically year 2–3). Coverage scope:

  • Errors in the dataset that cause downstream harm
  • Errors in the rules engine that cause downstream harm
  • Privacy breaches
  • Defamation claims

E&O insurance is one of the largest line items after payroll and infrastructure. It is non-negotiable for a project of this scope.

Indemnification

The project does not indemnify users against third-party claims. Commercial consumers are responsible for how they use the data and engine. The project's disclaimers and limitations are designed to make this clear.

Specific legal risks and mitigation

Risk: airline lawsuit over data accuracy

An airline disputes the project's representation of their policy and threatens legal action.

Mitigation: Every fact in the dataset has provenance. The project shows its sources. If the airline's own published policy is the source, the airline's complaint is internally inconsistent. If the data was incorrect, the project corrects it promptly and acknowledges the error publicly.

The project does not preemptively remove disputed data; it surfaces the dispute and continues to publish. This is consistent with consumer-information journalism and well-tested in court.

Risk: scraping legal action

An airline argues that the project's scrapers violate their terms of service.

Mitigation: Scrapers obey robots.txt. They rate-limit politely. They identify themselves in User-Agent. They access publicly-available pages without authentication. The volume of access is comparable to a single dedicated user. This pattern has held up legally in hiQ v. LinkedIn, Sandvig v. Sessions, and several EU cases.

If an airline specifically requests cessation of scraping, the project's policy is to comply (without precedent-setting acknowledgment), shift the data sourcing to community verification for that airline, and document the request publicly.

Risk: regulator dispute over rules engine interpretation

A national regulator argues that the rules engine's implementation of their regulation is incorrect.

Mitigation: The engine's interpretation is sourced and citable. When a regulator disputes an interpretation, the project engages constructively: review the regulator's position, update the engine if the regulator is right, document the disagreement if the regulator is wrong (e.g., taking a position contrary to CJEU rulings).

The engine remains open and auditable. Regulators are encouraged to publish their own interpretations against the engine's test fixtures so disagreements are computable.

Risk: claims-company lawsuit alleging anti-competitive behavior

A commercial claims company argues that the project's free service constitutes unfair competition or anti-competitive coordination.

Mitigation: The project is a non-profit operating under documented governance. Its free service is genuinely free. Its commercial revenue is from API tiers and grants, not from competing in claims services. The Sherman Act and EU competition law accommodate non-profit information services. The mitigation is in the structural setup, not in legal defense.

Risk: DMCA / similar takedown abuse

Someone files a fraudulent copyright or trademark complaint to remove specific content.

Mitigation: The project has a published counter-notice procedure. It reviews every complaint with counsel before removing content. It does not over-comply with frivolous demands. Legitimate complaints are processed promptly.

Jurisdiction and choice of law

  • The EU foundation is governed by the laws of its incorporation jurisdiction (NL, DE, or IE)
  • The US 501(c)(3) is governed by US law and the laws of its incorporation state (likely DE or NY)
  • The terms of service for API users specify jurisdiction (EU for free and EU-region commercial, US for US-region commercial)
  • The contributor agreement specifies the EU foundation's jurisdiction
  • Disputes go through good-faith negotiation, then mediation, before any litigation

The choice-of-law strategy makes the project legally addressable in clearly-defined venues. Disputes get routed to courts familiar with the kind of law involved (EU consumer protection for EU disputes; US commercial law for US disputes).