🚀 go-pugleaf

In article <4012@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>In article <2034@crdgw1.crd.ge.com> vita@daredevil.crd.ge.com (Mark F. 
>Vita) writes:
>
>> Well, if the fee is so <largely symbolic>, why not just get rid of it?
>
>I don't think it is purely symbolic. There is some legal reasons 
>behind it.

Ah, yes, the notoriously hyperactive Apple Legal Department rears its
ugly collective head again.  *Sigh*.  (Q: "What do you have when you
have 100 lawyers up to their necks in cement?"  A: "Not enough
cement.")

Well, "I'm no lawyer, but"... I do have a brother who is a musician
and who has dealt extensively with the Copyright Office with respect
to copyrighting songs.  As I recall, the key factor in preserving your
copyright is the inclusion of a copyright notice on all distributed
copies of the work in question, and not whether you charge any money
for them.  I mean, I've glanced over the guidelines a couple of times
myself, and nowhere do I recall seeing anything to the effect of: "In
order to retain your copyright, it will be necessary for you to gouge
people to the tune of $100 per year."  I mean, it's possible that I
skipped over that paragraph, but I don't think so.  :-)

>> development products.  But royalty fees on compilers are absolutely
>> inexcusable.  I mean, I've already paid for the product once; why
>
>I don't know the Lisp environment, but there are no royalties for using 
>MPW compilers.  Once you start shipping some of Apple's code (as with 
>MacApp), then there are licensing fees.  I would guess that shipping a 
>product with Macintosh Lisp results in shipping a significant amount of 
>Apple's code, hence the licensing fee.

Well, correct me if I'm wrong, but when I link a THINK C application,
I include a "significant amount" of Symantec's code (libraries and so
forth).  Why is that Apple finds it necessary to charge money to
preserve their copyright in this situation, but Symantec does not?
Are there some special, secret copyright laws I don't know about that
apply only to Apple?

Another analogous situation: SuperCard.  As I understand it,
"compiled" SuperCard projects can be distributed royalty-free.  I'm
sure that these compiled SuperCard stacks contain a LOT of Silicon
Beach's code.  But SB doesn't charge royalties.  What gives?

Maybe your lawyers should consider switching to a decaffeinated brand. :-)

>> this swell new technology, right?  Wrong; instead they charge a
>> $100/yr royalty fee for developing with MacApp.  Why?  I don't have to
>> pay $100/yr to make Toolbox calls.  Why should I have to pay $100/yr
>> to use MacApp?  
>
>You don't distribute the Toolbox code with your application.  You do 
>distribute the MacApp code.
 
True enough, but not really relevant to the point I'm trying to get
at.  

To the developer, it's a non-issue as to whether any of Apple's code
is included when they distribute an application.  Developers just want
to make calls to standard development libraries, and for the most
part, they don't care whether the code they're calling happens to
exist in ROM or on disk.  It isn't the developer's fault that MacApp
is not in ROM.  Apple should not be forcing them to possibly choose a
less optimal development environment on the basis of this distinction.

Developers want something that makes developing applications for the
Mac easier, faster, less error-prone.  This is exactly what MacApp is
for, and if Apple was smart, they'd be bending over backwards to get
developers to use it.  Happy developers == more quality applications
for the Mac == greater perceived utility for the consumer == increased
market share for Apple == increased $$$ for Apple.  By "bending over
backwards", I mean finding a way to let them use MacApp without
imposing any additional financial burden, and not hassling people over
petty issues such as whether any of "their code" is being included.
Shabby licensing fees and overpriced compilers just don't cut it.

Sure, $100/yr doesn't sound like a lot, but for many people (myself
included), it's the Principle of the Thing.  Recently I had a
situation for which something like MacApp would have been a great
help.  I eventually decided to go with Paul DuBois' excellent (and
*free*) TransSkel package instead.  Not that I necessarily wanted to
distribute the application commercially, but in the event that maybe I
did someday, I decided that I would rather not have this legal and
financial entanglement hanging over my head.

Surely you see how these licensing fees create disincentive, and how
this disincentive is bad for Apple in the long run.  Other companies
with far fewer financial resources than Apple manage to get along just
fine without licensing fees.  If Apple really had the desire, they
could get by without them too.

>You don't have to pay any fee unless you distribute an application.  The 
>$100 fee is for commercial applications.  Presumably if you sell 
>applications for a living you can afford a licensing fee.  

I don't think charging for these kinds of things is justified by
people's ability to pay.  I mean, presumably if I am selling
applications for a living, I could afford to pay $500 for System
Software upgrades.  Does this mean that Apple should start charging
$500 for system upgrades?  Of course not.

>> Apple should not be running their development services as a profit
>> center.  It's quite apparent that they are doing just that (the recent
>
>If you think these licensing fees make a profit, then you are mistaken.

Hmm, let's think about this statement for a minute.  Presumably, lots
(dozens? hundreds?) of people are sending Apple checks for $100, and
Apple is cashing them, and somehow Apple is managing not to make any
money on the deal.  Gee, you must have a lot of overhead there at
Apple. :-)  But seriously, where is Apple's cost in this transaction?

Anyways, what I actually said was that Apple should not be trying to
make money off their development services as a whole (not just
licensing fees).  Since you were careful not to deny this, and I am
trying to win this argument :-), I will take this as an admission that
the converse is in fact true: i.e., Apple does indeed make a profit
from their development services.  Herein lies the crux of the
argument.  I argue that such a policy, while it may make perfect
fiscal sense to a lot of myopic bean counters at Apple, in the long
run, is bad for the Macintosh and thus bad for Apple.  Apple should
concentrate on selling boxes, which is where the real money is, and
supply the support software which adds value to the machine at their
cost.  In this latter category I would put both system software and
development tools/services.  Apple has a commendable policy with
respect to the first item, and a mixed record on the second: they give
some things away from free (i.e. ResEdit, tech notes), but gouge for
other things (i.e., MPW shell/compilers, MacApp, ACL).

My fear is that Apple will shoot itself in the foot by pricing the
small developer out of the market.  In my opinion, the small developer
is where most of the nifty innovations come from.  If Apple squeezes
the little guy out, only the big, boring players will be left, and the
Macintosh will suffer as a result.  Would you really like to see the
Mac market left to clumsy, lumbering behemoths like Microsoft and
Ashton-Tate, companies for whom feeble efforts like Excel 2.2
represent "innovation"?  Not me.

Case in point: look at Nisus, a product from a relatively small
developer.  Microsoft has been hacking on Word for five or six years,
and these guys at Paragon come along one day and just blow it out of
the water.  Amazing.  We need more people like this.  We aren't going
to get them if they have to cough up $250 for a shell.

It just makes good business sense for Apple to make Macintosh
development as easy and as cheap as possible.  The benefits of such a
policy might not be as tangible as a check for $100, but they are just
as real, and much more significant over the long haul.

>Larry Rosenstein, Apple Computer, Inc.
>Object Specialist


----
Mark Vita                              vita@crd.ge.com
General Electric CRD               	..!uunet!crd.ge.com!vita
Schenectady, NY