rst2org
* Converted FAQ.rst to Org-Mode with Pandoc and subsequent paragraph fixes in Emacs.
This commit is contained in:
Ben McGinnes
parent
3c5f25fb8f
commit
b2f298e7d0
118
lang/gpygme/docs/FAQ.org
Normal file
118
lang/gpygme/docs/FAQ.org
Normal file
@ -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]].
|
||||
Loading…
Reference in New Issue
Block a user