Beyond the IP Assignment Clause
Two of our earlier guides already cover the contractual foundation of software ownership in real depth. Our guide on building without a technical co-founder walks through work-for-hire doctrine and why, under U.S. copyright law, a contractor's code is not automatically yours just because you paid for it. Our guide on choosing a development agency goes further into the specific IP assignment clause language that actually transfers ownership, plus source code escrow arrangements for when an agency's continued existence is itself a risk. If you haven't read those two pieces yet, they're the right starting point — this guide assumes that foundation and deliberately does not repeat it.
What neither of those guides covers in depth is what happens after the assignment clause is signed. A well-drafted contract that correctly assigns IP to your company is necessary, but founders who stop there routinely discover, months or years later, that a signed clause did not actually give them everything they assumed it did. Owning the legal rights to your code is a different question from controlling the actual repository it lives in. Owning code you wrote is a different question from knowing what license obligations came attached to the open-source packages that code depends on. Owning your product is a different question from being able to get your own data out of the tools you used to build and run it. And a clean IP assignment from one development agency doesn't protect you from becoming quietly dependent on a no-code platform, a cloud provider's proprietary services, or a SaaS tool that turns out to be much harder to leave than it was to join.
Is a signed IP assignment clause enough to guarantee you own your software?
No. A correctly drafted IP assignment clause is necessary but not sufficient. It establishes legal ownership of the code your team wrote, but it does not automatically give you administrative control of the repository it lives in, resolve the license obligations attached to open-source dependencies inside it, guarantee you can export your own data, or prevent you from becoming locked into a no-code platform, cloud provider, or SaaS tool the contract never mentioned.
This guide covers the five things a signed contract usually doesn't: what repository ownership actually requires as a technical and administrative matter, the open-source license terms that can create disclosure obligations you never agreed to, your actual rights (and lack of them) to export your own data, what real disputes over IP ownership look like when a founder relationship ends badly, and the vendor lock-in patterns that have nothing to do with your development agency at all.
What “Owning the Repository” Actually Means
What does it mean to actually own a code repository, not just have access to it?
True repository ownership means holding the organization-owner or administrator role on the platform the code lives on (typically GitHub or GitLab) — the ability to transfer, delete, or rename the repository, manage billing, and add or remove every other person's access. This is a fundamentally different thing from being handed read access, a one-time code export, or a zip file, none of which give you any of that control.
Founders frequently conflate three very different levels of access, and the gap between them only becomes visible at the worst possible moment — when a relationship is ending and you need to act on it. The first, weakest level is being added as a collaborator with read or write access to a repository someone else's account or organization owns. You can see the code, and maybe even edit it, but you cannot transfer it, you cannot see or change who else has access, and if the actual owner revokes your access or deletes their account, you can lose it entirely with no recourse beyond whatever your contract says on paper. The second level is a one-time export — a zip file of the code, or a downloaded copy of the repository's current state. This gives you a snapshot, but not the actual living repository: no commit history beyond what's in that snapshot, no issue tracker, no CI/CD configuration, no ability to receive future updates through the same channel. The third and only level that constitutes real ownership is holding the administrator or organization-owner role on the platform itself.
GitHub's own documentation is specific about what a real transfer requires and what it grants. To transfer a repository, the current owner must have administrator access to it, and transferring it into an organization requires repository-creation permission within that target organization (GitHub Docs, “Transferring a repository”). Once the transfer completes, the new owner gets immediate administrative control over the repository's contents, its issues and pull requests, its releases, its projects, and its settings — along with its stars, watchers, and wiki. A personal-to-personal transfer additionally requires the new owner to actively accept the transfer via a confirmation email within a limited window before it completes, which is itself worth knowing: a transfer someone initiates but you never accept is not a transfer at all.
The practical framing worth internalizing: a repository is not just a folder of files. It is the entire living record of your product — its full commit history, its issue tracker, its automated build and deployment configuration, its secrets and access tokens, and the actual mechanism through which future code changes get delivered. A zip file gives you the files as they existed on the day you asked for them. It does not give you any of the rest, and it does not give you the ability to receive the next change your own team makes tomorrow through the same channel everyone is already using.
“Transferring a repository allows you to transfer it to a new personal account, or to an organization on GitHub where you have the permissions required to create repositories.”
— GitHub Docs, “Transferring a repository”
For a founder who has hired an agency or an individual contractor, the practical, non-negotiable ask is simple to state and worth insisting on from day one rather than at the end of the engagement: the repository should live inside your company's GitHub or GitLab organization from the moment work begins, with your company holding the organization-owner role, and the contractor added as a collaborator with whatever level of access their work requires — not the other way around. If a repository was set up inside the agency's own organization for convenience early on, requesting a full transfer, and confirming you can independently verify organization-owner status yourself rather than taking someone's word for it, is worth doing well before any relationship shows signs of strain. Waiting until a dispute is already underway to ask for repository ownership is the single most common way founders discover, too late, that what they thought they owned was actually someone else's repository with their name added as a guest.
Open-Source License Obligations You Inherited
Can using open-source code in your product create legal obligations you didn't agree to?
Yes. Most modern codebases depend heavily on open-source packages, and those packages come with real license terms attached. Permissive licenses like MIT and Apache 2.0 impose light obligations, but “copyleft” licenses like the GPL and AGPL can require you to disclose your own derivative source code — in AGPL's case, even if you never distribute your software at all and only run it as a hosted service.
A signed IP assignment clause with your development agency tells you that the code your agency wrote for you belongs to you. It says nothing about the dozens or hundreds of open-source packages that code almost certainly depends on — and those packages each carry their own license, with their own terms, that apply to your product whether or not anyone read them before shipping. Understanding the real differences between the major license families is one of the highest-leverage, least-technical things a founder can learn, because the stakes range from “no practical obligation at all” to “you may be required to release your own product's source code.”
Permissive licenses: MIT and Apache 2.0
MIT and Apache 2.0 are both permissive licenses, and they sit at the light end of the obligation spectrum. Under the MIT license, you can use, modify, and distribute the code for essentially any purpose, including inside a closed-source commercial product, with the only real requirement being that you retain the original copyright notice and license text somewhere in your project. Apache 2.0 is similarly permissive — it does not require you to release your own derivative source code — but it adds one distinguishing detail worth knowing: it requires you to state any significant changes you made to the original files. That's a notice obligation, not a disclosure-of-source obligation, and it's a meaningfully lighter requirement than what's coming next.
Copyleft licenses: GPL and the AGPL “network use” clause
The GPL (GNU General Public License), originally written by Richard Stallman for the Free Software Foundation and the GNU Project, works on a fundamentally different principle called copyleft. The FSF's own framing states the GPL is meant “to guarantee your freedom to share and change all versions of a program — to make sure it remains free software for all its users” ( gnu.org, GPLv3). In practice, the copyleft mechanism means that if you distribute a modified or derivative work built on GPL-licensed code, you must make the corresponding source code available to recipients under the same GPL terms. The critical detail is the trigger: copyleft's disclosure obligation is triggered by distribution, not by internal use. Historically, this created what became known as the “SaaS loophole” — a company could take GPL-licensed code, modify it heavily, and run it only as a hosted web service without ever “distributing” a copy to anyone, and face no disclosure obligation at all, because no distribution had technically occurred.
The AGPL (Affero GPL), published in 2007, exists specifically to close that loophole. It is functionally identical to GPLv3 except for one addition, its Section 13 on remote network interaction: if users interact with AGPL-licensed software remotely over a network — exactly the SaaS delivery model — the operator must offer them the corresponding source code, even though no copy of the software ever left the company's own servers. Licensing attorney Kyle Mitchell's own detailed breakdown of the license underscores this is the entire point of AGPL's existence: it was written precisely because hosted, SaaS-style use had become the dominant way software actually reaches users, and GPL on its own no longer reliably enforced copyleft's original intent in that world (Kyle Mitchell, “Reading AGPL,” January 2021).
The practical consequence for a founder: if a developer on your team — your own employee, a freelancer, or an agency — incorporates an AGPL-licensed library into your product without flagging it, and your product is delivered as a hosted SaaS application (which is true of most modern startups), you may be legally obligated to make your own product's corresponding source code available to your users, regardless of what your IP assignment clause with your development agency says. The IP assignment clause correctly establishes that you own the code your agency wrote. It does not, and cannot, override the license terms attached to a third-party dependency that code was built on top of.
Documented real-world stakes: Hellwig v. VMware
The most prominent contested GPL-compliance dispute involving a major commercial vendor is worth knowing in outline, both because it's real and well-documented, and because it illustrates that these disputes are genuinely litigated, not theoretical. Linux kernel developer Christoph Hellwig sued VMware in the Hamburg District Court in Germany, backed by the Software Freedom Conservancy's GPL Compliance Project, alleging that VMware's ESXi hypervisor combined Linux kernel code (licensed under GPLv2) with proprietary code without providing the complete corresponding source required under the license. The case was filed in 2015; a first ruling in July 2016 dismissed it on evidentiary and procedural grounds under German civil procedure, without reaching a decision on the underlying merits of whether the disputed code was actually a “derivative work.” Hellwig appealed, and following a November 2018 appellate hearing, he chose not to pursue further appeal after a February 2019 hearing; the Software Freedom Conservancy announced the case's conclusion in Germany on April 2, 2019 (Software Freedom Conservancy, “VMware Suit Concludes in Germany,” April 2, 2019). The case never reached a merits ruling, and VMware was never found liable — but it stands as the clearest real illustration that GPL compliance disputes are litigated in real courts, by real organizations, against real commercial vendors, not just a theoretical risk raised in blog posts.
The scale of the underlying risk, separate from any single lawsuit, is documented in Synopsys's (now published under Black Duck, following a 2024 sale of the business to Clearlake Capital) annual Open Source Security and Risk Analysis report. The 2024 edition found that 74% of audited codebases contained high-risk open-source vulnerabilities — a 54% increase year over year — and, separately, that 53% of codebases contained open-source license conflicts, with 31% containing no discernible license or a custom, non-standard one (Synopsys investor press release, February 2024). Whichever specific figures the most recent edition of that report shows by the time you're reading this, the underlying pattern the 2024 data documents is the important part: license conflicts inside real, shipping commercial codebases are common, not a rare edge case, and most of them are never the result of a deliberate decision — they're the result of nobody checking.
The practical fix is inexpensive relative to the risk: ask whoever builds your product — in-house, freelance, or agency — whether they run automated open-source license scanning as part of their normal process (tools built for exactly this purpose are now standard and inexpensive), and ask to see the resulting license inventory for your own codebase at least once before a fundraising due-diligence process or an acquisition forces the question. A clean IP assignment clause with your development team says nothing about what licenses your dependencies carry; only an actual scan of your dependency tree answers that question.
Data Portability and Export Rights
Do you have a legal right to export your own data from a SaaS tool or platform?
It depends on jurisdiction and what data is involved. The clearest legal precedent is GDPR's Article 20, the “right to data portability,” which applies to personal data processed based on consent or contract by automated means, and applies to any company processing EU residents' data regardless of where that company is based. Outside personal data covered by GDPR, export rights are largely contractual, not guaranteed by default.
Ownership of your product's code is one question. A separate, equally consequential question is whether you can actually get your own data — your customer records, your usage history, your content — back out of whatever tools you used to build and run your business, if you ever need to leave them. This matters for the SaaS tools your business runs on day to day, and it matters just as much for a no-code platform or managed backend service your product itself was built on top of.
The clearest and most concrete legal precedent for a right to data portability comes from the EU's General Data Protection Regulation, specifically Article 20, effective since May 25, 2018. It grants a data subject the right to receive personal data they provided to a controller in a “structured, commonly used and machine-readable format” and to transmit that data to another controller without hindrance, where the processing is based on consent or on a contract and is carried out by automated means (GDPR Article 20). Because GDPR applies extraterritorially to any company processing EU residents' personal data regardless of where that company itself is based, this right is relevant to founders well outside the EU the moment their product has any European users — a detail that surprises many non-EU founders who assume the regulation simply doesn't apply to them.
It's worth being precise about what GDPR's portability right does and does not cover. It applies specifically to personal data, processed on the basis of consent or contract, by automated means — it is not a general-purpose right to export every piece of data a platform holds about your business, such as your aggregate business analytics or proprietary derived insights the platform itself generated. Outside the specific scope GDPR covers, whether you can export your own data from a given SaaS tool, no-code platform, or cloud service is almost entirely a matter of that vendor's own product design and contractual commitments — not a right the law guarantees you by default.
There is a genuine, well-documented positive example worth knowing, since it shows this problem is solvable when a vendor chooses to solve it. Google's internal Data Liberation Front, founded in 2009, describes its own goal as making “it easier for users to move their data in and out of Google products.” Its flagship product, Google Takeout, launched June 28, 2011, and remains a real, functioning export tool for a huge range of Google's own services (Google Takeout). The existence of a dedicated internal team, with its own name and its own explicit mission, whose entire job was making data portable, is a useful reference point for what a genuine commitment to data portability looks like in practice, versus a vague marketing claim of “you own your data” with no real export mechanism behind it.
The practical takeaway for a founder evaluating any SaaS tool, no-code platform, or managed infrastructure provider your product depends on: before committing, ask the specific question “can I export my data in a usable, structured format, right now, without contacting support,” and actually test the answer rather than accepting a general assurance. A platform that only offers export via a support ticket, or that exports data in a proprietary format nothing else can read, has given you a much weaker commitment than one with a self-service, standard-format export built into the product — and the gap between those two only becomes visible, expensively, at the exact moment you need to leave.
When the Relationship Ends Badly
What actually happens to your software's IP if a founder-developer or co-founder relationship ends badly?
Without a clear IP assignment and repository-ownership arrangement in place before the relationship sours, the practical outcome often comes down to who controls the actual repository and access credentials at the moment of the dispute — not just who has the stronger legal claim on paper. Recovering from a lockout typically requires legal intervention and negotiation, and can take months.
Our development-agency guide already covers the Hertz v. Accenture and Zimmer Biomet v. Deloitte disputes in depth — large, headline commercial lawsuits over failed engagements. This section covers a different, smaller-scale, and arguably more common pattern: what happens when a startup's own founding or early contracting relationship — a co-founder, an early freelance developer, a small agency — deteriorates, and control of the actual repository becomes the practical battleground.
One illustrative account, published as a case study by a UK law firm that handled the matter, describes a London-based B2B SaaS founder (identified in the firm's own published account only as “Leo,” explicitly anonymized) whose co-founder locked him out of the company's Git repository and asserted ownership over the backend code following a falling-out, with no formal IP assignment agreement in place between them (The Numbers Law Firm case study). Per the firm's account, the dispute was resolved through a cease-and-desist and a negotiated buyout within roughly ninety days, and the company was acquired for a seven-figure sum around six months later. It's worth being direct about the limits of this account: it's anonymized, self-published by the law firm that represented one side of the dispute, and not independently verifiable against a public court record — it should be read as an illustrative account of a common pattern, not as a citable, named legal precedent.
What makes this kind of account worth including anyway, despite its limited verifiability, is how consistently the underlying pattern shows up in general legal commentary from named practitioners. UK solicitor Jonathan Lea, writing specifically on what happens when co-founders resign, describes the same structural problem: informal early-stage arrangements, made between people who trust each other and see no need for paperwork, routinely leave nobody with a clean, undisputed legal claim to the code once trust breaks down (Jonathan Lea, “When Co-Founders Resign: Who Owns the Code and Intellectual Property?”). The pattern repeats often enough across independent legal commentary that it's safe to treat as a real, common failure mode, even without a single, court-docketed case number to cite for the general claim.
The reason repository access functions as the practical battleground, rather than the underlying legal ownership question, is straightforward and worth sitting with: a court can eventually determine who legally owns disputed code, but that process takes months, often longer, and costs real money in legal fees on both sides. In the meantime, whoever holds the actual administrator credentials to the repository, the hosting account, and the production infrastructure has practical, immediate control over whether the product keeps running, whether customers keep getting served, and whether the other party can even see what's happening to their own company's product. Legal ownership and practical control are not the same thing, and the gap between them is exactly what an early, deliberate repository ownership structure — discussed above — is designed to close before it ever becomes a dispute.
What a well-drafted termination clause should specify
Separate from the IP assignment clause our agency guide already covers, a contract with any developer, freelancer, or agency should specify, in plain and explicit terms, what happens on termination — not just who owns the IP in the abstract, but the concrete mechanics of a handoff. At minimum, a well-drafted agreement should address: how quickly access credentials and repository ownership transfer back to you on termination (a defined number of days, not “promptly”); whether any transition or handoff support is included, and for how long; a defined data-return window and format, separate from the code itself; and what happens to any active third-party accounts, API keys, or infrastructure provisioned under the contractor's own accounts rather than yours. None of this is exotic or unusual to ask for — it's the same instinct as insisting on repository ownership from day one, applied specifically to the moment the relationship ends, which is exactly the moment goodwill and informal cooperation are least reliable.
Vendor Lock-In Beyond Development Agencies
Can you get locked into a vendor even after your IP is correctly assigned by a development agency?
Yes. A correct IP assignment from a development agency has nothing to do with lock-in created by the platforms and tools your product runs on: no-code builders that don't let you export runnable code, cloud providers whose proprietary services require re-architecting to leave, and SaaS tools your business becomes operationally dependent on. Each creates real switching costs a clean contract with your developer never addresses.
A correctly assigned IP clause and a correctly transferred repository solve the ownership problem with respect to your development agency specifically. They do nothing at all about a different, broader category of dependency: the platforms, infrastructure, and tools your product itself is built on top of. These lock-in patterns exist independently of who wrote your code, and a founder who has done everything right on the contractual and repository-ownership front can still end up thoroughly locked into a vendor they never signed an IP agreement with in the first place, because there was never any code to assign ownership of — the lock-in lives in the platform itself.
No-code platforms: real ownership, no exportable code
No-code platforms present a specific and often misunderstood version of this problem. Bubble's own documentation is unusually direct about the actual arrangement: users “have ownership over your data, encompassing both your app's design and any data uploaded by your users,” while “Bubble retains ownership of the underlying code that powers your app.” More concretely on the export question: “Bubble apps can only be run on the Bubble platform; there's no way of exporting your application as code” (Bubble Docs, “Application and data ownership”). Bubble does support exporting your underlying data (via CSV, for instance) and does commit that, if the company ever discontinued operations, it would release its source code under an open-source license so users could self-host — a real, if contingent, commitment, worth knowing about but not the same as being able to leave on your own schedule today.
This is worth stating plainly because it's easy to misread as either better or worse than it actually is: you genuinely do own your app's design and your data. You do not own, and cannot export as runnable software, the underlying code that makes your app work — because on Bubble's own architecture, there is no separate “code” artifact independent of the platform in the way a traditional codebase has one. This is a fundamentally different kind of lock-in than an agency withholding your code: it's not a withheld asset, it's a platform where the asset you're building was never structured as something separable from the platform itself.
Real migrations off no-code platforms do happen, and the pattern in publicly available accounts is consistent, even where the sourcing is to a migration agency's own case study rather than the company's direct statement. Accounts describing companies like SuperQueer (reported to have scaled past 440 global partners and 300,000-plus data rows before migrating to FlutterFlow) and Dividend Finance (a funded solar-financing fintech reported to have adopted a hybrid approach, keeping core product logic in custom code while retaining Bubble for internal admin tooling) both describe the same underlying trigger: growth past a complexity or scale threshold the no-code platform's architecture wasn't designed to absorb gracefully. These specific accounts come from migration-services vendors' published case studies rather than from the companies' own on-record statements, so they're worth treating as directionally credible rather than independently verified in every detail — but the underlying pattern (scale eventually forces a migration decision) is consistent enough across sources to take seriously as a real, common trajectory, not a hypothetical risk.
None of this is an argument against no-code platforms, which remain a genuinely good fit for a real class of early-stage products, exactly as our co-founder guide covers. It is an argument for making the trade-off consciously: know, before you build, that the code itself is not the exportable asset on this category of platform — your design and your data are — and factor the cost of an eventual migration into your decision the same way you'd factor in any other structural constraint.
Cloud infrastructure lock-in: proprietary services, not just hosting
Cloud infrastructure lock-in is a real and measured concern among technology decision-makers, not a fringe worry. Flexera's 2020 CIO Priorities Report, surveying 302 CIOs and senior IT executives, found that 68% worried about vendor lock-in with public cloud (Flexera 2020 CIO Priorities Report, March 2020). More recent data on the same underlying concern comes from Flexera's separate, annual State of the Cloud Report; its 2025 edition found that managing cloud spend was the top challenge for 84% of organizations, 70% run a hybrid cloud setup, and organizations use an average of 2.4 public cloud providers — a pattern consistent with treating multi-cloud as a deliberate hedge against overdependence on any single provider (Flexera 2025 State of the Cloud Report).
The technical mechanism behind cloud lock-in is straightforward once named: it's not the hosting itself that creates lock-in, it's the proprietary, provider-specific services built on top of that hosting. A database service like AWS DynamoDB runs only on AWS — there is no way to lift a DynamoDB-dependent application and run it unmodified anywhere else, unlike an application built on an open-source, cloud-agnostic database such as PostgreSQL or MongoDB, which can run on any provider or on-premises. Similarly, a serverless function built specifically around AWS Lambda's particular triggers and integration model requires meaningful re-architecture, not a simple redeploy, to run on a different provider's equivalent service. The deeper a product's architecture leans on a specific provider's proprietary primitives, rather than open, portable standards, the more expensive and disruptive an eventual migration becomes — and that cost accumulates quietly, one convenient proprietary feature at a time, rather than as a single visible decision anyone consciously made.
The practical question worth asking your development team early, in plain language: “if we needed to move off this cloud provider in a year, what specifically would we have to rebuild, and how long would that take?” A team that has been deliberate about portability can name the specific proprietary services in use and estimate a real migration cost. A team that hasn't thought about it at all usually can't answer the question with any specificity — which is itself useful information, not because portability should always be prioritized over convenience (often the proprietary service is genuinely the right engineering choice), but because the trade-off should be a conscious one your team actually made, not a default nobody examined.
SaaS tooling dependency: the lock-in nobody signs a contract calling “lock-in”
The broadest and least examined category of lock-in is the accumulated dependency on the SaaS tools a growing company adopts one at a time — the CRM, the analytics platform, the customer support tool, the internal admin dashboard builder. Each individual adoption decision looks small and reversible in isolation. The accumulated effect, after two or three years of a growing company layering tool on top of tool, each with its own data model, its own integrations, and its own export limitations, is a web of operational dependency that can be considerably harder to unwind than a single vendor relationship, precisely because no single decision ever felt consequential enough to warrant the due diligence a bigger commitment would have gotten. The same “can I export my data in a usable format, right now, without contacting support” test described in the data portability section above is worth applying to every SaaS tool your business becomes operationally dependent on, not just the platform your product itself runs on — the CRM holding your entire sales pipeline deserves the same scrutiny as your cloud database provider, because losing access to either one is operationally catastrophic in its own way.
| Category | What Creates the Lock-In | What Reduces It |
|---|---|---|
| Development agency | Repository never transferred to your organization | Repository owned by your org from day one; IP assignment clause in writing |
| Open-source dependencies | Copyleft (GPL/AGPL) license terms inherited unknowingly | Automated license scanning; a reviewed dependency inventory |
| No-code platform | App design is not separable from the platform as exportable code | Conscious trade-off made upfront; a defined threshold for migrating off |
| Cloud infrastructure | Proprietary, provider-specific services (e.g. DynamoDB, Lambda triggers) | Preferring open, portable standards where the trade-off is close |
| SaaS tooling | Accumulated small adoptions, each with its own data model and export limits | Testing self-service export on every tool before committing, not after |
A Practical Ownership Checklist
Bringing the five areas above together into something you can actually act on:
Hold the repository in your own organization from day one
Not the agency's, not a contractor's personal account — your company's GitHub or GitLab organization, with your team holding the owner role, from the first commit.
Get a real open-source license inventory
Ask whoever builds your product to run automated license scanning and show you the results — a clean IP assignment clause says nothing about what your dependencies actually require.
Verify data export before you need it
For every platform, no-code tool, or SaaS product you depend on, actually test self-service export in a usable format — not a support-ticket promise — before you're relying on it operationally.
Write termination mechanics into every contract
Beyond IP assignment: a defined timeline for access and repository transfer, a data-return window, and what happens to accounts provisioned under someone else's name.
- 1
Insist on repository ownership before work begins, not after
The single highest-leverage, lowest-cost protection available — verify your organization holds the owner role yourself, rather than trusting a verbal assurance.
- 2
Request a dependency license scan at least once before any major milestone
A fundraising due-diligence process or acquisition will ask this question eventually — answering it on your own schedule is far cheaper than answering it under deadline pressure.
- 3
Treat every new SaaS or no-code adoption as a portability decision, not just a features decision
A five-minute export test before committing is inexpensive; discovering a tool has no real export path after two years of dependency is not.
- 4
Put termination mechanics in writing alongside IP assignment, not instead of it
Both matter, and they answer different questions — one covers who owns the code, the other covers how quickly you can actually act on that ownership if the relationship ends.
Frequently Asked Questions
Does a signed IP assignment clause mean I automatically own my repository too?
No. An IP assignment clause establishes legal ownership of the code your team wrote, but repository ownership is a separate, administrative matter — it requires your company holding the organization-owner or admin role on the platform (GitHub or GitLab) the code actually lives on, which has to be set up deliberately and isn't automatic just because the underlying code legally belongs to you.
What is the difference between GPL and AGPL licenses?
Both are copyleft licenses requiring disclosure of derivative source code, but they differ in what triggers that requirement. GPL's disclosure obligation is triggered by distributing the software. AGPL closes what became known as the "SaaS loophole" — its disclosure obligation is also triggered by offering the software as a hosted network service, even if no copy of the software is ever distributed.
Do MIT and Apache 2.0 licenses require me to release my own source code?
No. Both are permissive licenses. MIT requires only that you retain the original copyright notice and license text. Apache 2.0 additionally requires stating significant changes you made to the original files, but neither requires disclosing or releasing your own derivative source code, unlike GPL or AGPL.
Am I legally entitled to export my data from a SaaS tool or platform?
It depends on the data and jurisdiction. GDPR's Article 20 grants a right to data portability for personal data processed by automated means based on consent or contract, and applies to any company processing EU residents' data regardless of where that company is based. Outside that specific scope, export rights are largely a matter of the vendor's own product design and contractual commitments, not a right guaranteed by law by default.
What actually happens if a co-founder or early developer locks me out of the repository?
Without a prior IP assignment and clear repository-ownership structure, recovering access typically requires legal intervention — a cease-and-desist and negotiation, sometimes taking months — because whoever holds the actual administrator credentials has practical control regardless of who has the stronger underlying legal claim. This is exactly why setting up repository ownership correctly before any dispute arises matters more than resolving one after the fact.
Can I export my app as runnable code from a no-code platform like Bubble?
On Bubble specifically, no — per Bubble's own documentation, Bubble apps can only run on the Bubble platform, and there is no way to export the application as code, though you do own your app's design and your data, and can export the data. This is a structural feature of how no-code platforms like Bubble are architected, not a withheld asset, and is worth factoring into the build-vs-no-code decision upfront.
What creates cloud infrastructure lock-in beyond just choosing a hosting provider?
Proprietary, provider-specific services built on top of standard hosting — such as AWS DynamoDB or Lambda's specific trigger model — require meaningful re-architecture to migrate away from, unlike applications built on open, cloud-agnostic standards like PostgreSQL. Flexera's 2020 CIO Priorities Report found 68% of surveyed CIOs worried about public cloud vendor lock-in specifically for this reason.
How common are open-source license conflicts in real, shipping codebases?
Synopsys's 2024 Open Source Security and Risk Analysis report found that 53% of audited codebases contained open-source license conflicts, with 31% containing no discernible or a custom license — indicating this is a common, often-overlooked issue rather than a rare edge case.
What should a contract specify about what happens if the relationship with a developer or agency ends?
Beyond the IP assignment clause itself, a well-drafted agreement should specify a defined timeline (in days, not "promptly") for transferring access credentials and repository ownership back to you, whether any transition support is included, a defined data-return window and format, and what happens to any third-party accounts or API keys provisioned under the contractor's own accounts.
Is vendor lock-in only a risk with development agencies?
No. A correctly assigned IP clause and repository transfer solve lock-in risk specifically with your development agency. Separate lock-in risks exist with no-code platforms (code isn't exportable), cloud infrastructure (proprietary services require re-architecting to leave), and accumulated SaaS tooling dependencies — none of which an IP agreement with a developer addresses.
None of the five areas covered here replace the contractual foundation our earlier guides cover — a correctly drafted IP assignment clause and, where appropriate, source code escrow remain the starting point. What this guide adds is the layer most founders don't think to check until it's already a problem: whether you actually control the repository your code lives in, what license obligations came bundled with the open-source code inside it, whether you can get your own data back out of the tools you depend on, what really happens when a relationship sours, and where lock-in has quietly accumulated in places no IP clause was ever going to reach. Ownership, in practice, is the sum of all five — not just the one line in a contract that says the code belongs to you.