From: rmilner@zia.aoc.nrao.edu (Ruth Milner)
Newsgroups: misc.legal,comp.sys.sun.misc
Subject: Re: Put away your Motif manual; Sun's lawyers are at the door! (long)
Date: 23 Dec 92 23:12:03 GMT
Reply-To: rmilner@zia.aoc.nrao.edu (Ruth Milner)
Organization: National Radio Astronomy Observatory, Socorro NM

In article <1h80cpINNevp@spud.Hyperion.COM> koreth@spud.Hyperion.COM (Steven Grimm) writes:
>From the license agreement on the back of the Solaris 2.1 CD:
>
>2. License to Develop.  In the event that Customer desires to develop software
>programs which incorporate portions of Software ("Developed Programs"), the
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note this carefully. "Software" here refers to the bits and pieces of Solaris
2.1 which are contained on that CD. There will be a more specific definition 
earlier in the document.

You can write whatever you want if it doesn't incorporate stuff they provide.
The real question is: does "Software" include linked-in object code or include 
files? If so, then yes, you may very well be screwed, and Sun is saying, in 
essence, that you can only develop on Suns for SPARC-API/OL-compliant systems.

On the other hand, this is a "shrink-wrapped" agreement, and to date I don't
think they've really been tested in court yet (at least as of a year ago).
A few cases have started to go to court, but rather than risk the agreement
being declared non-binding, the company dropped the suit. (This information
comes from a colleague who reads something called the Attorney's Journal, or
some such.) I don't think anyone really knows if agreements like this will
stand up in court.

As well, I think there would a good argument for linked-in system code (e.g.
libc) not to be considered as being "incorporated" into your application
purely at link/run-time. You can't build anything on the system without the 
system doing this for you. If Sun tried to interpret it the other way, any
plain X11 client you built (not to mention all those third-party Motif 
programs Sun sites are running and companies are developing) would be in 
violation of the agreement, and I can't see that being their intention.

So let's interpret it that way and address your specific points:

>- I can't port a Motif application to Solaris 2.1.

Presumably a Motif application from another platform doesn't include portions 
of Solaris 2.1, so you're subject only to whatever restrictions have been 
placed on the application you want to port.

>- My program can't send things to my line printer unless I buy NeWSprint.

Only if it uses the fonts you have to license with NeWSprint. Which is highly
unlikely in the case of a line printer. :-)

If you develop a printing program that uses these fonts, you may not use the 
program on any system which isn't licensed for those fonts. That's covered in 
another Sun license agreement (OpenWindows and probably NeWSprint too).

>- If I develop a library, its API has to look the same as Solaris' (whatever
>  THAT means).

Only if you include portions of SunSoft's code in your library (e.g. you
directly incorporate individual object routines from libc.so or something).

If you plan to do this, you'd better make sure you know what the API looks
like, because you'll need to know anyway.

>Sun pays people to write this drivel?  Is there even a remote possibility
>that half these provisions wouldn't be laughed immediately out of court?

Yes, given the fact that the license restrictions are probably not as broad as 
you were making them out to be. Sun is trying to control what happens with the 
code they wrote. For example, if you were to incorporate routines that Sun 
provided in libc into your library, Sun is saying that you *may* redistribute 
it *provided* that all systems it is installed on are already licensed for 
Solaris 2.1. While I don't like the legal lingo, this is actually pretty 
reasonable. 

>Am I the only one who thinks the above is pretty ridiculous?

Probably not. :-)

I do think Sun has the legal and ethical right to dictate how you may redis-
tribute their code (which, after all, you have only licensed, not purchased
outright), and to say that it may not be *incorporated into* applications 
which are not compliant with their standards - assuming that they are not
including system .h files or system routines that the linker puts in auto-
matically.

However, it is getting to the point now where you really do have to sit down
and *think* about all the possible ways lawyers could interpret these agree-
ments, and how they all might affect you. Very painful.

A potentially far more insidious statement can be found on the back of the 
SunPro SPARCworks/SPARCompiler CD:

  2. Restrictions. [...] You agree that you will not export or re-export,
     whether directly or indirectly, the Software, *or any direct products
     thereof*, outside the United States without first obtaining the
     appropriate government approvals. [emphasis mine]

What this reads like to me is that you cannot distribute binary code produced
by the Sun compilers outside the U.S. without formal government approval. In
practice this should not have too much effect, since companies are required to
obtain this approval anyway, and PD code is generally made available in source
form (and often *only* source form for security reasons). But in principle it's
rather nasty.

For all I know this could be a federal law already anyway.
-- 
Ruth Milner                          NRAO/VLA                  Socorro NM
Computing Division Head      rmilner@zia.aoc.nrao.edu
Newsgroups: misc.legal