SGI OpenVault

[Brian Behlendorf]

On Tue, 27 Apr 1999, Gabe Wachob wrote:
> 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...)

I am well familiar with this kind of pressure, which even hits open-source
developers (see http://www.apache.org/docs/misc/nopgp.html).  Yes, there
are lots of extra-legal ways governments can apply pressure, and we have
to accept that Apple and SGI have deeper pockets than the FSF or Apache.
I could see this being used to justify section 9.1 of the APSL.  But
here... it just seems to be redundant.

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

Well, if it's deemed "illegal", then the license should be irrelevant in
that context.  You don't have any right under governmental law to use it.

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

I don't consider it a violation because the OSD can't mandate something
that applicable law prevents, because the OSD is about certifying licenses
which are contracts, and contract law can't override governmental law.  

A useful criteria might be this:

  a) if a license, by virtue of where it was written/distributed/used,
says it must be compliant with applicable law, and applicable law is
discriminatory, the license can still pass the OSD;

but,

  b) if the license explicitly discrimiates, even if only in a way that is
congruent with applicable governmental laws, then it can not pass the OSD.

That seems like a reasonable compromise.

Some have suggested that this begs the question of what the purpose of the
OSD and the OSI is.  I think the answer is morphogenic; what do we want it
to be?  I've got enough windmills to tilt against that trying to use it as
a wedge to change a country's public policies would quickly wear me out; I
think using it as a wedge to show commercial interests how to "do Open
Source right" is a more reasonable goal.

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

Yes.  Oh for a programming language for contract law.  Enough of this
crappy English language!  We need a compilable language for this.

> 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?)

Very true.

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

I think a valid question (and this affects the APSL discussions to) is why
the language found in most licenses is not enough; the boilerplate about
"this software is provided as-is, no warranties...", etc.  That would seem
to be sufficient to wash one's hands of all of that.  If it's not, I want
to see why lawyers think so; where is the case history?  Or even barely
relevant case history?

Perhaps another idea is to convince some of the larger companies to wash
their liability by granting the source code to some smaller organization,
perhaps a non-profit or not-for-profit industry organization, which is not
nearly as attractive as a litigation target as Apple or SGI might be.

	Brian