Custom Code Bad, Custom Code Good – Notes for your Software License Agreement

At a vendor presentation recently, I saw something funny on a slide of “best practices” for implementing supply chain planning in SAP:

Avoid ZAPO and ZATP

… which means Avoid customizing ATP and APO functions in SAP

<aside>
A bit of tech humor there; the convention for naming customized code in SAP is to prefix with a Z.
Most platforms have unique styles for calling out their customizations. For QAD (written in Progress/4GL), the accepted prefix is xx_. On AS/400 systems, I’ve seen different program numbering standards, such as prefixing all program numbers with “9” when the standard code has been changed.
</aside>

Opinions about custom code, build vs. buy, best of breed / integration vs. single supplier, etc. ripple back and forth through IT departments all the time. Infoworld recently featured yet another article on the subject; they pointed out that Open Source throws yet another wrinkle in the equation.

When talking about “customizations”, I prefer to be precise in my terminology, and for very good reason. Carefully read the language in your commercial software license agreement (SLA), especially where it talks about the ownership of intellectual property (IP) represented by any changes to the core package. Many times, the vendor will include language that gives them all IP rights to any changes – even if you make them! To address this, I like to put language in the SLA that differentiates, like this:

  • Modifications shall mean changes, additions, updates, or deletions of code or functionality made by [Licensee] to the source code of the [product].
  • Bolt-Ons shall mean changes, additions, updates, or deletions of programmatic code or functionality made by [Licensee] , that do not modify or use the owner’s source code.

Now, things can get a bit clearer. Most IT professionals agree on shying away from modifications. Wholesale modifications to large chunks of a company’s ERP system were common practice in the 80’s and 90’s – and many pay the price today, in systems that are many releases behind what is considered current. Bolt-ons, on the other, are typically easier to upgrade; assuming good programming practices have been in place, the “hooks” to the original application should be easier to identify and test.

Also, I can put language in that clearly delineates IP rights on modifications and bolt-ons. Bolt-ons are easy – it’s mine and nobody elses’. However, modifications are a bit grayer; minimally, I must get perpetual rights to use them.

Do you want to make sure your application group does not delve into the world of modifications? Easy – just don’t buy the source code! This has benefits in two areas –

  1. Modifications are not possible
  2. Typically saves a ton of money, too

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles

IoT Field Notes: Solving Interesting Tech Challenges 2

Three more types of tech challenges that come up in conversations about Smart, Connected Products. The details are interesting, but the higher-level insights are very informative.

Read more

IoT Field Notes: Solving Interesting Tech Challenges

Another practical story of tech discovery, as we labor to solve the Communication problem for one of a class of devices / products.

Read more