SGI OpenVault

[Brian Behlendorf]

On Tue, 27 Apr 1999, Gabe Wachob wrote:
[...]
> Is it the intent of the OSI that inclusion of a term

You mean, "intents of the OSD authors"... 

> which requires legal compliance in distribution and operation of the software
> renders a license non open-source? That would seem to be a large obstacle for a
> large commercial entity wishing to open source their software.

I think that's a reductio ad absurdum... licenses are contracts governed
by contract law, so I see "what the licenses that are OSD-compliant allow"
as not always a precise subset of "what the law in any given country
allows".  

I think it's redundant for a license to specify things that the legal code
of a given country already mandates, which is why things like export
provisions are generally pretty silly.  

E.g., if I wrote a program that implemented a crypto algorithm, by
(current) U.S. law I can't export that; however, I don't need to put that
into my license at all.  It's up to me to distribute it only to other US
citizens, and up to them to similarly make sure they don't violate US law
by exporting it.  The question then becomes, do *I* have liability if
someone *else* exports my code; and I'm not aware of any court case where
that has been tested. 

[...]
> If this term wasn't in the license, then SGI might have to spend more money
> litigating (they might have to anyway, mind you) the issue -- they'd probably win
> anyway (who knows), but having the explicit term lays out the risk allocation so
> that the end user understands better what is going to happen.

True; just as, if I put in my license on my crypto code, "you must not
violate U.S. law by distributing this outside the U.S.", I would be laying
out the risks; but it's redundant for me to make that a condition of the
contract.  IMHO.

> Now, this argument might be counter to the principles of the Open Source
> Definition, but we must remember that companies like SGI are doing this not for
> the public good (they could get sued for that), but because of the business case
> it makes for them. I would argue that a term like this reduces risks and makes
> that business case better and thus is beneficial for opensource (balancing, of
> course, against the increased restrictions on use of software it imposes).
> 
> I'm not saying the wording is perfect, just that the intent of the term is
> important.

I am also neutral on it; I don't think it violates the DFSG.  But I don't
think it's necessary.  That's not a legal opinion though.

> > The clause which requires people to follow "all export and import control
> > laws" is ambiguous, and could be construed as a bizarre inclusion by
> > reference of _all_ trade laws in the entire world.
> 
> Actually, I think its straightforward and thats exactly what it intends to do.
> Its another case of SGI covering its rear end. These are fairly standard
> traditional license terms.

I bet if you asked SGI if they intended for the laws of Saudi Arabia to
apply to someone in the US giving the code to someone in the UK, they'd
say no; in fact the term "applicable" appears to apply to the entire
sentence:

>    7. Compliance with Laws; Non-Infringement. Recipient shall comply with
>    all applicable laws and regulations in connection with use and
>    distribution of the Subject Software, including but not limited to,
>    all export and import control laws and regulations of the U.S.
>    government and other countries.

Yes, it could be written much more clearly; for one, the only countries
that should matter are that of the original author (the US), the
distributor, and the recipient.  But even then it's unclear - if the code
passes through France on its way from the US to Germany, is it bound to
French law?  The French would say so, I think.  =)  That's why it's
perhaps best to leave #include of laws out of licenses - because laws
change, and even a sweeping meta-law statement like the above could come
under question.

	Brian