SGI OpenVault

[Gabe Wachob]

Brian Behlendorf wrote:

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

Well, it may not be legal liability or anything of that nature. It may be that your
main source of distribution (as a software provider) is CDs and the government is
going to block all software you sell across the border (open source and otherwise,
legal and otherwise) because you are not actively trying to prevent usage of some
illegal software (which may be open source). In other words, governments have ways of
putting pressure on large corporations that they don't have on smaller, more
traditional open source software authors. (Also, governments may refuse to buy
software from companies who they perceive as distributing illegal software in their
country). This could happen even in the United States. And I imagine there are some
countries where a government would directly go after a software producer in a criminal
context for "allowing use of" illegal software (yeah, it makes no sense...)

So, a large software company *may* have very real desires to put language in the
license which allows them to relatively easily yank the license if their software is
deemed "illegal".

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

But don't forget, this isn't the Apache group we are talking about ;-) SGI, for
example, might sell machines and have consulting contracts with the government of New
Bad Country. And it may have assets which are reachable by that government..  Its
going to want to be able to say to that government that it is doing all it can to
comply with the laws of that country. I'm just trying to point out where SGI is coming
from. I'm not making a statement about whether or not this is a valid argument (though
I do think it has some merit).

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

Well, the issue is whether its acceptable -- obviously, we'd all like it not there,
but is this an accomodation to the large corporate interests that is
acceptable? Worthwhile?

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

Thats not how I interpreted the paragraph I was responding to (see how language can be
twisted and interpreted in so many ways? No you know why there are so many lawyers --
language is very very imprecise). I took the only "sensical" interpretation (which is
what a court would do absent evidence of an understanding otherwise) of the language
which is the one you mention and the one most of us think would apply.

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

Agreed! However, I wonder if that is indeed SGI's intent.

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

Well, the U.S. export laws apply sort of strangely (ie you can bring crypto on a
laptop to another country but you can't give crypto to your french-national coworker
in San Francisco), and I would imagine that it would take a thorough legal analysis to
figure out any sort of trustworthy answer -- the point is here again that SGI doesn't
want to bother with the termination term depending on a complex legal analysis -- they
just want to be able to terminate if there is a legal problem at all. Thats not good
for open source users -- it should be clearer.

The problem is "how clear"? If other country's export laws are as screwy as the
U.S.'s, then how could you craft a term that was more specific about which laws had to
be followed (you must follow the originating country's export laws, the receving
country's import laws, and any laws that might apply due to the sender and receiver's
nationality or other status specifically mentioned by an applicable law?)

Laws are usually fundamentally screwed up, complicated, not well-thought-out products
of self interest, but we have to live with them. We make do by ignoring them, staying
clear of them, or paying lawyers lots of money to tell us how to follow them. I think
SGI just wants to "stay clear" of them.. If someone can convince SGI to drop the term
altogether, thats great, but it seems to me that you are then asking them to take the
risk that they cannot easily terminate their involvement in any potential illegality.
The problem is that "illegality" is not often known ahead of time, especially when
there are many jurisdictions and illegality may be defined differently for each one.

    -Gabe