Hardware Based IP Protection

On 9/27/2022 1:51 PM, Don Y wrote:
> On 9/26/2022 1:09 PM, Ricky wrote:
>> A customer wants me to redesign a board to eliminate the production
>> bottlenecks.  They also want all IP so they can make the boards 
>> themselves
>> if my company is unable to.  I'm fine with that, but I'd like to have 
>> some
>> means of assurance they won't make boards without my royalty being
>> respected.
>>
>> The board has an FPGA which contains the "magic", an analog path, and a
>> digital path to the outside world.  The digital path needs a 3.3V/5V
>> interface.  There are two opamps that serve as filters with gain.  
>> There is
>> a need for several (3-4) LDOs.
>>
>> I've found a couple of chips from Greenpaks that could help here.  One 
>> is a
>> "Programmable Mixed-Signal Matrix" which could replace the opamps and
>> provide a configurable gain using the programmable "rheostat".  
>> Another has
>> four LDOs which would be useful and *might* be able to serve as the level
>> shifter.
>>
>> I'm waiting to hear back from someone from Renesas, who can discuss this
>> with me, or a disti FAE.  There are a lot of questions about how to turn
>> these into a custom part number to meet my needs.
>>
>> Anyone have experience with using these in production?
> 
> If you must share your IP -- *all* of your IP -- then there's little
> you can really do.  I've seen customers "steal" fully disclosed
> designs (industrial applications) without batting an eyelash -- pay
> for system #1 and reproduce it, exactly, multiple times thereafter
> (saving a few hundred kilobucks each time).

Right. If the customer wants *all* your IP then it seems better to 
charge appropriately up-front than to worry about royalties.

Sort of like if your girlfriend or wife tells you "I'm going to be going 
out for a bit with Larry from the office next door on Fridays. Just a 
friendly sort of thing, I'm not interested in him romantically. But he's 
just very handsome, funny, and rich, too!"

You can hope for the best, but probably best to assume the worst

On 9/28/2022 3:00 AM, bitrex wrote:
> On 9/27/2022 1:51 PM, Don Y wrote:
>> On 9/26/2022 1:09 PM, Ricky wrote:
>>> A customer wants me to redesign a board to eliminate the production
>>> bottlenecks.  They also want all IP so they can make the boards themselves
>>> if my company is unable to.  I'm fine with that, but I'd like to have some
>>> means of assurance they won't make boards without my royalty being
>>> respected.
>>>
>>> The board has an FPGA which contains the "magic", an analog path, and a
>>> digital path to the outside world.  The digital path needs a 3.3V/5V
>>> interface.  There are two opamps that serve as filters with gain. There is
>>> a need for several (3-4) LDOs.
>>>
>>> I've found a couple of chips from Greenpaks that could help here.  One is a
>>> "Programmable Mixed-Signal Matrix" which could replace the opamps and
>>> provide a configurable gain using the programmable "rheostat". Another has
>>> four LDOs which would be useful and *might* be able to serve as the level
>>> shifter.
>>>
>>> I'm waiting to hear back from someone from Renesas, who can discuss this
>>> with me, or a disti FAE.  There are a lot of questions about how to turn
>>> these into a custom part number to meet my needs.
>>>
>>> Anyone have experience with using these in production?
>>
>> If you must share your IP -- *all* of your IP -- then there's little
>> you can really do.  I've seen customers "steal" fully disclosed
>> designs (industrial applications) without batting an eyelash -- pay
>> for system #1 and reproduce it, exactly, multiple times thereafter
>> (saving a few hundred kilobucks each time).
> 
> Right. If the customer wants *all* your IP then it seems better to charge 
> appropriately up-front than to worry about royalties.

There are some markets where this isn't possible; where you *must*
disclose a design in its entirety (e.g., regulated industries).
Or, where some assurances must exist of continued availability
of the design documents even in the face of your (or your company's)
demise.

But, usually, the customers there aren't interested in going into
the equipment business against you.  Rather, their interests lie
elsewhere... USING your equipment to achieve some other goal
in which they are expert.

If you are designing a product for *them* to peddle (as opposed to
designing a product for them to *use*), then they need to be able
to support it.

I give non-exclusive license to customers so I don't lock myself
out of my own work.  E.g., I'd hate to have to reinvent every design
just to ensure I don't step on some portion of a design I've done for
a previous client.  They have to trust me not to reproduce "their"
product for someone else (which would be pretty unlikely, esp in
light of below).  If they object, I ask them if they want me to reinvent
everything I may have done for PRIOR clients before incorporating it
into *their* design?  (do they want to make the project artificially
more complex, costly and time-consuming?  Ah, I thought not!)

I'm not keen on "ongoing relationships" with clients.  I give them a hold
over me in the event of a *flaw* in my design/implementation.  But, ONLY so.
No, I'm not interested in making endless changes to the product for you.
Or, coming up with version 2 (god, what a colossal bore that would be!).
Or, possibly working on some similar product -- I'm off learning something
(technology or skillset) entirely new, and exciting!  THEY chose to plant
their feet in a particular market; there's no reason for me to follow
along!

If you *think* you've found a discrepancy between the specification and
my implementation, I will try to reproduce it using *my* codebase (no,
I'm not going to hope that the code you give me is truly *as designed*
without the "benefit" of your subsequent modifications) on *my* prototype.
If I can't reproduce it -- but can, readily, on YOUR (current) hardware
and (current) software, then it seems reasonable to assume it's YOUR
problem -- and, no, I'm not interested in helping you find it.  That's
a job for your employees!  "Shit work".  THEY created the problem
(cuz it doesn't exist in my release) so let THEM find/fix it!

[This is why waterfall is so "enabling", for me -- we KNOW what the
product/project is supposed to do; it's not an perpetual evolution
of ideas!  It also gives spec writing a lot of leverage in your
"long term commitment":  "Gee, that behavior was not specified
and, as such, left to the discretion of the Developer!  APPARENTLY,
I *chose* to make all the lights flash and smoke billow out of the
vents!"  :>  ]

So, I don't want a hook into them anymore than I'd give them a hook into
me!  "Let's each move on"  Hopefully, you'll make a shitload of money
on the product and speak well of me to others (when asked *or* without
prompting)

The OP is learning the downside of continued reliance on a contractual
relationship for payment.  I just make sure their final check clears and
wish them all the success in the world -- or not.  "Not my problem" as
I don't want to rely on their ability to market, their assessment of
what the market really wants/needs, the efforts of their competitors,
etc.

[I actually had this discussion with a close friend/fellow engineer
many many years ago.  "Don't you want your customers to succeed?"
"Sure!  But, that's not MY problem.  Ensuring their success would place
too much responsibility on me to ensure ALL aspects of their business
were 'fit'.  I'll do my best to give them the best *product* that
I can but it's easy for them to f*ck that up with bad policies,
pricing, execution, maintenance/updates, support, marketing, etc."]

> Sort of like if your girlfriend or wife tells you "I'm going to be going out 
> for a bit with Larry from the office next door on Fridays. Just a friendly sort 
> of thing, I'm not interested in him romantically. But he's just very handsome, 
> funny, and rich, too!"
> 
> You can hope for the best, but probably best to assume the worst

Perhaps not that dark.

I *expect* people to alter, evolve, etc. my design AFTER I am "done".
I suspect they will learn -- from their market -- of changes and
additions that would make THEIR product more marketable, etc.  So,
I wouldn't expect to find *my* implementation in production, later.

This is especially true of proof-of-concept projects where the
goal wasn't to produce a saleable product but, rather, demonstrate
that a technology was practical and how it could be exploited.
SOMEONE ELSE will figure out how to package it, *after* me.

I don't want to be in a position where I'm hounding a client over
their use/misuse of a past work ("Hey, you have to pay me if you
want to use that code in a different product's design!"  Note that
things like RTOSs and custom I/O subsystems can have great "repeat
use appeal") -- or, an accounting of how many units they've built!

Just like I don't want them hounding me for yet-another-change to
the product/project.

"Live long and prosper"!

On Monday, 26 September 2022 at 22:09:16 UTC+2, Ricky wrote:
> A customer wants me to redesign a board to eliminate the production bottlenecks. They also want all IP so they can make the boards themselves if my company is unable to. I'm fine with that, but I'd like to have some means of assurance they won't make boards without my royalty being respected. 
> 
> The board has an FPGA which contains the "magic", an analog path, and a digital path to the outside world. The digital path needs a 3.3V/5V interface. There are two opamps that serve as filters with gain. There is a need for several (3-4) LDOs. 
> 
> I've found a couple of chips from Greenpaks that could help here. One is a "Programmable Mixed-Signal Matrix" which could replace the opamps and provide a configurable gain using the programmable "rheostat". Another has four LDOs which would be useful and *might* be able to serve as the level shifter. 
> 
> I'm waiting to hear back from someone from Renesas, who can discuss this with me, or a disti FAE. There are a lot of questions about how to turn these into a custom part number to meet my needs. 
> 
> Anyone have experience with using these in production? 
> 
> -- 
> 
> Rick C. 
> 
It's pretty easy.
Just implement individual Activation Code for every board, to be generated by your server to get count of boards manufactured and activated.

On 9/28/2022 1:01 AM, Martin Brown wrote:

[attrs elided]

>> If you want to ensure 'N' is an accurate assessment of their
>> "usage of your design" (royalty), then you need to be a gatekeeper
>> for something that is related to N, in some way.
> 
> One of the simple ways is a single unreadable programmable component that you 
> retain control of and supply one per unit made. Once you share your secrets 
> with a third party they can clone the thing as they wish.

Yes.  Dallas (?) made some "unique 1-wire coins" that had individual codes
that you could recognize in software -- with a suitable polynomial.  This
allowed you to ship a coin as an activation token for your product.  Or,
as a REactivation token (e.g., for timed licensing)

I install encryption keys *after* the manufacturing test code has been
used to verify the device's proper operation.  So, I can farm out
production and never divulge any of my codebase to the manufacturer
"Feel free to copy my design!   Sell your units at half of the price I
charge for the genuine article!  Sadly, my code won't run on YOUR copies!"
(your customers may not yet know it but soon will!  "I'm sorry, but I don't
have a record of your purchase so why do you expect me to support you?
Contact the vendor from which you purchased your unit for support...")

But, if they can read the source code, then they can *see* what you are doing.
if they want to eliminate that (artificial) dependency ("to cheat you"), they
can easily do so.

OTOH, if the project is big and you were wise enough NOT to have a
*module* called "Activation" but, rather, distributed the code to
perform this task throughout the codebase, "innocuously", ferreting
out all such instances WITHOUT damaging "real code" can become a
significant task -- because they don't know where to look or what
to look *for*!

Will they notice that object foo and object bar overlap -- defined
during the *link* stage?  (so, no explicit reference to this fact
in the sources)  Will they remember that memftnA() handles overlapping
objects in one particular way while memftnB() behaves differently?
(e.g., memcpy vs memmove).  Or, will they gloss over those little
details because they THINK they know more than they really do! And,
in the process, miss a data relationship you've deliberately
encoded into the product?

> The other is require an activation code that only you can supply for each unit. 
> I have often done that for bespoke software. How sophisticated it needs to be 
> depends on the size of the market and the level of attack you anticipate being 
> levelled against it.

The true challenge is doing this when "everything" is disclosed.  I.e.,
when someone can read the code that checks the token and see how
validity is confirmed.  They can just bypass this check and defeat
the reliance on that code.

You can build a service into your "system" and require the device to
provide a credential in order to access that service.  But, same
problem.  And, how do you deter cloning of a "legitimate unit"
(watch to make sure two of the "same" unit never accesses the service
multiple times, concurrently?)

ISTR Sun used to broadcast queries on a high-numbered port to
try to identify other local nodes that might be sharing a
license, "illegally".

> It seems that someone has cracked the MS Office keys.

I thought most license hacking was being done by sharing
"known good" keys *or* patching binaries to disable the
validation tests.  (of course, the latter can be made
very difficult without access to sources)

[I'm surprised if MSOffice is still in use!  SWMBO has
been using Office 2K for... 20 years!  :> ]

> Even bespoke chips offer only limited protection against those with very deep 
> pockets. Cameca ion probes can be used to read back a chip mask set layer by 
> layer if you are determined and have deep enough pockets.

It used to be that you could just obfuscate the devices being used.
But, undergrads at local universities can now take photomicrographs
of die and identify manufacturer markings that way.  The equipment
is already in place along with folks skilled in the techniques.
"Have your *kid* do it..."

Yawn.

We used to (re: the video game competitor across town) come up with
"clever" ways of packaging the MPU or other key components to
discourage folks from seeing what was inside (via xray, solvent, etc.)
Burying BBRAM with factory loaded "keys" in a potted module.
Embedding "wires" that *looked* like they connected X to Y.  Embedding
plastic conductors that would dissolve with attacks on the encapsulant.
Etc.

But, you can beat most of these with a little patience.  Esp if your
(e.g., counterfeiting) business depends on doing so!  And, esp if
your adversary relies on a single solution for all his protection
needs!

The full custom raised the bar considerably.  It was a relatively
common practice; you'd be at a design center and notice other
competing firms in the next cubby.  (Express an interest in their
work -- just not TOO much interest!)

If you were smart/strategic, you made the custom DO something
beyond just deterring counterfeiting.

E.g., Atari (?) had a vector-graphics processor that only drew
*arcs* (no straight line segments).  This was REALLY difficult to
do with more traditional hardware.  (imagine drawing each digit
of each player's score using curved lines: 1, 7, 4, etc. along
with everything else on the screen!)

But, beyond novelty, you have to work to find a NEED for that
capability!

OTOH, having the ability to scale and rotate objects in real-time
opens doors that are similarly challenging yet represent real value!

> I used to know a firm in Silicon valley that specialised in it. We supplied MS 
> kit to them and sometimes shared software components.

There was an Aussie firm that specialized in reverse engineering
around the video game heyday.

But, for things like video games, you typically only had to reverse
engineer a couple of games to extract the core hardware systems
that were reused over and over.  And, if copying the software was
just a matter of dumping some ROMs, *you* could offer a "universal
kit" to unscrupulous "operators" with deep pockets but short arms.

"Here's some artwork/decals for the UNIVERSAL cabinet and here are
the ROMs for the new game!"

How do you, as a legitimate developer/manufacturer, compete
with that -- esp when it's YOUR IP that they are peddling?!

>> When I was doing video games, we designed a custom BLTer.
>> This added a lot of value to the product so made sense
>> from THAT financial aspect.  It did double duty at preventing
>> counterfeiters from STEALING our game designs (a very common
>> practice to see your game in a semi-generic cabinet with
>> just enough of the software changed so that it announces itself
>> as "SomeOther Game").
> 
> The other bespoke trick is to include code that exploits a known defect or 
> quirk in the target hardware platform so that any attempt to change it will 
> result in performance problems or non-functionality.

Exactly.  But, you're relying on the adversary not knowing about this.
Hence my "school boy" comment, up-thread.  They can *look* at the design
(hardware and software) and THINK they understand it.  They then make
minor changes (to add their functionality or disguise their theft) and
wonder why it suddenly doesn't work anymore!

Again, in video games (the most common place I encountered these
mechanisms), you'd do things like "draw" the game's name on the screen.
This would end up leaving the equivalent of "the drawing cursor"
(a purely invisible software construct) pointing to a particular
spot in display memory.  10,000 opcode fetches later, you could
casually verify that it was at the expected place.  The thinking being
that a counterfeiter would change the text being "drawn" which would
have the side effect of leaving the cursor somewhere *else*.  Ooops!
All those opcode fetches later, the drawing event is ancient history.

The trick to all such schemes is to never have a line of code that says:
     if (!everything_ok())
          crash();
because it becomes a behavioral marker for folks to determine when they
have successfully "beaten" your scheme.  Instead, you factor the test
into your normal behavior:
     result = intfunction() + everything_ok()
     result1 = activity1(result)
     activity9()
     result2 = activity2(result1)
     etc.
with the expectation that everything_ok() will yield a specific
value "normally".  If the incorrect value of everything_ok()
results in a minor change in behavior (e.g., the player's character's
speed increases a bit more than expected or the direction of a
projectile doesn't accurately represent a pure reflection off a
surface), then the player (who is initially the counterfeiter
checking his work) doesn't notice it.  Until these effects compound
and leave the player angry because "the machine cheated" (or
crashed).

But, WHEN did the effects first manifest?

You can do this by quietly leaving the CY in a particular state and
(also quietly) relying on that fact some number of opcode fetches
(or subroutine calls) later.  Or, some operation partially completed
(e.g., knowing when task switches will occur and peeking inside
a partially completed operation to use a "half baked" value -- despite
this being the sort of behavior one is taught NOT to do!)

> I recall one based on the timing difference of TEST vs AND on x86 and another 
> based on a page zero exploit on the 6502. Deliberately designing in a race 
> condition vulnerability for any cloners to fail on. One of them was entirely 
> accidental but proved incredibly effective!

I've used schemes like relying on bus capacitance to "hold" a value
for a specific number of machine cycles so any alterations to
the value being held or the code executed between points A and B
would result in "incorrect data" being present on the (floating) bus.
"Load" the bus differently and all bets are off.

With a distributed system -- or any multiprocessor -- there are lots of
opportunities to hide "information" in the interactions between them
by exploiting temporal relationships that you can "fail to document"
(and identifying them from an examination of the code is painful).

The problem with all such schemes is that they add cost to the development
cycle (and possibly material costs and/or performance hits).  Ideally,
you want to add *capabilities* to a design while you are protecting it.
So, your "cost" results in gains and not just "overhead".

When it came time to "install" the JapZappers (coding hacks designed
to complicate counterfeiting by running continuous checksums over
the code and injecting the results of their computations into the
code's actions, as above), you had to be extra careful because
the lack of a go/nogo "everything_ok()" test  meant you could never
reassure yourself that you had done this correctly.  YOU were a victim of
the same stealth that you were using to make the counterfeiter's
verification of his hack impossible!

Putting these sorts of things in place to trip up a *partner*
is doubly difficult because, in theory, you are working together
and aren't on the lookout for such subterfuge.  But, as devices
get increasingly complex (complex:  too big to fit in a single
brain), it gets easier to do so -- esp against "average" engineers
(who may be trusting as well as lacking in detailed observation
skills)

It's actually a delightfully challenging mindset!  One that many
folks are incapable of adapting "with gusto".

E.g., I don't share my baking recipes.  Well, I *appear* to but always
omit certain critical details that have a big impact on the resulting
product.  I've spent decades (literally hundred of iterations)
"perfecting" some of them and the idea of just giving away all of that
effort/experience doesn't sit well with me (I'll bake something FOR
you but I'm not going to teach you how to reproduce my efforts!
I'll show you how to make something *close*, but it will always be
a disappointment when you consult your memory of my version!  :> ).

I have become *so* good at hiding details that colleagues wives
will ask to WATCH me bake something during an offsite, "there"
or here.  ("Yours always tastes so much better than when *I* make
it!") and fail to notice the critical bits, beyond "ingredients".
Despite watching me measure ingredients, checking the temperature
of the oven, timing the bake, etc.

"Ah, but did you notice WHICH eggs I pulled out of the egg carton?
Don't they all *look* the same?  And, when I removed the chalazae,
did you notice how much of the yolk/whites I removed (as a side-effect)
in the process?

Did you notice the cavalier manner in which I measured certain ingredients
(when did I use a level teaspoon vs. a heaping one?)  Which were cold
vs. room temperature?  How much I let certain things thaw (while you
thought I was just "busy doing something else")?

Did you notice how long I let the mix sit at certain points, while I
appeared to be busy fetching other ingredients out of the refrigerator?
(The chemistry continues despite my apparent lack of interest.)  Or,
which rack I placed the items on?  Or, how large the portions?  Did you
happen to note how humid it was on that day?  Or, the temperature in the
house as I was letting them cool?

"Gee, these taste really good!  Now I *know* how you make them"
(yes, *exactly* as I told you -- cuz you've missed all of these
other undocumented details and will continue to miss them when
you next attempt to reproduce what you've observed!  But, you'll
get frustrated and won't ask to watch me a second time!  :> )

On 9/28/2022 7:49 AM, Don Y wrote:
> On 9/28/2022 3:00 AM, bitrex wrote:
>> On 9/27/2022 1:51 PM, Don Y wrote:
>>> On 9/26/2022 1:09 PM, Ricky wrote:
>>>> A customer wants me to redesign a board to eliminate the production
>>>> bottlenecks.  They also want all IP so they can make the boards 
>>>> themselves
>>>> if my company is unable to.  I'm fine with that, but I'd like to 
>>>> have some
>>>> means of assurance they won't make boards without my royalty being
>>>> respected.
>>>>
>>>> The board has an FPGA which contains the "magic", an analog path, and a
>>>> digital path to the outside world.  The digital path needs a 3.3V/5V
>>>> interface.  There are two opamps that serve as filters with gain. 
>>>> There is
>>>> a need for several (3-4) LDOs.
>>>>
>>>> I've found a couple of chips from Greenpaks that could help here.  
>>>> One is a
>>>> "Programmable Mixed-Signal Matrix" which could replace the opamps and
>>>> provide a configurable gain using the programmable "rheostat". 
>>>> Another has
>>>> four LDOs which would be useful and *might* be able to serve as the 
>>>> level
>>>> shifter.
>>>>
>>>> I'm waiting to hear back from someone from Renesas, who can discuss 
>>>> this
>>>> with me, or a disti FAE.  There are a lot of questions about how to 
>>>> turn
>>>> these into a custom part number to meet my needs.
>>>>
>>>> Anyone have experience with using these in production?
>>>
>>> If you must share your IP -- *all* of your IP -- then there's little
>>> you can really do.  I've seen customers "steal" fully disclosed
>>> designs (industrial applications) without batting an eyelash -- pay
>>> for system #1 and reproduce it, exactly, multiple times thereafter
>>> (saving a few hundred kilobucks each time).
>>
>> Right. If the customer wants *all* your IP then it seems better to 
>> charge appropriately up-front than to worry about royalties.
> 
> There are some markets where this isn't possible; where you *must*
> disclose a design in its entirety (e.g., regulated industries).
> Or, where some assurances must exist of continued availability
> of the design documents even in the face of your (or your company's)
> demise.
> 
> But, usually, the customers there aren't interested in going into
> the equipment business against you.  Rather, their interests lie
> elsewhere... USING your equipment to achieve some other goal
> in which they are expert.
> 
> If you are designing a product for *them* to peddle (as opposed to
> designing a product for them to *use*), then they need to be able
> to support it.
> 
> I give non-exclusive license to customers so I don't lock myself
> out of my own work.  E.g., I'd hate to have to reinvent every design
> just to ensure I don't step on some portion of a design I've done for
> a previous client.  They have to trust me not to reproduce "their"
> product for someone else (which would be pretty unlikely, esp in
> light of below).  If they object, I ask them if they want me to reinvent
> everything I may have done for PRIOR clients before incorporating it
> into *their* design?  (do they want to make the project artificially
> more complex, costly and time-consuming?  Ah, I thought not!)


Most of the projects I've worked on in my (relatively short with respect 
to design, I worked in the music biz for most of my 20s and early 30s) 
career have been fairly simple ones that I've felt comfortable enough 
saying "Pay me the agreed price and the design is yours to do with as 
you will" and handing off. It's the terms a number of clients tend to 
prefer, I charge them one-time-big-price and they seem comfortable with 
that.

But I'm starting to encounter situations with more complicated projects 
that as you say, incorporate significant building blocks I've used 
before, where I don't want to give away the farm.

Do you have a set of contracts you use for different situations? I 
should probably consult a contract lawyer to draw something better up 
than what I've been using.

onsdag den 28. september 2022 kl. 14.01.10 UTC+2 skrev a a:
> On Monday, 26 September 2022 at 22:09:16 UTC+2, Ricky wrote: 
> > A customer wants me to redesign a board to eliminate the production bottlenecks. They also want all IP so they can make the boards themselves if my company is unable to. I'm fine with that, but I'd like to have some means of assurance they won't make boards without my royalty being respected. 
> > 
> > The board has an FPGA which contains the "magic", an analog path, and a digital path to the outside world. The digital path needs a 3.3V/5V interface. There are two opamps that serve as filters with gain. There is a need for several (3-4) LDOs. 
> > 
> > I've found a couple of chips from Greenpaks that could help here. One is a "Programmable Mixed-Signal Matrix" which could replace the opamps and provide a configurable gain using the programmable "rheostat". Another has four LDOs which would be useful and *might* be able to serve as the level shifter. 
> > 
> > I'm waiting to hear back from someone from Renesas, who can discuss this with me, or a disti FAE. There are a lot of questions about how to turn these into a custom part number to meet my needs. 
> > 
> > Anyone have experience with using these in production? 
> > 
> > -- 
> > 
> > Rick C. 
> >
> It's pretty easy. 
> Just implement individual Activation Code for every board, to be generated by your server to get count of boards manufactured and activated.

when say it is easy you obviously never did anything like it....

they have the source so they can just remove any "activation" checks

On 9/28/2022 7:25 AM, bitrex wrote:

> Most of the projects I've worked on in my (relatively short with respect to 
> design, I worked in the music biz for most of my 20s and early 30s) career have 
> been fairly simple ones that I've felt comfortable enough saying "Pay me the 
> agreed price and the design is yours to do with as you will" and handing off. 
> It's the terms a number of clients tend to prefer, I charge them 
> one-time-big-price and they seem comfortable with that.

I think it's easier.  You charge enough to make it worth your while.
THEY know what it will cost them.  If they go on to make big money
on the product, so be it.  They'll have been happy to have worked with
you.  If the product flops, its hard for them to rationalize that they
paid you too much (they knew the price, up front).

I like fixed cost contracts and not time-and-materials.  It lets me plan
WHEN a project will be over.  And, I've heard too many gripes from clients
about other experiences where the project just dragged on and on (and
cost more and more!).

Sure, it can drag on and on because the client couldn't make up
his mind as to what he wanted.  But, the consultant should have
some discipline to *focus* the client else it sure looks like the
consultant is *bleeding* the client.

> But I'm starting to encounter situations with more complicated projects that as 
> you say, incorporate significant building blocks I've used before, where I 
> don't want to give away the farm.
> 
> Do you have a set of contracts you use for different situations? I should 
> probably consult a contract lawyer to draw something better up than what I've 
> been using.

My contracts are simple:  a list of deliverables (schematics, number of
prototypes -- I get to keep one, specification, source code -- if any,
test/acceptance criteria), a license to use the design elements,
a hook to ensure I will "promptly" repair any defects in the design
identified after sign off, indemnification against any patent/license
infringement that may occur, payment amount and schedule, client
will purchase and own any tools *I* deem necessary for me to perform
that work, etc.

If I am being asked to reverse engineer something, I make the client
assert his ownership of the technology that I'm being asked to
reverse engineer.

Not a lot of flowery language but, rather, more of a bulleted list.
I don't think reading a contract should be difficult and require
lots of nitpicking over what something "really" means.  I've not
found any client lawyer who objected to anything enough to throw
a monkey wrench in the deal.

I'm usually dealing with technical people and their focus is
on getting the job done, not wasting time hashing and rehashing
documents (cuz that takes time and costs money, even if you don't
see a figure associated with it).  Make this look too much like a
*job* and I'm likely to "no bid" and find something else to do!

On Wednesday, 28 September 2022 at 17:39:37 UTC+2, lang...@fonz.dk wrote:
> onsdag den 28. september 2022 kl. 14.01.10 UTC+2 skrev a a: 
> > On Monday, 26 September 2022 at 22:09:16 UTC+2, Ricky wrote: 
> > > A customer wants me to redesign a board to eliminate the production bottlenecks. They also want all IP so they can make the boards themselves if my company is unable to. I'm fine with that, but I'd like to have some means of assurance they won't make boards without my royalty being respected. 
> > > 
> > > The board has an FPGA which contains the "magic", an analog path, and a digital path to the outside world. The digital path needs a 3.3V/5V interface. There are two opamps that serve as filters with gain. There is a need for several (3-4) LDOs. 
> > > 
> > > I've found a couple of chips from Greenpaks that could help here. One is a "Programmable Mixed-Signal Matrix" which could replace the opamps and provide a configurable gain using the programmable "rheostat". Another has four LDOs which would be useful and *might* be able to serve as the level shifter. 
> > > 
> > > I'm waiting to hear back from someone from Renesas, who can discuss this with me, or a disti FAE. There are a lot of questions about how to turn these into a custom part number to meet my needs. 
> > > 
> > > Anyone have experience with using these in production? 
> > > 
> > > -- 
> > > 
> > > Rick C. 
> > > 
--It's pretty easy. 
--Just implement individual Activation Code for every board, to be generated by your server to get count of boards --manufactured and activated.
---when say it is easy you obviously never did anything like it.... 

> they have the source so they can just remove any "activation" checks
in theory you are right but in practice, not exactly.
Implementing private - public key pair is easy
implementing one time activation codes is easy
implementing one-way input bus only hardware is easy

.../ .... / ...
learn how Speedport Hybrid LTE DSL router by Deutsche Telekom is hard/software locked to local APN of the customer

onsdag den 28. september 2022 kl. 19.47.52 UTC+2 skrev a a:
> On Wednesday, 28 September 2022 at 17:39:37 UTC+2, lang...@fonz.dk wrote: 
> > onsdag den 28. september 2022 kl. 14.01.10 UTC+2 skrev a a: 
> > > On Monday, 26 September 2022 at 22:09:16 UTC+2, Ricky wrote: 
> > > > A customer wants me to redesign a board to eliminate the production bottlenecks. They also want all IP so they can make the boards themselves if my company is unable to. I'm fine with that, but I'd like to have some means of assurance they won't make boards without my royalty being respected. 
> > > > 
> > > > The board has an FPGA which contains the "magic", an analog path, and a digital path to the outside world. The digital path needs a 3.3V/5V interface. There are two opamps that serve as filters with gain. There is a need for several (3-4) LDOs. 
> > > > 
> > > > I've found a couple of chips from Greenpaks that could help here. One is a "Programmable Mixed-Signal Matrix" which could replace the opamps and provide a configurable gain using the programmable "rheostat". Another has four LDOs which would be useful and *might* be able to serve as the level shifter. 
> > > > 
> > > > I'm waiting to hear back from someone from Renesas, who can discuss this with me, or a disti FAE. There are a lot of questions about how to turn these into a custom part number to meet my needs. 
> > > > 
> > > > Anyone have experience with using these in production? 
> > > > 
> > > > -- 
> > > > 
> > > > Rick C. 
> > > >
> --It's pretty easy. 
> --Just implement individual Activation Code for every board, to be generated by your server to get count of boards --manufactured and activated. 
> ---when say it is easy you obviously never did anything like it....
> > they have the source so they can just remove any "activation" checks
> in theory you are right but in practice, not exactly. 
> Implementing private - public key pair is easy 
> implementing one time activation codes is easy 
> implementing one-way input bus only hardware is easy 

and neither of those does anything because they have the source and can easily remove any checks

> .../ .... / ... 
> learn how Speedport Hybrid LTE DSL router by Deutsche Telekom is hard/software locked to local APN of the customer

customers don't have the source so they can't remove the lock and it is permanently connected to the internet so can be remotely disabled 

On Wednesday, 28 September 2022 at 20:35:24 UTC+2, lang...@fonz.dk wrote:
> onsdag den 28. september 2022 kl. 19.47.52 UTC+2 skrev a a: 
> > On Wednesday, 28 September 2022 at 17:39:37 UTC+2, lang...@fonz.dk wrote: 
> > > onsdag den 28. september 2022 kl. 14.01.10 UTC+2 skrev a a: 
> > > > On Monday, 26 September 2022 at 22:09:16 UTC+2, Ricky wrote: 
> > > > > A customer wants me to redesign a board to eliminate the production bottlenecks. They also want all IP so they can make the boards themselves if my company is unable to. I'm fine with that, but I'd like to have some means of assurance they won't make boards without my royalty being respected. 
> > > > > 
> > > > > The board has an FPGA which contains the "magic", an analog path, and a digital path to the outside world. The digital path needs a 3.3V/5V interface. There are two opamps that serve as filters with gain. There is a need for several (3-4) LDOs. 
> > > > > 
> > > > > I've found a couple of chips from Greenpaks that could help here. One is a "Programmable Mixed-Signal Matrix" which could replace the opamps and provide a configurable gain using the programmable "rheostat". Another has four LDOs which would be useful and *might* be able to serve as the level shifter. 
> > > > > 
> > > > > I'm waiting to hear back from someone from Renesas, who can discuss this with me, or a disti FAE. There are a lot of questions about how to turn these into a custom part number to meet my needs. 
> > > > > 
> > > > > Anyone have experience with using these in production? 
> > > > > 
> > > > > -- 
> > > > > 
> > > > > Rick C. 
> > > > > 
> > --It's pretty easy. 
> > --Just implement individual Activation Code for every board, to be generated by your server to get count of boards --manufactured and activated. 
> > ---when say it is easy you obviously never did anything like it.... 
> > > they have the source so they can just remove any "activation" checks 
> > in theory you are right but in practice, not exactly. 
> > Implementing private - public key pair is easy 
> > implementing one time activation codes is easy 
> > implementing one-way input bus only hardware is easy
> and neither of those does anything because they have the source and can easily remove any checks
> > .../ .... / ... 
> > learn how Speedport Hybrid LTE DSL router by Deutsche Telekom is hard/software locked to local APN of the customer
> customers don't have the source so they can't remove the lock and it is permanently connected to the internet so can be remotely disabled
they can try to remove checks if checks are not part of the contract
but if checks are part of the contracts and you attach 3G/4G/LTE modem to communicate with a server at preset intervals, you get modem identified by number, by sim card, by "from" field in sms message
easy cake