Commit f8dfbd65 authored by Helge Kreutzmann's avatar Helge Kreutzmann

All changes are presented on debian-www without dissent

*Use <q>
*Close all <p>
*Unify spacing after full stops and question marks
*Use <br />
Thanks, Christel

CVS version numbers

english/legal/cryptoinmain.wml: 1.7 -> 1.8
parent fc54e753
......@@ -20,7 +20,7 @@
</table>
<p>Thank you for this opportunity to comment on Sam Hartman's white paper
entitled &ldquo;Exploring Cryptographic Software in Debian's Main Archive&rdquo;.</p>
entitled <q>Exploring Cryptographic Software in Debian's Main Archive</q>.</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
......@@ -34,15 +34,15 @@ 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 (&ldquo;EAR&rdquo;, 15 CFR Part 730 et seq.) administered by the
Commerce Department's Bureau of Export Administration (&ldquo;BXA&rdquo;). BXA
Regulations (<q>EAR</q>, 15 CFR Part 730 et seq.) administered by the
Commerce Department's Bureau of Export Administration (<q>BXA</q>). BXA
revised the provisions of the EAR governing cryptographic software most
recently on October 19, 2000. I refer to these as the &ldquo;new US
Regulations&rdquo; in order to distinguish them from prior regulations that
recently on October 19, 2000. I refer to these as the <q>new US
Regulations</q> 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 &ldquo;munitions&rdquo; under
were controlled for export from the United States as <q>munitions</q> 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
......@@ -77,7 +77,7 @@ 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
(&ldquo;NSA&rdquo;). However, the old regulations were silent with respect to
(<q>NSA</q>). However, the old regulations were silent with respect to
restrictions (if any) on the export of compiled executable software
derived from open source.</p>
......@@ -97,8 +97,8 @@ 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 &ldquo;open&rdquo;
nor &ldquo;community&rdquo; source. Exporters may provide proprietary source code
<p>Proprietary source refers to all source code that is neither <q>open</q>
nor <q>community</q> 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
......@@ -122,7 +122,7 @@ 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.
below in italics.</p>
<hr />
......@@ -162,8 +162,8 @@ 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
software is stored on a server outside the United States, known as the <q>non-US
server</q>. 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>
......@@ -254,12 +254,12 @@ the non-US portion of the archive.</i></p>
<h3><i>Our Goal</i></h3>
<p><i>We want to include cryptographic software in our main archive. We want to
<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
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>
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>
......@@ -366,7 +366,7 @@ include in the notification</p>
<blockquote class="question">
<p>
<span>D:</span>
How often do we need to notify? We want to notify as little as
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.
......@@ -542,7 +542,7 @@ however, the NSA notification must be in paper form.</p>
<blockquote class="question">
<p>
<span>D:</span>
Who can send in the notifications? For example, do they need to
Who can send in the notifications? For example, do they need to
be a US citizen?
</p>
</blockquote>
......@@ -594,17 +594,17 @@ please refer to www.bxa.doc.gov.</p>
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,
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
accomplish this access? Are there any other solutions to this
pre-notification area of the archive we should consider?
</p>
<p>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
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.
......@@ -626,9 +626,9 @@ software from eligibility for export under License Exception TSU.</p>
<blockquote class="question">
<p>
<span>D:</span>
Distribution, Mirroring and CDs
Distribution, Mirroring and CDs</p>
<p>Do our mirrors within the US need to notify the BXA if we add
<p>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
......@@ -636,8 +636,8 @@ software from eligibility for export under License Exception TSU.</p>
simple for mirror operators. What, if anything, would mirrors
outside the US need to do?</p>
<p>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
<p>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?
</p>
......@@ -656,13 +656,13 @@ notification is required for mirror sites.</p>
concurrent with shipment, or must approval predate shipment?
</p>
<p>
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>
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>
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?
</p>
......@@ -706,7 +706,7 @@ embargoed country.</p>
<span>D:</span>
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
measures? Does the defacto standard of (US) industry common-practice
meet due diligence?
</p>
</blockquote>
......@@ -733,7 +733,7 @@ effort.</p>
</blockquote>
<p>Simply posting cryptographic software on a server that may be accessible
from an embargoed country does not constitute &ldquo;knowledge&rdquo; that the
from an embargoed country does not constitute <q>knowledge</q> 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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment