From b2f298e7d03518a2cc93143c24b72e0847d89901 Mon Sep 17 00:00:00 2001 From: Ben McGinnes Date: Fri, 26 Jun 2015 19:49:10 +1000 Subject: [PATCH] rst2org * Converted FAQ.rst to Org-Mode with Pandoc and subsequent paragraph fixes in Emacs. --- lang/gpygme/docs/FAQ.org | 118 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 lang/gpygme/docs/FAQ.org 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]].