Folks,
While it may be new to those in UAV's - this type of regulation is simply a
fact of live (just like countries have regulations as to where you can fly with
UAVs, what hight you can fire a rocket at; and when to get a NOTAM issued).
In fact - you may be surprised to learn that even mundane products like Ant,
SpamAssasin, Tomcat or mod_perl are regulated.
It is something which commonly affects software and firmware for things such as
crypto, navigation and what not. The organisations behind a lot of open source
and free (software) products routinely file paperwork upon certain classes of
releases to deal with it.
Even a tiny bit of crypto in your firmware can already trigger such. And UAV's
are obviously quite a bit more complex regulatory.
It may be helpful to know that Open source entities, like the Apache Software
Foundation, have been helping their constituencies to deal with this; and in
the end of the day - it generally is not that onerous. In fact - using open
source and an entity or collective behind it can make everyones live easier;
especially that of (small) companies.
A couple of thoughts and pointers based on that experience:
- ITAR and a lot of related international export regulation is
international. While the actual legal instrument may be domestic; they tend to
be virtually identically across the globe.
So do not assume this is a strange US or Australian thing. A variation
typically applies to you.
- In general (i.e. the western world and ignoring anything used for
certain classes of aerial photography) we're talking regulated technology (e.g.
dual use) as opposed to prohibited technology. Which simplifies things greatly.
- When crossing borders; the software and 'not for profit' side can
typically ignore the 'import' side.
Because import generally deals with tariffs and things which are a
percentage of some payment/value. With open source - that tends to be zero. And
usually - when you get this wrong (i.e. as a small company who sells products
international); some paperwork, grumbling, paying up and accepting a bit of a
delay will resolve it.
The open source community are more affected by 'export' regulation.
Because those apply 1) regardless of commercial value and 2) when you
get this wrong things get painful on a *personal* level; as we're now in the
criminal department of prisons and lawsuits. And the corporate veil gets lifted
way easier; so this affects you as a private individual directly. Unlike in the
import case - one cannot hide behind a company, university or group. You are
(literally) in the dock.
- The good news is that 1) there is usually just one country involved;
the exporting one, 2) by now open source (reference) implementations are well
understood (and have commanded exceptions in the regulation) and 3) and in most
cases you only need to be concerned with something akin to a product or a final
release (and not every commit or patch). (Caveat: if you are a commercial
company - then this does not apply - and you'll need to do your own thing the
countries you operate in).
So a couple of practical things:
- If this community has a clear release process; or if one generally
bases its work on a release - you can argue that this is the point at which you
need to go through your compliance exercise. This usually requires a bit of
process (like getting consent around a release, having some release management
and some documented consent on 'approving' version X and its release notes as
'the' group release collectively.
- To keep it simple - you want to pick a single country where you as a
group are arguably located.
When selecting this country you may want to specifically look at what
exemptions or conditions that country imposes on how 'diligent' you need to be
around allowing your (free) download. Do you have to have just a few 'I am not
in one of the dirty-dozen/nine naughty countries' checkbox, do I need to filter
on IP, or do I need to do more ? Or is there something like the TSU exception
in EAR 740.13(e) - which lets one deal with downloading of open source
encryption software in certain cases without such ado.
- As it is open source (i.e. the algorithms are available for inspection) a
lot of this will typically boil down to a boiler plate& timely notification to
the right entity. You need to have some decent tracking of this (e.g. with the
version control system and release tagging). In most countries it is just that - a
notification. No approval needed. You can pretty much automate it.
- In order to help everyone; including companies who will have to do
their own filing once they start selling their products outside their home
country - you want to probably make this process very open and public. So that
a lot of people can just copy and paste.
- Secondly - as part of the process you'll have to settle on the 'right'
Export Control Classification Number (ECCN). Doing this collectively makes
things a lot easier for all involved; especially for small SMEs who have no
desire to become regulation experts.
A very elaborate example is http://www.apache.org/licenses/exports/
- When sorting through the issue - I would urge you to shop around for
opinions. Then diff, merge, and repeat.
At Apache I've found this issue to be far beyond the grasp of most of
the legal first-line assistance (including the advisors of the larger
(open-source) software entities). Advise was initially conflicting at best. And
resolving it generally requiring a mix of highly specialist people and the
chops of large international organisations and/or universities familiar with
international work on nuclear material and normal weapons work. Also - in most
countries it pays of to have an early and very open chat with the local
officials. Their job is ultimately to help (i.e. to further export of the home
country), they have rare expertise, I found them generally enjoying these
challenges and very willing to understand a not-for-profit its challenges. And
as you are at the boundaries of the regulation - interpretation (_their_
interpretation!) matters. And turning the tables; by asking 'them' what you
need to do can help a lot.
I realise that this may be the trigger to formalise things a little. If so -
have a look at the incubation process of the ASF (even, o especially if you
decided to run it yourself in, say, a continental european foundation); it can
greatly help you get to a clean legal situation from whereon you are able to
both deal with these issues -and- make it easier for your SMEs and research
groups to derive clear IPR and reduce legal risk. Happy to help if needed.
Furthermore - I noticed some concern on the list and desires to work under the
radar. Based on personal experience I'd not expect prodding the various export
regulators to cause awareness. The various agencies, spooks and what other
professional paranoid are generally well ahead of the game and perfectly able
to trends and dual use way earlier. And have generally no qualms about visiting
you at your house or work; or having a chat or a good look at a laptop when you
cross borders (even decades way before the no-fly lists). And are prone to have
done that sort of thing quite informal and under 'your radar' years ago. So I'd
really urge you to ignore that angle - and tackle this head on.
In the end we all win.
Thanks,
Dw (Who apologises for using the ASF above in a few examples - it just happens
to be the organisation I am most familiar with; and happened, as a board
member, to have had a first-row seat when they had to struggle through these
issues. You will find very similar approaches in Mozilla and many other well
ran open source projects).
PS: If you think this is a silly state of affairs (as knowledge ought to be
free - and these paper dragons are not going to stop a single spy) - then
consider talking directly to your national politicians. While the international
treaties are not very negotiable for western countries. your country has a
surprising amount of leeway in how they implement it locally. Blanket approvals
or exceptions are perfectly possible. Especially if you can argue that it
benefits domestic industry.
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel