gpgme/lang/gpygme/docs/FAQ.org

* 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]].