1. Explain that there are some code sections in the form of existing source code which are *already part of your own IP* and therefore you are unwilling to allow the customer to "own" these. However you are willing to provide a free license for the customer to use and redistribute said functions as part of the final binary. Or let them take the code and develop based on it freely without owing you anything else. 1a. Side-option here is to very quickly open-source that code, now the customer literally cannot own it, downside is, neither do you. But at least it's pretty easy to explain - "some parts of this code cannot comply with the contract as they are open-sourced under the 'Do whatever you want' license" If you are OK with that then this probably a good option as it forces the customer to compromise on the contract text. 2. If #1/1a doesn't fly and the customer refuses to modify the agreement - then your price just went up by a factor of 10-50. I'm not joking - the customer is essentially asking you to hand over something that is *already your IP*, and for that they need to pay, since you could get into legal issues later on if you ever re-use that code so you must be compensated for the loss of that IP. If a client refused to budge on this I'd fire them, I know that might not be an option for you but I would encourage you to dig your heels in a little bit on this. Chances are this is not the customer trying to own all your stuff out of greed, just a case of a standard contract where the customer wants to make sure you don't screw them later on by claiming ownership of the final codebase in its entirety, of do a bait and switch by forcing them to "licen$e these functions I own" later on.

Personally I never buy hardcopy "How to X with Y" type books any more, mostly because they are out of date by the time you get them (echoing your sentiments with for example Angular) and also because they tend to cater to the lowest common denominator and don't actually teach you much outside of Y's documentation. Foundational stuff like "Continuous Delivery", "Release It!", "Patterns of Enterprise Architecture" and all that kind of thing age much better IMO. I still refer back to my copy of the *original* Fowler Refactoring book from time to time :)

no worries - drop me a line here or email me anytime.

Having worked with SBO for many years I can tell you that there are plenty more surprises in store for you... Just wait til you dig deeper and have the pure joy of things like OITM.VatGourpSA (wtf?) or OCPR.E_mailL. Many field names seem like they ran out of vowels (CIN13.LstPchPrce). The thing that drive me nuts in the early days was the 4 character table names. Because, clearly RDR12 is Order Address Extension Data......anyway let me know if you get stuck with anything :)

Their documentation does suck - mainly because of the poor format they publish it in online (a single page with no proper index/TOC) but the framework and controls are pretty neat; I can't say we've had more stupid bugs than in any other control/web ui framework and at no point have we had anything that couldn't be worked around with a bit of manual labour :) Customization can be tricky at first because the framework is somewhat complex, but once you get your head into their way of doing things, it's really not too hard. We use the grid control extensively and have done some crazy things with it, once we "got" the concepts it really isn't hard. But I wouldn't bother with the MVC helpers personally - they save time in the short-term but will cost you long-term if you need to customise, they are super opinionated and very hard to modify their generated markup/script. Also personally I found their support pretty good once you have a paid subscription. The free support options aren't great (read-only forums, stack overflow, etc) but YMMV. Hope that helps.