This article is now located here: https://experts.barrgroup.com/articles/dead-code-law-and-unintended-consequences
Tags: copyright, embedded, ethics, firmware, opensource, patents, trends
Wednesday, February 6th, 2013 by Michael Barr
This article is now located here: https://experts.barrgroup.com/articles/dead-code-law-and-unintended-consequences
Tags: copyright, embedded, ethics, firmware, opensource, patents, trends
This entry was posted on Wednesday, February 6th, 2013 at 3:40 pm and is filed under Intellectual Property. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
Michael Barr is an expert on the design of software-powered medical devices and other embedded computer systems. (full bio)
Embedded Gurus - Experts on Embedded Software
website by Accent Interactive
Hi Michael,
You refer to the liability dangers of another parties source code in your code, does that apply to code that may exist in any version control software that we maintain, regardless of whether the code is in the shipped product?
Rod
It sounds like you are hypothesizing that the 3rd party source was never part of a released product’s build code but might be present in the version control repository. Obviously, I am not a lawyer. But the only way I am aware that could be problematic is if the same 3rd party was bringing suit and accused some other part of your code of being derived from theirs. That you once had their code could help them establish “access”, which could weaken your counter argument of independent discovery of the alleged derivative.
Dear Michael,
The points you make are good ones, but one should clarify what dead code is. There are cases where code is in a binary, but it is not used in the system. The use of object oriented technology and the use of standard libraries can both be sources of this kind of code. Some certification standards, such as DO-178C and DO-278A recognize this. They differentiate between dead code, code that is not executed and has not requirements, and deactivated code, code that is not executed but is intentionally not used in a particular system. The rationale for this is that it is often harder to safely remove such code then to ensure that it is not used. In any case, this deactivated code must be planned for, have requirements, and have a full set of unit tests. Of course, whatever one can safely remove, should be removed. Smarter linking technology can help here.
Sincerely,
James
Kiran and chandru (BAeHAL software ltd bangalore),
Yes i completely agree with James because as per DO178B safety critical software development guideline document Terms “Dead code” and “Deactivated Code” have distinct meanings:
Dead code : Dead code is source code (and it is a part of binary code) that is not executed in the final system and it will be not having traceability to any requirements (one can say unintentional code).
Deactivated code: code which is commented out or removed via #ifdef’s (it is not a part of final binary code) and it will be having traceability to its low level requirements (its a intentional code and it can be activated in some configurations through hardware traps for debugging or other purposes)
This article has given me a good insight into embedded code and code structure in general. Can you please recommend an excellent book which provides guidance on good embedded software architecture and design?
Thanks,
Subramanian