Software IP and source code
It is increasingly common to utilize existing software components in a new embedded design. These may be internally developed or are quite likely to come from an external source. Such software IP – like an RTOS, for example – is typically distributed in one of two forms: a binary library or source code. The question is: which of these is acceptable? If the conclusion is that source code is required, care is needed with exactly what will be delivered …
Most developers, if asked whether they would like to have source code for some software IP, would answer a very firm “yes”. It is not entirely clear why this is the case. Often, in life in general, using something that is just a “black box” is entirely acceptable; we just expect things that we use to do what they are supposed to do in the way the documentation says. Surely software could be seen in this way; make a call with some specific data as parameters and an expected result will occur. Hardware engineers use integrated circuits without expecting to see [or understand] the circuit diagram. Of course, this is all great if the black box does what the documentation says it should do!
For many, there is just a feeling of security, knowing that the source code is there, even if it is never used. Fears that the supplier might go out of business or be unresponsive to support calls are allayed by the source code sitting on the shelf. However, there are more concrete reasons for wanting it:
Every embedded system is different. This makes it very challenging to create binary modules that are adaptable enough for a large number of users. Vendors usually have to resort to having a large catalog of different variants, each preconfigured for a specific type of target system. Supply in source code form almost totally eliminates this issue, reducing it to a requirement for flexible build scripts.
A number of types of embedded application – medical, avionics, automotive, industrial are all examples – require certification. Typically this process applies to the entire application, including any externally sourced IP. Clearly, this leads to a demand for source code to be available. Its unavailability would be a firm show-stopper.
Another important matter to consider is what actually is “source code”? The anticipation is that is is clearly structured and laid out, with plenty of comments: code created with the human reader in mind. Commonly, this is exactly what is supplied and all is well. However, there are two other possibilities. It may be just code that is adequately structured and commented. This is better than nothing, but much harder to work with.
The third possibility is that the code is “scrambled” – it is valid C [say] code, but has had all the unnecessary whitespace and comments removed and identifier names have been modified to make them anonymous. Why would someone do this? The answer is that the vendor wants to gain all the advantages of source code for build flexibility, but wants to protect their IP. This is a valid strategy, so long as the vendor describes it correctly up-front. I have come across a user of an RTOS who was hoping to use the source code for debugging and was disappointed not to be able to make any sense of it – exactly where are the tasks’ registers stored?
When you are next looking to obtain an RTOS [for example] for an embedded project, it is worth checking whether source code is available. If it is, is it clear and readable and is it supplied automatically at no additional cost? [The answer is yes to both of these for Nucleus RTOS]. Making a charge for source code is not unreasonable, so long as you are made fully aware of the costs up front.
