Key takeaway: SR&ED open source eligibility comes down to the same two-part test the CRA applies to every claim. Did your team face genuine scientific or technological uncertainty, and did you investigate it systematically? The license on the code you started from has nothing to do with it. Forking a library and fixing a bug isn't SR&ED. Forking a library because no existing approach could handle your scale, and running a real investigation to find out why, can be — the same as if you'd written the code from scratch. Founders routinely under-claim open-source-heavy engineering work because they assume "we didn't build this from nothing" disqualifies it. It doesn't.
A lot of founders write off entire chunks of engineering work the moment open source shows up in the stack. "We forked an existing project" or "we're just extending a library" sounds, to most people, like the opposite of research. It isn't. The CRA doesn't have a rule about open source at all — the eligibility test is silent on where your starting code came from, because it was never designed to care.
This matters because a lot of real R&D at software companies happens exactly where open source lives: at the edge of what an existing library, model, or framework can do. If you're one of the teams doing that work and assuming it doesn't count, you're leaving a claim on the table for reasons the CRA never asked you to worry about.
It also cuts the other way. Plenty of teams assume the opposite mistake: that because open source is "free" and publicly available, using it heavily somehow makes a claim look weaker or more exposed to review. Not so. A claim built on open-source foundations is judged on the same evidence as any other claim: what your team investigated, what you tried, and what you learned. How much of the surrounding codebase you personally typed doesn't enter into it.
What actually decides SR&ED open source eligibility
Nothing about a project's origin as open source enters the CRA's test. Two things do: whether the work pursued an advancement of scientific or technological knowledge in the face of genuine uncertainty (the "why"), and whether that advancement was pursued through a systematic investigation — defining the problem, forming a hypothesis, testing it, drawing conclusions (the "how"). Per the SR&ED eligibility policy, that's the whole bar. There's no clause anywhere that mentions proprietary code, open licenses, forks, or contributions.
So the honest way to think about it is: strip the license away and ask what your team actually did. Did you know, going in, that the change you needed would work? If yes — you looked up the answer, applied a known technique, configured an existing option — that's not SR&ED, open source or not. If no — the existing implementation hit a wall nobody had documented a fix for, and your team had to figure out why and test candidate solutions — that's the same shape of work the CRA rewards when it happens in code your team wrote from a blank file.
Where open-source work fails the test
Say the unflattering part plainly first: most day-to-day open-source usage is not SR&ED. Installing a library, wiring it into your product, and configuring it according to its documentation is competent engineering, not research. The CRA's eligibility policy is explicit that activities aimed at "acquiring knowledge or know-how that already exists" don't meet the advancement requirement — its own examples are training, on-the-job learning, and applying what you already know. Reading a library's docs and using it as intended is the software equivalent of that: you're acquiring and applying existing knowledge, not generating new knowledge.
The same policy excludes quality control and routine testing from SR&ED. Our read: bumping a dependency version, patching a security vulnerability using the maintainer's own fix, or writing tests to confirm a library behaves as documented all fall on the routine side of that line. Useful work, sometimes urgent work. Not work that resolves a technological uncertainty.
A few patterns that don't clear the bar, regardless of how much open-source code is involved:
- Forking a project to strip out unwanted features or rebrand it. No technical uncertainty is being resolved; you know exactly what the result will look like before you start.
- Upgrading, patching, or configuring a library per its own documentation, even if the process takes weeks and touches a lot of code.
- Choosing between two well-documented open-source tools based on benchmarks or feature comparisons someone else already ran. Evaluation isn't investigation if the answer already exists in a blog post or a changelog.
- Contributing a bug fix upstream where the fix follows directly from reading the code — no hypothesis, no experiment, just correcting an obvious error.
None of that is a knock on the work. It's good engineering. It's just not the kind of work the SR&ED program exists to fund.
Where open-source work clears the test
The same activities look different the moment your team hits a wall nobody has already published an answer for. If you fork a library because the existing implementation can't hold up at your scale, your data shape, or your latency budget — and nobody, including the library's own maintainers, has a documented fix — you're now in the position every SR&ED claimant needs to be in: facing a problem where the outcome wasn't knowable in advance from available information.
What separates this from routine open-source usage is the same thing that separates any SR&ED claim from ordinary engineering: a real investigation. Trying things until one works, without ever figuring out why, doesn't count. Forming a hypothesis about why the existing approach breaks down, testing candidate fixes, and drawing conclusions from what happened does. A few examples of open-source-adjacent work that can meet the test:
- Extending an open-source model or algorithm to handle a case its authors never solved. A different data distribution, an order-of-magnitude larger dataset, or a latency constraint the original design didn't target, where you had to run real experiments to find a working approach.
- Forking a library because a documented limitation has no known fix, and investigating the underlying cause. Understanding why the problem exists, rather than papering over the symptom, before arriving at a solution.
- Integrating multiple open-source components in a way that exposes an interaction problem nobody has written about, where resolving it required systematic testing of different architectures, not a configuration change.
- Contributing a fix upstream that required genuine investigation. You had to understand and test why the library failed under your conditions; correcting an obvious typo in someone else's logic doesn't rise to that.
The overlap with eligible support work is exactly the same as any other project too: the computer programming, testing, and design categories the CRA recognizes apply whether the surrounding code was written in-house or forked from GitHub, as long as that work directly supports resolving the uncertainty.
"But we didn't invent it from scratch" is not the test
Name the mental error directly, because it costs founders the most claimable work: SR&ED does not require originating the whole system. The CRA's test asks whether your team's own contribution involved genuine uncertainty investigated systematically — not whether you started from an empty repository. A team that takes an open-source computer vision model and gets it working reliably on a novel sensor type, after months of failed approaches and real experimentation, did SR&ED work. A team that wrote a computer vision model from scratch using a textbook algorithm with a known, predictable outcome did not — even though their code has no open-source ancestry at all.
Framing your claim around "we built this ourselves" versus "we used open source" is the wrong axis entirely. The right axis is "we already knew how to do this" versus "we had to find out." Most engineering teams doing genuinely hard work with open-source foundations are on the "had to find out" side more often than they realize, because they've mentally filed all open-source-adjacent work under "using someone else's work," full stop.
Two teams, the same fork, different outcomes
Picture two startups that both fork the same open-source vector search library. Team A hits an error on install, finds the fix in a two-year-old GitHub issue, applies it, and ships. Team B forks the library because it falls over past 50 million vectors on their hardware. The library's own maintainers have an open issue with forty comments and no resolution; nobody has found why. So Team B spends six weeks testing different indexing strategies, profiling memory layout, and reading the underlying research papers the library was based on, before landing on a modified approach that works.
Team A's fork is not SR&ED. The fix already existed; applying it is exactly the kind of "acquiring knowledge that already exists" the CRA's eligibility policy excludes. Team B's fork almost certainly is, assuming the six weeks are documented as an investigation rather than remembered as "we messed with the config until it worked." Same starting repository, same license, same act of forking — completely different claims, because the uncertainty and the systematic investigation only showed up in one of them.
This is also where a lot of legitimate claims get missed rather than overclaimed. Team B's engineers are more likely to describe those six weeks as "we were stuck on scaling the search index" than as research, because from the inside it felt like frustration, not science. That's precisely the gap between what SR&ED-eligible work feels like while you're doing it and what it looks like on a T661 six months later — and it's a big part of why open-source-heavy engineering teams underclaim relative to teams building everything from a blank repository.
What this means for how you document the work
If any of your eligible work touches open-source code, document it the same way you'd document any other SR&ED activity — the open-source origin isn't a special case that needs extra justification, but it also doesn't earn you a pass on the usual bar. For each piece of work, be ready to show: what the existing implementation couldn't do, what you tried, what failed and why, and what you learned. That's the same evidence the CRA wants for any technical narrative, and it's the evidence that separates "we forked a repo" from "we forked a repo because we had to solve a problem nobody had solved."
One practical note: if your investigation is itself documented in a public GitHub issue, PR discussion, or upstream mailing list thread, that's not a liability — it's contemporaneous evidence, often better than what most claimants have. A commit history showing three failed approaches before the one that worked, with reasoning in the commit messages, is close to the ideal documentation trail the CRA is looking for regardless of whether the repository is public or private.
Ask a team lead whether "we forked pgvector and rewrote the index" sounds like R&D and you'll usually get a shrug — it sounds like Tuesday, not science. That's exactly the gap Glauq is built for: it watches your team's actual dev activity — commits, PRs, issue threads, Slack discussion of what didn't work — and flags where a pattern of investigation shows up, open-source-adjacent or not, instead of relying on someone remembering months later which fork was routine and which one ate six weeks. A qualified independent SR&ED expert then reviews what gets pulled in and makes the eligibility call before anything is filed; the automation surfaces candidates, it doesn't decide what counts.
Who should not stretch this
Not every team with open-source dependencies has an open-source SR&ED story, and pretending otherwise doesn't help anyone. If your engineering work is mostly integrating well-maintained libraries the way their documentation describes, choosing between mature tools based on published comparisons, or keeping dependencies patched and current, none of that clears the "why" half of the test — and dressing it up as research because open-source code was involved is the kind of overclaiming that draws CRA review attention you don't need. The test is the same one every other claim has to pass. Open source doesn't lower the bar, and it doesn't raise it either.
Frequently asked questions
Does using open-source software disqualify a project from SR&ED? No. The CRA's eligibility test has no provision about the licensing or origin of the code your team works with — per the eligibility policy, what matters is whether the work pursued a genuine technological advancement through systematic investigation. Open-source foundations are common in eligible SR&ED work, especially in software.
Does contributing code back to an open-source project count as SR&ED? Sometimes. If the contribution required genuinely investigating why an existing approach failed and testing candidate solutions, it can meet the two-part test. A straightforward bug fix or a change that follows directly from reading the existing code doesn't, since no uncertainty was resolved — this is the same standard applied to any other computer-programming support work.
Is forking a GitHub repository automatically SR&ED? No, and this is the most common overclaim risk in this area. Forking a project to remove features, rebrand it, or apply a documented fix isn't SR&ED, because the outcome is known before you start. Forking because an undocumented limitation blocks your use case, and running a real investigation to solve it, is a different situation entirely — our read is that the fork itself is never the eligible unit; the investigation that follows it is.
How is this different from just using a proprietary third-party library? It isn't, in terms of the eligibility test. The CRA's test doesn't distinguish between open-source and proprietary starting points. The same "did you already know the answer, or did you have to find out" question applies whether the library you're extending is on GitHub under an MIT license or licensed commercially. Open source only comes up here because founders more often assume it disqualifies work than they do for proprietary code.
What should we document if our SR&ED claim involves open-source code? The same technical narrative the CRA expects for any claim: the specific uncertainty, what you tried, what failed, and what you learned, per the T661 guidance. Commit history, PR discussion, and issue threads — public or private — are strong contemporaneous evidence, as long as they show the actual investigation and not only the final working code.
Does fine-tuning or extending an open-source AI model count for SR&ED? It can, under the same test as any other open-source work — the model being open source is irrelevant; what matters is whether adapting it involved genuine uncertainty your team had to investigate. Routine fine-tuning on a documented workflow isn't SR&ED any more than routine library integration is. Where the work does qualify, the same AI accountability standard applies: the automation can help document the work, but an independent expert still needs to make the eligibility call.
Open source doesn't change what counts as SR&ED. It just makes it easier to forget to ask the question. If your engineering work involves forking, extending, or fixing gaps in open-source code and you've never checked whether it clears the two-part test, check your eligibility or run the numbers on the SR&ED calculator before you assume the answer is no.