aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--lang/gpygme/docs/FAQ.org118
1 files changed, 118 insertions, 0 deletions
diff --git a/lang/gpygme/docs/FAQ.org b/lang/gpygme/docs/FAQ.org
new file mode 100644
index 00000000..37cfb748
--- /dev/null
+++ b/lang/gpygme/docs/FAQ.org
@@ -0,0 +1,118 @@
+* Frequently Asked‡ Questions
+
+‡ At this stage these are more like Frequently Anticipated Questions.
+
+** Using the Project
+
+*1. Why implement an interactive codebase?*
+
+For good or ill, modern application development has turned to many web
+based technologies. As a result there are many more developers who no
+longer use or know languages like C. Consequently complete APIs like
+GPGME are not available to them when they may very well need it or
+benefit greatly from it. Rather than continuing existing systems which
+utilise wrappers calling command line programs (e.g. [[https://bitbucket.org/vinay.sajip/python-gnupg][python-gnupg]]), it
+is best to provide access to GPGME in a manner which can be safely
+used by newer developers.
+
+*2. Won't that create bottlenecks or performance issues?*
+
+It might, but chances are these will be negligible for most
+implementations. Projects which truly needs greater optimisation should
+consider utilising the GPGME C code directly.
+
+*3. I want (or need) to use a proprietary licence with my project, can I
+use this?*
+
+Yes, when interacting with GPyGME as a stand alone API it is much the
+same as using any external API. That is, your code is simply
+communicating with another system and not integrating that system into
+your own code. Only when implementing your project in Python and
+importing the API as a module or library would your code then become
+subject to the LGPL 2.1+ (which might be fine anyway, consult with a
+lawyer for issues pertaining to your specific situation).
+
+** Australian Developers and ITAR
+
+*1. The current author/maintainer is in Australia, won't that cause
+problems with ITAR and the Wassenaar Arrangement?*
+
+I'm not developing a cryptosystem or any encryption algorithms, I'm
+developing an API. So I should not be affected one way or the other by
+the provisions of the [[http://www.austlii.edu.au/au/legis/cth/num_act/dtca2012207/][Defence Trade Control Act 2012]] (DTCA),
+particularly with the 2015 amendments which have been passed by the
+Australian Parliament.
+
+*2. What if you're wrong about that?*
+
+That seems somewhat unlikely. The DSGL explicitly cites cryptography
+and encryption software as being in Part 2 of the [[http://www.austlii.edu.au/au/legis/cth/num_act/dtca2012207/s4.html#defense_trade_cooperation_munitions_list][Defence Trade
+Cooperation Munitions List]], but neither GPGME nor GPyGME are
+encryption software directly. Even GPGME simply provides a means of
+accessing what it refers to as encryption engines; currently the
+engines it supports are GnuPG and GpgSM. As long as I do not develop
+any of these encryption engines my work is not affected by the
+provisions of Australia's export controls, no matter how backward or
+useless I might consider those controls to be.
+
+*3. In April 2016 the enforcement provisions of the DTCA come into
+force, could that change anything here?*
+
+If the Minister of Defence makes a specific announcement in Parliament
+naming me and this work as falling under the purview of the DTCA, then
+yes; otherwise no.
+
+The only other way it could happen is if the Defence definition of
+"public domain" changes or if exemptions based on something being in the
+public domain are removed.
+
+*4. What assurances can you give that this will remain the case and
+everything will be fine?*
+
+The Department of Defence's [[http://www.defence.gov.au/DECO/Default.asp][Defence Export Control Office]] (DECO)
+provides numerous resources to address concerns relating to this type
+of development. Included in this is the [[https://dsgl.defence.gov.au/pages/home.aspx][Defence and Strategic Goods
+List]] (DSGL) and its accompanying [[https://dsgl.defence.gov.au/pages/questionnaire.aspx][Activity Questionnaire]] and [[https://dsgl.defence.gov.au/pages/search.aspx][Online
+DSGL Search Tool]].
+
+I completed the questionaire using the following conservative
+assumptions: that this work is either or both of supply and publishing
+of software and technology; and that the entire project really is in
+the category of Part 2 of the DSGL as a dual-use technology. Even
+though I am still pretty sure that only GPG itself and GpgSM would be
+placed in that category. Maybe libassuan, dirmngr and pinentry would
+too. Still, assuming that it all did, including GPGME and GPyGME, the
+results are clear that both supply and publication are fine. The
+[[http://dfat.gov.au/international-relations/security/sanctions/sanctions-regimes/Pages/sanctions-regimes.aspx][definitions of supply and publishing]], however, indicate that this work
+would likely only ever be considered publishing.
+
+The reason for this is that all the existing software on which this work
+is built is what Defence classifies as being in the public domain. In
+this context that is not the same as the term is used for copyright and
+licensing, it means that the software and information is already freely
+available to anyone. Thus it would be the same for all or almost all
+free (libre) and open source software.
+
+Only Australian cryptographers developing entirely new encryption
+algortithms are likely to be directly impacted by the provisions of the
+DCTA. I am very much /not/ in that category. Furthermore, any algorithm
+added to the specifications for GPG would need to pass through an
+international selection process anyway, by which stage it would be
+exempt from these types of restrictions because it would already be in
+the public domain as far as Australia's Department of Defence is
+concerned.
+
+The results of my completed questionnaire are available [[Australian_DCTA_export_DECO_Questionnaire_Results.pdf][here]] (PDF) and
+a GPG signature of the file is [[Australian_DCTA_export_DECO_Questionnaire_Results.pdf.sig][here]]. The file is signed with my key
+(ID 0x321E4E2373590E5D).
+
+With regards to current sanctions by Australia against any entity as
+referenced in that document and available [[http://dfat.gov.au/international-relations/security/sanctions/pages/sanctions.aspx][here]], my method of
+publication consists of uploading information to the GPG git server in
+Germany. Germany is not currently a sanctioned country by Australia,
+nor are any of the involved companies sanctioned separately. In fact,
+the only reference to Germany on Australia's list of sanctioned
+entities pertains to a number of individuals, mostly members of
+Al-Qaeda, currently serving time in German prisons or having been
+deported from Germany. Additional details on those sanctions can be
+found [[http://dfat.gov.au/international-relations/security/sanctions/Pages/consolidated-list.aspx][here]] and [[http://dfat.gov.au/international-relations/security/sanctions/sanctions-regimes/Pages/sanctions-regimes.aspx][here]].