australian export controls and ict-apr26...important: the listing of goods, software and...

Issued on 22 April 2016

Australian Export Controls and ICT

Australian Export Controls and ICT A guide to understanding export control laws regarding the physical export, intangible supply, publication or brokering of information and communication goods, software or technology

Foreword This Guide has been developed to assist ICT industry, software developers, academics and researchers to improve their understanding how Australia’s export control laws apply to the export, supply, publication or brokering of proliferation‐sensitive information and communication software and technology.

1 Do export controls apply to you? The Defence and Strategic Goods List (DSGL) is the list that specifies the goods, software and technology that are subject to the export controls administered by Defence. A permit is required when exporting, supplying, brokering or publishing ‘DSGL‐listed items1’, unless there is an exemption. Controls on ICT goods, software and technology listed in the DSGL apply to all sectors in the same way. They are part of a wider national and international regulatory counter‐proliferation framework. Compliance with export controls is a serious obligation but it is manageable. This Guide will help you assess if export controls apply to your circumstances. Our experience has shown that less technology is controlled in most cases than an applicant expects. Misconceptions can arise in the academic and research sectors because researchers do not account for the ‘required2’ threshold for technology controlled in the DSGL. The DGSL defines ‘required’ technology as only ‘that specific information that is peculiarly responsible for achieving or extending the controlled performance levels, characteristics or functions of a controlled item’. Although researchers may employ technology listed in the DSGL, it will often not be controlled because it will not meet this ‘required’ threshold. It is important to note though that many activities taking place within the academic community consist of information that is “basic scientific research” or that is “in the public domain”. Such information is exempt from export controls. For example, undergraduate teaching will be outside the scope of export controls because teaching generally does not address controlled technology, and the material used for teaching is almost always already in the public domain. Also, the supply of DSGL‐listed software or technology from teacher to student within Australia is not subject to export controls. The same may not be true of post‐graduate teaching which may involve applied or experimental research that, inherently, is not in the public domain. If the postgraduate teaching is based in Australia but will teach students located overseas, the supply of DSGL‐listed software or technology may require a permit if it involves unpublished information.

1 References to ‘DSGL‐listed items’ in this Guide includes goods, software and technology. 2 “Required” is a defined term. Terms in the Guide that are surrounded with double quote marks are defined terms in the DSGL. A full listing of defined terms used in this Guide is in Annex 2.



IMPORTANT: You will not require a permit if: your activity is exempt from permit requirements ‐ When is a permit not required; your technology is exempted from control ‐ Exemptions (Decontrols) to the Technology

Controls; the supply is between the same “person” ‐ Collaborating Internationally; your goods, software or technology are not listed in the DSGL ‐ Summary of the main ICT

controls in the DSGL; or your technology is not required for the development, production or use of a DSGL‐listed item ‐

Understanding the Required Threshold. Annex 4 contains case studies of scenarios illustrating the circumstances where a permit may, or may not, apply.

IMPORTANT: You may require a permit if your goods or technology are listed in the DSGL, and there is no exemption for your circumstances.



2 How do I apply for advice or a permit? Before you apply for a permit with Defence Export Controls, you can conduct your own assessment of whether your goods, software or technology are listed on the DSGL, and whether your activity (the way in which you will be supplying, brokering or publishing) is controlled by the Defence Trade Controls Act. This Guide provides information on the types of controls and the exemptions that may apply.

STEP 1: The Online DSGL Tool has two key functions; a questionnaire and a search feature. Through a series of Yes/No style questions you can self‐assess if the activity is actually subject to export controls. People who are unfamiliar with export controls may find it easier to first assess if their activity is controlled before searching the DSGL. The search function displays the control item text from the DSGL based on the terms you enter, as well as links to other text that are key to understanding the extent or limits of the controls. The tool can be accessed at https://dsgl.defence.gov.au.

STEP 2: If you are unable to self‐assess whether the items are listed on the DSGL, or the exporting, supplying, publishing or brokering activity is controlled, or you are still uncertain, you can submit an “Application for DSGL/Activity Assessment” to us. Once we have considered your application, we will send you an assessment of whether the items or activities are controlled, and instructions on what to do next.

STEP 3: If we send you advice that you need to apply for a permit, or you have self‐assessed that a permit is required, you should submit an “Application to Export or Supply Controlled Goods and Technology”. We will assess the application, usually within 15 working days, and either issue you with a permit, or advise you why a permit is not required. Complex cases can take up to 35 working days to process. For some highly complex or sensitive cases that need extensive interagency consultation, the assessment time can exceed 35 working days.

When you submit an application you should attach documentation that helps us to assess the goods, software, and technology, and details of how the export, supply, publication or brokering activity will be undertaken. This assists us to get our assessment right the first time, and helps to ensure that if we need to contact you we have a good understanding of your application.

If the goods, software or technology involves encryption or cryptographic functionality, you should include the following as attachments to your application:

o A brief overview of the nature of your work.For example, if your field is cryptography, it will assist the assessment process for you to describe thetypes of mathematics you work with and the current developments in your field. This description couldbe similar to the wording used for a grant or research project proposal or summary.

o What is the primary function of the item?For example, is the primary function to provide confidentiality of data information?

o What is the cryptographic functionality of the item?For example, is the item used solely for the purposes of authentication or providing a digital signature?

o What stage of research is your work at?For example, has this body of work been funded? Are you in the early research stages of reviewingrelated papers and principles?

o Are there any practical applications of your research which have been developed?For example, do you have a final product or solution in mind?

Applications that contain encryption or cryptographic functionality are forwarded to the Australian Signals Directorate (ASD) as a routine part of our assessment process. ASD provide the technical expertise to assess the control status, and may contact you during their assessment for further information.

Application forms can be downloaded from www.defence.gov.au/deco.



3 Overview of Export Controls Australia’s export control system is part of an international effort to stem the proliferation of conventional, chemical, biological, and nuclear weapons and the systems that deliver them. Many goods designed for legitimate civil purposes can also contribute to the development of Weapons of Mass Destruction (WMD) or be used for a military end‐use. One of the key objectives of export controls is to ensure exports of such proliferation‐sensitive technology are consistent with Australia’s security interests and international obligations. Australia is a signatory to many international treaties and conventions, and a member of several export control regimes, all of which serve our national interests and contribute to the global effort aimed at reducing the risk of proliferation. Each export control regime assesses whether goods, software or technologies are able to contribute to a WMD or military end‐use and publishes a regime list of controlled goods, software and technologies. Australia’s control list, the Defence and Strategic Goods List (DSGL), is drawn directly from the regime control lists agreed by the export control regimes. The DSGL has two parts; Part 1 is the listing of controlled military items, and Part 2 is the controlled dual‐use items. More information on International Export Control Regimes and Treaties, and the DSGL is available at www.defence.gov.au/deco.

IMPORTANT: The listing of goods, software and technologies on the DSGL does not mean that the export, supply, publication or brokering of the item is prohibited; just that a permit may be required.

3.1 What do you mean by export, supply, publication and brokering? Exporting occurs when DSGL‐listed items leave Australia in tangible form, when it is intended that they be landed outside Australia. It includes items that are being sold, for demonstration, for research or teaching purposes, or being returned to a manufacturer or agent for repair. It also includes controlled software and technology stored on a physical medium, such as a USB drive, laptop, hard drive or CD that leaves Australia. Exports include scenarios where the software or technology is stored on a media storage device that is sent via postal service, or is carried in hand‐held or checked‐in luggage. Supply occurs when a person in Australia sends or provides access to DSGL‐listed software or technology to another person outside of Australia; e.g. the supply of information transmitted electronically. Examples of supply include sending DSGL‐listed software or technology via email or fax, or providing someone outside of Australia with a password to access DSGL‐listed software or technology stored electronically. The act of supplying technology is more likely to be controlled than the act of publishing technology. This is because researchers are more likely to transfer detailed methodologies of DSGL‐listed items during the course of their research before they end up publishing the outcomes of their research. Publication is when DSGL‐listed software or technology is made available to the public, or to a section of the public, via the internet or otherwise. Publication controls apply to anyone in Australia, or an Australian citizen or resident or Australian organisation located anywhere in the world.

EXAMPLE: The sending of source code, which contains controlled Part 2 technology, from Australia to a person overseas is a supply and requires a permit. Posting that same source code on a public website for anyone to access is publishing.

Brokering is when a person or organisation acts as an agent or intermediary in arranging the supply of DSGL‐listed items between two places located outside of Australia, and they receive a benefit for arranging that supply. Research benefit is not a benefit for the purposes of the brokering control. Further guidance on each of these activities is available on our website, www.defence.gov.au/deco.



4 When is a permit not required? The Defence Trade Controls Act 2012 contains several circumstances where the supply or publication of DSGL‐listed software or technology does not require a permit. In general, oral discussions and publication of Part 2 DSGL‐listed software and technology do not require a permit.

4.1 Oral supply You do not require a permit when orally supplying DSGL‐listed software and technology, for example by:

having a telephone conversation;

participating in a video conference; or

live streaming. Most importantly, given the specific and generally high thresholds for any technology to meet the controlled threshold in the DSGL, and given how complex controlled technology is, it is highly unlikely that controlled technology will be ever conveyed orally, except for one circumstance – you will need a permit if you are orally supplying a person overseas access to technology (e.g. telling them a password).3

EXAMPLES:

Oral supply exception applies: Kate has a telephone conference with her research partners in Germany. During that conversation, Kate discusses DSGL technology. The oral supply exception applies and therefore a permit is not required. However, as mentioned above, it is highly unlikely that controlled technology will ever be conveyed orally.

Oral supply exception does not apply: Kate has a telephone conference with her research partners in Germany. During that conversation, Kate orally provides her colleagues with a password to access a cloud server, so that they can share DSGL controlled technology. The oral supply exception does not apply as Kate is providing access to DSGL technology.

Therefore, a permit is required.

4.2 Publication of Part 2 DSGL‐listed Software and Technology There is no requirement for a permit to publish DSGL‐listed software and technology that is in Part 2 of the DSGL. This includes publishing recordings of verbal supply that contains Part 2 DSGL‐listed software or technology. More detail on publishing “software” and “technology” is available at our website.

IMPORTANT: Military software and technology is treated differently. It is an offence to publish software or technology that is listed in Part 1 (Munitions/Military List) of the DSGL without approval. This includes pre‐publication activities, such as submitting a publication for peer review.

3 Technically you also require a permit to orally supply technology to a Weapons of Mass Destruction program or for a military end use, but as it is almost

impossible to supply technology orally, this does not warrant further consideration.



4.3 Pre‐Publication supply As publishing DSGL‐listed software or technology that is in Part 2 of the DSGL does not require approval, ‘pre‐publication’ supply activities for Part 2 technology are similarly exempted from needing a permit. As a general concept, the pre‐publication exception would be available from the time the software or technology is ‘ready to be made public’.

EXAMPLES: No permits would be required for: Software that is supplied to a person overseas for the purpose of placing the software into

the public domain, or submitting the software to a certification authority for evaluation purposes.

Technology, including source code in written form, that has been documented and is supplied to a person overseas for review or expert commentary.

4.4 Supplies made to or by prescribed officials The supply of “software” or “technology” by, or to, members of the following groups in the course of their official duties does not require a permit:

Australian Defence Force;

Australian Public Service employee;

Australian Federal Police;

State or Territory police;

Australian Security Intelligence Organisation employee; or

Australian Secret Intelligence Service employee.



5 Exemptions (Decontrols) to the Software and Technology Controls There are several overarching exemptions which decontrol some “software” and “technology” that would otherwise be subject to export control. In Part 1 of the DSGL, the technology exemptions are written as Notes against Item ML22. In Part 2 of the DSGL, there are two General Notes that apply to all software and technology controls, being the General Technology Note and the General Software Note. These notes exempt from export controls:

Software and technology that is already “in the public domain”;

Technology that is “basic scientific research”;

Software and technology that is the minimum necessary information for patent applications;

Software (object code) and technology that is the minimum necessary for the installation, operation, maintenance and repair of controlled items, whose export has been previously authorised;

Software that is mass‐marketed; or

Medical equipment that incorporates controlled software.

5.1 Information in the Public Domain A permit is not required for information that is in the public domain. Information in the public domain can be:

published technical papers;

publications such as books, journals and newspapers that are available from stores or libraries that are accessible to the public;

subscriptions which are available to any individual who desires to obtain or purchase the published information;

unlimited distribution at a conference, meeting, seminar, trade show or exhibition that are generally accessible to the public;

information provided by a patent office without restriction in support of a domestic patent application;

information on general scientific principles that are commonly taught in schools, colleges and universities;

general information for marketing purposes such as product brochures and company presentations (if it contains intellectual property then it may be controlled technology), but it will be unlikely that company literature that is in the public domain will be controlled; or

basic information on function, purpose or general system descriptions of defence articles.

5.2 Basic Scientific Research “Basic scientific research” is defined in the DSGL as experimental or theoretical work undertaken principally to acquire new knowledge of the fundamental principles of phenomena or observable facts, not primarily directed towards a specific practical aim or objective. There are two approaches which may help to determine if research fits within this exemption – the use of the Australian Bureau of Statistics research definitions, or the use of Technology Readiness Levels. One approach is to assess if the Research meets the criteria of the Australian Bureau of Statistics definitions as being either pure basic research or strategic basic research. Research that meets either of these definitions will fall within the threshold of “basic scientific research” and will therefore be exempt from permit requirements. In addition, any technology that is derived from that research activity is also not subject to export controls.



The Australian Bureau of Statistics definitions4 are as follows:

Pure basic research is experimental and theoretical work undertaken to acquire new knowledge without looking for long term benefits other than the advancement of knowledge, and

Strategic basic research is experimental and theoretical work undertaken to acquire new knowledge directed into specified broad areas in the expectation of useful discoveries. It provides the broad base of knowledge necessary for the solution of recognised practical problems.

An alternative approach is the assessment of the maturity of the technology being researched using Technology Readiness Levels (TRLs). Technology Readiness Levels is a methodology that is used to determine the maturity of technology as it moves through its lifecycle from research and development through to production and deployment. Technology Readiness Levels are based on a scale from 1 to 9 with 9 being the most mature technology. In the context of ICT development and research, technology that is at levels 1 or 2 will not require a permit. As the technology reaches levels 3 and 4 in its maturity, the requirement for a permit will generally still not be met but an assessment should be conducted to confirm that view. Technology that is at levels 5 and above will usually have met the threshold of being technology “required” for the “development”, “production” or “use” of a DSGL‐listed item. Unless an exemption applies, technology at these levels will require a permit if it is supplied. A table describing the Technology Readiness Levels in more detail is at Annex 1.

5.3 The minimum necessary information for patent applications This exemption applies to the export or supply of DSGL‐listed software or technology where it is done for the purpose of seeking a patent in Australia or overseas. Seeking a patent includes lodging a patent application and the supply of DSGL‐listed software or technology to a person or organisation (e.g. a Patent Office, patent attorney, research collaborator or a patent review panel) that is directly associated with the lodging (or potential lodging) of a patent application, or as a result of the patent examination process. Supply for a purpose that is not directly related to seeking a patent will require a permit (unless other exemptions apply); for example, the supply of DSGL‐listed software or technology to a research collaborator located overseas before a decision is made to seek a patent. Once a provisional patent application is filed, any supplies of DSGL‐listed software or technology to further develop an invention prior to preparing/submitting a complete patent application will require a permit. The supply of DSGL‐listed software or technology for the purpose of locating investors and determining overseas markets (including forwarding a recently‐filed provisional application) will require a permit. The process of publishing a patent (or an unsuccessful application) into the public domain is covered by this exemption. Until such time as that information exists in the public domain, it is still controlled and would require a permit to be supplied if it is not for the purpose of seeking a patent and no other exemptions applied. This exemption does not apply to nuclear technology listed in Category 0 of the DSGL.

4 As at 22 July 2015



5.4 “Technology” for the installation, operation, maintenance and repair of previously exported goods

A permit is not required for:

“object code”being exported or supplied for the purposes of installation, operation, maintenance and repair of items that have been previously approved for export by Defence Export Controls, or

“technology” that is going to the same destination and end‐user as the originally‐approved items.

IMPORTANT: This exemption does not apply to “Information Security” software listed in Category 5, Part 2.

5.5 Mass‐market exemption for Software The General Software Note contains an exemption for “software” that meets all of the following conditions:

the item is generally available to the public by being sold, without restriction, from stock at retail selling points by means of any of over‐the‐counter transactions, mail order transactions, electronic transactions or telephone order transactions; and

the cryptographic functionality cannot easily be changed by the user; and

the item is designed for installation by the user without further substantial support by the supplier; and

when necessary, details of the items are accessible and will be provided, upon request, to the appropriate authority in the exporter’s country in order to ascertain compliance with conditions described in the three points above.

Restrictions could be achieved through:

only making your software available to particular clients or users;

the price is only available on request; or

certain criteria must be met before the software will be supplied. IMPORTANT: The mass‐market exemption does not apply to “information security” software listed in Category 5, Part 2. Note 3 in this Part lists additional requirements that must all be met for “information security” software to be exempt:

generally available to the public by being sold without restrictions; and the cryptographic function cannot easily be changed by the user; and it must be designed for installation by the user without further substantial support by the

supplier; and details of the above points will be made available to the regulator.

5.6 Medical equipment A permit is not required for Part 2 (Dual‐use) DSGL‐listed goods, software or technology when such items are incorporated into equipment that has been specially designed for medical end‐use. Specially designed for medical end‐use means that the equipment is designed for medical treatment or the practise of medicine, but it does not include equipment for medical research.

EXAMPLE: A company is developing software, including a cryptographic component, for use in a medical device. A permit is required by the company to grant access to the cryptographic routines and source code by overseas developers. However, when the medical device is exported from Australia a permit is not required.



6 Collaborating Internationally Software development will frequently rely on contributions from developers located across the world. These developers may be employed by an Australian entity but located elsewhere in the world; they may be employed by a foreign entity that is part of the same global organisation; or the developer may be a contractor who is located somewhere other than Australia. Different permit obligations will apply depending upon the actual circumstances of the relationship and the means by which any supply activity between a person in Australia and a person who is overseas occurs.

6.1 Intra‐company supply A permit is not required if the sender and recipient are the same “person”. The definition of “person” includes supplies between employees of the same body corporate, wherever located. Australian companies that are part of multinational corporations should note though, for the purposes of the legislation a body corporate extends only to the Australian registered entity.

EXAMPLES: A permit would not be required for: An individual uploading DSGL‐listed software or technology to a shared environment so

that the same individual can later access it when the individual travels outside Australia. An individual in Australia, acting as an employee of a body corporate, emailing DSGL‐

listed software or technology to another individual outside Australia who is also acting as an employee of the same body corporate.

6.2 Inter‐company supply The following are circumstances where the sender and recipient are not the same person:

A body corporate and its subcontractor;

A body corporate and its agent (who is not an employee);

A body corporate and its subsidiary;

A body corporate and its parent company;

A body corporate and any other company, even if it is wholly owned by the first body corporate; or

A body corporate and its employee, where the employee is not acting in the course of their duties.

6.3 Collaboration methods Companies that are part of multinational corporations often use various collaborative methods of sharing DSGL –listed software or technology rather than point‐to‐point transfers such as email or file transfer. Many of these methods are also common to international academic research collaborations. A common situation is where a multinational corporation or a global research institute has a shared environment (e.g. server, server hub, repository, document sharing program or online data sharing environment) for its subsidiary companies and/or individual researchers.

IMPORTANT: Export controls are not determined by where the software or technology is stored, or where that storage is located. Instead, it depends on whether a person in Australia supplies (including giving access to) DSGL-listed software or technology to a person outside Australia – regardless of the method.



A “person” located in Australia makes a supply when doing one of the following things:

Creates new DSGL‐listed software or technology and uploads it to a shared environment so that it becomes accessible by an individual or a foreign corporate entity outside Australia;

Downloads DSGL‐listed software or technology from this shared environment and develops and improves that technology (e.g. contributes to a collaborative software project), and then uploads the completed version of the DSGL‐listed software or technology so that it becomes accessible by an individual or a foreign corporate entity outside Australia;

Develops and improves that DSGL‐listed software or technology while it remains in the shared environment using remote access technology (i.e. without actually downloading the data), and that DSGL‐listed software or technology continues to be accessible by an individual or a foreign corporate entity outside Australia; or

Provides the username/password or other information required to gain access to this shared environment to an individual or a foreign corporate entity located outside Australia, even if they provide this information orally.



7 Summary of the main ICT Controls in the DSGL The DSGL contains a number of specific controls related to ICT goods and technology. These include:

Part 1: Munitions List: o Electronic equipment specially designed for military use (ML11) including software (ML21) and

technology (ML22); and

Part 2: Dual‐Use List: o High‐performance computers; o Systems, equipment and technology for the generation, operation or delivery of intrusion software; o Telecommunications systems, IP network surveillance equipment, missile telemetry and telecontrol

equipment, and test, inspection and production equipment; and o Information security systems, and test, inspection and production equipment.

Goods, software and technology designed or adapted for military use that are listed in Part 1 of the DSGL are controlled and will require a permit to be exported or supplied, unless one of the previously outlined exemptions is available. Dual‐use goods, software and technology that are listed in Part 2 of the DSGL, even if they are developed and used for commercial needs or used in an academic or research activity, will require a permit to be exported or supplied, unless one of the previously outlined exemptions is available. These summaries are further expanded below with the links to the relevant control text in the Online DSGL Tool. Both the summary below, and the full text on the Online DSGL Tool, should be read if the summary could be applicable to your circumstances.

7.1 High‐performance computers The following are links to relevant control items:

4A001

4A003

4A004

4A101

4A102

4D001

4D002

4E001

7.1.1 What is controlled? High performance computers are systems which can operate in extreme conditions, are radiation hardened, designed or modified for use in or for space launch vehicles, are specially designed for modelling, simulation or design integration of space launch vehicles, or have very high processing speeds. Digital computers, systolic array computers, neural computers, high performance quantum computers, and optical computers are also controlled.



7.2 Systems, equipment and technology for the generation, operation or delivery of intrusion software

In 2013, the Wassenaar Arrangement included new controls for the control of high end intrusion software tools. Export controls on the supply and export of such tools is very important considering the damage these tools can cause. Defence strongly supports these controls, and regulates their export or supply to prevent proliferation. The following are links to relevant control items:

4A005

4D004

4E001.c

7.2.1 What is controlled? This control includes the hardware, “software” and “technology” that is required to generate, operate, deliver or communicate with “intrusion software”, including:

a command and control or delivery platform itself and its core functional components;

malware command and control components, and build tools;

the toolkit for a piece of custom malware designed to extract data from a computer.

software that uses or serves exploits (not the actual malware binaries or exploits)

software that is specially designed or modified to o steal/modify data, or to modify the standard execution path to run externally provided

instructions, and either o avoid detection by monitoring tools, or o defeat protective countermeasures;

technology that is sufficient to achieve the appropriate combination of functions that o avoid monitoring tools, and o can defeat protective countermeasures, and either o is capable of extraction or modification of data, or o is able to modify the execution path to accept external instructions.

7.2.2 What is not controlled? “Intrusion software” as a stand alone component is not controlled. Rather, it is the hardware, software and technology components which are used to control or disseminate this software which are controlled. Defence acknowledges the need to balance national security needs with the economic interests in preserving a flourishing cyber industry. Bearing in mind that exemptions apply for software and technology that is “in the public domain”, there is no control on bugs and vulnerability information on commercially available software, the following (including if they represent subsets of the list in 7.2.1) would not be controlled when exported or supplied:

exploit or malware samples, or proof of concepts;

information on how to search for, discover or identify a vulnerability in a system, including vulnerability scanning;

information about the vulnerability, including causes of the vulnerability (eg bug bounties);

information on testing the vulnerability, including fuzzing or otherwise trying different inputs to determine what happens;

information on analysing the execution or functionality of programs and processes running on a computer, including decompiling or disassembling code and dumping memory;

port scanners, packet sniffers, protocol analysers and vulnerability scanners (which just find vulnerabilities without actually exploiting them and extracting or modifying data);

open source penetration testing software;

commercial off‐the‐shelf penetration testing software that is mass marketed (i.e. meets sub‐section (a) of the General Software Note);



software used to jailbreak commercial commodity devices;

information about “intrusion software” which is in the “public domain”;

publishing information about intrusion software into the public domain; and

pre‐publication activities for information regarding intrusion software, such as supplying a final draft of a publication or presentation.



7.3 Telecommunications, IP network surveillance, missile telemetry and telecontrol equipment The following are links to relevant control items:

5A001

5A101

5B001

5D001

5D101

5E001

7.3.1 What is controlled? This control covers telecommunications systems, equipment, and components that are, or contain:

EMP protection/ ionising radiation;

protection/ temperature hardening;

Underwater untethered communications systems;

High capacity radio transmitters;

Spread spectrum / frequency hopping;

Ultra‐wideband modulation;

High capacity digitally controlled radio receivers ;

Voice coding at rates of less than 2400 bit/s;

Optics fibres of more than 500m in length with a tensile strength of 2x109 N/m2 or more;

Electronically steerable phased array antennae operating above 31.8GHz;

Radio direction finding equipment >30MHz;

Jamming and interception equipment for mobile telecommunication services;

Passive Coherent Location systems or equipment;

Counter Improvised Explosive Device equipment; or

IP network communications surveillance systems. There are also controls on:

telemetry and telecontrol equipment, including ground equipment, designed or modified for missiles; and

test, inspection and production equipment that is specially designed for the development, production or use of telecommunications systems, and their functions or features.



7.4 “Information security” systems, and test, inspection and production equipment The following are links to relevant control items:

5A002

5B002

5D002

5E002

7.4.1 What is controlled? This control applies to systems, equipment, application‐specific electronic assemblies, modules and integrated circuits that are:

designed or modified to use “cryptography” employing digital techniques;

designed or modified to perform cryptanalytic functions;

specially designed or modified to reduce compromising emanations of information‐bearing signals;

designed or modified to use cryptographic techniques to generate the spread code for “spread spectrum” or “frequency hopping” systems;

designed or modified to use cryptographic techniques to generate channelizing codes, scrambling codes or network identification codes, for systems using ultra‐wideband modulation techniques;

ICT systems that are evaluated to assurance level exceeding EAL‐6;

communications cable systems designed to detect intrusion;

designed or modified to use or perform “quantum cryptography”; or

designed or modified to enable an item to achieve or exceed the functionality performance levels of other controlled items.

A permit will be required to supply or export:

functional strong crypto (source code, binary code or hardware incorporating the strong crypto), that will be directly implemented into a commercial or military product5 that is listed in the Defence and Strategic Goods List, or performs functions specified in 5A002, and there is no exemption in the General Technology Note, the General Software Note, the Cryptography Note, or elsewhere within the DSGL; or

software that is used to achieve the previous dot point, or has the characteristics or simulates the previous dot point; or

technology (eg. design methodology, recipe, algorithm, API or SDK) that meets the control threshold of systems, equipment and components listed in 5A002.

7.4.2 What is not controlled? The following are exempt from the controls:

software and technology that is “in the public domain”;

technology that is “basic scientific research”;

software and technology that is the minimum necessary information for patent applications;

products being exported for personal use (Note 2 in Part 2 of Category 5 describes this exemption);

hardware and related software that can be classified as for mass‐market use (Note 3 in Part 2 of Category 5 describes this exemption);

5 Crypto that is implemented into a military product will be controlled under either ML11 or ML22.



equipment, in which the cryptographic functionality is limited to supporting the primary function of the equipment, and the primary function of the equipment is not:

o information security o a computer o networking o sending, receiving or storing information (except in support of entertainment, broadcasting,

medical management or digital rights management) (Note 4 in Part 2 of Category 5 describes this exemption);

cryptography that is only used for authentication, digital signature or copy‐protection; or

equipment that is used for: o smart cards, smart card readers/writers, banking or money transactions; o portable or mobile radiotelephones and similar client wireless devices for civil use; o cordless telephone equipment not capable of end‐to‐end encryption; o wireless personal portable or mobile telephones for civil use which are not capable of end‐to‐end

encryption; o certain commercial wireless/radio network devices; o Switches, routers or relays where cryptographic functionality is limited to tasks of “operations,

administration or maintenance” (“OAM”); or o General purpose computers or servers where cryptography is integrated inside a CPU excluded by

Note 3.; part of an operating systems not listed in 5D002 or limited to “OAM”. A permit is not required to supply or export:

publicly available strong crypto (source code, binary code or hardware incorporating the strong crypto); or

publically available strong crypto in emails, presentations, workshops, executable simulations, and laboratory prototypes to demonstrate and validate proof of principle – these will be exempt by virtue of being “basic scientific research”, “in the public domain” or a publication activity; or

technology, (eg. design methodology, recipe, algorithm, API or SDK), that of itself does not meet the control threshold of systems, equipment and components listed in 5A002; or

software, source and object code that is compiled from publicly available cryptography software and technology.



8 Understanding the “required” threshold When combined, the control listing for a DSGL technology item and the General Technology Note limit the technology that is subject to export control to only that specific information that is peculiarly responsible for achieving or extending the controlled performance levels, characteristics or functions of a controlled item that is necessary for the “development”, “production” or “use” of the controlled goods or software. Each control item text will identify whether it is the technology for the “development”, “production” or “use” of the controlled item that is subject to control. The fact that the technology is intended for civilian use does not remove the requirement to seek a permit, though it would be relevant to whether a permit would be granted.

EXAMPLE: Control Item 4A001.a.1 lists electronic computers and related equipment, electronic assemblies and specifically designed components that are specially designed to operate at an ambient temperature below 228 K (‐45C) or above 358 K (85C). This control does not apply to computers specifically designed for civil automobile or railway train applications.

The related technology control, 4E001, only applies to the technology which is “required” for “development”, “production” or “use” of the computer so that can operate at those temperatures, i.e. the connector and circuit designs and configurations which can be sensitive to high and low temperatures. Other more general technology that does not influence the computer’s ability to function at high and low temperatures, or technology that does not contribute to the computer achieving that controlled level of performance [operating above 85C and below ‐45C], is not controlled.

Controlled “technology” may take the form of blueprints, plans, diagrams, models, formulae, tables, engineering designs and specifications, or manuals and instructions, either written or recorded on other media or devices such as disks, tapes or read‐only memories. It can also include instruction, skills, training, working knowledge or consulting services that involve the transfer of “technology”. Some specific “technology” is listed in the DSGL and controlled in its own right; however, most technology controls are directly related to controlled goods and software.

EXAMPLE: Super computers are listed in Control Item 4A003.b. The information that is needed for the general user to log on and undertake research activities on the computer is not controlled because the information to perform these tasks is likely be in the public domain. However, in the case of a super computer where hardware support is undertaken by contractors located outside of Australia, and someone in Australia needs to supply the super computer’s technology to that overseas contractor, that technology will be controlled as it is the technology “required” for the “use” of the super computer.



9 Conferences In general, permits will not be required for a person to present at a conference or to send (or take) the material for the presentation. The control thresholds for ICT‐related DSGL‐technology are very high and it would be extraordinary for a conference paper to contain technology that meets the DSGL technology control thresholds. This also extends to sending the presentation material to the conference organisers. In some circumstances, a researcher may attend an overseas workshop or meeting to discuss with their colleagues their research on DSGL technology. This would not be a conference situation and therefore the researcher may require a permit, or an amendment to their existing permit, to cover this situation.

10 Record‐keeping requirements and reporting The DTC Act requires a permit holder to keep records of the activities that were conducted under the permit for 5 years. There are various approaches that a permit holder can take to meet their obligation to keep a record of a supply, and these include:

• keeping copies of the supply activity, e.g. saving the email; • maintaining a register/log of supply activities, e.g. a spreadsheet with columns for the permit number,

software or technology description, end‐user/recipient, date supply commenced, and date supply ceased; or

• making a note when the first supply activity occurs and a similar note when the supply activity concludes, or the permit expires.

Similar obligations to keep records of exported goods apply to permits issued under the Customs Act 1901. In these circumstances, the obligation can be met by options including keeping a record of the commercial documentation that is generated to send the goods by sea, air or post. As a condition of a permit that is issued, there may be an additional requirement for the permit holder to submit a report to us on the activities that occurred during a particular period. This condition will be clearly stated on the permit when it is issued. We will send you reminders when a report is due, and reminders if you do not submit your report in the required timeframe.

11 Where can I get more information? More information on the export controls administered by Defence Export Controls, as well as the application forms required to apply for a permit, can be found at www.defence.gov.au/deco Email: [email protected] Phone: 1800 66 10 66



Annex 1: Technology Readiness Levels Technology Readiness Levels are a way of determining the maturity of technology as it moves through its lifecycle from research and development through to production and deployment. Technology Readiness Levels are based on a scale from 1 to 9 with 9 being the most mature technology.

Description Permit Required

TRL1 ‐ Scientific research begins translation to applied R&D ‐ Lowest level of technology readiness. Scientific research begins to be translated into applied research and development. Examples might include paper studies of a technology’s basic properties.

No

TRL2 ‐ Invention begins ‐ Once basic principles are observed, practical applications can be invented. Applications are speculative and there may be no proof or detailed analysis to support the assumptions. Examples are limited to analytic studies.

No

Research and Development

TRL3 ‐ Active R&D is initiated ‐ Active research and development is initiated. This includes analytical studies and laboratory studies to validate analytical predictions of separate elements of the technology. Examples include components that are representative, not yet integrated or not yet validated.

Maybe

TRL4 ‐ Basic technological components are integrated ‐ Basic technological components are integrated to establish that the pieces will work together.

Maybe

TRL5 ‐ Fidelity of breadboard technology improves significantly ‐ The basic technological components are integrated with reasonably realistic supporting elements so it can be tested in a simulated environment. Examples include “high fidelity” laboratory integration of components.

Yes (if no exemptions apply)

TRL6 ‐ Model/prototype is tested in relevant environment ‐ Representative model or prototype system, which is well beyond that of TRL 5, is tested in a relevant environment. Represents a major step up in a technology’s demonstrated readiness. Examples include testing a prototype in a high‐fidelity laboratory environment or in simulated operational environment.


Testing and Dem

onstration

TRL7 ‐ Prototype near or at planned operational system ‐ Represents a major step up from TRL 6, requiring demonstration of an actual system prototype in an operational environment.


TRL8 ‐ Technology is proven to work ‐ Actual technology completed and qualified through test and demonstration.


Production

and

Dep

loym

ent

TRL9 ‐ Actual application of technology is in its final form ‐ Technology proven through successful operations.




Annex 2: Definitions used in this Guide “Basic scientific research” means experimental or theoretical work undertaken principally to acquire new knowledge of the fundamental principles of phenomena or observable facts, not primarily directed towards a specific practical aim or objective.

“Cryptography” means the discipline which embodies principles, means and methods for the transformation of data in order to hide its information content, prevent its undetected modification or prevent its unauthorised use. “Cryptography” is limited to the transformation of information using one or more ‘secret parameters’ (e.g., crypto variables) or associated key management.

Note: “Cryptography” does not include fixed data compression or coding techniques.

Technical Note: ‘Secret parameter’: a constant or key kept from the knowledge of others or shared only within a group.

“Development” is related to all stages prior to serial production, such as: design, design research, design analyses, design concepts, assembly and testing of prototypes, pilot production schemes, design data, process of transforming design data into a product, configuration design, integration design, layouts.

“Frequency hopping” means a form of “spread spectrum in which the transmission frequency of a single communication channel is made to change by a random or pseudo‐random sequence of discrete steps.

“In the public domain”, as it applies herein, means “technology” or “software” which has been made available without restrictions upon its further dissemination (copyright restrictions do not remove “technology” or “software” from being “in the public domain”).

“Information security” is all the means and functions ensuring the accessibility, confidentiality or integrity of information or communications, excluding the means and functions intended to safeguard against malfunctions. This includes “cryptography”, ‘cryptanalysis’, protection against compromising emanations and computer security.

Note: ‘Cryptanalysis’ is the analysis of a cryptographic system or its inputs and outputs to derive confidential variables or sensitive data, including clear text.

“Intrusion software” “Software” specially designed or modified to avoid detection by ‘monitoring tools’, or to defeat ‘protective countermeasures’, of a computer or network�capable device, and performing any of the following:

a. The extraction of data or information, from a computer or network�capable device, or the modification of system or user data; or

b. The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.

Note 1: “Intrusion software” does not include any of the following: a. Hypervisors, debuggers or Software Reverse Engineering (SRE) tools; b. Digital Rights Management (DRM) “software”; or c. “Software” designed to be installed by manufacturers, administrators or users, for the purposes of

asset tracking or recovery.

Note 2: Network capable devices include mobile devices and smart meters.



Technical Notes: 1. ‘Monitoring tools’: “software” or hardware devices, that monitor system behaviours or processes

running on a device. This includes antivirus (AV) products, end point security products, Personal Security Products (PSP), Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) or firewalls.

2. ‘Protective countermeasures’: techniques designed to ensure the safe execution of code, such as Data Execution Prevention (DEP), Address Space Layout Randomisation (ASLR) or sandboxing

"Operations, Administration or Maintenance" ("OAM") means performing one or more of the following tasks:

a. Establishing or managing any of the following: 1. Accounts or privileges of users or administrators; 2. Settings of an item; or 3. Authentication data in support of the tasks described in paragraphs a.1. or a.2.;

b. Monitoring or managing the operating condition or performance of an item; or c. Managing logs or audit data in support of any of the tasks described in paragraphs a. or b. Note: "OAM" does not include any of the following tasks or their associated key management functions:

a. Provisioning or upgrading any cryptographic functionality that is not directly related to establishing or managing authentication data in support of the tasks described in paragraphs a.1. or a.2. above; or

b. Performing any cryptographic functionality on the forwarding or data plane of an item. “Object code” means an equipment executable form of a convenient expression of one or more processes (“source code” (source language)) which has been converted by programming system. Australian “person” means:

(a) the Commonwealth, a State or a Territory or an authority of the Commonwealth, a State or a Territory; or (b) an individual who is an Australian citizen; or (c) an individual who is, within the meaning of the Migration Act 1958, the holder of a permanent visa; or (d) a body corporate incorporated by or under a law of the Commonwealth or of a State or Territory.

“Production” means all production phases, such as: construction, production engineering, manufacture, integration, assembly (mounting), inspection, testing, quality assurance. “Quantum cryptography” means a family of techniques for the establishment of a shared key for “cryptography” by measuring the quantum‐mechanical properties of a physical system (including those physical properties explicitly governed by quantum optics, quantum field theory, or quantum electrodynamics). “Required”, as applied to “technology”, refers to only that portion of “technology” which is peculiarly responsible for achieving or extending the controlled performance levels, characteristics or functions. Such “required” “technology” may be shared by different goods. “Software” means a collection of one or more “programs” or ‘microprograms’ fixed in any tangible medium of expression.

Note: ‘Microprogram’ means a sequence of elementary instructions, maintained in a special storage, the

execution of which is initiated by the introduction of its reference instruction into an instruction register.

“Spread spectrum” means the technique whereby energy in a relatively narrow‐band communication channel is spread over a much wider energy spectrum.



“Technology” means specific information necessary for the “development”, “production” or “use” of a product. This information takes the form of ‘technical data’ or ‘technical assistance’. Controlled “technology” for the Dual‐Use List is defined in the General Technology Note and in the Dual‐Use List. Controlled “technology” for the Munitions List is specified in ML22.

Note 1: ‘Technical assistance’ may take forms such as instruction, skills, training, working knowledge and consulting services and may involve the transfer of ‘technical data’.

Note 2: ‘Technical data’ may take forms such as blueprints, plans, diagrams, models, formulae, tables,

engineering designs and specifications, manuals and instructions written or recorded on other

media or devices such as disk, tape, read‑only memories.

“Use” means operation, installation (including on‐site installation), maintenance (checking), repair, overhaul and refurbishing.



Annex 3: Notes in the DSGL that apply to control items The DSGL contains Notes which provide guidance on how to interpret a control text. Notes may apply to a Part, Category Item or sub‐item. The General Technology Note and the General Software Note apply to all technology and software controls through Part 2.

General Technology Note (This note applies to all technology controls in Categories 1 to 9.) 1. The export of “technology” which is “required” for the “development”, “production” or “use” of goods

controlled in Categories 1 to 9, is controlled according to the provisions of Categories 1 to 9. 2. “Technology” “required” for the “development”, “production” or “use” of goods under control remains under

control even when applicable to non�controlled goods. 3. Controls do not apply to that “technology” which is the minimum necessary for the installation, operation,

maintenance (checking) and repair of those goods which are not controlled or whose export has been authorised. Note: This does not release such “technology” specified in 1E002.e., 1E002.f., 8E002.a. and 8E002.b.

4. Controls on “technology” transfer do not apply to information “in the public domain”, to “basic scientific

research” or to the minimum necessary information for patent applications.



General Software Note (This note applies to all software controls within Categories 0 to 9.) Categories 0 to 9 of this list do not control “software” which is any of the following: 1. Generally available to the public by being:

a. Sold from stock at retail selling points, without restriction, by means of: 1. Over‐the‐counter transactions; 2. Mail order transactions; 3. Electronic transactions; or 4. Telephone order transactions; and

b. Designed for installation by the user without further substantial support by the supplier; Note: Entry 1. of the General Software Note does not release “software” specified in Category 5 — Part 2

(“Information Security”). 2. “In the public domain”; or 3. The minimum necessary “object code” for the installation, operation, maintenance (checking) or repair of

those items whose export has been authorised. Note: Entry 3 of the General Software Note does not release “software” controlled by Category 5 — Part 2

(“Information Security”).



Information Security Notes Note 1: The control status of “information security” equipment, “software”, systems, application specific

“electronic assemblies”, modules, integrated circuits, components or functions is determined in Category 5, Part 2 even if they are components or “electronic assemblies” of other equipment.

Note 2: Category 5 — Part 2 does not control products when accompanying their user for the user’s personal use. Note 3: Cryptography Note

5A002. and 5D002. do not apply to items as follows: a. Items meeting all of the following:

1. Generally available to the public by being sold, without restriction, from stock at retail selling points by means of any of the following:

a. Over‑the‑counter transactions; b. Mail order transactions; c. Electronic transactions; or d. Telephone call transactions;

2. The cryptographic functionality cannot easily be changed by the user; 3. Designed for installation by the user without further substantial support by the supplier; and 4. Not used 5. When necessary, details of the items are accessible and will be provided, upon request, to the appropriate authority in the exporter’s country in order to ascertain compliance with conditions described in paragraphs 1. to 3. above;

b. Hardware components or ‘executable software’, of existing items described in paragraph a. of this Note, that have been designed for these existing items, and meeting all of the following: 1. “Information security” is not the primary function or set of functions of the component or

‘executable software’; 2. The component or ‘executable software’ does not change any cryptographic functionality of

the existing items, or add new cryptographic functionality to the existing items; 3. The feature set of the component or ‘executable software’ is fixed and is not designed or

modified to customer specification; and 4. When necessary as determined by the appropriate authority in the exporter’s country, details

of the component or ‘executable software’, and details of relevant end‑items are accessible

and will be provided to the authority upon request, in order to ascertain compliance with conditions described above.

Technical Note: For the purpose of the Cryptography Note, ‘executable software’ means “software” in executable form, from an existing hardware component excluded from 5A002. by the Cryptography Note. Note: 'Executable software' does not include complete binary images of the "software" running on

an end‐item.



Note to the Cryptography Note: 1. To meet paragraph a. of Note 3, all of the following must apply:

a. The item is of potential interest to a wide range of individuals and businesses; and b. The price and information about the main functionality of the item are available before

purchase without the need to consult the vendor or supplier. 2. In determining eligibility of paragraph a. of Note 3, national authorities may take into account

relevant factors such as quantity, price, required technical skill, existing sales channels, typical customers, typical use or any exclusionary practices of the supplier.

Note 4: Category 5, Part 2 does not control items incorporating or using “cryptography” and meeting all of

the following: a. The primary function or set of functions is not any of the following:

1. “Information security”; 2. A computer, including operating systems, parts and components therefor; 3. Sending, receiving or storing information (except in support of entertainment, mass

commercial broadcasts, digital rights management or medical records management); or

4. Networking (includes operation, administration, management and provisioning); b. The cryptographic functionality is limited to supporting their primary function or set of

functions; and c. When necessary, details of the items are accessible and will be provided, on request, to the

appropriate authority in the exporter’s country in order to ascertain compliance with conditions described in paragraphs a. and b. above.



Annex 4: Case Studies We are developing software that will be using open source cryptographic sub‐routines. The DSGL controls apply to equipment and software that uses cryptography, except if there is an exemption. This also applies to software that in any way uses cryptographic sub‐routines and related libraries that are in the public domain (usually open source). In order to be excluded from the DSGL controls, the primary software (i.e. the final product that uses the cryptography) needs to be in the public domain, regardless of whether the cryptographic sub‐routines are open source or not. The most common scenario is when both components are in the public domain. If the developed software is listed in Part 2 (Dual‐use List) of the DSGL any release in the public domain (i.e. publications) would be exempt from the DTC Act and would not require a Defence Export Controls permit. I am developing software into which I plan to incorporate a new cryptographic algorithm which I have also developed. In the process of software development I need to collaborate with developers in the US and I will be exchanging parts of the software code with them. The development of the software is not controlled until you reach the point that you are including the algorithm in the software code. At that point, any controls which apply to the new algorithm will also apply to the software as a whole. A permit is required before details about the cryptographic algorithm can be supplied or exported, unless exemptions in the DSGL or exceptions in the DTC Act apply We are developing open source cryptographic software that is planned to be officially tested and certified. During the development phase, access to the software repositories will be limited to approved, collaborative users/developers, some of them overseas. This software development demonstrates a scenario where inherently open‐source cryptographic software is developed to comply with industry‐recognised assurances and certifications. There is clear intention to release the final product in the public domain after the formal certification process is finalised. During the certification process the access to the software is restricted and therefore, potentially outside the scope of the “in the public domain” exemption in the General Software Note. There are two main points to highlight. First, the majority of the technology required for development of this software is already in the public domain (publicly known encryption algorithms, certain integration routines and integration methods between different parts of the software). Software that implements this technology remains, however, under the DSGL control as this implementing software contains original, previously‐unpublished methods to implement and achieve certain level of cryptographic functionality, including those required for the software to pass the certification process. The second aspect of this scenario applies to the original intent to release this software into the public domain. This is practically identical to the standard academic publication scenario where potentially controlled technology is supplied during the pre‐publications activities. The pre‐publication exception will apply from when the technology is clearly intended to be released into the public domain. Once a decision has been made to release the software into the public domain, all the activities that are conducted to achieve publication are classed as pre‐publication activities and are exempt from the normal rules governing supply. These activities may include sending a copy of the software to a person overseas for verification / validation, or to a person conducting certain beta testing. Activities that are not in furtherance of the publication of the software (such as giving pre‐release versions to a select set of users for their own use, either with or without cost) are not considered to be pre‐publication and would therefore require a permit to supply.



Our company is starting a new software development project that will include cryptography. For this purpose we are setting up a cloud computing environment / data repository to facilitate collaboration between in‐house and overseas developers. A person does not need a permit to supply technology to him or herself. In the same way, a corporate entity is also a legal “person” and it does not need a permit to supply technology among employees from the same company. This rule applies whether the employees are sending the technology via email or the employees are accessing the technology from a cloud storage facility. However, if an Australian person enables access to the same cloud repository for a person overseas, who is not an employee of the company, (e.g. by supplying a password or keyword), then a permit would be required . The upload of data to the cloud, even if the data contains technology listed in the DSGL, is not regulated as at the time of upload, there is no intention to supply the technology to anyone overseas. The upload becomes a supply of the DSGL‐listed software or technology if at the time of upload a person overseas already has access to the cloud repository. Examples:

An Australian company grants their employees access to a cloud repository to facilitate work on a project while some employees are overseas. This is not considered as supply since all end users of the controlled technology are members of the same legal “person”.

An Australian company team leader uploads DSGL‐controlled technology to a cloud without giving anyone access to this technology, apart from himself or herself. This is not considered a supply as there is no intention to supply the technology to anyone overseas at the time the information is uploaded.

An Australian company invites engineers from their US sister company to work on a joint project and provides cloud access to them where the cloud contains controlled technology. This activity would require a permit as a person in Australia is providing access to controlled technology to another person located overseas.

What is the Defence Export Controls policy on supplying/exporting software covered by an open source licence? Sometimes this software has some restrictions on use, does this mean that exporting or supplying this software would require a Defence Export Controls permit? Any open source software or technology is automatically exempt from any DSGL control based on the definition of “in the public domain”, which is:

“Technology” or “software” which has been made available without restrictions upon its further dissemination (copyright restrictions do not remove “technology” or “software” from being “in the public domain”).

Copyright limitations on the released technology or software do not exclude it from being in the public domain as long as the access to it remains available to everyone, regardless if they have to pay for that access or not. This applies to open source licensing that could contain some limitations on use (personal use only), but in principle, will not have any limitation on further dissemination.



I am teaching a cryptography course through a Massive Open Online Course (MOOC). I understand the course material is not controlled but when one of my students asks me questions that aren’t in the course material isn’t that a controlled activity and I need a permit? As the course material is in the public domain, then the technology is exempt and a permit is not required to teach any of the material. If a student asks a further question that goes beyond the course material then in many cases a permit still won’t be required, as the level of detail is unlikely to be high. The circumstance where a permit may be required is when the student has developed the technology to a level that is beyond “basic scientific research” and it is being integrated into an information security system.

My research project involves looking at a certain aspect of cryptography. It is important for me to discuss this with my peers based at universities overseas. Do I need a permit to do this? If you are having a telephone conversation or similar, this may count as verbal supply and a permit would not be required; see Section 4.1 of this guide for more information. If your research involves a controlled technology, you will likely need a permit before you can transmit details relating to the cryptography aspect of your research in any other non‐verbal way. Note that if your research is considered to be “basic scientific research” then a permit is not required; see Section 5.2 of this guide for more information.

My company creates software containing cryptography that is either placed in the public domain or is made generally available to the public via retail sales. We wish to transfer source code for this software to our sister companies and external development partners outside Australia. If the software “object code” is either in the public domain or is generally available to the public via retail sales, it is exempt from export control – see sections 5.1 and 5.5. However, the source code is assessed separately to the object code. In most cases, it is likely that the source code is not in the public domain or generally available to the public, so it remains subject to export control.

I placed DSGL software and technology on a server and provided access to a person outside Australia prior to 2 April 2016 (the date that the Defence Trade Controls Act 2012 comes into force). The person outside Australia still has access to this information. Do I now need a permit? What if I want to update or revise the information on the server after 2 April 2016? From 2 April 2016 (the day that the supply offence in the Defence Trade Controls Act is scheduled to commence), each new upload of DSGL‐listed software or technology from Australia onto a server that is accessible to other persons outside of Australia will constitute a supply, and a permit will be necessary.

I am contracted to another company in Australia to engineer software and I know that the software I upload to the other company’s cloud servers is being accessed by other engineers who are located overseas. Do I need a permit to supply my controlled software to the engineers who are located overseas? No. You are supplying software, even if it is DSGL‐listed software, to another Australian company and therefore the DTC Act does not apply to you. The Australian company who has contracted you does require a permit as they have provided access to DSGL‐listed software to persons located outside of Australia.

An engineering design centre in Australia develops Microwave "Monolithic Integrated Circuits" (MMIC) power amplifiers that are controlled in 3A001 of the Part 2 (dual‐use) list. These MMIC integrated circuits are designed in Australia, sometimes in conjunction with the company’s other design centres in Western Europe and the US. Fabrication is undertaken in Taiwan and sold on world markets via the company’s distribution centre in Taiwan. What permits are required? In addition to the hardware, technology required for their design is also controlled (3E001). A permit would be required to export any circuits, or supply the design technology to the US, Western Europe and Taiwan. The hardware sold (and exported) from the distribution centre in Taiwan would not be subject to Australian export controls. Instead, Taiwanese export controls would apply.

australian export controls and ict-apr26...important: the listing of goods, software and...

Documents