Is open source development eligible for R&D tax?

Is open source development eligible for the R&D Tax Incentive?

Sometimes eligible

Sometimes. Releasing work as open source neither qualifies nor disqualifies it: your own experiments are assessed by the usual test even when the code is public. But public code counts as existing knowledge, routine maintenance and upstream fixes are not R&D, and work directed or paid for by others may not be conducted for your company.

Reviewed by George WalchFacts last verified 24 October 2026

A codec published as an open-source library

An illustrative company maintains an open-source compression library for sensor time series and funds its development. It hypothesises that a learned-dictionary codec can compress irregularly sampled IoT data 25% better than the best published codecs while decoding at 1 GB per second, a result no paper or public implementation it reviewed reports. It runs planned benchmarks against those codecs on fixed public and customer datasets, records each result in the repository, and publishes the code. Publication does not change the eligibility of the experiment.

Upstreaming fixes to a popular framework

A company's engineers spend a day a week fixing bugs they hit in a widely used web framework, sending the fixes upstream, answering issues and updating documentation. It is good citizenship and useful to the company, but it is debugging and maintenance using known techniques, and the framework's maintainers decide what is accepted.

The evidence that supports it

A dated review of existing libraries, issues, papers and benchmarks showing the gap before work started.

Issues, discussions or design documents where the hypothesis and target were stated.

The public commit and pull request history, with the hosting platform's own timestamps for each pull request.

Benchmark scripts and results stored with the code, per variant.

Records showing the company set the direction and paid for the work, such as roadmaps and employment of the contributors.

Any sponsorship or funding agreements, so their effect on the claim can be assessed.

Open source is part of almost every Australian software company's work, whether it consumes libraries, publishes its own, or contributes to projects run by others. None of these is a category in Division 355. Each one touches the eligibility test in a different place.

Public code is existing knowledge

The core test asks whether a competent professional could have determined the outcome from knowledge that is publicly available or reasonably accessible anywhere in the world. Public repositories, their issue trackers and their documentation are exactly that. Before treating a technical question as open, search for libraries that already solve it, issues where others hit the same wall, and benchmarks that answer it. If a maintained library does what you need, using it is routine. The novel algorithms page covers this search in more depth.

The same logic applies to your own published work. Once you release results, a later activity that relies on them is not resolving an unknown. That does not stop the next question being genuine: a follow-on experiment that asks something your published results could not answer is assessed on its own, against everything public at the time, your own releases included.

Publishing your own R&D

Releasing code under an open licence does not make an experiment more or less eligible. A commercial or community purpose can sit alongside the new-knowledge purpose: in JLSP [2016] AATA 23 the Tribunal accepted that generating new knowledge must be a real purpose but need not be the dominant one.

The integrity question is who the work is conducted for. The R&D entity must be the one that controls the direction of the activity, bears its cost and effectively owns its results. When you fund and direct your own project and hold its copyright, open-sourcing it usually leaves those with you. The guidance does not address open licences directly, so record the decision to publish and why.

Contributing to projects you do not control

Upstream work is different. When a foundation or outside maintainers set the roadmap and decide what is merged, it is harder to show the company directed a given piece of work or received its main benefit. Governance is evidence, not the test: an activity your company planned, funded and needed for its own product can still be yours even though a maintainer reviews the patch. Most upstream contributions are also routine: bug fixes, compatibility patches, documentation and release work. A contribution that is part of your own experiment, such as an instrumented change to test a hypothesis, is assessed with that experiment.

Edge cases peculiar to open source

Sponsored features. Expenditure is not at risk to the extent the company or an associate can expect payment as a result of incurring it, whatever the results (s 355-405).
Maintainer work. Triage, reviews of outside pull requests and releases are maintenance.
Free libraries. Using free open-source components adds no expenditure to the claim and changes nothing about eligibility.
Records. A public commit history is strong contemporaneous evidence. Commit dates can be edited locally, but the hosting platform's record of when changes were pushed, reviewed and merged is hard to alter after the fact. Rand's GitHub integration reads each pull request's opened, merged and closed dates and its commit dates; see the GitHub integration page.

Companies whose product is a developer tool or library will find activity scoping on the developer tools page.

Frequently asked questions

Does publishing our code mean we gave the R&D away?

Not by itself. The question is whether the company conducted the work for itself: whether it directed it, bore its cost and holds the results. Open-sourcing your own code usually leaves all three with you, though it is worth recording the decision and its reasons.

Can our engineers' time on a foundation project be claimed?

Only if the specific activity is eligible and conducted for your company. Who governs the project does not decide that alone: the question is who directed that piece of work, paid for it and benefits from its results. Work the foundation's roadmap sets is hard to show as yours; contributions that are part of your own experiment are easier to support.

A sponsor pays us to build a feature in our library. Is that claimable?

It may be limited. Expenditure is not at risk to the extent you can expect payment whatever the results. Raise sponsored and paid feature work with your accountant before it is included.

The R&D Tax Incentive is a self-assessment program. This page is general information, not tax, legal or financial advice; eligibility depends on your circumstances and you should seek independent advice for them.