ITAR, EAR and Open Source Question
Adam Firestone
group for comment, opinion and wisdom:
Small American open source software company builds middleware that is
used in a large number of commercial and government applications.
Among their contracts is a subcontract with a defense contractor
designing software for the US military. In two or three years, they
expect to have direct contracts with the military for production
support for fielded systems that use the small software company's
middleware.
Small software company has a business opportunity with a mainland
Chinese company and plans to go hawk their products at a meeting in
China later this month.
What, if any, are the export limitations on small software company?
Does the company have to submit a commodity jurisdiction request to
State as a matter of course, and then, potentially, a commodity
classification request to Commerce as a matter of course?
Many thanks in advance for the group's accumulated wisdom!
Adam
John Scott III
if the software is offered up as a commercial product, doesn't include crypto and isn't on a munitions list - you *should be* in the clear, also since its fully(?) the public domain
not knowing the tech its hard to say... by CYA anyway
> --
> You received this message because you are subscribed to the "Military Open Source Software" Google Group.
> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
>
> www.mil-oss.org
-----------------------------------------------------------
John Scott
240.401.6574
< jms...@gmail.com >
http://powdermonkey.blogs.com
@johnmscott
Have you joined MIL-OSS?:
http://groups.google.com/group/mil-oss
http://mil-oss.org/
Ali-Reza Anghaie
- Everything is either EAR or ITAR controlled. Services included.
- If you're doing something specific for the DoD, or did it for them
~first~, you'd want to get a EAR or ITAR jurisdiction ruling.
- FOSS code, that's in the public from the start, is treated (99% of
the time) like open Academic material. And thus falls under some EAR
exception and no license would be needed.
So you should be OK in most cases would be my first guess.
For a longer discussion you can ping me out-of-list and we can setup
time (I won't charge, it's just generally a conversation better had
interactively).
-Ali
Adam Firestone
You have certainly set me on the right path.
Ali - I'd like to take you up on your offer. Will message offline.
Many thanks again,
Adam
Harley Garrett
I'm a newbie too to OSS-MIL and I'm no current expert but ITAR is not something to be taken lightly. I think procedures I used in a prior life are still current. If the SW is covered by the US Munitions List (ML) administered by the State Department's Director Defense Trade Controls (DDTC), you will need a DSP-73 for temporary export to market hawk the product outside the US. But for sales outside the US you'll need a DSP-5 for permanent export. The real question is "is the middleware considered an ML item?"
As John pointed out, even if it contains no crypto processes, the DDTC may decide it should be subject to Munitions List controls. To answer that you need to submit a "CJ request" to the State Dept (DDTC). CJ stands for "commodity jurisdiction" and the CJ request is the process by which they determine if it is or isn't 1) State vs Commerce Jurisdiction and 2) on or off the ML. The CJ request form is a DS-4076 and guidelines are at this site for electronic submission:
http://www.pmddtc.state.gov/commodity_jurisdiction/index.html
In my view if the small firm had no defense contracts nor intention of selling to the DoD, the export issue would fall under the Dept of Commerce (DOC) not the US State Dept. They would decide if it is something that can (or could be) "dual used" by both military and commercial purposes. If Commerce decided it was "dual use" they would control its export under their Commodity Control List (CCL) process. See:
http://www.pmddtc.state.gov/commodity_jurisdiction/index.html
Now that I've thoroughly confused you, and since the company is selling through a prime now to the military, it should fall under the US State Department's jurisdiction, not Commerce.
On that note, I'm attaching two pdfs on the DSP-73 process but would suggest you use the CJ Request venue first - see the DSP-5 guidelines at attachment 3 --particularly para 5 of the DSP-5 guidelines and the above pmddtc link.
While all this seems onerous, State does a much better job responding than it used to before e-commerce. It used to take weeks or even months to get a DSP-5 or 73 but they are doing a very good job these days responding to those seeking to export without violating any ITAR rules. They'll assign a case # to your CJ and you can check its status often and probably email or talk to a staffer directly if need be on any other details.
My view is that you will need a DSP-5 for off-shore sales. Also understand that even if the product is exportable to other countries, the State Dept keeps a list of "bad guys" where no such exports are permitted. Given our current relations with the Chinese, that should not be a problem -- but it could be in the future or if the middleware is considered sensitive due to what it does (function) in military systems. But from your email, I doubt that will be an issue.
Also, if it is used in the military now or in the future, my read of DoDI 8500.1 is that it must also meet IA (information assurance) standards - and if it contains crypto functions, the middleware (with the crypto process embedded) must be verified under the Common Criteria, NIAP, or NSA Crypto Module Validation Program (CMVP). I sort of doubt the middleware includes crypto but in the off chance it does, the above will apply.
Hope this helps.
Harley Garrett
Allan Hardy
>> Everything is either EAR or ITAR controlled. Services included.
I've had export people make that statement before, I am not sure it is true with regards to open source. The EAR even has a section (734.3b) that specifically states things that are NOT subject to EAR (to refute that EVERYthing is Subject stance)
Basically for OSS, with the exception of OSS with encryption software - OSS is not subject to the EAR.
OSS (Publicly available software) is only subject to the EAR when it is classified as ECCN 5D002 or 5D992 , software products that do not fit those two classifications are not applicable, not subject.
From the actual regulations
§ 734.3 (b) Items NOT subject to the EAR.
3) Publicly available technology and software, except software classified under ECCN 5D002 on the Commerce Control List, that:
(i) Are already published or will be published as described in §734.7 of this part;
(ii) Arise during, or result from, fundamental research, as described in §734.8 of this part;
(iii) Are educational, as described in §734.9 of this part;
(iv) Are included in certain patent applications, as described in §734.10 of this part.
Note to paragraphs (b)(2) and (b)(3) of this section: A printed book or other printed material setting forth encryption source code is not itself subject to the EAR (see §734.3(b)(2)). However, notwithstanding §734.3(b)(2), encryption source code in electronic form or media (e.g., computer diskette or CD ROM) remains subject to the EAR (see §734.3(b)(3)). Publicly available encryption object code software classified under ECCN 5D002 is not subject to the EAR when the corresponding source code meets the criteria specified in §740.13(e) of the EAR.
To go further into this, even if there is encryption and a ECCN5D002 classification, Open Source still gets a waiver under TSU exception in EAR 740.13(e) , which applies to software containing or designed for use with encryption software that is publicly available as open source.
This exception says that " Posting encryption source code and corresponding object code on the Internet (e.g., FTP or World Wide Web site) where it may be downloaded by anyone neither establishes "knowledge" of a prohibited export or reexport for purposes of this paragraph, nor triggers any "red flags" necessitating the affirmative duty to inquire[...] "
As a practical matter it’s hard for OSS to stay away from encryption, if it provides even basic name/password support.
Of course in the end I am speaking of US Export, other countries have different rules, it is each specific exporter's responsibility to understand and comply with all export regulations applicable within their jurisdiction (- disclaimer off)
Allan
Gunnar Hellekson
I am constantly in awe of the expertise we have on this list. Thanks everyone!
Is there a volunteer who can, sun-managers style, weave all these responses into a single document that we can post on the website or throw into a FAQ? That would be amazing.
g
Ali-Reza Anghaie
>
>
>>> Everything is either EAR or ITAR controlled. Services included.
>
>
>
> I've had export people make that statement before, I am not sure it is true
> with regards to open source. The EAR even has a section (734.3b) that
> specifically states things that are NOT subject to EAR (to refute that
> EVERYthing is Subject stance)
I totally agree that the language is fluxored but it's exactly the
statements made in DC over and over by the committees that revised the
rules (including the meetings that revised and loosed the encryption
rules).
They call the "exception" or non-coverage a built-in "license" for the
Export (EAR only, no such thing in ITAR). It makes no sense except to
those who say that but therein lies the rub. Because basically, like
many Federal Regulations, it only takes a new novel interpretation by
a Prosecutor or IG to make your life miserable. Which is part of the
reason I said I'd offer discussion offline on this.
In terms of encryption just use the existing FOSS libraries that
aren't encumbered in Patents (like the ECC libraries) and you'll be
OK. The revised rules accommodated exactly that. Homebrew it and you
might have to answer questions and be inconvenienced.
I think we all agree that, at this high level, there is nothing that
was stated by the OP that raises a red flag.
(BTW, Allan brings up the fun aspects of re-export and import of other
countries. That totally depends on specifics of what you're doing and
the politics around it.)
Fun times... Cheers, -Ali
Ali-Reza Anghaie
> On Wed, Jan 4, 2012 at 18:47, Allan Hardy <al...@hardy.com> wrote:
>>
>>
>>>> Everything is either EAR or ITAR controlled. Services included.
>>
>>
>>
>> I've had export people make that statement before, I am not sure it is true
>> with regards to open source. The EAR even has a section (734.3b) that
>> specifically states things that are NOT subject to EAR (to refute that
>> EVERYthing is Subject stance)
>
> I totally agree that the language is fluxored but it's exactly the
> statements made in DC over and over by the committees that revised the
> rules (including the meetings that revised and loosed the encryption
> rules).
>
> They call the "exception" or non-coverage a built-in "license" for the
> Export (EAR only, no such thing in ITAR). It makes no sense except to
> those who say that but therein lies the rub. Because basically, like
> many Federal Regulations, it only takes a new novel interpretation by
> a Prosecutor or IG to make your life miserable. Which is part of the
> reason I said I'd offer discussion offline on this.
As a side note this is a big issue in Academic environments too. The
specificity of the language versus the ambiguity of updates and
rulings causes a lot of headache. It makes no sense that FOSS or
public academic information (e.g. dissertations) would be covered
under EAR but there are huge segments of the enforcement side of
things that just decide something ~shouldn't~ be public. All that ties
into over-classification at the front-end, etc.
So when I say 'the short' of it, that's what I really meant. Because
this could turn into a lot of citations and rulings that show people
were hit (or saved) both ways. And then we could devolve into economic
nationalism vs free markets. Which, on another side note, we should
all agree to do in person over beers. ;-)
-Ali
