[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Crypto in Main document...



If we're going to have this thing wrapped up in a week, we need to start
gathering opinions now.

I think we need a short period of random discussion before we try
to figure out how we're going to express our opinions.  [Also, I got
practically no sleep last night, so random discussion is what I'm best
at right now.  Always do what you're good at...]  Below is my first
impression.

[Please send your own impressions, or feel free to state your opinions
formally.  We are going to need to issue an opinion, and while a formal
proposal might get some ammendments before we're ready to vote on it,
it wouldn't be bad to write up a formal proposal.]

>     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.

My first thought, on reading this, is: Do we care about stability?
If U.S. laws or regulations are likely to change significantly (because
of constitutional challenges, lobbying, etc.) do we care?  If so, what
kinds of likely changes do we care about?  [Does it matter to us if the
legal climate on cryptography requiers us to change our crypto policy
a couple times every year?]

...
>     There are also third-party groups that copy the Debian software
>     onto mirrors so that people around the world can download and use
>     it.

We should include a definition of "mirrors".  We're not using the
common use meaning of the word.

...

> 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. 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 server outside the US onto our main server in the US.

Would some of the reasons why we want this matter to a legal person?

> In addition, there are two constantly evolving releases of Debian: the
> testing and unstable releases.

There's also security.debian.org which doesn't evolve so much, but
which still represents a stream of changes.

> 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.

It might matter that some developers work on software specifically for
use on non commodity hardware?  Most of our efforts are directed at
commodity hardware, but not all.  To my knowledge there's not been
any crypto-specific software specially targetted at non-commodity
hardware, but that could change.

Should we mention that in the past we took pains to ensure that
the developers who worked on the crypto software are not u.s.
citizens, nor working in the u.s.?  [I'm not sure if we still
do this?]

> 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 think we should insert a statement about our desire to provide a
smoothly upgradable system here.  [That we don't ever want to have to make
a change so sudden that the system ceases to work during the upgrade.
Nor do we want to have to stop offering functionality that we used
to offer.]

Any legal advice should keep this conservative nature in mind.

> Our Goal
> 
> 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 ignorance. Obviously, we also want to avoid taking
> unnecessary risks.
>
> In particular we would like to consider the following activities:
> 
>   * 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.
>
>   * Distributing cryptographic software as part of our releases over
>     the Internet and on CDs.
> 
>   * Adding and changing DFSG-free cryptographic software on our CVS
>     server.

    * electronic communication between developers, which takes a
      variety of forms.

[I think some of those forms -- e.g. bug tracking system -- already
reside in the U.S., but I suspect bringing this up would be relevant]
   

> -------------------------------------------------------------------------------
> 
> Questions
> 
> Adding Software to Releases
> 
> Do we need to notify the Bureau of Export Administration (BXA) about
> software we add to releases? What information do we need to include in
> the notifications? 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.

"What steps do we need to take to properly react to new regulations?
Can we wait until someone notifies us of a change?"

> Would it be acceptable to set up an official mirror in a country
> forbidden in ear section 740.13(e)?

We should define what we mean by "official" [listed on our page
identifying such all mirrors].


Thanks,

-- 
Raul



Reply to: