Stage 2: Identification and Resolution
In the identification and resolution phase, the auditing team inspects and resolves each file or snippet flagged by the scanning tool.
For example, the scanning tool’s report can flag issues such as conflicting and incompatible licenses. If there are no issues, then the compliance office will move the compliance ticket forward to the legal review phase.
If there are issues to be resolved, then the compliance officer creates subtasks within the compliance tickets and assigns them to the appropriate engineers to be resolved. In some cases, a code rework is needed; in other cases it may simply be a matter of clarification. The sub-tasks should include a description of the issue, a proposed solution to be implemented by engineering, and a specific timeline for completion.
The compliance officer may simply close the subtasks once all issues are resolved and pass the ticket along for legal review. Or they might first order a re-scan of the source code and generate a new scan report confirming that earlier issues do not exist anymore. Once they’re satisfied that all issues are resolved, the compliance officer forwards the compliance ticket to a representative from the legal department for review and approval.
In preparation for legal review, you should attach all licensing information related to the open source software to the compliance ticket, such as COPYING, README, LICENSE files, etc.
Stage 3: Legal Review
In the legal review phase, the legal counsel (typically a member of the open source review board, or OSRB) reviews reports generated by the scanning tool, the license information of the software component, and any comments left in the compliance ticket by engineers and members of the auditing team.
When a compliance ticket reaches the legal review phase, it already contains:
- A source code scan report and confirmation that all the issues identified in the scanning phase have been resolved.
- Copies of the license information attached to the ticket: typically, the compliance officer attaches the README, COPYING, and AUTHORS files available in the source code packages to the compliance ticket. Other than the license information, which for OSS components is usually available in a COPYING or a LICENSE file, you need to also capture copyright and attribution notices as well. This information will provide appropriate attributions in your product documentation.
- Feedback from the compliance officer regarding the compliance ticket (concerns, additional questions, etc.).
- Feedback from the engineering representative on the auditing team or from the engineer (package owner) who follows/maintains this package internally.
The goal of this phase is to produce a legal opinion of compliance, and a decision on the incoming and outgoing license(s) for the software component in question. The incoming and outgoing licenses are in the plural form because in some cases, a software component can include source code available under different licenses. There are three possible outcomes at this stage:
If there are no issues with the licensing, the legal counsel would then decide on the incoming and outgoing licenses of the software component and forward the compliance ticket one step further in the process into the compliance architectural phase.
The incoming license is the license under which you received the software package. The outgoing license is the license under which you are licensing the software package. In some cases, when the incoming license is a permissive license that allows relicensing (e.g., BSD), companies will relicense that software under their own proprietary license. A more complex example would be a software component that includes proprietary source code, source code licensed under License-A, source code that is available under License-B, and source code available under License-C.
During legal review, the legal counsel will need to decide on the incoming and outgoing license(s):
Incoming licenses= Proprietary License + License A + License B + License C
Outgoing license(s) = ?
If a licensing issue is found, such as mixed source code with incompatible licenses, the legal counsel will flag these issues and reassign the compliance ticket in JIRA to engineering to rework the code.
For example, legal review may uncover that closely held intellectual property has been combined with an open source code package. Legal counsel will flag this and re-assign the compliance ticket to engineering to remove the proprietary source code from the open source component. In the event that engineering insists on keeping the proprietary source code in the open source component, the open source executive committee (OSEC) will have to release the proprietary source code under an open source license.
In some cases, if the licensing information is not clear or if it is not available, the legal counsel or engineering staff members contacts the project maintainer or the open source developer to clarify the ambiguities and to confirm under which license that specific software component is licensed.
Stage 4: Architecture Review
In the architecture review, the compliance officer and an engineering representative on the auditing team or open source review board perform an analysis of the interaction between the open source, proprietary, and third-party code. This is accomplished by examining an architectural diagram (see an example, below) that identifies:
- Open source components (used “as is” or modified)
- Proprietary components
- Components originating from third-party software providers
- Component dependencies
- Communication protocols
- Other open source packages that the specific software component interacts with or depends on, especially if it is governed by a different open source license.
The result of the architecture review is an analysis of the licensing obligations that may extend from open source to proprietary or third-party software components (and across open source components as well).
If the compliance officer discovers any issues, such as a proprietary software component linking to a GPL licensed component, the compliance officer forwards the compliance ticket to engineering for resolution. If there are no issues, then the compliance officer moves the ticket to the final stage in the approval process.
Stage 5: Final Review
The final review is usually a face-to-face meeting of the auditing team or open source review board (OSRB) during which the team approves or rejects the usage of the software component.
The team bases its decision on the complete compliance record of the software component, which includes the following:
- A source code scan report generated by the scanning tool.
- The list of discovered issues, information on how they were resolved, and who verified that these issues were successfully resolved.
- Architectural diagrams and information on how this software component interacts with other software components.
- Legal opinion on compliance, and decision on incoming and outgoing licenses.
- Dynamic and static linkage analysis, if applicable in an embedded environment (C/C++).
In most cases, if a software component reaches the final review, it will be approved unless a condition has presented itself (such as the software component is no longer in use). Once approved, the compliance officer will prepare the list of license obligations for the approved software component and pass it to appropriate departments for fulfillment. This can include:
- Updating the software inventory to reflect that the specific OSS software component version x is approved for usage in product y, version z.
- Issuing a ticket to the documentation team to update end user notices in the product documentation, to reflect that open source is being used in the product or service.
- Triggering the distribution process before the product ships.
Steps accomplished after the OSRB approval
For a more detailed usage process and possible scenarios, see our ebook Open Source Compliance in the Enterprise.