License Compliance

This document describes how the Apache OpenWhisk project's source code and release artifacts maintain compliance with ASF licensing policy in the following sections:

Policies and rules

The Apache OpenWhisk project repositories MUST follow Apache Release Policy. every artifact distributed MUST contain only appropriately licensed code per Apache Licensing Policy. It includes two check points:

  • Each project repository MUST provide a LICENSE file and a NOTICE file.

  • With a few exceptions, source files consisting of works submitted directly to the ASF by the copyright owner or owner's agent must contain the appropriate ASF license header. Here are the exceptions:

    • Files without any degree of creativity don't require a license header.
    • Sometimes shorter form of ASF license header can be used if the recommended Apache source header is not appropriate.

Project specific rules

In accordance with Apache LICENSE policies, the following tables lists the specific files, by type, that the community has discussed and have agreed MUST have an ASF approved Apache 2 license or can be excluded for a valid approved reason.

Note: These lists are not comprehensive and are intended to be informative only. Each project repository's respective LICENSE and NOTICE files should be considered the canonical source for their specific licensing declarations.

Project ASF License header policy

In accordance with Apache LICENSE policies, the table below lists files/file types that the community affirms MUST have an Apache LICENSE header since they are creating works representing Intellectual Property.

In addition, the recommended type of approved ASF license header (i.e., “full” or “minified” header) is noted as best practice.

File typeASF Header TypeRationale
Source code (e.g., *.scala, *.go, *.java, *.py, etc.)FullSource code.
Action functions (source) (e.g., .js, .py, .swift, etc, particularly under tests/dat folder.)FullSource code.Use “Mini” header as best practice for performance reasons.
Ansible Group vars. (YAML) (*/group_vars/all)FullProject convention.
Docker image build file (Dockerfile)FullMay contain functional (script) code.
Documentation (e.g., *.md)FullIntellectual property.
Gradle files (build.gradle, *.gradle)FullMay contain functional scripts and code (e.g., Groovy, Kotlin).Includes build (build.gradle) and settings (settings.gradle)files.
Gradle properties files (*.properties)FullProject convention.
Groovy code (*.groovy)FullSource code.
MakefileFullMay contain functional (script) code.
Scala Configurations (*.conf)FullScala (Java) configuration files may contain code or interfaces.
Scala Properties (*.properties)FullProject convention.Example: openwhisk/blob/master/tools/eclipse/scala.properties
Script files (*.sh)FullMay contain functional (script) code.
Vagrantfile configuration file (Vagrantfile)FullProject convention.
Web Content (e.g., *.html, .css)FullSource code.
Windows Command file (*.cmd)FullMay contain functional code.
YAML files (*.yaml, *.yml)FullMay contain functional code.
Note: Includes (.travis.yml)

Notes

  • Full ASF License headers are always accepted regardless if a “Mini” header is recommended as best practice.
  • Action source files used in performance testing may be added to “Known exclusions” when justified.

General Exclusions

In accordance with Apache LICENSE policies, the table below lists general exclusions by file (type) as agreed to by the project community along with the justification.

TAGFile typeRationale
ANS.CFGAnsible Configuration Files (*.cfg)Configuration files. Not much creativity.
Example: openwhisk/ansible/ansible.cfg
ANS.ENVAnsible environment files (*.env)Configuration files. Not much creativity.Example: ansible/environments/distributed/files/openstack/openstack.env
ANS.HOSTSAnsible hosts files (hosts)Configuration files. Not much creativity.Example: openwhisk/ansible/environments/distributed/hosts
ANS.INIAnsible (host) Inventory Files (*.ini)Configuration files. Not much creativity.
Example: openwhisk/ansible/environments/local/hosts.j2.ini
API.ENCEncrypted API Credentials used in TravisConfiguration data.Example: openwhisk-catalog/credentials.json.enc
DATA.AUTHAPI Auth. keyConfiguration data.Example: ansible/files/auth.guest
DATA.TESTEmpty (zero-length) test filesEmpty test data file.Example: openwhisk/tests/dat/actions/empty.js
GIT.1Git configuration (.gitattributes, .gitignore)Configuration file. Not much creativity.
GIT.2Git tracking (.git subdirectory)Git file tracking. Not part of project source.
GODEPS.JSONGoDeps dependencies data (Godeps.json)
GODEPS.READMEGoDeps Readme file (Readme)Plain text Readme generated by the GoDeps utility; states the directory and JSON file within it were autogenerated.
GRDL.PROPGradle Wrapper properties (gradle-wrapper.properties)Generated by Gradle.Example: openwhisk-cli/gradle/wrapper/gradle-wrapper.properties
I18N.1Golang Internationalization resource files (i18n_resources.go)Not much creativity. The file is auto-generated; not able to add header.Example: openwhisk-client-go/wski18n/i18n_resources.go
IDEIDE configuration files (e.g., .project)Not much creativity.
IGNORETooling “ignore” files (e.g., .gitignore, .dockerignore)Not included in source release.
IMAGEBinary Image files (e.g., .png, .jpg, .ico)Binary files.Example: openwhisk/docs/images/OpenWhisk.png
J2Jinja2 Template files (*.j2)REVIEW Not much creativity.Example: openwhisk/ansible/templates/whisk.properties.j2
JSONJSON files (*.json)Configuration and test data files. - Note: JSON files don't support commentsExample: openwhisk/tests/dat/actions/echo.json
KUBE.1Kubernetes Configurations (e.g., *.env)Configuration file. Not much creativity.
Example: openwhisk//ansible/environments/distributed/files/openstack/openstack.env
OAPIOpen API (Swagger) documentsJSON files describing API input data.Example: openwhisk/blob/master/tests/dat/apigw/testswaggerdoc2 for test input data
PEMPrivacy Enhanced Mail (PEM) files (*.pem)Contains generated, base64-encoded x509 keys.Example: openwhisk/ansible/roles/nginx/files/openwhisk-server-key.pem
PROFILEProfiling configuration scripts (.profiling.*)Configure Docker container for profiling (build).
PYDEVPyDev configuration files (.pydevproject)Not included in source release.
TEST.JARJava Application Resource (JAR) files (*.jar)Binary JAR files used for testing (Actions).
TEST.ZIPZIP compressed archive files (*.zip)Binary ZIP files used for testing (Actions).
XMLXML files (*.xml)Configuration and test data files.Example: openwhisk/tools/eclipse/java.xml

Known exclusions

License scanning exclusions

The Apache OpenWhisk project enforces and verifies ASF License header conformance on all source files using the project's own scanCode utility (on all Travis CI builds) and Apache RAT tool (on all automated releases).

In accordance with Apache policy, these utilities exclude specific files from the ASF license header requirement which are configured in the following files:

ASF License header exclusions

The following page contains a non-comprehensive listing of all project files, by repository that are known to not have ASF license headers along with the policy tag indicating the justification against the table above: license_exclusions.md

Enforcement and verification

This section describes how the Apache OpenWhisk project enforces and verifies LICENSE and NOTICE file compliance as part of the DevOps and Release processes.

ScanCode

This utility is used to enforce LICENSE compliance on all contributions as they are submitted to GitHub.

The scancode utility code and documentation are under the OpenWhisk Utilities repository. The community has agreed that all repositories MUST include ASF LICENSE scanning as part of the Travis Continuous Integration (CI) process enabled to run on every contribution via a GitHub Pull Request (PR). This means no new or updated files can be merged unless they have a valid ASF LICENSE header where required by policy.

The README for this repository includes a table that indicates where the scancode utility is invoked, as part of the GitHub Travis CI process, per project repository.

Apache Rat

The Apache Rat tool is used to verify LICENSE and NOTICE file compliance as part of the release process.

verify_source_code.sh in the tools folder is to verify license compliance. Apache Rat is used to verify license headers. Files excluded license header verification following the previous rules are configured in the file pom.xml.

cd $OPENWHISK_SOURCE_DIR
cp $SCRIPTDIR/lib/pom.xml ./
mvn clean apache-rat:check

The script snippet, shown below, is used to check LICENSE file and NOTICE file in every repository when either an automated or manual release is initiated by a Release Manager.

for repo in $(echo $repos | sed "s/,/ /g")
do
    repo_name=$(echo "$repo" | sed -e 's/^"//' -e 's/"$//')
    echo "Check the repository $repo_name"
    cd $OPENWHISK_CLEANED_SOURCE_DIR/$repo_name && ls {LICENSE*,NOTICE*}
done

How to run

After downloading the source codes to your local disk, run the following script to verify license compliance:

$ ./tools/travis/verify_source_code.sh

Apache Tentacles

Although Apache Tentacles is a tool to check LICENSE file and NOTICE file in artifacts uploading to a staging repository, it is not usable for the Apache OpenWhisk project because it doesn't support the unpacking of tar.gz files.### Known exclusions