Page tree
Skip to end of metadata
Go to start of metadata

Overview

To ensure that we have the legal right to distribute your contribution, the Foundation has three requirements for every contribution:

  1. Contributor License Agreement. Before contributing for the first time, every contributor (or their employer) must complete the appropriate contributor license agreement.
  2. License information. Projects and contributions must include certain license information, copyright notices, and other information.
  3. Third-party code compliance. Contributions that include third-party open source code must comply with applicable licenses and Foundation policies.

These requirements are ongoing and may require action beyond the initial contribution. (For example, if a project incorporates new third-party open source code at some point after the initial contribution, the license notices may need to be updated.)

Requirements for Contributions

Contributor License Agreement

Each contribution to a Foundation open source project must be covered by a contributor license agreement (CLA). This is a legal agreement granting the Foundation the necessary rights (under copyright and patent laws) to distribute the contribution.

If your employer owns the rights to your contributions, you should submit a Corporate Contributor License Agreement (CCLA) (PDF) signed by an authorized representative of your employer.

If you alone own the rights to your contributions, you should sign and submit an Individual Contributor License Agreement (ICLA) (PDF).

If you change jobs after contributing to the Foundation under your previous employer's CCLA, please notify the Foundation so that we can ensure that an appropriate CLA is in place with you or your new employer.

If your employer required you to sign an "employee invention assignment agreement" or similar terms when you were hired, it is possible that your employer owns the copyright even if the contribution was developed on your own time. If you have any question about which CLA you should submit, please contact us.

License Information

All Foundation projects must include certain license information and copyright notices. If you are contributing a new project, you must include LICENSENOTICE, and CONTRIBUTING files, as described below. If you are contributing to an existing project, you may need to add information to the NOTICE or CONTRIBUTING file.

The LICENSE file

LICENSE file must be present at the root of each project, and must contain the text of the Apache License, Version 2.0.

The NOTICE file

A NOTICE file must be present at the root of each project, and must contain the copyright notices of each copyright holder who has contributed to the project. If you are contributing to an existing project, you should add (or update) your copyright notice in the NOTICE file.  It must also contain any other attributions required by third-party dependencies (see below).  

You should use this template for your NOTICE file:

NOTICE Template
[PROJECT_NAME] - Symphony Software Foundation
Copyright [XXXX-XXXX] [Copyright holder 1 - name and email]
Copyright [XXXX-XXXX] [Copyright holder 2 - name and email]
...
Copyright [XXXX-XXXX] [Copyright holder N - name and email]

This product includes software developed at the Symphony Software Foundation (http://symphony.foundation).

[Other notices, as necessary]
Because contributions are licensed (not assigned) to the Foundation under our CLAs, contributors retain copyright to their work. Therefore, your copyright notice should identify yourself (or your employer) as the copyright holder, and not the Foundation.

The CONTRIBUTING file

The CONTRIBUTING file contains basic instructions to prospective contributors about how to make a contribution to the project – submitting a CLA, filing issues, making pull requests, etc. A sample CONTRIBUTING.md file (in Markdown) is provided below. Project leads are free to revise to fit the practices and style of the project, but references to the Foundation's contribution requirements must be included.

Please note that Github will prompt this content when a user creates an issue or pull request, you can read more on Github Contributing Guidelines

CONTRIBUTING.md Example
# Contributing to [project name]
Thanks for your interest in the project! Here is some basic information about how to contribute.

# Contributor License Agreement (CLA)
All contributions to [Symphony Software Foundation](https://symphony.foundation/) projects must be made under a [Contributor License Agreement](https://symphonyoss.atlassian.net/wiki/display/FM/Legal+Requirements#LegalRequirements-ContributorLicenseAgreement) that authorizes the Foundation to distribute your code under the Apache License. Contributions must also meet the Foundation's [license and notice requirements](https://symphonyoss.atlassian.net/wiki/display/FM/Legal+Requirements) that must also be met.

Pull requests (PRs) submitted to the project cannot be accepted until you have a CLA in place with the Foundation.

# Contributing Issues

## Prerequisites

* [ ] Have you searched for duplicate issues?  A simple search for exception error messages or a summary of the unexpected behavior should suffice.
* [ ] Are you running the latest release of the project?

## Raising an Issue
* Create your issue in the project issue tracker.
* New issues contain two templates in the description: bug report and enhancement request. Please pick the most appropriate for your issue, and delete the other.
  * Please also tag the new issue with either "Bug" or "Enhancement".
* Please use [Markdown formatting](https://help.github.com/categories/writing-on-github/)
liberally to assist in readability.
  * [Code fences](https://help.github.com/articles/creating-and-highlighting-code-blocks/) for exception stack traces and log entries, for example, massively improve readability.

# Contributing Pull Requests (Code & Docs)
To make review of PRs easier, please:

 * Please make sure your PRs will merge cleanly - PRs that don't are unlikely to be accepted.
 * For code contributions, follow the general structure of the existing code.
 * For documentation contributions, follow the general structure, language, and tone of the existing docs.
 * Keep PRs small and cohesive - if you have multiple contributions, please submit them as independent PRs.
 * Reference issue #s if your PR has anything to do with an issue (even if it doesn't address it).
 * Minimize non-functional changes (e.g. whitespace shenanigans).
 * Ensure all new files include a header comment block containing the [Apache License v2.0 and your copyright information](http://www.apache.org/licenses/LICENSE-2.0#apply).
 * If necessary (e.g. due to 3rd party dependency licensing requirements), update the NOTICE file with any required attribution or other notices
 * If your contribution includes source code for any Category B-licensed dependencies, add an appropriate notice to this CONTRIBUTING file


[Optional -- include if the repository contains Category B-licensed source code]
# Licensing Matters
This project contains source code for [SuperWidget 1.2.3], which is licensed under [the Mozilla Public License, version 1.1]. For details, see [lib/superwidget/].
[/Optional]


Source code license headers

Each source code file should include a license header comment, containing the following text:

Copyright [yyyy] [project name] [developers]
SPDX-License-Identifier: Apache-2.0

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

SPDX information

We encourage project teams to place a SPDX-format LICENSE.spdx file in the root of each project. SPDX is a standard for describing machine-readable license information about open source projects. For more information on SPDX, please see the SPDX website. See below for a basic example LICENSE.spdx file. For a tutorial on adding SPDX information to a project, see here.

LICENSE.spdx Example
SPDXVersion: SPDX-2.1
DataLicense: CC0-1.0
Creator: John Smith (jsmith@acme.com)
PackageName: bot-example
PackageOriginator: John Smith (jsmith@acme.com)
PackageHomePage: https://github.com/symphonyoss/bot-example
PackageLicenseDeclared: Apache-2.0

Third-Party Code Compliance

If your contribution includes any third-party open source code, the license for that code must permit its use within an Apache-licensed project, and the Foundation's use of the code must comply with the terms of the third-party license.

Identifying acceptable licenses

All Foundation projects must be licensed under the Apache License, Version 2.0 and the license for any third-party code must be compatible with this requirement. The Foundation categorizes open source licenses in the same way as the Apache Software Foundation:

  1. Category A licenses have similar terms to the Apache License. Contributions to the Foundation can include (or depend upon) code licensed under Category A licenses. Examples: common variants of the BSD and MIT licenses; the Apache License.
  2. Category B licenses impose restrictions on downstream use of the third-party code, but permit the code to be included in an Apache-licensed project. Typically, these are "weak copyleft" licenses requiring that modifications to the third-party code be licensed "reciprocally" under the same license. Contributions can include (or depend upon) Category B code, but if the code itself is included with the contribution, you should include a notice in the CONTRIBUTING file as described below. Examples: the CDDL, EPL, and MPL licenses.
  3. Category X licenses impose restrictions that prevent the code from being included in an Apache-licensed project. Because all Foundation projects must be Apache-licensed, the Foundation does not accept contributions with Category X dependencies. Examples: most proprietary licenses; any version of the GPL, LGPL, or AGPL; Creative Commons Non-Commercial and No-Derivatives licenses.

The Foundation analyzes all contributions to determine the license of each dependency and works with contributors to resolve any incompatibilities, so contributors do not need to carefully research each dependency before contributing. But because all incompatibly licensed dependencies must be removed before the Foundation can accept a contribution, contributors should take care to avoid them during development.

Including required third-party notices

Depending how your contribution uses third-party open source software, you may need to add notices to the project you're contributing to.

If your contribution contains third-party code directly (i.e. not via an import or similar reference resolved by the build system or interpreter) you must include a copy of the applicable license and preserve any copyright notices, license information, disclaimers, and similar notices in the third-party code. You should also add a notice in the following form to the project's NOTICE file:

This project includes code from SuperWidget 1.2.3, which is licensed under a BSD-style license. For details, see lib/superwidget/.

If you have a LICENSE.spdx file in your repository, you should also update the PackageLicenseDeclared setting to use the appropriate SPDX license expression for your "mixed license" repository.

If your contribution contains Category B-licensed code directly, you must also add a notice in the following form to the project's CONTRIBUTING file:

This project contains source code for SuperWidget 1.2.3, which is licensed under the Mozilla Public License, version 1.1. For details, see lib/superwidget/.

The purpose of this notice is to make contributors aware that their modifications to the Category B code will be governed by the terms of the Category B license.

If the third-party license requires specific notices, you must add them to the NOTICE file. For example, some open source licenses require that you include a description of any modifications made to the third-party code.

Validating license and notice information

When you make a contribution, the Foundation attempts to validate compliance with these requirements automatically using our Contrib Toolbox project. Contrib Toolbox checks for LICENSE and NOTICE files and, using the license information provided by build tools, attempts to validate that the licenses for any dependencies are acceptable Category A or Category B licenses. However, no automated tool can resolve these questions definitively, so we depend upon our contributors to provide complete and accurate information.

  • No labels