Preparation of open source software compliance guidelines
Aim:
The purpose of these Open Source Software Compliance Guidelines (Guidelines) is to provide guidance in the development of procedures designed to verify compliance with the license requirements of various open source software (OSS) applications and code used internally or included in products for distribution. Lawyers, advisors and technology consultants need to be aware of the issues surrounding open source software in order to properly advise their clients.
The result of these Guidelines should be (1) an Open Source Software Compliance Policy (OSS Policy) that outlines the policies and procedures applicable to the company’s use of OSS, and (2) an inventory (Open Source Inventory). OSS) of all OSS approved for use. inside the company.
The OSS Policy must be designed taking into account the culture of the company and the specific way of operating to be effective. The OSS Policy should also be regularly reviewed and updated.
The OSS Inventory is the end result of these Guidelines and the OSS Policy. However, it will also serve as a ready-made document, in modified form, that can be provided to customers requesting a list of OSS contained in distributed products and to a potential partner or acquirer conducting due diligence.
It is important to note that proprietary third party software often contains OSS components. Therefore, particularly when such software is included in a distributed product, it is necessary for the vendor to identify all OSS components so that they can be considered as set forth below.
Designated Guardian:
A person or committee must be designated for approval of all OSS proposed for internal use or included in products for distribution. For this procedure to be effective, relevant company personnel must be notified that the company requires prior approval of all OSS used in any way within the company. Such notice must be conspicuous and repeated at regular intervals. In addition, supervisors should also be instructed to enforce this requirement. Special attention should be paid to development teams that are used to pulling OSS from multiple places and typically operate under tight deadlines.
Approval request:
1. Approval requests must be submitted within the time period prior to use/implementation as set forth in the OSS Policy. The approval process must begin with the submission of a document that contains at least the following information:
2. Name/Version number/Source of the open source software
3. Name of the applicable license (eg, GNU General Public License v.2, zlib, BSD) and source address of the license
4. Name of the Entity/Person granting the License
5. Source address from which the OSS will be obtained
6. Description of how the OSS will be used (eg, internally, as a development tool, integrated into a distributed product, etc.)
7. If included in the distributed product, a description of how these OSS will interact with the company’s proprietary source code (i.e., will the OSS be compiled and/or linked statically or dynamically with the source code? owned by the company?)
8. How the OSS will be implemented (eg, modified vs. unmodified, standalone, statically linked, dynamically linked, etc.).
9. Description of whether the OSS will be modified
10. Statement on whether the OSS is a key component of the product
11. Statement on whether the OSS known and widely used
12. Deadline for the use/implementation of OSS
Approval process:
The approval process involves examining risk areas related to the use of the particular OSS. Risk areas may include:
1. Does the OSS license require that modified source code be publicly available?
2. Does the OSS license require that the source code of the company’s proprietary software be publicly available? (for example, will there be static linking of the GPL code to the company’s proprietary software?)
3. Has there been any litigation or other issues related to the OSS issue?
4. Does the OSS license contain ambiguous terms, which could cloud the company’s rights to use the OSS in a certain way?
5. Will the lack of guarantees and compensation for intellectual property represent a risk for the company in the face of customer expectations and demands?
It is important that the approval process is completed quickly, and the expected time frame for approval should be stated in the OSS Policy. Otherwise, users and developers are likely to get frustrated and find ways around procedures as deadlines approach.
When new versions of approved OSS are used, an expedited approval process must be carried out. This allows the OSS Inventory to stay current and will prevent inventory gaps from forming that could end up becoming large holes.
Compliance:
The goal of an OSS Policy is to achieve compliance with each OSS license. Depending on the licenses involved, compliance may include any of the following:
1. Inclusion in appropriate documentation of warranty disclaimers, liability exclusions, author attribution, and proprietary rights notices.
2. Inclusion in the appropriate documentation of the applicable OSS end user license agreement.
3. Public delivery or availability of the source code for the unmodified version or the modified version.
4. Public release or availability of the company’s proprietary software source code if linked to a "copyleft" open source software code in a way that requires this result.
5. Marking of the modifications made to the OSS source code.
Audits:
Periodically, at least annually, an audit should be conducted to verify that the OSS Inventory is accurate and up-to-date. The audit process can be as simple as distributing the OSS Inventory to key personnel who will sign it off, or as complex as installing monitoring software that will identify OSS on the company’s computer system. The scope of the audit will depend on the needs of the business and the volume of open source OSS in use.
OSS Training:
Current and new employees are required to participate in an OSS Policy training session to ensure they are aware of company procedures and requirements in this area.