Repository navigation
IPFS Specifications Licensing #137
Description
Activity
@jbenet Need your feedback here.
Why ShareAlike? Just CC-BY sounds more aligned with non-copyleft source licenses like MIT.
Reacted by David Dias, John Meyer and Carlo van DriestenI'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.
@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.
Reacted by Cherian Paul and anatoly techtonikIt 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.
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.
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.
I am not a contributor to this repo, so my voice doesn't count. =)
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.
- https://github.com/ipfs/community/blob/master/LICENSING_POLICY.md suggests using CC BY 4.0 (no share-alike!) for "documentation" and "non-code"
@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.
-
- pinned this issue
on Jul 21, 2023 - changed the title
[-]Specifications Licensing[/-][+]IPFS Specifications Licensing[/+]on Jul 21, 2023 We use the Community Specification License in all of our working groups for UCAN, WNFS, IPVM, etc https://github.com/CommunitySpecification/Community_Specification/
@expede set this all up, including CLA bot to get sign off for things. This preps us for use by any major standards org.
Reacted by Brooklyn Zelenka and BumblefudgeFWIW W3C and its CGs use a custom license for specs and Apache-2 for all software contributions.
DIF, where I've long worked, gives individual WGs a wide array of choices of various licenses for specs, IPR regimes for meetings, and Apache-2 or MIT for all software:
(Src).I am extremely not a lawyer, but I don't think the licensing of the actual specs or sample implementations is actually the biggest attack vector-- what I suspect we really want is a PATENT POLICY that applies to any substantial contribution TO specs or implementations, which I believe would be covered by the Community Specification (which was invented recently to provide a more lightweight way achieving what the heavier, bespoke CLAs that DIF and W3C CGs use to protect their specs from covert/depth-charge patents)
But plus one to getting this sorted soon!
Yes. The community specifications cover both the open-ness of the spec as well as patents by participants.
Any of the CC options don't give us this coverage.
Whoa, you're having all the fun without me.
I don't recall the exact reasons why people moved away from CC0; the spec license debates in the web community were very painful and I have tried to forget as much as possible from them. I will say this, however: the WHATWG people used to be very intense about wanting CC0 and today they use "This work is licensed under a Creative Commons Attribution 4.0 International License. To the extent portions of it are incorporated into source code, such portions in the source code are licensed under the BSD 3-Clause License instead."
I certainly agree that a patent policy would be very good. I am sorry to say that I have misgivings about using the Community Specification license, however. Its entire revision history is three commits by two people, the most recent of which is over two years old. The entire review process seems to have been a total of six issues and one PR, three of which are typos and still open after six months. I found more typos just scanning through it. It seems to want to abstract away from typical WG processes, which is a good idea, but this leads it to make assumptions that I am not sure any random WG participant will understand. For instance, they have an “Approved Specification” that 1) has a direct impact on their patent licensing terms and 2) is linked to governance expectations. As described, this excludes all groups that work based on "Living Standards" (e.g. WHATWG, many CGs). It also creates a dependency between the validity of the licensing and running governance according to the rules they laid out. That's not a bad idea, but in order for it to work the governance of the groups has to actually match — I can imagine a lawyer tearing this apart by pointing out that e.g. issues weren't opened in the way described in the license or some such detail that participants would likely never think of.
It also seems to be making a bunch of claims about the output being appropriate for submission to an SDO — has anyone actually asked an SDO about that? I am not aware of the W3C looking at this, for instance.
Maybe I'm missing history and this is a lot more battle-tested than it looks like, but I would be hesitant to make it load-bearing without significantly more review.
Hi all,
I think the IPFS community is doing a great job at creating these specifications and I would absolutely love to work with them and encourage contribution. I am talking from my perspective as a test and validation expert in the automotive industry who is engaged in a lot of international standardization.The main points from my perspective are:
- The license should be as easy as possible and definitely NOT be a complex conditional construct or even a custom license. This triggers an absolute burocratic nightmare at every larger company. This here is a good example for a nightmare license
- Specifications cover concepts and code at the same time and should not use a license that is primarily used for publishing a power point presentation
- Licenses like the CC-BY-4.0 specifically exclude patents which e.g. lead to restrictions of use and contributions and trigger long investigations if the content is allowed to be used. They are not released for general/unrestricted use at larger companies.
- I would stick to a license which is already used in the ecosystem context. In this case MIT here for IPFS
- MPL 2.0 is often used as it shares the spirit of "redistribute your changes" and has a weak copy-left regarding changes made in the same file. I personally think that this covers the spirit of such specifications quite well BUT I would also say that a specification for common components and interfaces is useless without re-sharing. (MPL 2.0 would be fine for the re-use of specs in a book mentioned above btw)
In general I would say:
Don't overengineer in this discussion. Avoid the main pitfalls I have described. Take something permissive and clear to understand as you don't want to scare away people.My personal choice would be MIT
Best regards
CarloStatus after eight years, and the practice we drifted into is inconsistent rather than absent.
- Every IPIP ends with "Copyright and related rights waived via CC0", because
ipip-template.mdcarries that section. 21 of 22 IPIPs have it, along withtemplate.md,src/meta/ipip-process.mdandsrc/compact-denylist-format.md. - The normative specs do not. Path gateway, trustless gateway, subdomain gateway, UnixFS, IPNS record, Kademlia DHT and Routing V1 carry no notice at all.
- The repo has no LICENSE file, so GitHub reports no licence for it.
So a proposal is public domain, but the spec that comes out of it is not marked, which is backwards. Someone implementing from specs.ipfs.tech has nothing to rely on.
Two workable choices from the thread: CC0, which matches what the templates already do, or the Community Specification License that @bmann raised, which adds patent commitments at the cost of complexity. CC-BY 4.0 is the middle option WHATWG landed on. @jdsika's point holds in every case: one line at the top/bottom of each document, not a conditional construction.
This needs a decision from whoever stewards the repo (cc @mishmosh), then a mechanical pass to apply it and add a LICENSE. #395 is the same question and should close with this one.
- Every IPIP ends with "Copyright and related rights waived via CC0", because
I think we should use the CC-BY-SA 4.0 International license. But I am not a lawyer.