The five best people on your project do not work for you. They have for two years. One in São Paulo opens the issues nobody else can reproduce. One in Lagos owns the storage layer. One in Lahore wrote the rate-limiter shipping in your enterprise tier. One in Hanoi reviews every PR. One in Tallinn rewrote your CLI in a weekend.
You want to hire them. The question is how, without (a) ambiguating the IP lineage on code they have already written, (b) tripping a sanctions or export-control wire your investors will surface in Series B diligence, (c) creating a retroactive employment relationship in a country that reads two years of monthly stipends as a contract, and (d) handing a maintainer an offer letter so generic it tells them you do not understand what they do.
This piece is the playbook for that hire. It sits downstream of the tech-industry thesis on what an Employer of Record is and why tech adopted it first. None of what follows is legal advice; sanctions, export-control, and IP-assignment questions are jurisdiction-specific and need review by your GC and local counsel. What this piece can do is give you the structure of the questions, sourced and laid out.
Why this hire is harder than a standard EOR hire
A normal EOR hire has a clean before-and-after. A contributor hire does not. The before-and-after has been blurred for years: a public commit history under the candidate's personal email, a stack of Apache CLAs or DCO sign-offs, 24 months of small payouts via Open Collective or GitHub Sponsors, perhaps a personal fork the contributor sells support contracts on, perhaps a Discord title nobody remembers assigning. Each piece is benign on its own; together they make the standard "all work-product created during the course of employment" assignment ambiguous about what is actually changing on day one. The five problems the rest of this piece works through: IP lineage on pre-employment commits, the CLA-to-employment handoff, retroactive stipend exposure in substance-over-form jurisdictions, sanctions and export-control posture, and equity that holds up when ISOs, EMI, and Section 102 are all unavailable.
What the standard IP template misses
GitHub's Balanced Employee IP Agreement (BEIPA) is the best public starting point for an open-source company. It carves out an employee's personal projects on their own time and resources, including projects that touch the same domain as the employer. Version 2.0 added German-specific language.
Two things BEIPA leaves out. It has no Prior Inventions schedule; the current text has the employee represent there are no conflicting agreements, but does not enumerate what they have already created, and for a five-year commit history that is the wrong default. And it is written from a US-employer baseline, so the foreign-law overlays that govern employee inventions (German compensation, Brazilian moral rights, Japanese remuneration, Vietnamese remuneration to inventors) do not appear. The fix is procedural: bolt a Prior Inventions schedule onto the front, bolt country riders onto the back, use the BEIPA core in between.
Prior Inventions Schedule
Employee: [Name]
Effective date: [employment start date]
The following materials were created by Employee prior to the Effective Date
and are excluded from the assignment provisions of this Agreement. Employee
retains all rights to the extent set forth in the underlying licenses, except
as carried forward by Section [X] of this Agreement.
1. Public open-source contributions
- Project: [name + repository URL]
- Role: [contributor / maintainer / committer]
- Period: [first commit] to [last pre-employment commit]
- License: [Apache-2.0 / MIT / etc.]
- CLA / DCO status: [Apache CLA dated YYYY-MM-DD / DCO sign-offs / none]
2. Personal projects (Employee's own repositories)
- [Repo URL, license, brief description]
3. Pre-existing third-party work product
- [Prior employer materials, university IP, with reference docs]
4. Carried-forward license to the Company
For items in Section 1 contributed under an open-source license to the
Company's project, Employee acknowledges the Company already holds the
rights granted by that license, and nothing in this Schedule diminishes
those rights. Items in Sections 2 and 3 are not licensed to the Company
by virtue of this Schedule.
The carried-forward license clause exists because the company already owns its rights in the contributor's existing PRs through the Apache CLA or DCO chain; listing those PRs should not retract that grant. Sign and date the schedule.
The CLA-to-employment handoff
A maintainer who becomes an employee keeps sending PRs. As a contributor under the CLA or as an employee under the assignment clause? Both, and the offer letter should say so. If the project uses the Apache ICLA, section 4 covers original work and section 8 contemplates employer-owned contributions. Keep existing ICLAs on file (employment does not invalidate them), add a Corporate CLA so post-employment contributions ride the corporate grant, and include a one-paragraph IP-lineage clarification in the offer letter. If the project uses DCO sign-offs, continue signing off as before; the offer-letter assignment clause does the legal work.
Ask the new employee to keep their existing Git author identity. Switching to a corp email on day one creates a discontinuity that complicates the lineage; switch later, after a few months of overlap.
Foreign-law overlays BEIPA does not cover
Each country below has statutory rules that override or supplement the contract. The bolt-on is short, but it has to be there.
The pattern is similar across all five: the contract assigns economic rights; the employee retains moral rights, and in two of the five a statutory right to compensation that survives the contract. None are blockers; all belong in the offer package. Pakistan (Patents Ordinance 2000), Nigeria (Patents and Designs Act), South Korea (Invention Promotion Act), and Mexico (Federal Law for the Protection of Industrial Property) follow the same shape: assignment plus statutory-compensation acknowledgment.
Retroactive misclassification: the stipend problem
Suppose your project has paid a contributor in São Paulo $400 per month for 24 months through Open Collective, plus merch and conference reimbursements. They have a "core maintainer" Discord title and merge rights, and you have asked them to prioritize specific bugs.
In Brazilian labor law, this looks like employment. The CLT does not require a written contract; it requires the de-facto relationship to contain four elements: personal services (pessoalidade), non-eventuality (não-eventualidade), subordination (subordinação), and remuneration (onerosidade). Regular monthly payments, ongoing assigned work, and direction satisfy each. Brazil is at the strict end, but Spain, France, Germany, and Italy apply substance-over-form tests of a similar shape, and the US DOL economic-realities test under the 2024 final rule lands in the same place.
What helps:
- Audit the stipend history before the offer. Pull Open Collective and GitHub Sponsors records. Most companies have not done this.
- Reset the relationship in the offer. Acknowledge prior stipend payments honestly as stipends rather than deferred wages, and document that the new employment is not a continuation of a pre-existing employment relationship.
- Use a one-time conversion bonus, not back-pay. A signing bonus paid through the EOR's payroll on day one, with normal withholdings, is cleaner than truing up the prior stipend period.
- Retire the fiscal-host stipend on the start date. Continuing Open Collective payments after employment starts compounds the ambiguity.
- Document the role transition for contributors you do not hire. A short written wind-down (final stipend, thank-you, no further obligations) reduces the risk that the unhired peer files a claim later.
A Brazilian wrinkle. The STJ in Tema 1.226 (September 2024) held that genuinely voluntary, risk-bearing stock-option plans are commercial in nature, taxed as capital gain on sale rather than as wages at exercise. That helps the equity story for Brazilian hires; it does not change the misclassification analysis for the prior stipend period.
The OFAC and export-control decision tree
OFAC maintains total embargoes on Cuba, Iran, North Korea, Syria, and the occupied Crimea, Donetsk, and Luhansk regions of Ukraine; US persons cannot generally enter employment relationships there without specific licensing. Russia and Belarus are not on the total-embargo list but carry dense sectoral and entity-specific sanctions that make ordinary employment in Russia commercially impractical for most US-headquartered software companies.
Pakistan, Vietnam, and Nigeria are not embargoed. Each has nuances under BIS's EAR and each has SDN-listed individuals and entities that an EOR's onboarding screen should catch. The EAR exclusion for publicly available source code under § 734.7 covers most open-source projects, with encryption controls under § 740.13(e) and § 742.15 applying only to source implementing non-standard cryptography.
A working decision tree
Three honest notes. A competent EOR runs SDN, Entity List, and Denied Persons screens as standard; the question is whether they tell you what they found and why they cleared it. EAR analysis for source code is usually less dramatic than people fear because most open-source projects qualify as publicly available under § 734.3(b)(3) and § 734.7. And the equity-grant question is separate from the employment question; an EOR can sometimes employ a contributor whose grant needs more diligence than the employment itself.
Equity, 409A, and the NSO-only reality
ISOs are not available to non-US employees and are not workable through an EOR for US persons either. UK EMI requires employment with a UK qualifying company; Israeli Section 102 requires the Israeli grantor to be the employer. The default for EOR-employed grantees is NSOs.
§ 409A requires NSOs from US issuers to carry a strike not less than FMV at grant, supported by a valid 409A valuation. Pricing below FMV produces immediate income inclusion plus a 20% additional tax for any optionee with US tax nexus, including dual nationals, US residents temporarily abroad, and individuals who later relocate to the US.
The cap-table fairness conversation:
- State the structure plainly. We are granting NSOs because the EOR structure makes ISOs, EMI, and Section 102 unavailable; we use NSOs across the board for foreign hires.
- Explain the 409A pricing. Strike is FMV from the most recent 409A valuation; that valuation governs all grants until the next refresh.
- Disclose country-specific tax framing. Brazil benefits from Tema 1.226 where the plan is genuinely voluntary and risk-bearing. Vietnam and Pakistan usually have foreign-exchange controls that need local counsel before the grant date.
- Address cap-table optics. A maintainer who carried weight for two years before the first sales rep will compare grants to the AE's. Grant on comp bands keyed to role and seniority; where you add a founding-contributor allocation, say so explicitly.
The companion piece on stock options for EOR employees goes deeper.
Dev-specific benefits that actually matter
A standard EOR bundle is statutory minimum plus a small private-health top-up and a flexible-PTO statement. For DevRel and maintainer hires that reads as a tell. Five line items shift the read.
- Maintainer time. A formal 10% to 20% carve-out for personal OSS work, including projects unrelated to the employer's product line. Pair the carve-out with the BEIPA personal-projects clause; otherwise the employer is paying the employee to create IP it might later claim.
- Conference and speaking budget. Separate from training, typically $5K to $15K per year for senior DevRel or maintainer hires. Add an honoraria-disposition policy (keep it, donate it, or expense it) for public-facing employees.
- Sabbatical. Three to six paid weeks after a tenure milestone, commonly four years. Cheaper than people expect; significantly reduces burnout in maintainer roles where the work is partly emotional labor.
- Equipment for exotic architectures. $2K to $5K above the standard equipment budget so a maintainer can buy ARM, RISC-V, or older-architecture machines to test against. For maintainers of compilers, runtimes, or low-level libraries this is the job.
- Public-presence support. Brand and legal support for employees publishing under their own name. For DevRel hires whose personal handle is more visible than the company's, this is the benefit they notice.
Most EORs can administer all five. The question is whether they add non-standard line items to the local employment contract, or treat anything beyond their template as a side-letter stipend. The first is much less brittle.
Works councils, codetermination, and the OSS policy question
The Works Constitution Act (BetrVG) provides that any German establishment with five permanent employees, three eligible for election, can form a Betriebsrat. The employer cannot prevent it; obstruction is a criminal offense under § 119 BetrVG. Once a council exists, § 87 BetrVG gives it co-determination rights.
Two § 87 categories matter for an OSS company. § 87(1) Nr. 1 covers employee conduct in the establishment, read to include internal policies governing behavior, including contribution policies. § 87(1) Nr. 6 covers technical devices designed to monitor behavior or performance, which German courts read broadly to cover any tool capable of monitoring regardless of intent: GitHub Enterprise, Slack, observability tooling, AI coding assistants. The 2021 Works Council Modernization Act added § 80(3), which lets a council retain an external expert at company expense whenever the employer wants to introduce or use AI.
The practical implication. An OSS contribution policy (who contributes what, on whose time, under what IP rules) is a workplace-conduct policy that may require Betriebsrat agreement once a council exists. The 20% maintainer-time carve-out is in the same category, as are policies on AI coding assistants, public speaking, and social-media conduct. The plan: treat five German employees as a timing question; draft the OSS contribution policy before you cross the threshold; bring the council in early on AI tooling; and use a framework agreement (Rahmenbetriebsvereinbarung) plus narrower side agreements rather than renegotiating each cycle.
France has Comité Social et Économique at 11 employees; Brazil has CIPA for certain industry classifications. The others on the list (Estonia, Vietnam, Pakistan, Nigeria, Japan, South Korea, Mexico) have no Betriebsrat-equivalent at small headcount but each has a representation regime worth a one-line check.
Roles open-source companies hire through EOR
The maintainer-conversion column mirrors where the project's earliest contributors were already living, which is rarely where a venture-backed sales team would pick. That is why this hiring pattern needs an EOR with deep coverage rather than the standard EU-and-LATAM list.
Countries this reader hires into
- Brazil. Largest LATAM contributor base; CLT misclassification risk on prior stipends; 2024 STJ ruling helps the equity story.
- Nigeria. Growing developer population with English fluency; SDN screening and payroll-route diligence are the operational items.
- Pakistan. Deep developer pool; SDN and BIS Entity-List screens at onboarding clear the general case.
- Vietnam. Growing senior bench; check EAR exposure for advanced-computing adjacency.
- Estonia. Strong open-source culture; statutory IP defaults are workable but need contractual support.
- Japan. Critical for APAC DevRel; Article 35 sets the employee-invention compensation framework; consult-and-publish procedure matters more than the dollar amount.
- South Korea. Strong developer market; the Invention Promotion Act creates a similar reasonable-compensation right; localized DevRel has outsized impact.
- Mexico. Core LATAM DevRel and engineering geography for US-headquartered OSS companies; nearshore time zones favor synchronous community work.
What to look for in an EOR partner
Five criteria separate the providers that work for this profile from those that do not.
- Owned entities in the geographies your contributors actually live in. Verify entity ownership in Brazil, Nigeria, Pakistan, Vietnam, Estonia, Japan, South Korea, and Mexico specifically.
- A documented process for prior-contributor IP onboarding. Ask the provider to walk through a maintainer hire with a five-year commit history. If the answer is "we use our standard offer letter," that is the answer; if it includes a Prior Inventions schedule template, country riders, and a CLA-to-employment paragraph, that is a different answer.
- Honest answers on sanctions-adjacent geographies. Ask under what circumstances they will employ in Pakistan, Vietnam, or Nigeria, and what the OFAC and BIS screening procedure produces.
- Equity mechanics that match the offer letter. NSO grants, § 409A pricing, and country-specific reporting (Brazil's DCBE, Vietnam's foreign-exchange controls, South Korea's overseas-employer equity reporting).
- Migration to entity, written down. For a Series-A OSS company the most likely first-entity geography is Germany or the UK; for Series-B, often Brazil.
Borderless AI operates on an owned-entity model across 170+ countries, invoices payroll without pre-funded deposits, and runs SDN and BIS Entity List screens as part of standard onboarding. The criteria above matter more than any single brand.
The first 90 days of a contributor-to-employee conversion
- Days 1 to 7. Provider verification. Prior Inventions schedule drafted with the candidate and reviewed by counsel; country riders attached. CLA-to-employment paragraph drafted. Open Collective and GitHub Sponsors records audited; conversion-bonus structure decided. SDN and BIS screens run.
- Days 7 to 21. First country live. Local employment contract issued in the worker's language and jurisdiction with the country rider. Background and right-to-work checks completed. Benefits enrollment, including the dev-specific line items. NSO grant issued; 409A confirmed; country-specific tax disclosure delivered.
- Days 21 to 45. Payroll cycle one runs. Git author identity preserved; corporate CLA reference takes over for new contributions. Open Collective receiving relationship closed for the project. Internal contribution policy published.
- Days 45 to 90. Second and third country conversions follow the template. If German headcount approaches five, works-council preparation runs in parallel and the framework OSS-policy is drafted. Migration-to-entity plan drafted for any country expected to cross the threshold within 18 months.
Cost and timeline: entity vs. EOR vs. continued contractor
Typical ranges, not quotes. Confirm with finance and counsel for any specific country.
EOR is usually cheaper below 8 to 15 employees per country. The crossover comes faster in Germany (works-council and statutory load) and Brazil (compliance perimeter), later in Estonia, Mexico, and most of South Asia.
A practical decision frame
FAQs
How do I convert an open-source contributor into a full-time employee?
Through an EOR in the contributor's home country, with three modifications to the standard offer package: a Prior Inventions schedule enumerating pre-employment commits and personal projects; a CLA-to-employment paragraph clarifying that existing CLA or DCO sign-offs are not invalidated by employment and post-employment contributions ride the corporate CLA; and a country rider for the local employee-invention regime (Germany's ArbnErfG, Japan's Article 35, Brazil's moral-rights and software-law overlay, Estonia's Patents Act, Vietnam's IP Law).
Does the GitHub BEIPA template work in Germany or Brazil?
BEIPA's core works as a baseline, and version 2.0 added German-specific language. It does not include a Prior Inventions schedule or country riders, so it should be supplemented for any non-US hire. Brazil specifically needs explicit treatment of moral rights under Lei 9.610 and the software-rights regime under Lei 9.609.
Can I hire a contributor in Pakistan or Vietnam through an EOR?
Generally yes. Neither is under a total OFAC embargo. Standard onboarding includes SDN screening and a BIS Entity List screen. Roles touching advanced computing, semiconductors, or non-standard cryptography require additional EAR analysis. Equity grants typically proceed as NSOs with standard 409A pricing once screens clear.
What is the misclassification risk after paying a contributor through Open Collective for two years?
Material in substance-over-form jurisdictions: Brazil, Spain, France, Germany, Italy. Regular monthly payments, ongoing assigned work, and direction can satisfy de-facto employment elements without a written contract. Mitigations: audit the stipend history, retire the stipend on the start date, use a one-time conversion bonus, document the parties' position in the offer.
Can EOR-employed maintainers receive ISOs or EMI?
No. ISOs are not available to non-US employees and not workable through an EOR for US persons. UK EMI requires direct UK qualifying-company employment. Israeli Section 102 requires the Israeli grantor to be the employer. The default is NSOs with § 409A pricing.
Does Brazil's 2024 stock-options ruling change the offer?
It helps. STJ Tema 1.226 holds that genuinely voluntary, risk-bearing plans are commercial in nature, taxed as capital gain on sale rather than as wages at exercise. Plan structure has to support that characterization. It does not change the misclassification analysis for the prior stipend period.
When do I trigger a German works council?
Five permanent German employees, three eligible for election, can form a Betriebsrat under § 87 BetrVG. The council has co-determination rights over conduct policies (including OSS contribution policies) and over monitoring-capable technology (which covers most modern dev tools).
Further reading
- How Tech Companies Are Turning to Employer of Record Services
- How US SaaS companies build their first EMEA team with EOR
- EOR for fintechs: regulated roles that can and cannot sit on EOR paper
- Why medical companies are turning to Employer of Record services
Where this leaves an open-source company
The contributor-to-employee hire is the most defensible hire a Series-A open-source company can make. The candidate has been doing the work, in public, with a track record any GC can audit. The reason it has been hard is that the standard EOR offer letter was built for a candidate without history, and the standard contributor relationship was built for someone the company would never hire. The version that works takes both seriously: a Prior Inventions schedule that names the commits, a CLA-to-employment paragraph that does not pretend the past did not happen, a country rider that respects the local statute, an OFAC and BIS screen that produces a paper trail, and an NSO grant with cap-table language that explains itself.
If you are converting your first contributor, the conversation worth having is not about pricing. It is whether the provider can show you the schedule template, the rider, the screen procedure, and the migration plan on a call. Borderless AI's open-source team is built for that conversation.
