diff options
Diffstat (limited to 'polish/legal/cryptoinmain.wml')
| -rw-r--r-- | polish/legal/cryptoinmain.wml | 759 |
1 files changed, 759 insertions, 0 deletions
diff --git a/polish/legal/cryptoinmain.wml b/polish/legal/cryptoinmain.wml new file mode 100644 index 00000000000..c4b130e71cc --- /dev/null +++ b/polish/legal/cryptoinmain.wml @@ -0,0 +1,759 @@ +#use wml::debian::template title="Exploring Cryptographic Software in Debian's Main Archive" BARETITLE=true +#use wml::debian::translation-check translation="1.3" + +# Nota bene! This is basically draft text from the lawyers, and it must +# _not_ be modified for spelling errors and such. Formatting changes are +# fine (I think). -- Joy + +<table border=0 width="100%" summary="mail headers"> +<tr><td width="10%">To:</td> + <td><a href="http://www.spi-inc.org/">Software in the Public Interest</a>, <a href="http://www.debian.org/">Debian Project</a></td></tr> +<tr><td width="10%">From:</td> + <td>Roszel C. Thomsen II, Partner, <a href="http://www.t-b.com/">Thomsen & Burke LLP</a></td></tr> +<tr><td width="10%">Date:</td> + <td>July 31, 2001</td></tr> +<tr><td width="10%">Re:</td> + <td>Exploring Cryptographic Software in Debian's Main Archive</td></tr> +</table> + +<p>Thank you for this opportunity to comment on Sam Hartman's white paper +entitled “Exploring Cryptographic Software in Debian's Main Archive”.</p> + +<p>We are providing this information as a general guideline to you. BXA +requires that each entity exporting products be familiar with and comply +with their affirmative obligations set forth in the Export Administration +Regulations. Please note that the regulations are subject to change. We +recommend that you obtain your own legal advice when attempting to +export. In addition some countries may restrict certain levels of +encryption imported into their country. We recommend consulting legal +counsel in the appropriate country or the applicable governmental +agencies in the particular country.</p> + +<p>By way of background, the export of cryptographic software from the +United States is governed under the United States Export Administration +Regulations (“EAR”, 15 CFR Part 730 et seq.) administered by the +Commerce Department's Bureau of Export Administration (“BXA”). BXA +revised the provisions of the EAR governing cryptographic software most +recently on October 19, 2000. I refer to these as the “new US +Regulations” in order to distinguish them from prior regulations that +were more restrictive.</p> + +<p>When the Clinton Administration came to Washington, encryption items +were controlled for export from the United States as “munitions” under +the Arms Export Control Act and the International Traffic in Arms +Regulations. Most applications for licenses to export strong encryption +items were denied. Industry and public interest groups lobbied for +liberalization, and the Clinton Administration reformed the outdated +U.S. export controls on encryption items in a series of graduated steps, +culminating the new US Regulations. The new Bush Administration is +considering further liberalizations that may be published later this +year.</p> + +<p>Despite these liberalizations, the U.S. export controls on commercial +encryption items remain complex and onerous. American companies must +submit encryption items for technical reviews by the intelligence +authorities prior to export. Exports to some agencies of foreign +governments require licenses, as do exports to telecommunications and +Internet service providers wishing to provide services to some +government agencies. Finally, post-export reporting requirements apply +to many exports from the United States. Thus, U.S. encryption export +controls continue to impose a significant regulatory burden on American +companies, retarding the worldwide deployment of strong cryptography in +commercial software programs.</p> + +<p>Not all software programs with encryption are commercial products, +however. For purposes of the EAR, cryptographic source code controls +fall into three categories: (a) open source, (b) community source, and +(c) proprietary source. The rules governing exports of each type of +source code are different, and they have been amended in important +respects in the new US Regulations.</p> + +<p>Open source refers to software that is available to the public without +restriction free of charge, under a GNU-style license agreement. Debian +would appear to fall into this category. The old regulations allowed +the export of open source to any end-user without a technical review, +provided that the person making the open source available filed a +contemporaneous notification with BXA and the National Security Agency +(“NSA”). However, the old regulations were silent with respect to +restrictions (if any) on the export of compiled executable software +derived from open source.</p> + +<p>Under the new US Regulations, not only the open source, but also the +compiled executable software derived from open source, is eligible for +export under the same conditions as the open source itself, provided +that the compiled executable is available without restriction and free +of charge. Unfortunately, if you include the compiled executable +software into a product that you distribute for a fee, then the +resulting product is subject to all of the rules that apply to +commercial software programs. For example, they must be submitted to +BXA and NSA for a one-time technical review, described above.</p> + +<p>Community source refers to software that is available to the public free +of charge for non-commercial use but that contains further restrictions +on commercial use. Community source may be exported under essentially +the same conditions as open source, but community source remains subject +to more detailed reporting requirements.</p> + +<p>Proprietary source refers to all source code that is neither “open” +nor “community” source. Exporters may provide proprietary source code +to any end-user in the EU and its partners, and to any non-government +end-user in other countries, promptly upon filing of a technical review +with BXA and NSA. The same reporting requirements applicable to +community source also apply to proprietary source.</p> + +<p>Please keep in mind that persons in the US who may post to sites outside +the US are governed by US law, even if they do so in their individual +capacity. Therefore, you may want to warn persons in the US that their +posting to the current crypto server outside the US are still subject to +US regulations.</p> + +<p>Finally, you should be aware that a core set of US export controls apply +to all exports of open source cryptographic software from the United +States. In essence, these controls prohibit the export of open source +cryptographic software under License Exception TSU to (1) prohibited +parties (listed at <a href="http://www.bxa.doc.gov/DPL/Default.shtm">http://www.bxa.doc.gov/DPL/Default.shtm</a>, +(2) prohibited countries (currently Cuba, Iran, Iraq, Libya, North +Korea, Sudan, Syria and Taliban Occupied Afghanistan) and (3) design, +development, stockpiling, production or use of nuclear, chemical or +biological weapons or missiles.</p> + +<p>With this background, your specific questions with respect to Debian are +address in the order that they appear in Sam Hartman's white paper, +below in italics. + +<hr> + +<h2><i>Exploring Cryptographic Software in Debian's Main Archive</i></h2> + +<p><i>Sam Hartman</i></p> + +<p><i>Debian Project</i> + +<hrline> + +<p style="margin-left: 2em"> + <i>Debian is a free operating system. Currently for US export reasons, Debian + splits cryptographic software off into a separate archive located outside + the US. This document summarizes the questions we would need to answer from + a legal standpoint in order to merge these two archives.</i> +</p> + +<hrline> + +<h3><i>About Debian</i></h3> + +<p><i>Debian is a group of individuals working to produce a free operating system. +These individuals are responsible for decisions they make while working on +Debian; there is no legal Debian organization that developers work for or that +decisions are made on behalf of. There is a registered non-profit, Software in +the Public Interest (SPI), that holds money and resources for Debian. So +decisions developers make may impact resources owned by SPI and thus impact +SPI. Other Debian resources are owned by various sponsors. Debian generally +depends on sponsors for network connectivity. There are also third-party groups +that copy the Debian software onto mirrors so that people around the world can +download and use it. Others make and sell CDs of Debian. All these groups might +be accountable to a greater or lesser extent for the decisions Debian makes. We +want to conduct ourselves in a manner that minimizes the liability for all +parties and, within that constraint, maximizes the value of our efforts.</i></p> + +<p><i>As with all operating system vendors, Debian needs to include cryptographic +software. This software provides security, allows users to engage in Internet +commerce, and accomplishes other tasks requiring cryptography. Today, this +software is stored on a server outside the United States, known as the "non-US +server". Currently Debian takes no measures to assist US developers in +following export control regulations if they upload software to the non-US +archive or to prevent them from uploading software. We would like to move +cryptographic software from the non-US server onto our main server in the US.</i></p> + +<p><i>With the increasing networked nature of the work, and the fact that more and +more critical functions are being placed on computing platforms, and the +unfortunate growth of mischief and deliberate malice, security is going to be +increasingly important. Cryptography is an important corner stone of a number +of security processes. Any OS that does not make an effort to seamlessly +increasingly important. Cryptography is an important corner stone of a number +of security processes. Any OS that does not make an effort to seamlessly +integrate cryptography is unlikely to be competitive.</i></p> + +<p><i>Putting all software on a single source, and the corresponding ability to +create a single set of CD's that have integrated cryptographic support makes it +easier for the users, makes it easier for CD vendors, simplifies the task of +developers uploading software to these sites, and simplifies the task of +replicating the software repositories on the internet.</i></p> + +<p><i>The rest of this document will focus on the main server within the US and on +its mirrors and copies around the world. It's important to realize that there +is currently a parallel structure set up to deal with the non-US server.</i></p> + +<p><i>Every few months Debian developers release a new official version of Debian. +This software is made available on the main (and for cryptographic software, +the non-US) server to a group of primary mirrors around the world. These +mirrors copy the software off the main server and make it available to users +and secondary mirrors. The users can use HTTP, FTP, or a variety of other +methods to retrieve the software. CD images are made available to users and +resellers. These images can be burned onto physical CDs by individuals or by +those wanting to sell/give away Debian.</i></p> + +<p><i>In addition, there are two constantly evolving releases of Debian: the testing +and unstable releases. These releases are updated on a daily basis by +developers around the world. Like the official releases, these releases are +made available on the main and non-US servers to primary mirrors. The primary +mirrors make software available via HTTP, FTP and other methods both to end +users and to secondary mirrors. CD images are sometimes made from these +releases. The important difference between these evolving releases and the +official release is that they are constantly changing.</i></p> + +<p><i>Often, developers upload binaries and source code at the same time. However, we +support many different types of computers each of which requires different +binaries for the same source code. Most developers make binaries only for one +of the computer architectures we support when they upload a changed program. +Automated processes go and use the source code they have uploaded to make +binaries for the other architectures. As such, some binaries for a particular +source code program will likely be uploaded at a later time than that source +code.</i></p> + +<p><i>Some Debian developers also use Debian resources to work on as-yet-unreleased +software. The primary resource that is useful for this task is the Debian CVS +server. Source code to projects on this server is almost always available to +the public, but may change many times in a day. The CVS server is in the US. +server. Source code to projects on this server is almost always available to +the public, but may change many times in a day. The CVS server is in the US.</i></p> + +<p><i>However most Debian software is not developed directly by Debian developers. +Instead, the software is released to the public by some third party. Some +software is made available to the public on sites within the US, while other +original authors release their software on sites outside the US. Debian +developers are responsible for integrating the software into Debian. As part of +this job, many Debian developers end up working closely with the original +software author, often contributing code back to the original release.</i></p> + +<p><i>The software in Debian complies with the Debian Free Software Guidelines; the +DFSG. We believe this software has publicly available source code in the sense +of section 740.13(e) of the EAR. The guidelines require that the source code be +redistributable. The DFSG indirectly requires that one be able to distribute a +product based on the source code without paying a fee. We distribute all the +source code in Debian as part of our releases. Other software is distributed in +our non-free archive, but our focus in this document is on the DFSG-free +software. We would be interested in knowing to what extent we could move +non-DFSG-free software for which we can distribute source code into the US, but +we want to make sure advice in this area does not get confused with advice on +how to handle DFSG-free software.</i></p> + +<p><i>Debian developers live around the world and are citizens of many countries. +Obviously some are US citizens, but many others are not. Some may be citizens +of the seven forbidden countries in EAR section 740.13(e).</i></p> + +<p><i>As mentioned, we have mirrors all around the world. We do not have any official +mirrors (mirrors with which the project is connected) in any of the seven +countries listed in EAR section 740.13(e), although since our software is +publicly available, it might be copied into these countries. Most mirrors +within the US currently only mirror the main server (the one without +cryptography), although some mirror both the main and non-US portions of the +archive. Debian takes no responsibility for mirrors within the US that mirror +the non-US portion of the archive.</i></p> + +<hrline> + +<h3><i>Our Goal</i></h3> + +<p><i>We want to include cryptographic software in our main archive. We want to +understand the risks to developers, users, SPI, mirror maintainers, CD +resellers, sponsors and any other parties that are connected with Debian so +that we can make an informed decision. We want to be able to document and +publicize these risks so that these parties do not commit a crime through +that we can make an informed decision. We want to be able to document and +publicize these risks so that these parties do not commit a crime through +ignorance. Obviously, we also want to avoid taking unnecessary risks.</i></p> + +<p><i>In particular we would like to consider the following activities:</i></p> + +<ul> +<li><i>On a daily basis, adding and modifying DFSG-free software to our releases. + In practice only the testing and unstable releases are modified on a daily + basis, but the other releases are modified from time to time.</i></li> + +<li><i>Distributing cryptographic software as part of our releases over the + Internet and on CDs.</i></li> + +<li><i>Adding and changing DFSG-free cryptographic software on our CVS server.</i></li> + +<li><i>Any reactions we'd have to have to any changes in cryptographic regulations + (or laws).</i></li> +</ul> + +<hrline> + +<p><em>END Debian Document Preamble</em> + +<p>I will try to reflect these goals in my answers to your questions. By +way of summary, I think that an initial notification should suffice for +the current archive and updates thereto. A new notification would be +required only if a new program with encryption should be added to the +archive. Additional distribution of freeware does not require further +notification. However, commercial versions would be subject to the +technical review, licensing and reporting requirements that apply to +other commercial products. Predicting the future of changes to laws or +regulations is difficult, but if the law changes, you would either have +to take down the site or modify it in order to remain in compliance. +You have no obligation to inform other constituencies of their legal +obligations, but if you have a list of frequently asked questions, I +would be pleased to suggest appropriate responses that you might wish to +offer.</p> + +<p>Questions (Note, each question by Debian is marked with "D:")</p> + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Do we need to notify the Bureau of Export Administration (BXA) + about software we add to releases?</i></td> +</tr></table> +</blockquote> + +<p>If the notification is drafted properly, and the archive remains on the +site identified in the notification, then you only have to file a single +notification with BXA for the initial archive. Only one notification +for one U.S. site is required; no separate notification is required for +mirror sites inside or outside the U.S. This notification would only +have to be updated if you added a new program implementing encryption.</p> + +<pre> + Department of Commerce + Bureau of Export Administration + Office of Strategic Trade and Foreign Policy Controls + 14th Street and Pennsylvania Ave., N.W. + Room 2705 + Washington, DC 20230 + + Re: Unrestricted Encryption Source Code Notification + Commodity: Debian Source Code + + Dear Sir/Madam: + Pursuant to paragraph (e)(1) of Part 740.13 of the U.S. Export + Administration Regulations ("EAR", 15 CFR Part 730 et seq.), we are + providing this written notification of the Internet location of the + unrestricted, publicly available Debian Source Code. Debian Source Code + is a free operating system developed by a group of individuals, + coordinated by the non-profit Software in the Public Interest. This + archive is updated from time to time, but its location is constant. + Therefore, and this notification serves as a one-time notification for + subsequent updates that may occur in the future. New programs will be + the subject of a separate notification. The Internet location for the + Debian Source Code is: http://www.debian.org. + + This site is mirrored to a number of other sites located + outside the United States. + + A duplicate copy of this notification has been sent to the ENC + Encryption Request Coordinator, P.O. Box 246, Annapolis Junction, MD + 20701-0246. + + If you have any questions, please call me at (xxx) xxx-xxxx. + + Sincerely, + Name + Title +</pre> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>What information do we need to include in the notifications?</i></td> +</tr></table> +</blockquote> + +<p>The draft language above includes the information that you need to +include in the notification</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>How often do we need to notify? We want to notify as little as + possible as it creates more work for us and for the government, + but we want to notify as often as necessary to follow the + regulations.</i></td> +</tr></table> +</blockquote> + +<p>As drafted above, and assuming that the archive remains on the Internet +site identified in the notification, you should not have to file a +subsequent notification for subsequent updates. You would only file +another notification if you added a new program implementing +cryptography.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>If we move our cryptographic software into this country, + and the laws or regulations change to be more restrictive, what + are we likely to lose? Would we have to destroy any software, + or CDs? Would we have to remove it from our master or secondary + sites? If we use the increased availability of cryptographic + software to improve the security of the rest of the system, and + the cryptographic legal climate worsens, would be likely to have + to discard all copies of such software in the U.S.?</i></td> +</tr></table> +</blockquote> + +<p>The trend has been toward increased liberalization of the export +controls on cryptography in the United States, rather than increased +restrictions. This trend has been constant over the past decade and has +accelerated in the past year. We cannot advise you with respect to what +you might lose unless and until new regulations are published. However, +we believe that you would retain copyrights to the software and some, +albeit perhaps more limited, rights to export.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>In order of decreasing preference, we would like to notify:</i> + + <ul> + <li><i>Once for the entire Debian archive</i></li> + + <li><i>Once for each official release (keeping in mind that + testing/unstable change between releases)</i></li> + + <li><i>Once when a new program containing cryptography is added to + the archive</i></li> + + <li><i>Once when a new version of a program containing cryptography + is added to the archive.</i></li> + </ul> + </td> +</tr></table> +</blockquote> + +<p>I think that you only have to file a new notification if you add a new +program that incorporates cryptography. Updates to existing programs +should be covered by the broad language of the notification we +suggested, above.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>New packages enter the debian archive through the following sequence + of steps. At what point must the notification happen?</i> + + <ol> + <li><i>Upstream developer releases a package as open-source. + This step gets skipped in the case of a native-Debian package.</i></li> + <li><i>A Debian developer packages the source and binary for Debian, + frequently with source changes.</i></li> + <li><i>The package is uploaded to ftp-master, incoming.</i></li> + <li><i>The new package fails to install, because it's new.</i></li> + <li><i>Ftp admins add the needed records for the package.</i></li> + <li><i>The package installs into the archive, within a few days.</i></li> + <li><i>The package gets copied to the mirror sites.</i></li> + </ol> + </td> +</tr></table> +</blockquote> + +<p>The regulations are pretty clear that the notification has to occur +prior to or contemporaneous with public availability. Exports prior to +public availability require an export license. Therefore, if the archive +in step 3 is not publicly available, then either the package must be made +publicly available prior to step 3 (and notifications sent), or export +licenses will be needed for Debian developers. If the archive in step 3 +is publicly available, then notification at that point would eliminate the +need to have export licenses for Debian developers.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>If the upstream author has notified BXA, is the notification needed? + (Packaging for debian can involve modifications to the source + involving file locations, and occasionally functional differences, + although the general goal is to make the upstream code work in + Debian with minimal modification.)</i></td> +</tr></table> +</blockquote> + +<p>If the upstream author has notified BXA, that is sufficient.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Do we need to notify when new binaries (object code) are added if + we have already notified for the source code?</i></td> +</tr></table> +</blockquote> + +<p>I do not think that you have to file a new notification for object code, +provided that a notification for the source code has been filed.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Is notification required for programs that do not contain crypto + algorithms, but are linked against crypto libraries? What about + programs that launch other programs in order to do cryptographic + functions?</i></td> +</tr></table> +</blockquote> + +<p>As long as the program is open source, it may include an open crypto API +and still qualify under License Exception TSU.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>New programs can be checked easily prior to their release (and + notification done at that time), but when an update is performed, + there isn't a manual step at which to do the notification. Would + it be acceptable to notify BXA for each addition of software, with + an indication that future updates may include the addition of + crypto functionality?</i></td> +</tr></table> +</blockquote> + +<p>Yes. Overreporting should probably be avoided where reasonable, but +underreporting must be avoided. Future updates of an existing program +do not require separate notification. Only new programs require separate +notification.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Can we automate the process of sending in notifications?</i></td> +</tr></table> +</blockquote> + +<p>You may automate the process of sending notifications. This in an +internal procedural matter. BXA and NSA do not care how you handle the +filing of notifications internally.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>What form should the notification take?</i></td> +</tr></table> +</blockquote> + +<p>The BXA notification may be in either electronic or paper form; +however, the NSA notification must be in paper form.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Who can send in the notifications? For example, do they need to + be a US citizen?</i></td> +</tr></table> +</blockquote> + +<p>Any person may send in the notification; citizenship is not relevant.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Are there any other concerns we should be aware of? What steps + other than notification do we need to take?</i></td> +</tr></table> +</blockquote> + +<p>Other than notification, you might consider implementing a reverse IP +lookup that identifies the computer requesting the download, and that +blocks downloads of the cryptographic archive to countries embargoed by +the United States: Cuba, Iran, Iraq, Libya, North Korea, Syria, Sudan +and Taliban Occupied Afghanistan. In addition, you might consider +having a provision in your license agreement, or a separate screen prior +to download, that advises the person downloading the software as +follows:</p> + +<p>This software is subject to U.S. export controls applicable to open source +software that includes encryption. Debian has filed the notification with +the Bureau of Export Administration and the National Security Agency that +is required prior to export under the provisions of License Exception TSU +of the U.S. Export Administration Regulations. Consistent with the +requirements of License Exception TSU, you represent and warrant that you +are eligible to receive this software, that you are not located in a country +subject to embargo by the United States, and that you will not use the +software directly or indirectly in the design, development, stockpiling +or use of nuclear, chemical or biological weapons or missiles. Compiled +binary code that is given away free of charge may be re-exported under the +provisions of License Exception TSU. However, additional technical review +and other requirements may apply to commercial products incorporating this +code, prior to export from the United States. For additional information, +please refer to www.bxa.doc.gov.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Currently, users around the world can access and potentially + download software that is awaiting integration into our archive. + Likely, we would do any necessary notifications as software is + processed into the archive, so software in this state would be + awaiting notification. Would this be a problem? If so, would it + be acceptable to set up an alternate queue of cryptographic + software awaiting integration into the archive available only to + our developers? In order to process software into our distribution, + developers who are often outside the US need to examine the + software and make sure it meets certain guidelines. How should we + accomplish this access? Are there any other solutions to this + pre-notification area of the archive we should consider?</i> + + <p><i>One issue we often run into is software patents. Clearly the + integration of cryptography into software doesn't remove any of the + patent concerns we would normally have to think about. However, are + there any new issues we need to consider when patents interact with + cryptography export regulations? It seems that at least for exemption + TSU (section 740.13 of the EAR), patents do not influence whether the + source code is public.</i> + </td> +</tr></table> +</blockquote> + +<p>It is important to differentiate between the archive that has been a +subject of notification, and new programs. You can update the archive +that has been a subject of notification without further notification, as +described above. Only new programs need to be subject of a separate +notification, prior to posting. If new programs must be reviewed by +developers prior to posting, and such software is not both publicly +available and already notified to the U.S. government, then I recommend +that you consider obtaining an export license authorizing this limited, +pre-notification review. You are correct that patents do not disqualify +software from eligibility for export under License Exception TSU.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Distribution, Mirroring and CDs</i> + + <p><i>Do our mirrors within the US need to notify the BXA if we add + cryptography to our archive? How often do they need to notify BXA? + We would like to avoid a situation where mirrors have to notify for + each new program Debian adds to the archive, even if our master + server must send in such notifications. We need to keep operations + simple for mirror operators. What, if anything, would mirrors + outside the US need to do?</i></p> + + <p><i>If we send an update to a mirror rather than waiting for it to + download software, do we need to take any special steps? What if we + send a mirror a request to download new/changed software?</i></p> + </td> +</tr></table> +</blockquote> + +<p>Once the notification has been filed for the central server, no further +notification is required for mirror sites.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Which of the following vendors (if any) would be able to ship + unmodified Debian binaries (and source) with only notification? + Which would require review and approval? Could the review be + concurrent with shipment, or must approval predate shipment?</i> + + <p><i> + A) mail-order shipment of CD's for the cost of the media?<br> + B) mail-order shipment of CD's for profit?<br> + C) off-the-shelf sales of CD's for the cost of the media?<br> + D) off-the-shelf sales of CD's for profit?<br> + E) vendor providing CD's from A or C above, along with hardware. HW + sold at a profit, but with no preinstall?<br> + F) E, but with software pre-installed?<br> + G) any of the above, selling support for the software? + </i></p> + + <p><i>If it's easier, another way to look at this is: what conditions must + be met for the vendor to ship binaries under License Exception TSU, + and what expenses is the vendor allowed to recover costs and/or sell + at a profit?</i></p> + </td> +</tr></table> +</blockquote> + +<p>Reasonable and customary fees for reproduction and distribution are +allowed, but not license fees or royalties. Support also is allowed, +subject to the above limitation.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>If the one-time review is required for unmodified binaries shipped + for-profit, can that approval be used by other vendors which are + shipping unmodified binaries?</i></td> +</tr></table> +</blockquote> + +<p>A one time review is for the product, and is vendor-independent.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>Would it be acceptable to set up an official mirror in a country + forbidden in EAR section 740.13(e)?</i></td> +</tr></table> +</blockquote> + +<p>You would have to apply for a license to set up an official mirror in an +embargoed country.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>If it is technically infeasible to block access from the T7 countries + to a web (or ftp, etc) server, does due diligence require extreme + measures? Does the defacto standard of (US) industry common-practice + meet due diligence?</i></td> +</tr></table> +</blockquote> + +<p>The de facto industry standard should suffice. I hope that the government +will recognize that any system devised by man can be defeated, with enough +effort.</p> + + +<blockquote> +<table border="0" width="100%"><tr> +<td width="10%" valign="top">D:</td> + <td><i>What steps should we take if we become aware of someone downloading + software into one of these countries from a mirror within the US? + What if we become aware of downloads into one of these countries + from a mirror outside the US?</i> + + <p><i>Some of our developers may live in or be citizens of the seven + countries forbidden for exemption TSU. Would it be a problem for + these developers to have access to cryptographic software on our + machines? Would we need to ask them not to download such software? + What steps should we take if we become aware of them downloading + cryptographic software?</i></p> + </td> +</tr></table> +</blockquote> + +<p>Simply posting cryptographic software on a server that may be accessible +from an embargoed country does not constitute “knowledge” that the +software has been exported there. Therefore, criminal liability would +not apply to the act of posting. We recommend that you perform IP +checking and deny downloads to known embargoed countries. This due +diligence also would provide a defense to a claim of civil liability. +If you find out that your software has been downloaded to a prohibited +destination, then I recommend that you block future downloads to that +specific site unless and until you obtain a license from BXA.</p> + +<hr> + +<p>Debian thanks the <a href="http://www.hp.com/">Hewlett-Packard</a> +<a href="http://www.hp.com/products1/linux/">Linux Systems Operation</a> +for their support in obtaining this legal opinion.</p> |