Supply - when controlled technology, or access to that technology, is provided to users located outside of Australia.
Publication - when controlled technology is placed it in the public domain.
Pre-publication - activities, such as supplying a draft publication to a publisher or a peer reviewer, that support the pubication process.
Export - sending goods and/or technology from Australia to a place outside of Australia.
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; seeSection 4.1 of our ICT 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 the ICT 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.