[lsb-discuss] LSB conf call notes for 2008-05-14

[Robert Schweikert]

<snip>
> The rules are very simple: if a company outside the US develops a product that
> contains cryptography and then exports it to another country there are two
> options:
> a) The company does not use US IP, therefore they are allowed to do whatever
> they want with their software. Even if the company exports the software to
> the US. Notice that we are a norwegian company, we only have a sales office
> in the US, no development is done in the US.
>
> b) The company does use US IP, therefore they are restricted by the US Export
> Control. They cannot export the software to any place that is banned on the
> US Export Control list.
>
> Exceptions for open source software apply to some, but we distribute software
> under a dual license thus we are not totally covered by those exceptions.
> Many of our customers are outside the US and they do not target the US market,
> therefore they want to have freedom to do whatever they want with their
> products, and that includes not being under the US Export Control. If you ask
> us to add support for NSS, you are asking us to take a step that can
> jeopardize many of our customers, so the answer is very simple: NO.
>   
I don't think anyone is asking Trolltech to implement a layer around 
NSS. Whether or not this should and/or can be done is your decision. 
This decision has, or should have no bearing on the LSB. From an LSB 
point of view the situation is reasonably straight forward.

1.) We have requests from various sources to include crypto capability 
int the LSB.
2.) OpenSSL simply is not ready.
3.) NSS is ready, we get support from upstream, and it is shipped with 
every distro.

This makes NSS pretty much our only choice if we intend to listen to our 
customers.

How our customers deal with US export restrictions is not for us to 
decide. There certainly will be applications that need crypto that will 
not be LSB compliant because we use NSS and not openSSL. However, there 
will also be applications that will be LSB compliant because we have a 
solution to the crypto problem. Today any app needing crypto cannot be 
LSB compliant because we have no solution. When NSS is part of the LSB 
at least some of the applications can certify. Thus, we made an improvement.

We cannot solve the legal issues of the world on this list, nor should 
we argue about company policy. The Trolltech legal team has come to an 
interpretation of the law and based on this there is a company policy in 
place. Again, this should have no bearing on the LSB decision on whether 
or not NSS becomes part of the LSB. A large part of Qt is part of the 
LSB and will remain part of the LSB. To the best of my knowledge we have 
no requests to include the Trolltech wrapper to crypto in the LSB and 
therefore this is more or less an academic discussion.

I think we should make a strong effort to get NSS into LSB 4.0 even if 
it is a trial use module.

> And believe me, many companies that develop software for Linux outside the US
> use cryptography and they are not under US Export Control, nor they want to
> be under US Export Control.
>
>   
I don't think anyone is arguing that point either. The fact remains that 
these companies cannot be LSB compliant because we have no crypto 
solution. If NSS is part of LSB than they can at least evaluate the 
situation and decide what is more important. There is of course also the 
possibility that a legal team from a different company comes up with a 
different interpretation of the law.

Robert

-- 
Robert Schweikert                       MAY THE SOURCE BE WITH YOU
(robert.schweikert at mathworks.com)                 LINUX
The MathWorks Inc.
Phone : 508-647-2042