Federal Laboratory Consortium for Technology Transfer

Securing a Non-Exclusive Licence for Federal Laboratory Software

Federal research software can give Australian businesses access to algorithms, data-processing systems and engineering tools developed for public purposes. The process of obtaining a non-exclusive licence for a laboratory’s software tool normally starts with identifying the owning laboratory and assessing whether the software is sufficiently mature for commercial use. The licence permits the recipient to use the software while allowing the owner to continue licensing it to other organisations, possibly within different markets or fields of application.

A successful arrangement depends on more than securing permission to download a program. The parties must define permitted uses, establish ownership, allocate technical and financial risk, and account for Australian privacy, competition, cybersecurity and operational requirements. The following process moves from initial discovery through evaluation, negotiation and deployment, with particular attention to the needs of Australian organisations.

Locating the right laboratory and tool

The Federal Laboratory Consortium connects more than 300 federal laboratories with businesses, entrepreneurs and researchers through its laboratory directory, technology locator and available-technology listings. Its seven regional areas provide a practical starting point for identifying a laboratory whose scientific expertise matches a commercial problem. A search should use technical concepts, industry terms and intended application rather than assuming that the software carries the same name used by the laboratory.

Shortlisted tools should be reviewed for available versions, documentation, demonstrations, test data, supported platforms and third-party dependencies. Users should also determine whether the listing covers a deployable product, an experimental prototype or a research capability requiring further development. A strong commercial candidate usually has defined inputs and outputs, understandable operating requirements and evidence of testing beyond a single research project.

Establishing a workable evaluation path

After making initial contact, the applicant should explain the intended application, Australian operating location, target users, expected deployment model and commercial timetable to the laboratory’s technology transfer office. Providing a concise use case helps the laboratory assess whether its intellectual property can support the proposed activity. It also allows the parties to identify issues such as export controls, classified information, data restrictions or the need for a confidentiality agreement.

A non-disclosure agreement may be needed before technical documents, source code or trial data are released. Evaluation should occur under realistic conditions, using representative data and the operating systems expected in production. The testing plan should measure accuracy, processing speed, uptime, resource consumption, integration effort and failure recovery rather than relying only on laboratory benchmarks.

The laboratory then confirms its commercialization pathway. Depending on the software’s development history, it may require an invention disclosure, market assessment, funding approval or review by its parent agency. Some tools are already cleared for licensing, while others need additional validation. Acceptance of a business proposal does not guarantee approval, so the parties should agree on ownership, funding responsibilities and decision dates before substantial evaluation work begins.

Defining the non-exclusive licence

A non-exclusive licence grants defined rights to use, execute and reproduce the software without transferring ownership or preventing the owner from granting other licences. Its scope should state whether the recipient may install the software on internal servers, host it as a service, use it for customer-facing services, create modified versions or distribute outputs. The field of use, territory, duration, user categories and any limits on sublicensing or onward distribution must be explicit.

The commercial terms should reflect the value created by both parties. They may include an upfront fee, annual subscription, milestone payments, royalties, a minimum annual commitment or a combination of these. The agreement should also address technical support, software updates, security patches, implementation assistance, training and the treatment of improvements. A licence permitting modifications should explain who owns new code, whether improvements must be offered back to the laboratory and how the laboratory may use them.

Risk allocation is equally important. The software is generally supplied without an assurance that it will meet every commercial requirement, so the agreement should contain appropriate disclaimers, warranties where justified, indemnities and a liability cap. Termination rights, audit provisions, attribution requirements, publicity permissions, record retention, governing law and dispute forum should be settled before signature. Undefined obligations such as “reasonable efforts” can create avoidable disputes if measurable standards are available.

Completing commercial and legal due diligence

The prospective licensee must verify the licensor’s authority to grant the proposed rights. This includes checking the ownership of copyright in the code and documentation, control of relevant patent claims and the chain of title through contractors and research partners. Government funding can also produce retained rights or statutory march-in provisions, depending on the funding agreement and recipient. Open-source libraries, datasets and commercial components must be reviewed separately because their licences may restrict distribution or create attribution and disclosure duties.

Australian privacy obligations require particular attention where the software processes identifiable information. The Privacy Act 1988 (Cth) and Australian Privacy Principles may apply to an Australian organisation handling covered personal information, while the laboratory’s location does not determine the Australian entity’s obligations. The licence should identify the controller and processor roles, permitted data uses, security measures, breach notification, deletion, audit rights and approved subprocessors. Data-residency expectations and restrictions on combining laboratory data with commercial information should be contractual rather than assumed.

Procurement and operational rules can also affect whether the arrangement proceeds. Where the Australian Consumer Law applies to the transaction, representations about fitness, quality and performance must be accurate and consistent with the ACL and ACCC expectations. Australian Government or critical-infrastructure customers may require suppliers to align with the Australian Signals Directorate’s Essential Eight security framework. Contracts valued in USD introduce AUD conversion and bank costs, while royalties, services and intangible licences may have different GST and withholding-tax treatments, so Australian tax advice should be obtained before the final economic model is approved.

Deploying the software in Australia

The licence should fit a supportable deployment model. Cloud access may suit organisations in Sydney, Melbourne, Brisbane and Perth with reliable connectivity, but farms, mines and remote monitoring sites often require edge computing, local data storage or intermittent synchronisation. The distance between metropolitan engineering teams and regional operations makes remote onboarding, clear escalation paths and defined response times especially valuable. A staged rollout can begin with a representative pilot before wider production use.

Operational details must be settled alongside the legal agreement. This includes data import formats, API limits, user authentication, backup procedures, disaster recovery, monitoring and software version upgrades. Australian users may also require integrations with local ERP systems, cloud platforms and field equipment. Training should cover both laboratory administrators and frontline personnel, while support responsibilities should identify who restores service after a failure and who communicates security or functional changes.

The consortium’s drone-based agricultural monitoring example illustrates why technical evaluation should extend into a complete operating workflow. Australian drone operations must comply with CASA requirements, including applicable registration, permissions and operating rules. The total business case should also include infrastructure, integration and field-service costs rather than licence fees alone. Although it concerns equipment rather than laboratory software, a practical automation equipment guide offers a useful commercial analogy: testing the full deployment economics can prevent an organisation from committing to equipment or integration expenses before the software has proved its value.

Recommendations for a stronger licensing process

A disciplined process gives both the laboratory and the Australian licensee a clearer basis for decision-making. The following actions address the points most likely to delay or weaken a transaction:

The resulting licence becomes an operational framework rather than a standalone permission to use software. When each right, condition and risk has a clear owner, the Australian organisation can deploy the tool with greater confidence while the laboratory retains control over its intellectual property and future licensing choices.