Skip to content

DRAFT: Document our licensing policy #298

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
May 7, 2018
Merged

DRAFT: Document our licensing policy #298

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
200a242
Document our licensing policy
Mr0grog Apr 23, 2018
ee7031e
Change CC-BY-SA license to CC-BY for docs
Mr0grog May 3, 2018
f913e08
Remove recommendation to set up GitCop
Mr0grog May 3, 2018
68f2fc0
Ensure "Inc." is always followed by a period
Mr0grog May 7, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions docs/licensing-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# IPFS Licensing Policy

In order to ensure an open source project is actually open and re-usable in a legal sense, it’s critical that licensing information is clear. Repositories in the `ipfs`, `libp2p`, and `ipld` organizations should all follow this policy for licensing their contents.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wasn’t sure if ipfs-shipyard should be included here, too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. Shipyard includes projects that often originated outside of the org and may have custom licenses due to historical reasons.
For example ipfs-shipyard/ipfs-companion is CC0 (it was originally a hobby project of mine, we've moved it to IPFS Org about a year or two after inception).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it’s worth, I don’t know if existing repos really need to change (it might be nice to make them all consistent, though). I also definitely hear that a lot of shipyard projects might not start as PL projects, so it seems reasonable that they could have differing licenses. :)


Unless there is a particular reason to use a different licensing structure, please use the following for new projects:

1. Copyright should always be assigned to **Protocol Labs, Inc,** regardless of the type of license. (In an ideal future, we can assign copyright to a foundation, but Protocol Labs is the best usable legal entity we have now.)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the comma after "Inc" be a full stop?


2. All software code should be licensed under the MIT license. Canonical license text for the MIT license can be found in this repository’s [`LICENSE` file](../LICENSE) or at the [Open Source Initiative website](https://opensource.org/licenses/MIT).

2. All documentation and non-code resources (e.g. logos and imagery) should be licensed under the Creative Commons Attribution 4.0 International (CC BY 4.0) license. An [easy-to-read, linkable description](https://creativecommons.org/licenses/by-sa/4.0/) and canonical license text in [HTML](https://creativecommons.org/licenses/by/4.0/legalcode) and [plain text](https://creativecommons.org/licenses/by/4.0/legalcode.txt) can be found at the Creative Commons website.

If a repository is a software project with some built-in docs or resources (e.g. `go-ipfs`), it can all be licensed under the MIT license. The CC BY license is meant for projects that are not overwhelmingly code, such as websites, guidance, discussion repos, and so on.


## Attaching a License
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just an idea: it may be super helpful if we had some form of license validation/automation that could be dropped into existing release pipelines to check if things mentioned in this section are valid on every build.

Most of our projects is in JS and Golang. aegir could provide script for that out-of-the-box, something similar could be created for Golang as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could definitely be useful, but I think it might be a little out-of-scope here:

  • We need to agree on a clear policy before we can validate that something fits the policy :)
  • There are at least a few open questions that would need to be answered to build that tool. I think we should be careful not to let that derail just agreeing on a policy:
    • There will always need to be some exceptions to that policy, so you’ve got to figure out how any given tool will handle that.
    • What’s validatable here? The suggested README language is intentionally only a suggestion; there are lots of other good ways to word it.
    • What about repos that don’t have a build process? (e.g. ipfs/ipfs)
    • What about https://project-repos.ipfs.io ?

Maybe this particular discussion is better in a separate issue?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lidel Language independent things like a license could also be checked on a repository level with some bot checking things (like ci-sync. I wouldn't put it into AEgir.


When licensing a project, be sure to:

1. Name the the license and provide a link to it from the project README under the heading “license.” Example:

```md
## License

Copyright (c) Protocol Labs, Inc. under the **<LICENSE NAME>**. See [LICENSE file](./LICENSE) for details.
```

Or for multiple licenses:

```md
## License

All software code is copyright (c) Protocol Labs, Inc. under the **MIT license**.

Other written documentation and content (c) Protocol Labs, Inc under the **Creative Commons Attribution License**.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing full stop after "Inc".


See [LICENSE file](./LICENSE) for details.
```

2. For software that will be redistributed, the full text of the license(s) **must** be in a file named `LICENSE` in the repository root. Other projects **should** do this, too, but their readmes can alternatively link to a separate license document, like this: [Creative Commons Attribution](https://creativecommons.org/licenses/by/4.0/).


## Contributor Licensing (DCO)

We manage contributor licensing via a *Developer Certificate of Origin (DCO).* All commits with new code from any contributor **must** include a DCO signoff trailer. See the [contributing guide part 2](../CONTRIBUTING-2.md#a-license-and-a-signed-off-by-trailers-are-required) for more details. Commits with extremely trivial or changes or that do not change content (e.g. merge commits) are excepted.

If you’re setting up a new repository, make sure the README includes a link to our contribution guidelines so people can find information about the DCO signoff.