A guide to understanding export control laws regarding the physical export, intangible supply, publication or brokering of information and communication goods, software or technology
This Guide has been developed to assist ICT industry, software developers, academics and researchers to improve their understanding of how Australia's export control laws apply to the export, supply, publication or brokering of proliferation-sensitive information and communication software and technology.
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 items ', 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.
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 generally 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.
Annex 4 contains case studies of scenarios illustrating the circumstances where a permit may, or may not, apply.
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. 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 assess that a permit is required, you should submit an "Application to Export or Supply Controlled Goods and Technology". We will assess the application and either issue you with a permit, or advise you why a permit is not required.
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 so 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:
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.
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 have military uses. One of the key objectives of export controls is to prevent such proliferation-sensitive technology from ending up in the wrong hands.
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 have potential military end-use, and publishes a list of controlled goods, software and technologies.
Australia's control list, the Defence and Strategic Goods List (DSGL), is drawn directly from the control lists agreed to 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.
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; i.e. the supply of information that is 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.
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.
Further guidance on each of these activities is available on our website, www.defence.gov.au/deco.
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, verbal discussions and publication of Part 2 DSGL-listed software and technology do not require a permit.
You do not require a permit when verbally supplying DSGL-listed software and technology; for example:
The verbal supply exception is not available if you are verbally supplying a person access to the technology (e.g. providing a passcode) or the verbally-supplied technology will be used in a WMD program or for a military end-use.
IMPORTANT: In certain circumstances, a recording of a verbal supply may require a permit for that recording to be made available to a person outside of Australia. For example, if a lecture containing DSGL-listed software or technology has been recorded and is later emailed or is made available for viewing/download to a defined audience or group of people, such as an international research group or students located overseas, this would require a permit. A permit would also be required if that lecture was loaded onto a laptop and taken overseas.
The person who is making the recording available to others is the person who is supplying the DSGL-listed software or technology, and is therefore required to obtain a permit. This may not be the same person who gave the lecture.
There is no requirement for a permit to publish software and technology that is listed 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.
The exemption from a permit requirement for publishing software or technology that is listed in Part 2 of the DSGL extends to 'pre-publication' supply activities as well. As a general concept, the pre-publication exception would be available from the time the software or technology is 'ready to be made public'.
Example: 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.
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:
A permit is not required for information that is in the public domain. Information in the public domain can be:
"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 definitions are as follows:
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.
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.
A permit is not required for:
Restrictions could be achieved through:
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:
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.
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.
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.
The following are circumstances where the sender and recipient are not the same person:
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.
A "person" located in Australia makes a supply when doing one of the following things:
The DSGL contains a number of specific controls related to ICT goods and technology. These include:
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.
The following are links to relevant control items:
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.
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:
"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:
The following are links to relevant control items:
This control covers telecommunications systems, equipment, and components that are, or contain:
There are also controls on:
The following are links to relevant control items:
This control applies to systems, equipment, application-specific electronic assemblies, modules and integrated circuits that are:
A permit will be required to supply or export:
The following are exempt from the controls:
A permit is not required to supply or export:
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 (-45?C) or above 358 K (85?C). 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 85?C and below -45?C], 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.
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:
Similar obligations to keep records of exported goods apply to permits issued under the Customs Act. 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 a 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.
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
Phone: 1800 66 10 66
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.
|Research and Development||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|
|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|
|Testing and Demonstration||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.||Yes|
(if no exemptions apply)
|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.||Yes |
(if no exemptions apply)
|Production and Deployment||TRL8 - Technology is proven to work - Actual technology completed and qualified through test and demonstration.||Yes |
(if no exemptions apply)
|TRL9 - Actual application of technology is in its final form - Technology proven through successful operations.||Yes |
(if no exemptions apply)
"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.
"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:
Note 1: "Intrusion software" does not include any of the following:
Note 2: Network capable devices include mobile devices and smart meters.
Note: "OAM" does not include any of the following tasks or their associated key management functions:
"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.
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.
"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.
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.
(This note applies to all technology controls in Categories 1 to 9.)
(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:
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.
5A002. and 5D002. do not apply to items as follows:
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:
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.
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.
A PDF of the Australian Export Controls and ICT Guide is available.