Re: [Paparazzi-devel] ITAR and export regulation(Was: question about paparazzi on sounding rocket)

[Jake Stewart]

> While it may be new to those in UAV's - this type of regulation is simply a 
> fact of live

In the interest of fleshing this out, I have to disagree with you.  It's a fact 
of life that governments like to huff and puff a bit and pretend that they're 
actually doing something to protect people.  But, as far as I can tell these 
export restrictions (on software) have never had any legal effect on anyone.

I couldn't find any cases where anyone has ever been prosecuted for exporting 
cryptography.  The closest case seems to be "Bernstein v. United States", where 
a college student pre-emptively challenged the export laws and had them 
declared unconstitutional.  So there has never been a threat to exporting any 
software you want, a college student seems to have had the restrictions struck 
down before anyone ever had to actually defend themselves against them.  
Essentially, since 1995, all open source software has been constitutionally 
protected free speech. 

The gov. seems to have been partially successful at using an unconstitutional 
law to scare some people into filing for permits and/or forcing them into using 
some slightly annoying tactics to circumvent their regulations, i.e. serving 
their code from servers in another country.

So we're certainly safe on the software side.  Coders have no fear, your work 
product is constitutionally protected free speech (at least in the US).

I think the hardware is probably pretty safe also.  It was mentioned that 
autopilots are specifically included in export restrictions and it's not a 
matter of what you call it.  I have to disagree with this also.  You could call 
anything with the processing power of a TI-85 graphing calculator an 
"autopilot" if you used the reasoning I'm currently seeing expressed.

To be clear, an "autopilot" would have to be something capable of automatically 
piloting an aircraft.  Unless you have a black box that you connect to an 
aircraft which can then be flown automatically by the box you don't have an 
autopilot.  So it is a matter of what you call things, the problem is that 
we're calling them something they're not and trying to jump through hoops that 
don't have to exist.

The boards are simply generic microcontroller hardware platforms.  They aren't 
autopilots until you add another handful of components and program them with 
autopilot software.  What it looks like people are doing is analogous to taking 
a light bulb on a switch and calling it a "covert optical enemy signaling 
device", then lamenting the government red tape involved.

I'd hazard that you're in more danger of being sued for making false claims 
about a product when some customer doesn't realize they need 3-4X more hardware 
(and about 3X the money) to make the board pilot anything, than having to deal 
with government regulators stepping in on the basis of some largely unenforced 
international agreement.

To be factual, the LISA board for example, is not an autopilot.  In fact, it 
can't do anything at all.  It's not even functional as a barometer since you 
need additional components to get a barometric reading from it.  If you add 
some sort of serial link and software to readout the barometric sensor, it 
could then be called a barometer.  If you go further and add an IMU and some 
code to it you could then call it a flight stabilizer, but it still wouldn't be 
an autopilot.  Only by additionally adding a GPS to it AND programming it with 
autopilot software it could finally be called an autopilot.

So it's not like we would be trying to skirt some law by downplaying it's 
capabilities, pretending a bogus use, or suggesting alternate uses (I only 
suggested that because it would help non-technical minds understand the nature 
of the device), but rather because the hardware simply and truthfully is not an 
autopilot.  A commercial black box autopilot system is an "autopilot", a STM32 
processor with a handful of connectors wired to it is not an autopilot.  No 
matter what buttons you push on the device it's not going to pilot your plane 
without a lot more hardware. The board is, at best, 1/4 of a minimal autopilot. 
 It's not like you're removing one resistor and trying to call a missile 
guidance system "miscellaneous electronics", you're trying to do the opposite 
and call a generic microcontroller and some connectors something it's not.

That's not to say that you couldn't market a pointed stick as a "short range 
ballistic projectile weapon" and get yourself into some trouble, but why go 
there in the first place?


-Jake

 
> 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