-
Notifications
You must be signed in to change notification settings - Fork 226
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.
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
DRAFT: Document our licensing policy #298
Conversation
License: MIT Signed-off-by: Rob Brackett <[email protected]>
@@ -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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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. :)
See new guidance at: ipfs/community#298 License: MIT Signed-off-by: Rob Brackett <[email protected]>
docs/licensing-policy.md
Outdated
|
||
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-ShareAlike 4.0 International (CC BY-SA 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-sa/4.0/legalcode) and [plain text](https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt) can be found at the Creative Commons website. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be in favour of just CC-BY as it matches MIT well, it's without copyleft.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t have any particular opinion, but that certainly makes sense. It would be great to hear from more people which is preferable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I updated this to CC-BY since there was no other input.
docs/licensing-policy.md
Outdated
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-SA license is meant for projects that are not overwhelmingly code, such as websites, guidance, discussion repos, and so on. | ||
|
||
|
||
## Attaching a License |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
License: MIT Signed-off-by: Rob Brackett <[email protected]>
It turns out folks are really unhappy with how it works, so we don't want to recommend using it on new repos. We don't yet have a good replacement to recommend, though. License: MIT Signed-off-by: Rob Brackett <[email protected]>
d1a4dda
to
f913e08
Compare
OK, I’ve updated the non-code license to CC-BY (instead of CC-BY-SA) and removed the GitCop recommendations (nobody’s happy with it). Anything else this needs? |
docs/licensing-policy.md
Outdated
|
||
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.) |
There was a problem hiding this comment.
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?
docs/licensing-policy.md
Outdated
|
||
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**. |
There was a problem hiding this comment.
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".
License: MIT Signed-off-by: Rob Brackett <[email protected]>
This is based on discussion from #139, ipfs-inactive/faq#165, and ipfs/ipfs#319. In trying to get the docs repo all set, it seemed like we should have whatever the current policy is clearly documented.
Feel free to edit or change whatever doesn’t seem right here.