Skip to content
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

Merged
merged 4 commits into from
May 7, 2018
Merged

Conversation

Mr0grog
Copy link
Contributor

@Mr0grog Mr0grog commented Apr 23, 2018

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.

License: MIT
Signed-off-by: Rob Brackett <[email protected]>
@ghost ghost assigned Mr0grog Apr 23, 2018
@ghost ghost added the status/in-progress In progress label Apr 23, 2018
@@ -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. :)

Mr0grog added a commit to ipfs-inactive/docs that referenced this pull request Apr 24, 2018
See new guidance at: ipfs/community#298

License: MIT
Signed-off-by: Rob Brackett <[email protected]>

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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

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
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.

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]>
@Mr0grog Mr0grog force-pushed the docs/licensing-policy branch from d1a4dda to f913e08 Compare May 3, 2018 18:21
@Mr0grog
Copy link
Contributor Author

Mr0grog commented May 3, 2018

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?


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?


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".

License: MIT
Signed-off-by: Rob Brackett <[email protected]>
@Mr0grog Mr0grog merged commit 47a4d2c into master May 7, 2018
@ghost ghost removed the status/in-progress In progress label May 7, 2018
@Mr0grog Mr0grog deleted the docs/licensing-policy branch May 7, 2018 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants