Currently there is no consistent policy for licenses allowed in the EIPs repository (aside from the EIP itself.) This is especially relevant for reference implementations.
Policy Options
There are three camps:
Please be aware that I am biased, so if I misrepresented your views below, call me out on it.
Simple, clearly unambiguous. Most permissive for implementers. Most restrictive for authors.
Allow non-copyleft open source assets
This is my view.
Assets may be any license that doesn’t impose significant restrictions on implementations. So this would allow MIT, Apache-2.0, and likely some others. It would, however, deny GPL-3.0 and BUSL-1.1.
More ambiguous (we’d need to maintain a list of approved licenses), but balances author vs. implementer interests.
Allow any license we can legally distribute, and allow linking to reference implementations we cannot distribute.
Also extremely unambiguous, provides authors the most flexibility, but doesn’t preserve our immutability/availability goals and can potentially create copyright traps.
While CC0 is optimal for the EIP, I feel it’s too restrictive for reference implementations.
I’d consider especially CC0 4.a stating “No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.”
IMHO (not a lawyer obviously) “No […] patent rights held by Affirmer are […] licensed” implies that I cannot be 100% sure when I use a reference implementation licensed under CC0, whether I will applicable to license fees under certain circumstances.
This was the prime reason why we decided to use MIT license (also used throughout OpenZeppelin) for the Reference Implementation in our ERC-6956. We wanted people to be able to freely use it, without having any second thoughts. Especially since for our edge-case there is a broad application range with physical products and smartphones involved etc. and as soon as things get beyond digital-only, you enter a patent landscape that’s hard to comprehend.
Thanks, although I believe I have another angle, which has not been discussed so far.
As responded in much more detail to your comment in PR 6956, we have a situation, where we do own patents that have at least similarities to the EIP and I want to be very clear that the EIP and reference implementation can be used freely and unrestricted by anyone. Yet, I do no want to grant a free, unlimited and world-wide license on any of our patents, as they cover much more than just what’s in the EIP and reference impl.
For the EIP I think CC0 still works, but I would argue that if we were to enforce CC0 for reference implementations and not allow any amendments, I would in my case not have the legal framework to ensure people it is safe to use our reference implementation here. That’s why the reference implementation must allow MIT, BSD or similar imo.
I don’t think the EIPs repository has the authority to stop you from additionally granting patent licenses If you wanted to dual license under CC0-1.0 and/or MIT, of course that’d be fine. I think @Pandapip1 just wants one of the options to be CC0-1.0 (though I may be misrepresenting his position.)
Well, that’s clear but I think I didn’t express myself clear enough .
I meant; I have a patent US1234, which is partly similar to the EIP. But the EIPs content is e.g. just one aspect, not the complete content of the patent. So I need to find a legal way, to license EIP + Reference Impl freely and unrestricted. But at the same time, it is not possible for me to say “With this EIP I grant you a license for US1234” - because the US1234 has other aspects beyond the EIP, which I do not need or want to waive.
Dual licensing works imo! I just thought the goal was to have CC0 mandated as in the verbatim Waiver in the EIP. That would’ve been an issue - but seems all is fine then. Thanks for the clarification
The current validation doesn’t allow any external linking at all. Is this conversation the right place to petition to allow external links in the Reference Implementation section? It would be hard to validate their license so I am in general pro allowing any reference impl.
When people link to an external implementation, it’s often their production implementation. It usually comes with a ton of stuff that isn’t directly related to the EIP itself, and often divides the functionality over several libraries. Simplicity and minimalism are rarely a primary concerns. A reference implementation for an EIP should be short and sweet, and help clear up any questions in the EIP.
@/Dexaran brought up an excellent concern with ERC-20. Having an external reference implementation right in the EIP gives the authors of that EIP an unfair advantage, since it looks like their implementation is the “official” one. Once the proposal goes to the Final status, it can no longer be updated, so no competing reference implementations can be added.
All that said, @xinbenlv has started a project over at https://ercref.org/ to provide a better source of reference implementations.
When people link to an external implementation, it’s often their production implementation. It usually comes with a ton of stuff that isn’t directly related to the EIP itself, and often divides the functionality over several libraries. Simplicity and minimalism are rarely a primary concerns. A reference implementation for an EIP should be short and sweet, and help clear up any questions in the EIP.
I completely agree with this.
The main purpose of the “reference implementation” is to be a demo of the proposal. It is supposed to answer questions of “how it should work” or “does the logic of that particular code match the logic described in the EIP”.
To find a production implementation the reader must use Google - this will allow for healthier competition among multiple potential implementers.
I don’t see any reason for a “reference implementation” to be a link at all. In my opinion it would be much better to write the code in the text of the EIP and make it CC0 licensed alongside the text.
I agree completely with the logic behind not allowing production implementations and think that there can be clear rules to enforce around this.
The idea and intention behind a reference implementation is difficult for ERC authors to fulfill without the ability to provide external links to github for example.
This is all the info in EIP-1 about reference implementations: “An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. This section may be omitted for all EIPs.”
This is a great initiative. At a certain point the reference implementations section is unnecessary. I’d propose doing one of the following:
deprecating the reference implementation section and pushing more towards initiatives like ercref
allowing external links to github with some restrictions such as permissive free licensing, not production implementations
editing EIP-1 and the eip-template to provide more clarity on the goals and parameters of the current reference implementation section. For example can it be pseudocode or inherit an unimplemented additional ERC that is abstracted in the reference.
If you wanted to dual license under 
.