HTML strict

CVS version numbers

english/legal/cryptoinmain.wml: 1.4 -> 1.5

1 files changed, 162 insertions, 165 deletions

diff --git a/english/legal/cryptoinmain.wml b/english/legal/cryptoinmain.wml
index c1326167aaf..f6ffb898b6e 100644
--- a/english/legal/cryptoinmain.wml
+++ b/english/legal/cryptoinmain.wml
@@ -4,14 +4,18 @@
 # _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>
+<table width="100%" summary="mail headers">
+<colgroup span="2">
+<col width="10%">
+<col>
+</colgroup>
+<tr><td>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>
+<tr><td>From:</td>
 	<td>Roszel C. Thomsen II, Partner, <a href="http://www.t-b.com/">Thomsen &amp; Burke LLP</a></td></tr>
-<tr><td width="10%">Date:</td>
+<tr><td>Date:</td>
 	<td>July 31, 2001</td></tr>
-<tr><td width="10%">Re:</td>
+<tr><td>Re:</td>
 	<td>Exploring Cryptographic Software in Debian's Main Archive</td></tr>
 </table>
 
@@ -300,12 +304,12 @@ 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 class="question">
+<p>
+<span>D:</span>
+	Do we need to notify the Bureau of Export Administration (BXA)
+	about software we add to releases?
+</p>
 </blockquote>
 
 <p>If the notification is drafted properly, and the archive remains on the
@@ -354,25 +358,25 @@ have to be updated if you added a new program implementing encryption.</p>
 </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 class="question">
+<p>
+<span>D:</span>
+	What information do we need to include in the notifications?
+</p>
 </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
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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>
+	regulations.
+</p>
 </blockquote>
 
 <p>As drafted above, and assuming that the archive remains on the Internet
@@ -382,18 +386,18 @@ 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,
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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>
+	to discard all copies of such software in the U.S.?
+</p>
 </blockquote>
 
 <p>The trend has been toward increased liberalization of the export
@@ -405,25 +409,24 @@ 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>
-
+<blockquote class="question">
+<p>
+<span>D:</span>
+	In order of decreasing preference, we would like to notify:
+        </p>
 	<ul>
-	<li><i>Once for the entire Debian archive</i></li>
+	<li>Once for the entire Debian archive</li>
 
-	<li><i>Once for each official release (keeping in mind that
-	  testing/unstable change between releases)</i></li>
+	<li>Once for each official release (keeping in mind that
+	  testing/unstable change between releases)</li>
 
-	<li><i>Once when a new program containing cryptography is added to
-	  the archive</i></li>
+	<li>Once when a new program containing cryptography is added to
+	  the archive</li>
 
-	<li><i>Once when a new version of a program containing cryptography
-	  is added to the archive.</i></li>
+	<li>Once when a new version of a program containing cryptography
+	  is added to the archive.</li>
 	</ul>
-	</td>
-</tr></table>
+	
 </blockquote>
 
 <p>I think that you only have to file a new notification if you add a new
@@ -432,25 +435,23 @@ 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>
-
+<blockquote class="question">
+<p>
+<span>D:</span>
+	New packages enter the debian archive through the following sequence
+	of steps.  At what point must the notification happen?
+</p>
 	<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>
+	<li>Upstream developer releases a package as open-source.
+	   This step gets skipped in the case of a native-Debian package.</li>
+	<li>A Debian developer packages the source and binary for Debian,
+	   frequently with source changes.</li>
+	<li>The package is uploaded to ftp-master, incoming.</li>
+	<li>The new package fails to install, because it's new.</li>
+	<li>Ftp admins add the needed records for the package.</li>
+	<li>The package installs into the archive, within a few days.</li>
+	<li>The package gets copied to the mirror sites.</li>
 	</ol>
-	</td>
-</tr></table>
 </blockquote>
 
 <p>The regulations are pretty clear that the notification has to occur
@@ -463,56 +464,56 @@ 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?
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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>
+	Debian with minimal modification.)
+</p>
 </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 class="question">
+<p>
+<span>D:</span>
+	Do we need to notify when new binaries (object code) are added if
+	we have already notified for the source code?
+</p>
 </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
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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>
+	functions?
+</p>
 </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
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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>
+	crypto functionality?
+</p>
 </blockquote>
 
 <p>Yes.  Overreporting should probably be avoided where reasonable, but
@@ -521,11 +522,11 @@ 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 class="question">
+<p>
+<span>D:</span>
+	Can we automate the process of sending in notifications?
+</p>
 </blockquote>
 
 <p>You may automate the process of sending notifications. This in an
@@ -533,34 +534,34 @@ 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 class="question">
+<p>
+<span>D:</span>
+	What form should the notification take?
+</p>
 </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 class="question">
+<p>
+<span>D:</span>
+	Who can send in the notifications? For example, do they need to
+	be a US citizen?
+</p>
 </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 class="question">
+<p>
+<span>D:</span>
+	Are there any other concerns we should be aware of?  What steps
+	other than notification do we need to take?
+</p>
 </blockquote>
 
 <p>Other than notification, you might consider implementing a reverse IP
@@ -589,10 +590,10 @@ 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
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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
@@ -603,17 +604,17 @@ please refer to www.bxa.doc.gov.</p>
 	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
+	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
 	TSU (section 740.13 of the EAR), patents do not influence whether the
-	source code is public.</i>
-	</td>
-</tr></table>
+	source code is public.
+	
+</p>
 </blockquote>
 
 <p>It is important to differentiate between the archive that has been a
@@ -628,39 +629,39 @@ 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>
+<blockquote class="question">
+<p>
+<span>D:</span>
+	Distribution, Mirroring and CDs
 
-	<p><i>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
 	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>
+	outside the US need to do?</p>
 
-	<p><i>If we send  an update to a mirror rather than waiting for it to
+	<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?</i></p>
-	</td>
-</tr></table>
+	send a mirror a request to download new/changed software?
+	
+</p>
 </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
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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>
+	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>
@@ -669,14 +670,12 @@ notification is required for mirror sites.</p>
 	   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>
 
-	<p><i>If it's easier, another way to look at this is:  what conditions must
+	<p>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>
+	at a profit?</p>
 </blockquote>
 
 <p>Reasonable and customary fees for reproduction and distribution are
@@ -684,38 +683,38 @@ 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
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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>
+	shipping unmodified binaries?
+</p>
 </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 class="question">
+<p>
+<span>D:</span>
+	Would it be acceptable to set up an official mirror in a country
+	forbidden in EAR section 740.13(e)?
+</p>
 </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
+<blockquote class="question">
+<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
-	meet due diligence?</i></td>
-</tr></table>
+	meet due diligence?
+</p>
 </blockquote>
 
 <p>The de facto industry standard should suffice.  I hope that the government
@@ -723,22 +722,20 @@ 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
+<blockquote class="question">
+<p>
+<span>D:</span>
+	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
+	from a mirror outside the US?
+</p>
+	<p>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>
+	cryptographic software?</p>
 </blockquote>
 
 <p>Simply posting cryptographic software on a server that may be accessible