Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!rutgers!husc6!cca!mirror!rayssd!brunix!nancy!omh
From: omh@nancy (Owen M. Hartnett)
Newsgroups: comp.sys.mac
Subject: Re: MacApp Licensing Fee
Message-ID: <15309@brunix.UUCP>
Date: Thu, 7-May-87 20:54:26 EDT
Article-I.D.: brunix.15309
Posted: Thu May  7 20:54:26 1987
Date-Received: Sat, 9-May-87 18:01:11 EDT
References: <3113@sunybcs.UUCP> <174400030@uxc.cso.uiuc.edu> <727@apple.UUCP>
Sender: root@brunix.UUCP
Reply-To: omh@nancy.UUCP (Owen M. Hartnett)
Organization: Brown University Computer Science Dept.
Lines: 72

>
>We are now looking into this matter and hope to have a solution available
>soon.  In the meantime, I would like to point out the reason why there is
>a MacApp licensing fee.  It is not because we are greedy, since a fee of
>$100 per year per developer for an unlimited number of applications is not
>a way to get rich quick.  Rather, since MacApp is an important asset of
>Apple, and is only licensed to the developer (just like the system file
>and finder), there are legal requirements that we charge some kind of fee
>in order for the licensing arrangement to hold up (I'm not a legal expert,
>so any questions on this should be directed to Apple's licensing department).
>This is reminiscent of the old "For $1 and due consideration, etc." except
>that it's not $1.  In any case, we are not out to make money on MacApp and
>we are working on a solution for non-commercial applications.  Stay tuned.
>-- 
>David Goldsmith
>Apple Computer, Inc.
>MacApp Group
>

As a commercial developer, and a purchaser of MacApp, there is *no way*
I would ship a commercial package with MacApp because of its restrictive
"licensing" agreement.  First off, this is an old argument which forward
thinking companies like Aztec and Lightspeed have resolved in a 
perfectly rational manner: They don't demand a fee for the *products*
of their compiler.  True, MacApp is novel and it's object oriented
languages are currently in vogue but that's no excuse for these
restrictions and royalties.

However, this is mild compared to the "licensing agreement" which you are
required to submit.  You're giving Apple some pretty significant rights
over your product, including the power to cease distribution of your
product in the face of "incompatibility."  Imagine being required to pull
your products off the shelf while Apple figures out what to do.  They still
haven't decided how to handle electronic distribution of software.
Admittedly, the word "compatible" is vaguely defined earlier in the
agreement, but the word compatible has other meanings as well which, in
the hands of a good lawyer, could place your software in peril.

Some might feel that Apple is justified because a great deal of the object
code is generated from Apple written source code.  The same argument 
might be made of any compiler.  After all, what is a compiler?  A tool
to generate object code.  What is the only thing MacApp can be used for?
Generating object code.  Whether I can code:

	Put a scroll bar on that window.

or 	kWantHScrollBar
or	TrackControl(
or	$A968

the same thing happens.

Why does Apple require a license?  Obviously, to protect their user
interface from infringement.  But Apple already does this, by requiring
licenses for System and Finder, which are, of course, necessary to run
any MacApp program.  I submit that the legal requirements are overkill
and counterproductive to Apple's intention to provide an hospitable
programming environment.  I believe Apple is shooting itself in the
foot with this license.  

So, Apple, if you're rethinking your ideas about licensing MacApp,
why not open up the box?




Owen Hartnett
Brown University Computer Science

omh@cs.brown.edu.CSNET 
omh%cs.brown.edu@relay.cs.net-relay.ARPA
{ihnp4,allegra}!brunix!omh