If someone has already provided a solution to a problem you’re facing, it may make sense to use it rather than trying to solve yourself the same.
In the following, I will present my personal view on how to reuse such solution, focusing on reusing and integrating a piece of software. I think the same will also be true for media content like videos and audio files, or documents.
First of all, does the foreseen software provides all the required features and fulfill all the requirements (You can think of this as “IRCA”: identify, read reviews, compare, and analyze) ? Is is supported ? Will it integrate nicely with the rest of your system ?
Intellectual property rights, e.g. patents, trademarks, copyright shall be considered as well.
Check license and target group
When it is clear that this particular piece is THE solution, it is time to check if it can be used for what it is planed for.
Just because it is available on the internet doesn’t mean that it is allowed to use it for all purposes. The copyright law (The statutes and court decisions regarding the rights to creative and literary works) has to be respected. The owner shall provide a license agreement listing the restrictions on how to use the software (or media content, document, etc).
A distinguish has to be made between COTS (“Commercial off-the-shelf”) that can be free or not and OSS (Open source software).
For OSS, the Copyleft effect (typically for software licensed under the GNU GPLv2 license) has to be considered. As so many open source licenses exist and as each file can contain its own license agreement, the use of tools like Fossology appear as mandatory.
Worst, even if the license agreement allows to integrate it, it does not mean that it can be redistributed everywhere! Some countries do not allow the use of certain technologies, e.g. advanced cryptography algorithms. Specific regulations and Export Control and Customs (ECC) must be considered as early as possible.
Some examples may be useful to illustrate this:
- Oracle Java Virtual Machine (JVM) Code License agreement targets “General Purpose Desktop Computers and Servers”: it means that if the JVM is installed on the server with a specific task, this agreement does not apply.
- It is not allowed to redistribute Sysinternal tools (e.g. psexec). End customers shall download the tools from Microsoft website.
- Reuse a code snippet from Stack Overflow is not as simple as one could think.
- A license is mandatory to redistribute Adobe Reader.
Last, what happen if the author stops the development of the item ? Or does not support it anymore ? An Escrow Agreement may be a solution, developing technical expertise on the product, etc.
Redistribute OSS source code and eventual modifications
GPL license requires that the source code is accessible to the end customer. It can be provided on-demand or being delivered with the binaries. Easy, but the same version has to be provided. Source code and binaries for OSS items shall be downloaded at the same time, ideally directly from the author (source has to be trusted) and check for consistence (a corrupted archive has no value).
Redistribute the source code and the eventual modification with the product seems to me the easiest way to fulfill this requirement from the GPL, alternative would be to provide the complete source code for the exact version to anyone asking for it. This can be easily checked and implies the use of a framework in order to keep things organized (all source code in one place).
Integrate to the documentation (and online help if applicable) the use of OSS documentation, ideally with the data from the bill of material (see below).
Note: OSS source code redistribution may not be the single limitation imposed by the license.
Create a Bill of material
A system is constantly evolving. For instance, the author may deliver new versions fixing some security flaw that has been discovered (more on this in chapter Maintenance) and assuming this is not the single 3rd party item included in the software, it is difficult to keep an overview.
The Bill of material shall list all software components, media and documents, their corresponding owner, download location, license, etc. Difficult to create initially but keeping it up-to-date provides a great value.
Once the first version of the system is delivered, some maintenance may be required.
Microsoft provides security hotfixes every month (Patch Tuesday). Security problems affect any kind of software, and the provider is responsible to provide fixes to his customers. At least, the items listed in the CVE (Common vulnerabilities and exposures) database shall be fixed. It is no secret that a well-defined vulnerability management process to address security vulnerabilities is a must. A good practice is to register to the announcement mailing-list of the software as well as to get involved in the support community forums, allowing to gain first-hand experience.
Note: I won’t describe anything about liability and warranty aspects. The provider is, as far as I know, responsible regarding his customers e.g. in case of a patent infringement. This may be an additional requirement by using OSS (this article provides additional information).
In order to keep track of those changes, common practices use a versioning control system, e.g. Git for source code. But which tool can be used for binaries ? SVN (Subversion) may be a good choice as it provides a global version number for each commit. Alternative would be Actifactory (Open source).
Ultimate Target is the reproducible build, allowing to prove that the system building process is meeting the high quality standard customers are paying for (or required by the sector of activity).
Integrating a third party software component allows to gain competence and development time, enabling a faster time-to-market. At the same time, it involves some obligations against the customers.
Final note: Ensure coherence by keeping the variety of third party software components low.