This document captures the general guidelines for contributing to open source projects hosted by ODPi. These guidelines express the provisions in the ODPi Intellectual Property Policy.
Note that each hosted project may adopt thier own guidelines, which would supercede these provisions in the case of conflict.
All source code must clearly identify the open source license used. Refer to the ODPi Intellectual Property Policy for the licenses the project supports without having a specific Board of Director waiver.
Requirements to ensure license compliance
- Each repository must contain a license file. Include the plain-text version of the license as a LICENSE file in the top-level directory of the repostiory.
- All source files need to include a header to clearly show the license. ODPi has standardized on including SPDX short-form license identifiers and a general copyright statement as shown below ( this example is for Apache 2.0 licensed code ):
/**
Copyright Contributors to the [NAME OF PROJECT] Project.
SPDX-License-Identifier: Apache-2.0
**/
For property or configuration files that do not support comments, the license may be omitted. If comments are supported the license header should be included.
Contributors may choose to include a copyright statement specifying themselves and/or their employer (as applicable) as the copyright holder of their contributions, but the ODPi does not require or recommend this.
Finally, please note that pre-existing third-party license notices and copyright notices should not be modified or removed by anyone other than the copyright holder. Any questions on including code under a different license than the project should be discussed with the project lead and ODPi Board of Directors.
We have tried to make it as easy as possible to make contributions. This applies to how we handle the legal aspects of contribution. We use the same approach — the Developer’s Certificate of Origin 1.1 (DCO) — that the Linux® Kernel community uses to manage code contributions.
We simply ask that when submitting a patch for review, the developer must include a sign-off statement in the commit message.
Here is an example Signed-off-by line, which indicates that the submitter accepts the DCO:
Signed-off-by: John Doe john.doe@hisdomain.com
You can include this automatically when you commit a change to your local git repository using git commit -s.
There are a number of great tools out there to manage DCO signoffs for developers to make it much easier to do signoffs.
- DCO command line tool, which let's you do a single signoff for an entire repo ( https://github.com/coderanger/dco )
- GitHub UI integrations for adding the signoff automatically ( https://github.com/scottrigby/dco-gh-ui )
When bringing in a code repository for the first time, or commits done before the DCO checks are enabled, there would be a series of commits that don't include the sign-off statement. You can retroactively signoff commits you've made by make a commit with your DCO signoff that contains a new text file ( suggested name is past_commits.txt ) with the following contents:
The following commits were made pursuant to the Developer Certificate of Origin, even though a Signed-off-by: was not included in the commit message.
<COMMIT HASH> <COMMIT MSG>
...
Each user who has made the past commits should have thier own Signed-off-by: line in the commit message.