Skip to content

Instantly share code, notes, and snippets.

@bessonm

bessonm/licensing.md

Created December 12, 2019 17:31
Show Gist options
  • Save bessonm/d2efd3f6f7ea313ac24d2f9d0f8d83c4 to your computer and use it in GitHub Desktop.
Save bessonm/d2efd3f6f7ea313ac24d2f9d0f8d83c4 to your computer and use it in GitHub Desktop.
Download ZIP
Contributing exemple - How to comply with licensing agreements
Raw
licensing.md

Licensing

We choose to apply the Apache License 2.0 (ALv2) : http://www.apache.org/licenses/LICENSE-2.0

As for any project, license compatibility issues may arise and should be taken care of.

Concrete instructions and tooling to keep Iceberg ALv2 compliant and limit licensing issues are to be found below.

However, we acknowledge topic's complexity, mistakes might be done and we might not get it 100% right.

Still, we strive to be compliant and be fair, meaning, we do our best in good faith.

As such, we welcome any advice and change request.

To any contributor, we strongly recommend further reading and personal research :

How to manage license compatibility

When adding a new dependency, one should check its license and all its transitive dependencies licenses.

ALv2 license compatibility as defined by the ASF can be found here : http://apache.org/legal/resolved.html

3 categories are defined :

  • Category A : Contains all compatibles licenses.
  • Category B : Contains compatibles licenses under certain conditions.
  • Category X : Contains all incompatibles licenses which must be avoid at all cost.

As far as we understand :

If, by any mean, your contribution should rely on a Category X dependency, then you must provide a way to modularize it and make it's use optional to Iceberg, as a plugin.

You may distribute your plugin under the terms of the Category X license.

Any distribution of Iceberg bundled with your plugin will probably be done under the terms of the Category X license.

But "you can provide the user with instructions on how to obtain and install the non-included" plugin.

References :

How to comply with Redistribution and Attribution clauses

Lots of licenses place conditions on redistribution and attribution, including ALv2.

References :

LICENSE file

In Source distribution

This file contains :

  • the complete ALv2 license.
  • list dependencies and points to their respective license file
    • Example : This product bundles SuperWidget 1.2.3, which is available under a "3-clause BSD" license. For details, see deps/superwidget/
  • do not list dependencies under the ALv2
In binary distribution

// TODO

NOTICE file

In source distribution

The NOTICE file is not for conveying information to downstream consumers -- it is a way to compel downstream consumers to relay certain required notices.

In binary distribution

// TODO

License Headers

// TODO

Examples

Apache Lens:

Apereo:

Docassemble:

Tooling

nexB

nexB provides a set of tools to manage licenses and dependencies.

Licensed

Licensed helps to alert when a dependency license needs review

license-maven-plugin

This plugin helps to :

  • generate LICENCE file,
  • eventually generate NOTICE file (third-party-licenses).
  • bundle external licenses
  • generate license headers

maven-notice-plugin

This plugin helps to :

  • generate NOTICE file (third-party-licenses).

Maven-License-Verifier-Plugin

This plugin helps to :

  • fail build if licensing requirements are not met

Requirements are based on 4 license categories :

  • Forbidden
  • Valid
  • Missing
  • Unknown

Usage example

Valid and Forbidden licenses are defined in licenses.xml based on license name. Multiples names can be used to match a license.

Dependencies missing license are accepted by adding them in xml allowedMissingLicense.xml based on groupId and artifactId of the dependency.

Plugin goal can be used on the command line :

mvn se.ayoy.maven-plugins:ayoy-license-verifier-maven-plugin:verify

Or in a pom file : Parent pom

<plugin>
    <groupId>se.ayoy.maven-plugins</groupId>
    <artifactId>ayoy-license-verifier-maven-plugin</artifactId>
    <version>1.0.5</version>
    <executions>
        <execution>
            <phase>compile</phase>
            <goals>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <licenseFile>${project.parent.basedir}/licenses.xml</licenseFile>
        <excludedMissingLicensesFile>${project.parent.basedir}/allowedMissingLicense.xml</excludedMissingLicensesFile>
        <failOnForbidden>false</failOnForbidden>
        <failOnMissing>false</failOnMissing>
        <failOnUnknown>false</failOnUnknown>
    </configuration>
</plugin>

Child pom

<plugin>
    <groupId>se.ayoy.maven-plugins</groupId>
    <artifactId>ayoy-license-verifier-maven-plugin</artifactId>
</plugin>

license-compatibility-checker

Helps to check dependencies licenses present in node_modules. It outputs compatibility level with the current project, based on a matrix.

tldrlegal

Helps to give an overview of dependencies licenses.

apache2-license-checker

Helps to give an overview of dependencies licenses and compatibility with ALv2.

How to manage LICENSE file

// TODO - choose tool and provide instructions

How to manage NOTICE file

// TODO - choose tool and provide instructions

How to manage license headers

// TODO - choose tool and provide instructions

How to prevent a build with unwanted dependency

// TODO - choose tool and provide instructions

How to manage bundled distribution

// TODO - choose tool and provide instructions

Unresolved questions - HELP WANTED -

  • Should test dependencies be taken into account for source distribution ?
    • It appears to be YES
  • Should build time dependencies be taken into account ?
    • It appears to be NO but might depend on the actual stuff done by this dependency
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment