Oct
2
The Mysterious Case of the Missing Medical Devices
Posted by Clif Burns at 9:19 pm on October 2, 2007
Category: BIS • Sanctions
Invitrogen and the Bureau of Industry and Security (“BIS”) recently signed a settlement agreement pursuant to which Invitrogen agreed to pay $30,000 for three shipments and one attempted shipment of human leukocyte antigen tissue typing trays to Syria without a license. The shipments and attempted shipments had been made, and voluntarily disclosed, by Dynal Biotech, which Invitrogen acquired in 2005. The charging documents allege that these shipments and alleged shipments violate General Order No. 2 of Part 736 of the Export Administration Regulations which forbids exports of all items “except food and medicine” to Syria.
HLA tissue typing trays are used, among other things, to determine whether tissue or organs are compatible for transplantation into a particular individual. Clearly this product isn’t food or medicine within the exemptions provided by General Order No. 2.
But the trays are arguably medical devices under the Trade Sanctions Reform Act of 2000 (“TSRA”) which prohibits unilateral sanctions affecting medical devices. TSRA defines “medical devices” by referencing the definition of “medical devices” under the Federal Food, Drug and Cosmetic Act. Section 201 of that Act defines a medical device to include:
an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is … (2) intended for use in the … the cure, mitigation, treatment, or prevention of disease, in man or other animals … .
This, of course, raises the question as to why General Order No. 2 exempts food and medicine but not medical devices. By failing to exempt medical devices it appears to run afoul of TSRA’s prohibition on unilateral sanctions on exports of medical devices. This is even more clear in this case because section 906(a)(2) notes that medical devices can be shipped to Syria notwithstanding any determination that Syria is a state sponsor of terrorism.
Of course, this was not the case to litigate the issue with BIS. Counsel for Invitrogen wisely decided that it would cost much more than the $30,000 agreed fine to litigate the matter. But BIS should know better.
Of course, perhaps there’s a reason I’ve missed for not including medical devices in the General Order No. 2 exemption. I haven’t had the time to fully research the matter, so if you can explain the mysterious case of the missing medical devices, please leave a comment enlightening everyone.
UPDATE: A reader points out that Section 5(a)(2)(A) of the Syria Accountability and Lebanese Sovereignty Restoration Act of 2003 permits the President to impose, as one of the sanctions on Syria, a prohibition on “the export of products of the United States (other than food and medicine) to Syria.” However, there is nothing in the legislation that suggests that Congress explicitly intended to overturn the language of TSRA which permits the unlicensed export of medical devices to Syria. There is no reference at all in the Syria Accountability Act to TSRA. In that context, then, “food and medicine” should be seen as referring to the “agricultural commodities,” “medicines,” and “medical devices” as defined in TSRA.
Of course, I am not recommending that this argument be used by anyone as a basis for not applying for a license for a medical device to be exported to Syria, since BIS will certainly seek to penalize such an export. Rather, I am suggesting that BIS should amend General Order No. 2 to make it consistent with TSRA.
Permalink
Copyright © 2007 Clif Burns. All Rights Reserved.
(No republication, syndication or use permitted without my consent.)
14 Comments:
Read TSRA Section 906(a)(2).
I did, EB, and I cited that provision in the post. That provision — 906(a)(2) — says that the provision of 906(a)(1) which says that countries that support state terrorism can only get medical devices on a one year license doesn’t apply to Syria or North Korea. So I’m not sure I understand your point.
I believe that section 221(a) and (b) of the Patriot Act amends section 906(a)(2) of TSRA to allow the President to penalize exports of medical devices. Though, I could be wrong (I often am).
Again, I’m not reading those provisions that way but in fact reading them in the opposite way. Section 221(b) of the Patriot Act adds the language “or to any other entity in Syria or North Korea” to 906(a)(2) making clear that shipments of medical devices to private entities, as well as the government, in Syria isn’t subject to the one year license requirement. And I don’t see anything that suggests that medical devices under these provisions are treated differently from food or medicine. Again, I haven’t had the time to do comprehensive research on this, so I’m still open to being corrected here.
I agree with you Clif. I’ve had to research the issue for a medical device company. But then, as I’ve mentioned before, BIS ducks and weaves around TSRA all the time. For example, despite its own regulations stating that the inclusion of encryption products in medical devices do not affect their classification as EAR99, BIS will not classify items with operating systems with strong encryption as EAR99 even when its open source software like Linux to which license exception TSU applies.
The House passed S.1612, raising the penalties under IEEPA to 250K for per se civil penalties, and $1 million and 20 years for willful violations. It applieas not just to violations occurring after passage, but also “enforcement actions” pending on the date of enactment. The bill was sponsored by Senator and presidential candidate Chris Dodd.
Mike,
Shame on you! TSU is unavailable for open source or publicly available software employing encryption unless that encryption is mass market software with symmetric key length 64-bits or less and is classified under ECCN 5D992.
If your aim is to export the encryption software under the TSU exception as operation technology or software, keep in mind TSU solely permits the export of the “minimum necessary” operation technology or software. It is a rare bird indeed which requires as a minimum to operate some form of encryption.
I find this to be one of the greatest myths promulgated by many professional members of the export community – that open source or publicly available software (freeware and/or shareware) is somehow exempted or excepted from treatment under the licensing provisions of the EAR.
I say myth because while it is true that freeware/shareware or open source software would be exempt as publicly available if I could prove it had no encryption capabilities (or if I could prove that the software had encryption capabilities, but that the encryption was encryption with symmetric key length which did not exceed 64-bits, TSU exception would very likely be available) in practice, I can rarely prove either to be the case and am stuck in the 5D002 quagmire. I also find that many folks who craft freeware/shareware or open source software could care less about US export control laws and am grateful to those who simply answer my inquiries in the first instance – even just to say they do not know.
It is not true that open source software is automatically available for TSU – especially considering that most software nowadays, even open source and freeware/shareware, employs some sort of encryption. I also think I’d be hard-pressed to prove that Linux was the minimum necessary software to operate any technology.
Here again, I note that I adopt a conservative (albeit definitively legal) approach to interpretation of the regulations.
Clif,
It appears to me that TSRA prohibits the President from imposing unilateral sanctions pertaining to medical devices.
Congress enacted the legislation (The Syria Accountability and Lebanese Sovereignty Act of 2003) forming the foundation of General Order No. 2 to Part 736 of the EAR.
It looks like a separation of powers issue.
Mr. Lancaster:
Just to make sure I did not wake up in an alternate universe, I re-read EAR 740.13(e) for the nth time: It contained none of the restrictions you suggest. There is no mention of a 64 bit restriction. I post the whole subsection below just to save you the trouble.
With respect, as my old friends at Boeing heard me say many times, especially when riding herd over agreements with SAIC, there is no substitute for actually reading the regulations.
Any myths belong to you.
**********************************************
(e) Encryption source code (and
corresponding object code)
(1) Scope and eligibility. This paragraph (e)
authorizes exports and reexports, without review,
of encryption source code controlled by ECCN
5D002 that, if not controlled by ECCN 5D002,
would be considered publicly available under
734.3(b)(3) of the EAR. Such source code is
eligible for License Exception TSU under this
paragraph (e) even if it is subject to an express
agreement for the payment of a licensing fee or
royalty for commercial production or sale of any
product developed using the source code. This
paragraph also authorizes the export and reexport
of the corresponding object code (i.e., that which
is compiled from source code that is authorized
for export and reexport under this paragraph) if
both the object code and the source code from
which it is compiled would be considered
publicly available under 734.3(b)(3) of the EAR,
if they were not controlled under ECCN 5D002.
(2) Restrictions. This paragraph (e) does not
authorize:
(i) Export or reexport of any encryption
software controlled under ECCN 5D002 that does
not meet the requirements of paragraph (e)(1),
even if the software incorporates or is specially
designed to use other encryption software that
meets the requirements of paragraph (e)(1) of this
section; or
(ii) Any knowing export or reexport to a
country listed in Country Group E:1 in
Supplement No. 1 to part 740 of the EAR.
(3) Notification requirement. You must notify
BIS and the ENC Encryption Request
Coordinator via e-mail of the Internet location
(e.g., URL or Internet address) of the source code
or provide each of them a copy of the source code
at or before the time you take action to make the
software publicly available as that term is
described in 734.3(b)(3) of the EAR. If you
elect to meet this requirement by providing copies
of the source code to BIS and the ENC
Encryption Request Coordinator, you must
provide additional copies to each of them each
time the cryptographic functionality of the
software is updated or modified. If you elect to
provide the Internet location of the source code,
you must notify BIS and the ENC Encryption
Request Coordinator each time the Internet
location is changed, but you are not required to
notify them of updates or modifications made to
the encryption software at the previously notified
location. In all instances, submit the notification
or copy to [email protected] and to
[email protected].
Note to paragraph (e). 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 under the “Know Your
Customer” guidance provided in Supplement No.
3 to part 732 of the EAR.
Mike,
I read paragraph (e) as the process which one follows to make encryption source code and corresponding object code publicly available.
If I am not the one making the software available, how do I know the person who put it out on the internet followed the process required in paragraph (e) to remove the 5D002 classification?
In particular dealing with foreign companies and independents, I can rarely get a confirmation that the software contains encryption – let alone convince them to send an email to BIS and the Encryption Czar each time the URL changes.
If I can not confirm with the one who posted teh software or code that BIS has been notified as required in 740.13(e)(3), TSU is unavailable. Having reached a dead end (because BIS requires that the one who releases the software or code at least endorse the request), the next logical step is to see if the software qualifies as mass market encryption software as described in 740.13(d).
The wording concerning mass market encryption software with symmetric key length 64-bits or less is found all the way on the other side of the EAR at 740.13(d).
Matthew:
With respect:
First, the key length limitation applies to that subparagraph only. The subparagraphs in this section are set forth in the disjunctive rather than the conjunctive, i.e., its “or”, not “and”. 740.13(d) does not limit 740.13(e).
Second, the Linux Gnu GPL copyright license requires posting of all derivatives. These, by definition, are not proprietary and they have to post in order to avoid infringing upon the Linux copyright. Perhaps SAIC doesn’t use any GPL software, a lot of firms don’t. That unfamiliarity may explain BIS’s irrational position on CCATS involving Linux and Linux variants such as Fedora.
The public avialability exception is not statutory: Its rooted in the First Amendment, with which all the lads and lassies at Commerce, Treasury and State seem to be unfamiliar. Apparently, they think that their status as Masters of the Universe, bestowed upon them by virtue of having a degree from a Beltway or Ivy League diploma mill, allows them to run roughshod over mere Constitutional rights of citizens.
Mike,
You are illuminating my earlier point. That is the great myth to which I earlier referred.
Since BIS requires notification in (e)(5), unless the folks who put it out there share with the rest of us that the notification requirement has been met (and note that some actually do post such notifications), TSU is unavailable for otherwise “publicly available” encryption software and source code unless BIS accepts notification from a party who did not post the software or source code – something I understand BIS is loathe to do.
Let’s say I post encryption source code to the internet. If I do not notify BIS of the posting, TSU is unavailable, right?
So, if someone else simply assumes that the code I posted is “publicly available”, he or she will make an unauthorized use of TSU.
My point is that if you make big assumptions upfront about what other folks have or have not done or have or have not intended, you could run into legal trouble.
For example, let’s say I consider the encryption source code proprietary, but accidentally post it to a site open to the public when attempting to post it to my company’s secure site. I, of course, never notify BIS of the posting, which is left open on the internet for two days – during which time you find it and forward it on to your overseas subsidiary for consideration under TSU. You have just violated the provisions of the TSU exception in paragraph (e).
I believe BIS only permits the one who posts to the internet to lodge the required notification with BIS. Furthermore, BIS always treats this information as confidential and proprietary to the requestor. In other words, BIS does not maintain a website saying, “The software and source code available at these links are available for the TSU exception – notification requirement satisfied,” so unless you notify BIS yourself, you have no way of knowing if TSU is available under paragraph (e) unless the one who posts openly shares the information with the community.
The same is true of all Commerce-controlled information posted to the internet. The only one who can claim with any real degree of certainty that the information was intentionally posted to the internet for public and open use is the one who posted it.
This is the great myth.
The lesson for all export controls professionals is that there is a real degree of risk in exporting or transferring to foreign nationals any information, software, or source or object code found on the internet. If you do not know that BIS requirements have been satisfied, there is risk in assuming that BIS requirements have been met.
So, assuming instead that the requirements for making the software publicly available have not been met (i.e. assuming that the poster did not notify BIS), paragraph (d) offers the best access to use of the TSU exception, but it is very limited.
Matthew:
With respect, with open source software operating systems, you don’t have to rely on the source to notify BIS and NSA, you simply do it yourself. The 7th Circuit Court of Appeals desribed the Gnu GPL license as follows:
“One prominent example of free, open-source software
is the Linux operating system, a derivative of the Unix
operating system written by AT&T in the 1960s and now
available without cost. (Unix® is a trademark of The Open Group, but the source code to many variants of AT&T’s work is freely available.) Linux is one of many modern derivatives of Unix—which is not itself under the GPL.**** Linux, initially the work of Linus Torvalds, is maintained by a large open-source community. International Business Machines offers Linux with many of its servers, or customers can install it themselves. IBM has contributed code to the Linux project and furnishes this derivative work
to anyone else with an interest. Red Hat, Inc., sells media (such as DVDs), manuals, and support for the installation and maintenance of Linux. The GPL covers only the software; people are free to charge for the physical media on which it comes and for assistance in making it work. Paper manuals, and the time of knowledgeable people who service and support an installation, thus are the most expensive part of using Linux.”
Some open source vendors who follow the business model described above, such as Red Hat, now follow Microsoft’s example and post the ECCN and License exception determinations on their web-site, including the CCAT number, so you can rely on that; but, even if they didn’t, any user can simply submit a notification or even a CCAT for the version they use themselves and thereby qualify for TSU.
Mike,
First, let me give rousing applause to all companies like Red Hat who post export compliance resources to the web. (See, http://www.redhat.com/licenses/export/).
The problems I’ve run into trying to send notifications or requests to BIS regarding other companies’ products and software are:
1) as a general rule, BIS requires the manufacturer to submit or endorse the request (especially regarding CCATs), and;
2) lack of insight into other companies’ products.
Starting with 2) above first, assuming the manufacturer or software writer is unresponsive, I will not typically know if the software my folks want to export even contains encryption. It may be impossible for me to even gather the requisite information to know whether or not TSU would be required prior to export. Acting conservatively, I could assume encryption exists and send notification to BIS, but then reposnsibility rests with me to maintain the list of URLs sent in, and update them as appropriate. Also, what if the software link is removed from the web altogether? Does TSU’s availability dissipate?
Regarding 1) above, this is 100% true for CCATs. I believe I may remember BIS saying that it is acceptable for a non-manufacturer/non-poster to send notice of software publicly available on the internet. Even so, the record-keeping requirements are ridiculously burdensome for the average practitioner – so much so that I would only ever turn to TSU as an exception of last resort. I have similar distaste for use of the ENC exception at 740.17. Also, the use of the TSU exception described at 740.13(e) is unavailable for countries in Country Group E:1, so I am scratching my head a bit at how 740.13(e) helps get web-based publicly available encryption software to Syria.
I agree that it appears that TSU would likley apply – given that the third party were cooperative in providing all the information you’d need concerning the third party software you were trying to export. My point is that in practice the third party is often not helpful, and not even responsive in the first instance. Surf the web a bit and you’ll come across strings from independent software developers and loose groups of code writers ridiculing export practitioners who have contacted the individual or group and requested export controls information. Also, if you take the most conservative approach and make all the conservative assumptions, use of the TSU exception saddles you with responsibility for yet another spreadsheet to track and update regarding URLs sent in to BIS for third party software and code.
Actions by companies like Red Hat – in posting ECCN and CCATs information to a readily available website – are one of the few things preventing some of us from drowning in export paperwork. Other companies maintain responsive and knowledgeable export controls staff, and they deserve to be applauded as well.
I simply fail to see the utility of the TSU exception. In my opinion, any benefits it may have are far outweighed by the paperwork created in using it. If it is truly freely available on the web, download it once you’ve crossed the border.
