Skip to content

Latest commit

 

History

History
45 lines (27 loc) · 2.91 KB

licensing.md

File metadata and controls

45 lines (27 loc) · 2.91 KB

Licensing Policy

This document describes source{d}'s licensing policy for the open source projects.

All the projects developed or being developed by source{d} should be open source and follow the rules presented below.

Templates are available at the end of this document.

Licence

At the time of creating a new project you can choose between two different licenses:

  • GPL v3.0, applied to all projects whose nature is specific to core parts of our stack like language analysis, machine learning, etc. and which are mostly applications and are intended to be consumed through a separate client library owned by us. This allows clean interaction to third-party proprietary code. Examples: bblfsh/server, bblfsh/*-driver

  • Apache License 2.0, this license should be applied to projects which are libraries or tools that are intended to be consumed by third-parties as source code dependencies, which the GPLv3 and variants doesn't allow (if consumers are not GPL). Examples: bblfsh/*-client

  • Creative Commons BY-SA 4.0, this license should be applied to projects which are heavy on creative content, have creative content as their key aspect, or are purely editorial content (creative content as in information and knowledge that is not in form of code). Examples: src-d/blog, src-d/awesome-machine-learning-on-source-code

Variants of GPLv3, such as AGPLv3 or LGPLv3 can be used under request and on a per case basis.

Re-license

When a piece of code is copied between two or more source{d} projects covered by different licenses, source{d} employees are entitled to relicense the code as needed among those projects, if all the code was written by source{d} employees. THIS CANNOT BE DONE WITH 3RD PARTY CODE.

Developer Certificate of Origin

All our projects should include a Developer Certificate of Origin (DCO) document to protect us against any individual contributor revoking our rights to distribute their contribution to any of our projects.

In practice, this means that every commit since the introduction of the DCO, should be signed off by the author, using git commit -s. Being irrelevant if the author is a source{d} employee or an individual contributor.

To learn more about DCO please read:

Templates