IPFS Specifications Licensing

[RichardLitt]

I think we should use the CC-BY-SA 4.0 International license. But I am not a lawyer.

[RichardLitt]

@jbenet Need your feedback here.

[vmx]

Why ShareAlike? Just CC-BY sounds more aligned with non-copyleft source licenses like MIT.

[Stebalien]

I'm mostly worried about proprietary extensions to the specs. Our primary concern with IPFS is adoption, hence the loose license. With the docs, we'd like to encourage people to modify and republish them as they see fit (books, tutorials, etc.). However, I don't see this happening with the specs and don't see any reason to encourage it. Any source code embedded in the specs should be licensed as permissively as possible (public domain as much as possible) but I don't see any reason to license the text in a similar manner.

[vmx]

@Stebalien In my opinion your argumentation for docs also holds true for specs. What if someone wants to publish a book which explains the spec in more detail? It would contain parts of the spec and hence make the whole book ShareAlike.

On more general note: As with many things (especially open source) I prefer doing opportunity management instead of risk management. Looking at the benefits of being more open rather then possible risks.

I personally don't see any risks, hence for me the opportunities outweigh.

[Stebalien]

It would contain parts of the spec and hence make the whole book ShareAlike.

Fair point. The specs are likely to become (or be included in) docs and we'd like to enable that. Furthermore, people will want to build proprietary protocols on-top of our protocols and, while I'd rather they didn't... adoption is our primary goal. We can always create non-proprietary protocols to compete with them as long as people are using the underlying tech.

I withdraw my objection. CC-BY sounds fine. Although, really, we should pick a license that covers IP like the IETF one but I don't know of a good one for text-documents off the top of my head.

Also, we probably need to go though the spec contributions and get a signoff.

On more general note: As with many things (especially open source) I prefer doing opportunity management instead of risk management. Looking at the benefits of being more open rather then possible risks.

You have to look at both. Flying is fun; hitting the ground afterwards is not.

[Mr0grog]

For what it’s worth, it seems like we are converging on CC-BY 4.0 as a general standard for non-code stuff over in ipfs/community#298. No reason specs have to follow that, of course, especially if better language around IP is especially important for these.

[techtonik]

I am not sure that forcing things with legal is about "consensus" that decentralized technology is about. As long as there is a community process and single point of reference (like this repo or GitLab repo) the copyright doesn't matter. If you need a reference as an IPFS author, give people link to your git history, if you want to force stop people from copying and modifying the spec for their proprietary products, then I better opt-out from this process. I value the work of individuals, not the work that is being resold to big corporates with this "copyright" stuff. CC0 and git history is my choice.

[techtonik]

I am not a contributor to this repo, so my voice doesn't count. =)

[lidel]

Ok, this feels like a mess we should clean up:

• Default policy for code is easy, MIT and Apache-2 dual license, as stated in: https://protocol.ai/blog/announcing-the-permissive-license-stack/

  • buuut https://github.com/ipfs/community/blob/master/LICENSING_POLICY.md only lists MIT, should be updated.

• Non-code, sadly, is all over the place:

  • https://github.com/ipfs/community/blob/master/LICENSING_POLICY.md suggests using CC BY 4.0 (no share-alike!) for "documentation" and "non-code"
    • but the docs.ipfs.io uses CC-BY-SA 4.0
    • Multiformats README uses CC-BY-SA 3.0
    • libp2p/specs have no license specified (??!) at all
    • 👉 When I was writing Gateway specifications I went with CC0, and that was used as a template, and we now have a bunch of specifications at https://specs.ipfs.tech under that.

@darobin I remember you mentioned other projects switching away from CC0 due to some edge case problems, do you remember the details? If we need to switch to CC-BY should it include SA, or can we relax it?

If we want to switch to something else, we should do it sooner than later + update https://github.com/ipfs/community/blob/master/LICENSING_POLICY.md to reflect that.