Depends on your usage of the term "bricks", a brick can be a a "very hard" brick where you would basically have to reflash firmware onto the flash chip directly

Depends on your usage of the term "bricks", a brick can be a a "very hard" brick where you would basically have to reflash firmware onto the flash chip directly using an external programmer, a soft brick could be easily recoverable via the built in software without needing any external tools at all. First a quick and simple answer to your question: Demo/Evaluation code, allows the device manufacturer to evaluate your library to make sure its fit for purpose before commiting to licencing it, however you don't want manufacturers just ripping off your code and shipping it to customers without a licence. So the demo code stops functioning at the end of the trial period. But this code is only ever meant to be ran in the lab, never on the end customers device. Now a more WALL O'TEXT answer. A common example of a soft brick could be the iCloud Activation Lock but another could be an expired licence (depends completely on the business model of the thing in question). Personally, my ethos on selling a "module"/library to be included in someone else's product would be that you wouldn't brick the device on licence expiry but alert the user/company by other means that the licence has expired. My views might be different if it was the device manufacturer put in the code, for example iCloud Activation Lock, which in general is a good thing as it helps reduce the resale value of stolen devices, however I'm not a big fan of the eWaste it creates when people forget to remove the lock when recycling devices. In this case it seems to be part of the devices bootloader, and a quick google of the company involved I'm gonna guess it relates to the firmware updater part of the bootloader. How would I have done it in this case? Well in the first place I prob would have sold a perpetual licence with no expiry in the binary and then work out a support plan with the company for my recurring income stream, But for the sake of argument, if I were going to do down the time based expiry method (Making dam sure the company knew of this expiry and what the extension cost would be, and how to issue an update without my updater, as the company may decide to invest the time in creating their own updater instead of using mine - one final update so to speak) I would set a deadline in the updater to stop accepting new updates after that date unless a new signed licence was included in the update file. That way the user gets to still use their device (wouldn't even have to pester the user that my module was expired) but if the company wanted to push updates using my updater they would have to sign a new agreement. However this would prob just drive the company to stop releasing updates for the device in question instead of paying up. (which would go against my ethos, I want companies to update their devices for as long as possible, I'm also a believer of the expression "you get more flies with honey than with vinegar", bricking your clients customers devices ain't gonna win you many friends if any at all, thats gonna hit the pocket book later down the road even if you were 100% legally right to do so because who is going to want to do business with you after the cat is out of the bag? EDIT: I still remember the FDTI bricking incident - long story short: there are clones of FDTI chips, these clones got into end users products, FDTI pushed a driver update via windows update that "bricked" these clones (reworte the PID on them), were dicks to people about it on twitter, FDTI lost a ton of good will, MS pulled the update after it was discovered, FDTI reversed course and changed the driver to split of a canned message instead of its real output when a clone is detected instead of bricking the clone chip. But ever since then I've avoided using FDTI chips even if they are dam useful at times.