Licences for Assets / Reference Implementations in EIPs

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.

All assets must be CC0-1.0

This view is held by @Pandapip1.

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.

Unrestricted Reference Implemenations

This view is held by @xinbenlv and @gcolvin.

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.

Related Reading


Thank you for summarizing it, @SamWilsn !

My stance is generally: “we should make it easy for ERC authors to share reference implementations for educational purpose”.

On that basis, for the question I am happy with either of the following:

  1. Allow check-in a broad range of Open Source Licenses for RefImp code into asset folder
  2. Allow link to external reference implementations.

Disallowing both will make it super hard to share reference implementation and undermine the open standardization effort.

How broad is broad? Would you permit a license that allows viewing the reference implementation, but disallowed any derivative work?

If so, what is the point of such a reference implementation?

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.

We discussed this at some length in

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 :rofl: 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 :wink: .

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

Right, that makes sense.

Yep, that’s perfectly understandable. The requirements, today, of the EIPs repository are roughly:

  • Text of the EIP itself, including any inline code, MUST be available under CC0-1.0.
  • Files under the ../assets/eip-xxxx/ directory SHOULD be CC0-1.0, but MAY be a non-copyleft OSI approved license.

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.

We do allow some external links, and are open to more (following EIP-5757). You can see the full list of currently permitted origins in EIP-1.

Eh, it’s close enough :person_shrugging:

In addition to the reasoning behind prohibiting external links in general, there are a couple important concerns specific to external 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.

@/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 to provide a better source of reference implementations.

1 Like

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

With sufficiently complex standards, the reference implementations would get unwieldy to write in the file. was written purely as a reference for ERC-7540 and is over 100 lines of solidity without including the inherited ERC-4626 library which is an additional several hundred lines.

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.