Skip to content

haikoschol/oss-review-toolkit

master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Code
This branch is 9841 commits behind oss-review-toolkit:main.

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
cli
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

OSS Review Toolkit

Linux (OpenJDK 8) Windows (Oracle JDK 9)
Linux build status Windows build status
Linux code coverage
Interact with us!
ort-talk

Introduction

The goal of the OSS Review Toolkit (ORT) is to verify Free and Open Source Software licence compliance by checking project source code and dependencies.

At a high level, it works by analyzing the source code for dependencies, downloading the source code of the dependencies, scanning all source code for license information, and summarizing the results.

The different tools that make up ORT are designed as libraries (for programmatic use) with a minimal command line interface (for scripted use).

The toolkit is envisioned to consist of the following libraries:

  • Analyzer - determines dependencies of a software project even when multiple package managers are used. No changes to software project required.
  • Downloader - fetches the source code based on output generated by the Analyzer.
  • Scanner - wrapper around existing copyright / license scanners which takes as input the output of the Downloader and produces standardized output such as SPDX.
  • Evaluator * - Evaluates the scan results from Scanner as OK or NOT OK based on user specified approval / rejection ruleset.
  • Advisor * - Retrieves security advisories based on Analyzer results.
  • Reporter - Presents the output from Analyzer and Scanner in various formats, making it easy to identify the dependencies, licenses, copyrights and issues.
  • Documenter * - Generates the outcome of the review, e.g. Open Source notices and annotated SPDX files that can be included into your distribution.

* Libraries to be implemented, see our roadmap for details.

Installation

Follow these steps to run the OSS Review Toolkit from source code:

  1. Ensure OpenJDK 8 or Oracle JDK 8u161 or later (not the JRE as you need the javac compiler) is installed and the JAVA_HOME environment variable set.

  2. Clone this repository recursively, i.e. with submodules (git clone --recurse-submodules).

  3. Change into the created directory and run ./gradlew installDist to build / install the start script for ORT. On the first run, this will also bootstrap Gradle and download required dependencies. The start script can then be run as:

    • ./cli/build/install/ort/bin/ort --help

    Alternatively, ORT can be directly run by Gradle like:

    • ./gradlew cli:run --args="--help"

    Note that in this case the working directory used by ORT is that of the cli project, not directory gradlew is located in (see gradle/gradle#6074).

  4. Make sure that the locale of your system is set to en_US.UTF-8, using other locales might lead to issues with parsing the output of external tools.

  5. Install any missing external command line tools as listed by

    • ./cli/build/install/ort/bin/ort requirements

    or

    • ./gradlew cli:run --args="requirements"

Tools

analyzer

The Analyzer determines the dependencies of software projects inside the specified input directory (-i). It does so by querying whatever supported package manager is found. No modifications to your existing project source code, or especially to the build system, are necessary for that to work. The tree of transitive dependencies per project is written out as ABCD-style YAML (or JSON, see -f) file named analyzer-result.yml to the specified output directory (-o). The output file exactly documents the status quo of all package-related meta-data. It can be further processed or manually edited before passing it to one of the other tools.

downloader

Taking the ABCD-syle dependencies file as the input (-d), the Downloader retrieves the source code of all contained packages to the specified output directory (-o). The Downloader takes care of things like normalizing URLs and using the appropriate VCS tool to checkout source code from version control.

scanner

This tool wraps underlying license / copyright scanners with a common API. This way all supported scanners can be used in the same way to easily run them and compare their results. If passed a dependencies analysis file (-d), the Scanner will automatically download the sources of the dependencies via the Downloader and scan them afterwards. In order to not download or scan any previously scanned sources, the Scanner can be configured (-c) to use a remote cache, hosted e.g. on Artifactory or S3 (not yet implemented, see #752). Using the example of configuring an Artifactory cache, the YAML-based configuration file would look like:

artifactory_cache:
  url: "https://artifactory.domain.com/artifactory/generic-repository-name"
  apiToken: $ARTIFACTORY_API_KEY

reporter

The reporter generates human-readable reports from the scan result file generated by the scanner (-s). It is designed to support multiple output formats. Currently the following report formats are supported:

  • Excel sheet (-f Excel)
  • NOTICE file (-f Notice)
  • Static HTML (-f StaticHtml)
  • Web App (-f WebApp)

Getting Started

Please see GettingStarted.md for an introduction to the individual tools.

Configuration

Please see Configuration.md for details about the ORT configuration.

Supported package managers

Currently, the following package managers / build systems can be detected and queried for their managed dependencies:

Supported license scanners

ORT comes with some example implementations for wrappers around license / copyright scanners:

Supported remote caches

For reusing already known scan results, ORT can currently use one of the following backends as a remote cache:

Development

The toolkit is written in Kotlin and uses Gradle as the build system. We recommend the IntelliJ IDEA Community Edition as the IDE which can directly import the Gradle build files.

The most important root project Gradle tasks are listed in the table below.

Task Purpose
assemble Build the JAR artifacts for all projects
detekt Run static code analysis on all projects
test Run unit tests for all projects
funTest Run functional tests for all projects
installDist Build all projects and install the start scripts for distribution

License

Copyright (C) 2017-2018 HERE Europe B.V.

See the LICENSE file in the root of this project for license details.

About

A suite of tools to assist with reviewing Open Source Software dependencies.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • HTML 61.5%
  • Kotlin 31.9%
  • JavaScript 6.3%
  • CSS 0.2%
  • Ruby 0.1%
  • Shell 0.0%