I've been in this design game for a long time. The thought of royalties is
appealing
but probably not realistic for an electronic product.

Unlike a song, which is recorded ONCE and reproduced repeatedly without
being changed for 10-20 years, an electronic product is a constantly
evolving thing, like a young child growing up. Electronic products have a
short lifetime, and even then there will be constant revisions.

I still think the best way to get paid royalties is to supply the chips,
security link blown, at a price negotiated. Then, place the sources of all
revisions in a lawyer's safe, who, in the event of your untimely demise,
will sell the sources at a nominal price (or free).
But, Lord, I hate to deal with lawyers...

--Bob Axtell



At 06:02 PM 5/31/2003 -0700, you wrote:
>     Another possibility is to find a distributor that offers a device
>     programming service, or a third-party programmer. You set up a deal
>     whereby the programming house holds the code. The mfr places an order
>     for programmed parts with them at a price that includes your royalty,
>     which the programmer then sends to you.
>
>I'd love to hear if anyone finds such a service.  It seems pretty ideal
>for a number of reasons, but I've never heard of a service that can
>break out a royalty and send that profit elsewhere...  It potentially
>solves the "source code escrow" issue as well...  (OTOH, I doubt whether
>anyone wants to pay this third party as much as the service would cost
>to provide.)
>
>
>Speaking from the other side of things, having to track and pay per-box
>(or worse) royalties is a real PITA for a large company selling a
>diverse product set, with each device possibly containing multiple
>pieces of licensed software.  DEC charges (used to charge) a per-port
>royalty to companies who had licensed their LAT protocol, which doesn't
>sound bad until you realize that we were selling products that were
>expandable, and had (for instance) no way of telling whether the 16 port
>expansion card was going into a box that was supposed to contain LAT or
>not.  For that matter, we really didn't want to sell a separate version
>of software (it would have ended up being different versions) containing
>LAT just to enforce DECs royalty policy...  It was awful.  We did our
>best and sent DEC money periodicly, and they never seemed to get pissed
>off at us, but...  (It especially hurt because most of our competitors
>hadn't bother to license the protocol from DEC at all...)
>
>BillW
>
>--
>http://www.piclist.com hint: To leave the PICList
>mailto:piclist-unsubscribe-request@mitvma.mit.edu

--------------------------

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu